Re: [TLS] TLS Export Channel Binding

[Jonathan Hoyland <[e-mail]>]

Hi Alexey

On Mon, 4 May 2020 at 16:23, Alexey Melnikov <[e-mail]>
wrote:

> 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?
>
>
If two protocols use the same channel binding there is a risk that the
messages from one can be confused with the messages from the other.
This might happen accidentally, or an adversary might be able to forge one
from the other.
If you wanted to do a formal analysis of the of the security of TLS 1.3 +
SCRAM then a generic binding means you have to factor in what every other
possible protocol might do.
If you use a unique and specific channel binding then the analysis is far
easier and can be a lot more robust (this assumes a global coordinator of
unique strings, such as IANA).
>From an analysis perspective it's easier to rule out classes of attacks
than to consider all possible interactions between all users of the
interface, some of which you won't know about, or perhaps haven't even been
invented yet.

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.
>
>
Yeah, I think the design in TLS 1.3 is much more robust, especially from a
formal analysis perspective.
By constructing channel bindings based on the parameters negotiated over
the top you get a belt-and-braces design.
If you have a contributive channel binding [1] then if the security of
either the underlying protocol (in this case TLS) or the over-the-top
protocol (in this case SCRAM) fails, then the channel binding guarantees
the authentication still happened properly.
Consider the case where an adversary publishes the server's private key to
twitter.
If you have a contributive channel binding then if the SCRAM handshake
succeeds you could be sure that you were talking to the real server, and
weren't being MITMed.
If you don't base the channel binding on the parameters agreed in the
upper  protocol it's possible (in theory) that an adversary could compute
two SCRAM handshakes that appear to succeed, but that actually agree
different parameters.
In this particular case it's not obvious how that could happen, but it's
easy to think up pathological examples, and [1] has a few concrete examples
too.


> > 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?
>

Sorry if I was unclear, there's nothing problematic with this per se.
It's just that the channel binding can't be dependent on itself, but
including everything that precedes the channel binding just seems like an
easy win, esp. as (in this case) that includes all parameter negotiation.


> > 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
>
> Regards,

Jonathan

[1] Bhargavan, Karthikeyan, Antoine Delignat-Lavaud, and Alfredo Pironti.
"Verified Contributive Channel Bindings for Compound Authentication." *NDSS*.
2015.
https://prosecco.gforge.inria.fr/personal/karthik/pubs/verified-channel-bindings-ndss15.pdf