Re: RFC 9266: Channel Bindings for TLS 1.3 support

On Fri, Nov 21, 2025 at 02:57:26PM -0800, Jacob Champion wrote:
> 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

For apps like PG I'm much more interested in real OAuth support.  But
that's because I use PG in a corporate environment where we use
Kerberos, PKIX, and OAuth for authentication.

In particular I want the _client_ to be configurable to be smart enough
as to how to fetch the darned OAuth rock the server wants.  I'm much
more interested in OAuth for authentication than I am in OAuth for
authorization -- GRANTs and RLS (and/or VIEWs that JOIN authz tables)
are plenty good enough for authz in PG.

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

+1

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

I do think the momentum for DANE is increasing.  I think PG could help
in this regard given that widespread use of PG in the public Internet,
w/ WebPKI, is fairly newish development.

DANE has done wonders for email security.

Nico
--