RFC 9266: Channel Bindings for TLS 1.3 support

On 20/11/2025 22:58, * Neustradamus * wrote:

Dear PostgreSQL team, dear all,

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

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

Can you add the support of RFC 9266: Channel Bindings for TLS 1.3?
- https://datatracker.ietf.org/doc/html/rfc9266

I think that would be great. Patches are welcome!

The tricky part is probably going to be to make the protocol changes in
a way that is both backwards-compatible and as secure as possible. But
I'm sure it can be done.

Channel Bindings for TLS: https://datatracker.ietf.org/doc/html/rfc5929

- XEP-0388: Extensible SASL Profile: https://xmpp.org/extensions/xep-0388.html
- XEP-0440: SASL Channel-Binding Type Capability: https://xmpp.org/extensions/xep-0440.html
- XEP-0474: SASL SCRAM Downgrade Protection: https://xmpp.org/extensions/xep-0474.html
- XEP-0480: SASL Upgrade Tasks: https://xmpp.org/extensions/xep-0480.html

Little details, to know easily:
- tls-unique for TLS =< 1.2 (RFC5929)
- tls-server-end-point =< 1.2 + 1.3 (RFC5929)
- tls-exporter for TLS = 1.3 (RFC9266)

After the jabber.ru MITM, it is time to add it:
- https://notes.valdikss.org.ru/jabber.ru-mitm/
- https://snikket.org/blog/on-the-jabber-ru-mitm/
- https://www.devever.net/~hl/xmpp-incident
- https://blog.jmp.chat/b/certwatch/certwatch

PostgreSQL does support channel binding, with tls-server-end-point. I
believe that sufficient to prevent an attack like that. (Assuming that
it's configured correctly, but that's an issue of insecure defaults
rather than a missing feature).

What are the benefits of tls-exporter over tls-server-end-point? I agree
it would be good to support tls-exporter, since RFC9266 specifies it as
mandatory for channel binding over TLS 1.3. But aside from the RFC, is
there some practical difference?

- Heikki

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&amp;q=tls-exporter&amp;l=&amp;d=-1&amp;s=i

There was some initial work there [1]/messages/by-id/YwxWWQR6uwWHBCbQ@paquier.xyz, 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]https://mailarchive.ietf.org/arch/msg/kitten/zpesKSHsiuy1RvhPlbSUGajLbKQ/), 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]: /messages/by-id/YwxWWQR6uwWHBCbQ@paquier.xyz
[2]: https://mailarchive.ietf.org/arch/msg/kitten/zpesKSHsiuy1RvhPlbSUGajLbKQ/

On Thu, Nov 20, 2025 at 1:52 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:

PostgreSQL does support channel binding, with tls-server-end-point. I
believe that sufficient to prevent an attack like that.

No, IIRC unique bindings (-unique and -exporter) prevent MITM even if
the attacker has the server's private key, as long as they do not also
possess the SCRAM verifiers. tls-server-end-point does not prevent
against that (so you can terminate TLS on a different node from the
verifiers).

--Jacob

Dear Heikki,

Thanks for your answer.

Several people would like to deprecate "tls-server-end-point" (RFC 5929) like Simon Josefsson (author of several RFCs) because RFC 9266 exists since July 2022:
- https://mailarchive.ietf.org/arch/msg/kitten/zpesKSHsiuy1RvhPlbSUGajLbKQ/
- https://datatracker.ietf.org/person/Simon%20Josefsson

For example, he is the GNU SASL maintainer and he does not want to add tls-server-end-point support:
- https://gitlab.com/gsasl/gsasl/-/issues/13

Other talks about tls-server-end-point:
- https://mailarchive.ietf.org/arch/browse/kitten/?q=tls-server-end-point&amp;gbt=1&amp;index=
- https://mail.jabber.org/hyperkitty/search?count=200&amp;q=tls-server-end-point&amp;page=1&amp;mlist=standards%40xmpp.org&amp;sort=date-asc
- https://mailarchive.ietf.org/arch/browse/tls/?q=tls-server-end-point&amp;gbt=1&amp;index=

So it is really important to support "tls-exporter".

