Re: [TLS] TLS Export Channel Binding

[Alexey Melnikov <[e-mail]>]

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