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.melni...@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
