On Mon, May 4, 2020, at 09:14, Jonathan Hoyland wrote: > I've only skimmed the SCRAM RFC, but it might make sense to include > `client-first-message` and `server-first-message` as context to the > exporter interface, because it seems that the channel binding isn't > needed until the `client-final-message`. The idea is to use the > transcript to bind the channel binding to the negotiation of SCRAM > parameters, and thus allow you to define a single "TLS-SASL-SCRAM" > string (or whatever makes sense), rather than have one for each > possible set of parameters. Obviously you'd need to think some more > about whether that was actually secure, but at first glance it seems > like a reasonable approach.
I had originally written a long-ish reply about why we couldn't make this SCRAM specific, but I've just realized after going back and looking at the spec and one of my own implementations that I was completely wrong. This is a great idea, and I believe would be secure since the client-first- message and server-first-message will contain their respective random nonces. A malicious client or server *could* slip some arbitrary text into either message, but if I understand TLS exporters security properties correctly this should not pose a problem and the export data should still be indistinguishable from random noise to someone without the TLS master secret (a sanity check by an expert on this statement would be appreciated). I have updated the draft with these changes: https://datatracker.ietf.org/doc/draft-whited-tls-channel-bindings-for-tls13/ I'm still not entirely clear if this would be a better draft for the KITTEN WG or this one. If we update the SCRAM RFCs I think it may be better to go through KITTEN, but I'm not sure that they'll want to take that work on. I'll ask. Any advice here would be appreciated since I know almost nothing about IETF policy or procedures. Thanks for your feedback! —Sam _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
