Re: RFC 9266: Channel Bindings for TLS 1.3 support

On Fri, Nov 21, 2025 at 9:28 AM Nico Williams <nico(at)cryptonector(dot)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(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...

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

Thanks,
--Jacob