Re: RFC 9266: Channel Bindings for TLS 1.3 support - Mailing list pgsql-hackers

From * Neustradamus *
Subject Re: RFC 9266: Channel Bindings for TLS 1.3 support
Date
Msg-id AS8PR10MB74274EE18745F46F4AA762EBCBD5A@AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: RFC 9266: Channel Bindings for TLS 1.3 support  (Jacob Champion <jacob.champion@enterprisedb.com>)
List pgsql-hackers
Dear Jacob Champion,

Thanks for your answer.

Links of XEPs are here to confirm that "tls-exporter" is needed and already used.

XEPs are already supported by a lot of projects/softwares/companies in production, for example on GitHub, we can see:
- https://github.com/search?q=XEP-0480+-repo%3Axsf%2Fxeps+-repo%3Axsf%2Fxep-attic+-repo%3Axsf%2Fxmpp.org&type=code
- https://github.com/search?q=XEP-0388+-repo%3Axsf%2Fxeps+-repo%3Axsf%2Fxep-attic+-repo%3Axsf%2Fxmpp.org&type=code
- https://github.com/search?q=XEP-0440+-repo%3Axsf%2Fxeps+-repo%3Axsf%2Fxep-attic+-repo%3Axsf%2Fxmpp.org&type=code
- https://github.com/search?q=XEP-0474+-repo%3Axsf%2Fxeps+-repo%3Axsf%2Fxep-attic+-repo%3Axsf%2Fxmpp.org&type=code

XEP-0001 specify "Experimental" states:
- https://xmpp.org/extensions/xep-0001.html#states-Experimental

At the same time, about these XEPs, it is the base of the "draft-melnikov-sasl2" done by Alexey Melnikov (author of
severalRFCs): 
- https://datatracker.ietf.org/doc/html/draft-melnikov-sasl2
- https://datatracker.ietf.org/person/Alexey%20Melnikov

I have informed several projects about SCRAM-SHA-*, SCRAM-SHA-*-PLUS (SCRAM-SHA-* with Channel Binding), and Channel
Bindingsince a very long time. 
The support of different SCRAM versions and/or different Channel Binding versions have been added in a lot of
projects/softwares/librarieswith success. 
Of course, it is not yet perfect everywhere.
The security is important.

Other GitHub searches in code (Good commented source codes are good):
- tls-server-end-point: https://github.com/search?q=tls-server-end-point&type=code
- tls-exporter: https://github.com/search?q=tls-exporter&type=code
- rfc5929: https://github.com/search?q=rfc5929&type=code
- rfc9266: https://github.com/search?q=rfc9266&type=code
- rfc 5929: https://github.com/search?q=%22rfc+5929%22&type=code
- rfc 9266: https://github.com/search?q=%22rfc+9266%22&type=code

For more informations to all, I can add Wikipedia links about Salted Challenge Response Authentication Mechanism
(SCRAM)and Channel Binding: 
- https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism
- https://en.wikipedia.org/wiki/Salted_Challenge_Response_Authentication_Mechanism#Channel_binding

Note: Channel Binding is not only linked to SCRAM.

Regards,

Neustradamus

________________________________________
From: Jacob Champion <jacob.champion@enterprisedb.com>
Sent: Thursday, November 20, 2025 22:52
To: * Neustradamus *
Cc: PostgreSQL Hackers
Subject: Re: RFC 9266: Channel Bindings for TLS 1.3 support

On Thu, Nov 20, 2025 at 12:59 PM * Neustradamus *
<neustradamus@hotmail.com> wrote:
> In 2022, I have contacted PostgreSQL team about Channel Binding:
> - https://www.postgresql.org/search/?m=1&q=tls-exporter&l=&d=-1&s=i

There was some initial work there [1], but we'd still need to figure
out channel binding negotiation, which seems like something we should
not be on the bleeding edge of.

I still wish we'd made endpoint binding opt-in, but that's water under
the bridge. The binding "infrastructure", such as it is, isn't really
in a healthy place right now (as you've seen [2]), and I think we need
SASL to give us additional agility before we can really make progress.

> We are in 2025, I relaunch the subject because several developers always say me: "it is not supported by PostgreSQL".

...who says that?

> - XEP-0474: SASL SCRAM Downgrade Protection: https://xmpp.org/extensions/xep-0474.html

That says
    WARNING: This Standards-Track document is Experimental.
Publication as an XMPP Extension Protocol does not imply approval of
this proposal by the XMPP Standards Foundation.
and
    In the long term the author strives to publish this as an RFC
rather than a XEP to also make this protection available to other
protocols, after gaining implementation experience.
and
    If [an RFC is published for this] implementations SHOULD NOT
implement this XEP and SHOULD implement the superseding RFC instead.

So we should probably not implement production features based on it.

> Linked to:
> - Channel Binding: https://github.com/scram-sasl/info/issues/1

(Looks like you're on thin ice with several of the projects listed
there. Please treat other OSS communities with respect, and don't spam
their repositories.)

Thanks,
--Jacob

[1] https://postgr.es/m/YwxWWQR6uwWHBCbQ%40paquier.xyz
[2] https://mailarchive.ietf.org/arch/msg/kitten/zpesKSHsiuy1RvhPlbSUGajLbKQ/

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: RFC 9266: Channel Bindings for TLS 1.3 support
Next
From: shveta malik
Date:
Subject: Re: Improve pg_sync_replication_slots() to wait for primary to advance