Re: RFC 9266: Channel Bindings for TLS 1.3 support

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(at)cryptonector(dot)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
--