Regards,

Neustradamus

________________________________________
From: Heikki Linnakangas <hlinnaka@iki.fi>
Sent: Thursday, November 20, 2025 22:52
To: * Neustradamus *; PostgreSQL Hackers
Subject: Re: RFC 9266: Channel Bindings for TLS 1.3 support

On 20/11/2025 22:58, * Neustradamus * wrote:

Dear PostgreSQL team, dear all,

In 2022, I have contacted PostgreSQL team about Channel Binding:
- https://www.postgresql.org/search/?m=1&amp;q=tls-exporter&amp;l=&amp;d=-1&amp;s=i

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

Can you add the support of RFC 9266: Channel Bindings for TLS 1.3?
- https://datatracker.ietf.org/doc/html/rfc9266

I think that would be great. Patches are welcome!

The tricky part is probably going to be to make the protocol changes in
a way that is both backwards-compatible and as secure as possible. But
I'm sure it can be done.

Channel Bindings for TLS: https://datatracker.ietf.org/doc/html/rfc5929

- XEP-0388: Extensible SASL Profile: https://xmpp.org/extensions/xep-0388.html
- XEP-0440: SASL Channel-Binding Type Capability: https://xmpp.org/extensions/xep-0440.html
- XEP-0474: SASL SCRAM Downgrade Protection: https://xmpp.org/extensions/xep-0474.html
- XEP-0480: SASL Upgrade Tasks: https://xmpp.org/extensions/xep-0480.html

Little details, to know easily:
- tls-unique for TLS =< 1.2 (RFC5929)
- tls-server-end-point =< 1.2 + 1.3 (RFC5929)
- tls-exporter for TLS = 1.3 (RFC9266)

After the jabber.ru MITM, it is time to add it:
- https://notes.valdikss.org.ru/jabber.ru-mitm/
- https://snikket.org/blog/on-the-jabber-ru-mitm/
- https://www.devever.net/~hl/xmpp-incident
- https://blog.jmp.chat/b/certwatch/certwatch

PostgreSQL does support channel binding, with tls-server-end-point. I
believe that sufficient to prevent an attack like that. (Assuming that
it's configured correctly, but that's an issue of insecure defaults
rather than a missing feature).

What are the benefits of tls-exporter over tls-server-end-point? I agree
it would be good to support tls-exporter, since RFC9266 specifies it as
mandatory for channel binding over TLS 1.3. But aside from the RFC, is
there some practical difference?

- Heikki

On 20/11/2025 23:59, Jacob Champion wrote:

On Thu, Nov 20, 2025 at 1:52 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:

PostgreSQL does support channel binding, with tls-server-end-point. I
believe that sufficient to prevent an attack like that.

No, IIRC unique bindings (-unique and -exporter) prevent MITM even if
the attacker has the server's private key, as long as they do not also
possess the SCRAM verifiers. tls-server-end-point does not prevent
against that (so you can terminate TLS on a different node from the
verifiers).

If I understood the incident correctly, the attacker managed to somehow
obtain a valid TLS certificate for the victim domain. They used that to
perform a MITM attack. They did not have the server's private key. (Or
if they did, they did not use that for the attack).

That's an advantage in general though, even if it wouldn't have made a
difference in this instance. So fair point.

- Heikki

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&amp;type=code
- https://github.com/search?q=XEP-0388+-repo%3Axsf%2Fxeps+-repo%3Axsf%2Fxep-attic+-repo%3Axsf%2Fxmpp.org&amp;type=code
- https://github.com/search?q=XEP-0440+-repo%3Axsf%2Fxeps+-repo%3Axsf%2Fxep-attic+-repo%3Axsf%2Fxmpp.org&amp;type=code
- https://github.com/search?q=XEP-0474+-repo%3Axsf%2Fxeps+-repo%3Axsf%2Fxep-attic+-repo%3Axsf%2Fxmpp.org&amp;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&amp;type=code
- tls-exporter: https://github.com/search?q=tls-exporter&amp;type=code
- rfc5929: https://github.com/search?q=rfc5929&amp;type=code
- rfc9266: https://github.com/search?q=rfc9266&amp;type=code
- rfc 5929: https://github.com/search?q=%22rfc+5929%22&amp;type=code
- rfc 9266: https://github.com/search?q=%22rfc+9266%22&amp;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&amp;q=tls-exporter&amp;l=&amp;d=-1&amp;s=i

