Hi Jonathan,
On 04/05/2020 14:14, Jonathan Hoyland wrote:
Hi Sam,
If you wanted to use a SCRAM based SASL auth then you could pick
`p=SCRAM-SHA256-PLUS`, or any other very specific IANA-registered
string, and update the SCRAM RFC to require that string with TLS 1.3.
You actively don't want for the same channel binding to be an input to
multiple different protocols (or even the same protocol but with
different parameters) because it opens the door to confusion attacks.
Can you elaborate on what you are trying to protect from?
Historically channel bindings were constant once TLS negotiation was
complete (they could change if TLS renegotiation happens). So they never
depended on what was sent over the protocol above TLS.
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 channel binding isn't needed until the `client-final-message`" is
correct. Can you elaborate on what is problematic with this?
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.
Channel bindings that bind both the underlying channel and the
higher-level protocol make more sense to me that channel bindings that
only identify the underlying channel, because you don't have to worry
about the (potentially pathological) behaviours of other users of the
binding.
Best Regards,
Alexey
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
