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

[Jonathan Hoyland <[e-mail]>]

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.
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.)

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.

Regards,

Jonathan

On Wed, 27 Oct 2021 at 19:39, Ruslan N. Marchenko <[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?
>
>
>
>