Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-kitten-tls-channel-bindings-for-tls13-09.txt> (Channel Bindings for TLS 1.3) to Proposed Standard

[Alexey Melnikov <[e-mail]>]

Hi Jonathan,

On 05/11/2021 15:34, Jonathan Hoyland wrote:
> Hi Simo,
>
> As I said in my email to Sam, my language here was sloppy, I meant 
> that the channel binding is included in the key derivation process, 
> and thus the output keys will be related to each other.
> The term channel bindings has two different meanings using in very 
> similar contexts, which leads to great confusion and is why I prefer 
> the term compound authentication (see Chapter 4.4 of my thesis) 
> <https://pure.royalholloway.ac.uk/portal/files/33074422/2018HoylandJGPhD.pdf>. 
>
> A channel binding is a "name" of a channel as you say, but it is also 
> used to mean using one channel to authenticate another.
> Very specifically if channel `a` is bound to channel `b` then that 
> means that if channel `b` is securely authenticated then channel `a` 
> was formed honestly (i.e. even if all of the long term key material 
> for channel `a` has been leaked, I can be sure that my channel `a` 
> peer is the same actor as my channel `b` peer.)
>
> Channel bindings that aren't bound to a specific session are less 
> secure than ones that are, so yes, you can use them, but that doesn't 
> mean they have the security properties you need.
> The purpose of binding a protocol to an underlying TLS session is to 
> leverage some of the security guarantees offered by the TLS layer.
> If those guarantees are never necessary because the over-the-top 
> protocol is always perfectly secure, just run the protocol on the wire 
> and drop the TLS complication.
> If those guarantees are at least sometimes necessary then you need to 
> securely bind the two channels together.
>
> Channel binding does more than simply guarantee that the messages were 
> the same, it also guarantees that the identity of the actors at each 
> layer remains the same, and that the keys derived in each layer match.
> With an appropriately designed channel binding you can use TLS's 
> protection against MITM attacks to protect insecure protocols run over 
> the top.
> Having now looked at SCRAM a little bit, using the TLS channel binding 
> guarantees that some malicious server isn't passing the client's 
> messages off to another server and performing a malicious 
> authentication there.
> Using a unique string from SCRAM means that messages from some other 
> protocol won't be compatible.
> If you don't require a unique string I could write a new protocol 
> SCRAM++ with cross-compatible messages, but different security 
> guarantees, and use that to compromise SCRAM clients.
> Obviously that's a patently malicious example, but it's perfectly 
> possible that some new version of SCRAM produces messages that an old 
> version of SCRAM misinterprets.
> It's even highly likely that a server that supports old versions of 
> SCRAM for backwards compatibility would use the same key material for 
> all versions.

I've been reading this exchange and I still struggle to understand what 
do you think the issue is. But more importantly, what are the possible 
fixes? If you can propose specific modifications to how 
draft-ietf-kitten-tls-channel-bindings-for-tls13 should be constructing 
channel binding for TLS 1.3, then maybe we can make some progress on this.

Best Regards,

Alexey

