Re: RFC 9266: Channel Bindings for TLS 1.3 support

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