| From: | Nico Williams <nico(at)cryptonector(dot)com> |
|---|---|
| To: | * Neustradamus * <neustradamus(at)hotmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "alexey(dot)melnikov(at)isode(dot)com" <alexey(dot)melnikov(at)isode(dot)com>, Simon Josefsson <simon(at)josefsson(dot)org> |
| Subject: | Re: RFC 9266: Channel Bindings for TLS 1.3 support |
| Date: | 2025-11-23 06:16:56 |
| Message-ID: | aSKm2BqNm0gP4Lkm@ubby |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Nov 23, 2025 at 01:44:18AM +0000, * Neustradamus * wrote:
> Links of XEPs are here to confirm that "tls-exporter" is needed and
> already used.
How are XEPs relevant to PG?
> Several people would like to deprecate "tls-server-end-point" (RFC
> 5929) like Simon Josefsson (author of several RFCs), that you know of
> course, because RFC 9266 exists since July 2022:
I responded to that. Simon did not respond to my last message. Silence
might denote acquiescence, or it might not, but at any rate there is
currently no effort to obsolete TSEP.
> For example, he is the GNU SASL maintainer and he does not want to add
> tls-server-end-point support:
That's his right.
> So it is really important to support "tls-exporter".
I don't disagree with that. It's not because TSEP might get obsoleted.
One issue that arises is that if you support more than one kind of CB
then you need to be able to negotiate it (for some value of negotiation
anyways; if the server doesn't want the client's choice, you can just
fail, but de minimis you really need to be able to tell the user why
authentication failed).
Nico
--
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ocean_li_996 | 2025-11-23 06:33:14 | Re:Re: [BUG] Incorrect historic snapshot may be serialized to disk during fast-forwarding |
| Previous Message | ocean_li_996 | 2025-11-23 06:05:05 | Re:Fix logical decoding not track transaction during SNAPBUILD_BUILDING_SNAPSHOT |