There was some initial work there [1]/messages/by-id/YwxWWQR6uwWHBCbQ@paquier.xyz, 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]https://mailarchive.ietf.org/arch/msg/kitten/zpesKSHsiuy1RvhPlbSUGajLbKQ/), 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]: /messages/by-id/YwxWWQR6uwWHBCbQ@paquier.xyz
[2]: https://mailarchive.ietf.org/arch/msg/kitten/zpesKSHsiuy1RvhPlbSUGajLbKQ/

On Fri, Nov 21, 2025 at 12:46 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:

If I understood the incident correctly, the attacker managed to somehow
obtain a valid TLS certificate for the victim domain. They used that to
perform a MITM attack. They did not have the server's private key. (Or
if they did, they did not use that for the attack).

Oh! Thank you for pointing that out. Yeah, having the private key for
*a* host certificate shouldn't help you if it doesn't have the same
public fingerprint as the one in use at the peer. (I'm not sure I
really internalized that distinction before.)

--Jacob

On Fri, Nov 21, 2025 at 12:49 AM * Neustradamus *
<neustradamus@hotmail.com> wrote:

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

Right, but even that draft says

All of the features below are optional (in order to remain backward
compatible with RFC 4422). However if any is implemented, all of
them MUST be implemented in a protocol. This makes client
implementations easier.

So even if we were to charge ahead and assume that the XEP
implementation is exactly what's going to be standardized in a future
version of SASL, we're still introducing interoperability pain if we
don't do other currently-experimental things too.

In the past, we've said that we're going to wait for published RFCs,
and I think that's served us well. We just need to keep an eye on what
the Kitten WG is up to.

That doesn't stop anyone from maintaining a patchset that tracks the
state of the drafts, though. It's only a barrier to getting it
committed and released.

Thanks,
--Jacob

On 21 Nov 2025, at 17:38, Jacob Champion <jacob.champion@enterprisedb.com> wrote:

In the past, we've said that we're going to wait for published RFCs,
and I think that's served us well.

I am a strong supporter of this strategy.

--
Daniel Gustafsson

On Thu, Nov 20, 2025 at 11:52:07PM +0200, Heikki Linnakangas wrote:

After the jabber.ru MITM, it is time to add it:

PostgreSQL does support channel binding, with tls-server-end-point. I
believe that sufficient to prevent an attack like that. (Assuming that it's
configured correctly, but that's an issue of insecure defaults rather than a
missing feature).

Yes, tls-server-end-point is sufficient.

What are the benefits of tls-exporter over tls-server-end-point? I agree it
would be good to support tls-exporter, since RFC9266 specifies it as
mandatory for channel binding over TLS 1.3. But aside from the RFC, is there
some practical difference?

