| From: | * Neustradamus * <neustradamus(at)hotmail(dot)com> |
|---|---|
| To: | Jacob Champion <jacob(dot)champion(at)enterprisedb(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>, Nico Williams <nico(at)cryptonector(dot)com> |
| Subject: | Re: RFC 9266: Channel Bindings for TLS 1.3 support |
| Date: | 2025-11-21 08:49:25 |
| Message-ID: | AS8PR10MB74274EE18745F46F4AA762EBCBD5A@AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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 several RFCs):
- 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 Binding since 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/libraries with 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(dot)champion(at)enterprisedb(dot)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(at)hotmail(dot)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/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shveta malik | 2025-11-21 09:10:14 | Re: Improve pg_sync_replication_slots() to wait for primary to advance |
| Previous Message | Heikki Linnakangas | 2025-11-21 08:46:02 | Re: RFC 9266: Channel Bindings for TLS 1.3 support |