[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] TLS Export Channel Binding
From:       "Sam Whited" <sam () samwhited ! com>
Date:       2020-05-09 12:34:17
Message-ID: 0eed2fcc-3747-40b2-855b-59312b0e23c6 () www ! fastmail ! com
[Download RAW message or body]

Hi all,

After thinking about this a little more, I think we should keep the
draft generic and not make it SCRAM specific. While I generally agree
with Jonathan's defense-in-depth strategy, there is also value in having
a direct replacement for tls-unique that can be substituted in
everywhere tls-unique is used to make the upgrade path easier. If we do
that, we can always add a SCRAM specific channel binding type later on
and slowly start the process of upgrading the n-places that use tls-
unique with protocol specific binding types.

Thoughts?

—Sam

On Mon, May 4, 2020, at 12:56, Jonathan Hoyland wrote:
> Hi Alexey
>
> On Mon, 4 May 2020 at 16:23, Alexey Melnikov
> <alexey.melnikov@isode.com> 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

-- 
Sam Whited

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[prev in list] [next in list] [prev in thread] [next in thread]