tls-server-end-point suffers from a design problem: it assumes that
signature algorithms have an asssociated digest function, but this turns
out not to be true, and so for some signature algorithms the tls-server-
end-point CB data are undefined :( (you can blame me and my co-authors
for this). Using the exporter-based CB you will not have this problem.

The main benefit of "end-point"-style CB data is that it's easier to
deal with server-side ("reverse") proxies. That's primarily a benefit
for HTTP applications, and almost certainly not relevant to PG (unless
there _are_ reverse proxies for PG -- are there?).

(It _was_ also easier to implement end-point CB when the TLS library
doesn't support the exporter -- that was a problem 15 years ago, but not
now.)

Nico
--

On Fri, Nov 21, 2025 at 08:30:42AM +0000, * Neustradamus * wrote:

Dear Heikki,

Thanks for your answer.

Several people would like to deprecate "tls-server-end-point" (RFC 5929) like Simon Josefsson (author of several RFCs) because RFC 9266 exists since July 2022:

We must either fix or _replace_ tls-server-end-point (TSEP), but we
cannot not have end-point-style CB. I followed up to Simon with reasons
for why. Those followups will also answer Heikki's questions about
pros/cons.

That said, for _PG_ I think the exporter CB are almost certainly better.

Nico
--

On Thu, Nov 20, 2025 at 08:58:54PM +0000, * Neustradamus * wrote:

- XEP-0388: Extensible SASL Profile: https://xmpp.org/extensions/xep-0388.html
- XEP-0440: SASL Channel-Binding Type Capability: https://xmpp.org/extensions/xep-0440.html
- XEP-0474: SASL SCRAM Downgrade Protection: https://xmpp.org/extensions/xep-0474.html
- XEP-0480: SASL Upgrade Tasks: https://xmpp.org/extensions/xep-0480.html

Why are XEPs relevant to PG?

On Thu, Nov 20, 2025 at 01:59:22PM -0800, Jacob Champion wrote:

On Thu, Nov 20, 2025 at 1:52 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:

PostgreSQL does support channel binding, with tls-server-end-point. I
believe that sufficient to prevent an attack like that.

No, IIRC unique bindings (-unique and -exporter) prevent MITM even if
the attacker has the server's private key, as long as they do not also
possess the SCRAM verifiers. tls-server-end-point does not prevent
against that (so you can terminate TLS on a different node from the
verifiers).

If the attacker has the server's private keys then presumably also have
the credentials needed to also terminate the SASL/GSS-API mechanism's
server/acceptor side, so channel binding will not protect you.

The original intent for channel binding was so we could have channels
that authenticate end-points either very weakly (IPsec) or not at all
(TLS w/ anonymous ciphersuites, IPsec w/ BTNS). But channel binding
also serves to detect unwanted proxies -- not wanted by the app, but
maybe wanted by the user. Channel binding has also inspired various
token binding schemes to reduce the risk of bearer token compromise.

Nico
--

On Fri, Nov 21, 2025 at 06:24:07PM +0100, Daniel Gustafsson wrote:

On 21 Nov 2025, at 17:38, Jacob Champion <jacob.champion@enterprisedb.com> wrote:

In the past, we've said that we're going to wait for published RFCs,
and I think that's served us well.

I am a strong supporter of this strategy.

+1

On Fri, Nov 21, 2025 at 9:28 AM Nico Williams <nico@cryptonector.com> wrote:

The main benefit of "end-point"-style CB data is that it's easier to
deal with server-side ("reverse") proxies. That's primarily a benefit
for HTTP applications, and almost certainly not relevant to PG (unless
there _are_ reverse proxies for PG -- are there?).

There is some newer/in-progress work that's beginning to converge on
that, yes (direct-mode SSL+ALPN, server-side SNI, others?).

On Fri, Nov 21, 2025 at 9:38 AM Nico Williams <nico@cryptonector.com> wrote:

If the attacker has the server's private keys then presumably also have
the credentials needed to also terminate the SASL/GSS-API mechanism's
server/acceptor side, so channel binding will not protect you.

Why does that follow? I would think that the avenues for leaking a key
in today's containerized world are much different from the avenues for
leaking database credentials. Or do I misunderstand what you mean...?
I want to make sure I haven't misled people on our SCRAM guarantees...

(But I agree with you that most people probably want unique bindings
for the default use case, not end-point bindings.)

Thanks,
--Jacob

On Fri, Nov 21, 2025 at 10:21:41AM -0800, Jacob Champion wrote:

On Fri, Nov 21, 2025 at 9:38 AM Nico Williams <nico@cryptonector.com> wrote:

If the attacker has the server's private keys then presumably also have
the credentials needed to also terminate the SASL/GSS-API mechanism's
server/acceptor side, so channel binding will not protect you.

Why does that follow? I would think that the avenues for leaking a key
in today's containerized world are much different from the avenues for
leaking database credentials. Or do I misunderstand what you mean...?
I want to make sure I haven't misled people on our SCRAM guarantees...

Well, you're right that if we're talking about a Heartbleed type leak
then what I said does not follow. However loss of the TLS server
credential's private keys is still close enough to catastrophic.

That reminds me of another motivation for channel binding: protection
against wayward CAs. In the WebPKI this is reasonably well accomplished
by certificate transparency, but it's still nice to be able to use CB to
protect against that. In corporate networks (where PG is mostly
deployed, no?) this is not that interesting a consideration.

(But I agree with you that most people probably want unique bindings
for the default use case, not end-point bindings.)

The situation has changed. In the mid- to late-00s unique CB support
was harder to come by. But EP CB is still useful for HTTP applications
for reasons having to do with reverse proxies.

Nico
--

On Fri, Nov 21, 2025 at 11:17 AM Nico Williams <nico@cryptonector.com> wrote:

Well, you're right that if we're talking about a Heartbleed type leak
then what I said does not follow. However loss of the TLS server
credential's private keys is still close enough to catastrophic.

Sure, but it's nice that SCRAM (the only thing we use bindings for at
the moment) makes it slightly less catastrophic. I just wanted to make
sure that the property of "attacker must have the private key and the
SCRAM verifiers to fully masquerade" had not collapsed into "private
key is sufficient" for some reason.

