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

From Jacob Champion
Subject Re: RFC 9266: Channel Bindings for TLS 1.3 support
Date
Msg-id CAOYmi+=T=Cx1ksUc-U1K22_=VzgP7_Bh1nMuYj7vyNzMKYBh7g@mail.gmail.com
Whole thread Raw
In response to Re: RFC 9266: Channel Bindings for TLS 1.3 support  (Nico Williams <nico@cryptonector.com>)
Responses Re: RFC 9266: Channel Bindings for TLS 1.3 support
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Greg Burd
Date:
Subject: Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB barriers
Next
From: Nico Williams
Date:
Subject: Re: Optimize cardinality estimation when unique keys are fully covered