Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-kitten-tls-channel-bindings-for-tls13-09.txt> (Channel Bindings for TLS 1.3) to Proposed Standard

["Ruslan N. Marchenko" <[e-mail]>]

Hi Jonathan,

Am Freitag, dem 05.11.2021 um 15:34 +0000 schrieb Jonathan Hoyland:
> 
> Having now looked at SCRAM a little bit, using the TLS channel
> binding guarantees that some malicious server isn't passing the
> client's messages off to another server and performing a malicious
> authentication there.
> ...
> If you don't require a unique string I could write a new protocol
> SCRAM++ with cross-compatible messages, but different security
> guarantees, and use that to compromise SCRAM clients. 
> Obviously that's a patently malicious example, but it's perfectly
> possible that some new version of SCRAM produces messages that an old
> version of SCRAM misinterprets. 
Authentication method and SCRAM mechanism negotiation must happen
before SCRAM exchange. if parties don't agree on the method/mechanism
negotiation fails. If you control the server to the level that you
negotate one method/mechanism but use another - you're not mitm, you
just _pwn_ the service, and no binding in the world would solve that.
> It's even highly likely that a server that supports old versions of
> SCRAM for backwards compatibility would use the same key material for
> all versions. 
> 
> Requiring a unique string makes the messages totally unrelated. 
> 
> I don't find the arguments "It's always been insecure in the past" or
> "We have bad APIs" especially compelling. 
> 
It's not "historically insecure", it's just not a secret key by design.
It's public (non-secret) but unique and imutable property of the TLS
channel (not application/authentication channel, mind you). Finished
packet - is not a secret - any sneaky person can snoop it. Certificate
digest - is not a secret, any person in the world can get it. It's not
a guardian of the confidentiality, rather a warrant of integrity.


Regards,
Ruslan