That reminds me of another motivation for channel binding: protection
against wayward CAs. In the WebPKI this is reasonably well accomplished
by certificate transparency, but it's still nice to be able to use CB to
protect against that. In corporate networks (where PG is mostly
deployed, no?) this is not that interesting a consideration.

"Mostly" is probably still accurate? But WebPKI is more important for
us than it used to be, I think. (And with the recent demise of OCSP,
additional server authentication factors may help fill the gap for
some people, maybe?)

Thanks!
--Jacob

On Fri, Nov 21, 2025 at 11:42:41AM -0800, Jacob Champion wrote:

On Fri, Nov 21, 2025 at 11:17 AM Nico Williams <nico@cryptonector.com> wrote:

Well, you're right that if we're talking about a Heartbleed type leak
then what I said does not follow. However loss of the TLS server
credential's private keys is still close enough to catastrophic.

Sure, but it's nice that SCRAM (the only thing we use bindings for at
the moment) makes it slightly less catastrophic. I just wanted to make
sure that the property of "attacker must have the private key and the
SCRAM verifiers to fully masquerade" had not collapsed into "private
key is sufficient" for some reason.

That's a fair take.

(I'm very down on SCRAM. I'd much rather have an asymmetric zero-
knowledge PAKE.)

That reminds me of another motivation for channel binding: protection
against wayward CAs. In the WebPKI this is reasonably well accomplished
by certificate transparency, but it's still nice to be able to use CB to
protect against that. In corporate networks (where PG is mostly
deployed, no?) this is not that interesting a consideration.

"Mostly" is probably still accurate? But WebPKI is more important for

Correct. CT is not a silver bullet.

us than it used to be, I think. (And with the recent demise of OCSP,
additional server authentication factors may help fill the gap for
some people, maybe?)

Fair enough, as more public cloud PG offerings come along, WebPKI will
matter more to PG.

I wonder if DANE (DNS-based Authentication of Named Entities [RFC 6698])
might be a good idea for PG. IMO DANE is a great idea in general, but
browser communities do not agree yet (for reasons, often to do with
performance, which I think by and large do not apply to PG).

Nico
--

On Fri, Nov 21, 2025 at 11:57 AM Nico Williams <nico@cryptonector.com> wrote:

(I'm very down on SCRAM. I'd much rather have an asymmetric zero-
knowledge PAKE.)

Hey, get an OPAQUE-PLUS over the line and I bet someone here will take
interest :D

(It's hard for me to be more down on SCRAM than I am on plaintext
LDAP, though. SCRAM's pretty good.)

I wonder if DANE (DNS-based Authentication of Named Entities [RFC 6698])
might be a good idea for PG. IMO DANE is a great idea in general, but
browser communities do not agree yet (for reasons, often to do with
performance, which I think by and large do not apply to PG).

Possibly. I did briefly look at RPK a few months back, but that was in
the context of a pinned key (i.e. "SSH into Postgres") rather than
with DANE. I feel like I've seen people talking about DANE a lot more
recently? Maybe there'll be momentum for that at some point.

--Jacob