> Requiring a unique string makes the messages totally unrelated.
>
> I don't find the arguments "It's always been insecure in the past" or 
> "We have bad APIs" especially compelling.
>
> Regards,
>
> Jonathan
>
>
> On Fri, 29 Oct 2021 at 14:55, Simo Sorce <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     Hi Jonathan,
>
>     On Thu, 2021-10-28 at 18:46 +0100, Jonathan Hoyland wrote:
>     > Hi Ruslan,
>     >
>     > Yes, two distinct TLS connections having the same exporter key
>     would be
>     > really bad, but I'm specifically talking about two runs of some
>     protocol
>     > bound to a single TLS session.
>     > A single TLS session will return the same key (modulo rekeying,
>     resumption
>     > etc.) if you call the Exporter API with the same label.
>     > This means that the channel bindings it produces, which will
>     then be used
>     > to derive the keys of the higher layer protocol, will produce
>     related keys.
>     >
>     > The key reason for making the binding retrieval context-specific
>     is to make
>     > sure that different protocols run in the same TLS session
>     produce disjoint
>     > keys.
>
>     Note, Channel Bindings are *not* a key and should never used as such,
>     so I think you are using a false premise here.
>     Channel Bindings are, at most, a unique value associated with a
>     session
>     (keep in mind that often Channel Bindings do not even bind to a
>     specific session, see 'tls-server-end-point' which is used in
>     preference in many cases within HTTPS endpoints because of the way
>     server termination is built in some scalable architectures).
>
>     > When someone tries to copy a message from a SCRAM handshake into
>     some
>     > GSS-API run on a single TLS connection I want to be sure that it
>     will be
>     > rejected, without having to understand exactly how every version
>     of SCRAM
>     > and GSS-API ever (including ones that will be drafted in the
>     future) works
>     > (not to mention every other protocol past, present, and future
>     that uses
>     > the same string.)
>
>     Both SCRAM and GSS-API are authentication mechanisms that use shared
>     keys for authentication. Both protocols are inherently resistant to
>     message swapping because the chances of producing a message on one
>     protocol that can be successfully decrypted/HMACed on the other are
>     astronomically low (they must be or the protocols are broken).
>
>     Channel bindings are just a way to tie those authentications to the
>     specific channel used underneath. I can't see how using the same value
>     for both protocols can lead to any compromise (see again 'tls-server-
>     end-point', where there isn't even a "same" channel guarantee, or
>     previous CBs where the binding was done to an IP address or other
>     clear
>     text session value).
>
>     If passing an arbitrary channel binding values could suddenly (and
>     predictably?) allow one protocol to be swapped for the other or have
>     one protocol generate derived session keys that are usable with the
>     other, it would mean those authentication mechanisms (SCRAM,GSS-
>     API,...) are completely broken, as that would mean the keys and
>     derivations used in those protocols are not providing the necessary
>     security guarantees.
>
>     > In the same way that we include strings in the TLS key schedule
>     to ensure
>     > that handshake messages can't be confused with each other or
>     with earlier
>     > versions of TLS, or even with Exported Authenticators, or MLS,
>     or any other
>     > protocol that uses keys, we should use channel bindings to separate
>     > protocols run over the top of TLS.
>
>     Yes, this is done because those messages are not further confounded
>     with additional private keys, but the situation is substantially
>     different when you talk about authentication mechanism that
>     already use
>     additional key material, key derivation and random challenges.
>
>     HTH,
>     Simo.
>
>     > Regards,
>     >
>     > Jonathan
>     >
>     > On Wed, 27 Oct 2021 at 19:39, Ruslan N. Marchenko
>     <[e-mail] <mailto:[e-mail]>>
>     > wrote:
>     >
>     > > Hi Jonathan,
>     > >
>     > > Am Mittwoch, dem 27.10.2021 um 18:02 +0100 schrieb Jonathan
>     Hoyland:
>     > > > Hi Ruslan,
>     > > >
>     > > > Without digging into the guts of GSS-API and SCRAM I can't
>     give you a
>     > > > concrete attack, the issue is that all our assumptions about
>     protocol
>     > > > security assume that different protocols use totally
>     separate key
>     > > > material.
>     > > > For example if I have one protocol that signs arbitrary
>     blobs and
>     > > > another that requires me to sign a challenge to prove I know
>     a private
>     > > > key then even if they're both perfectly secure on their own
>     they are
>     > > > totally broken in composition.
>     > > > This separation of keys is one of the core reasons for the
>     use of
>     > > > HKDFs, it lets us take some source randomness and use it to
>     generate
>     > > > independent keys.
>     > > >
>     > > > Designing a channel binding that explicitly suggests people
>     use the
>     > > > same key material for different things is bad practice and poor
>     > > > protocol design.
>     > > > Pretty much every attack is on the table if you have
>     multiple protocols
>     > > > using the same keys, message forgery, improper
>     authentication, key
>     > > > leakage, etc.
>     > > > The reason for separation of keys is to simply rule out this
>     entire
>     > > > class of vulnerability.
>     > >
>     > > Sorry maybe I'm missing something but why would two unrelated
>     protocols
>     > > have same key? The binding is derived from TLS session key, if two
>     > > unrelated TLS sessions are having the same key this is the
>     problem by
>     > > itself, and binding material is not amplifying it, just
>     falling to the
>     > > same problem bucket. And if they are related (eg resumed) then
>     protocol
>     > > muxing should perhaps be part of applicaiton stack and it
>     should still
>     > > be happy with a common security context.
>     > >
>     > > > If you don't separate the keys then whenever you make any
>     change to any
>     > > > protocol you have to consider its security in composition
>     with every
>     > > > other protocol, including ones that you don't know about or that
>     > > > haven't been written yet.
>     > > >
>     > > > Using different labels for different purposes shouldn't require
>     > > > anything complicated, as it's just changing the input
>     literals to the
>     > > > API call.
>     > > >
>     > > There's a difference in telling TLS stack "give me binding of that
>     > > type" - which is pretty much high level abstract call, and
>     asking TLS
>     > > to perform key derivation (export) for specific label - which
>     requires
>     > > speaking native TLS implementation api. Now that we have a
>     bunch of TLS
>     > > implementations and several abstractions and all other binding
>     types
>     > > are independent of the higher protocol - it may be challenging
>     changing
>     > > the API to make the binding retrieval context-specific. Not
>     that it is
>     > > impossible to make such change, but why?
>     > >
>     > >
>     > >
>     > >
>     > _______________________________________________
>     > Kitten mailing list
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/kitten
>     <https://www.ietf.org/mailman/listinfo/kitten>
>
>     -- 
>     Simo Sorce
>     RHEL Crypto Team
>     Red Hat, Inc
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls