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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
