Re: RFC 9266: Channel Bindings for TLS 1.3 support

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
--

In response to

Browse pgsql-hackers by date

  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