Re: [TLS] Refactoring the negotiation syntax

[Ilari Liusvaara <[e-mail]>]

On Mon, Jul 18, 2016 at 03:27:28PM +0200, Kyle Rose wrote:
> On Wed, Jul 13, 2016 at 7:12 PM, Eric Rescorla <[e-mail]> wrote:
> 
> > There have been a lot of discussions about whether we should try to
> > refactor cipher-suite negotiation to be less monolithic in the cipher
> > suite. I've generally been on the "no" side of that on cost/benefit
> > grounds as well as not quite seeing how it would fit into the rest
> > of the infrastructure. However, now that we're starting to get full
> > implementations, and it's becoming clearer how the new elements
> > (principally PSK-resumption and key_shares) interact with cipher
> > suites, I've started to think that in fact we may be able to clean
> > things up. One proposal for this is below [0]. I know this is
> > pretty late in the process, but if we do want this change it's
> > better to do it now.
> >
> > I'm sure we'll need to discuss this in Berlin, but in the meantime,
> > fire away.
> >
> >
> > The basic idea here is to factor out the TLS 1.3 negotiation into three
> > mostly orthogonal axes.
> >
> > - Symmetric cipher/PRF  -- indicated by the cipher suite list as in TLS 1.2
> > - Key exchange -- indicated by the key_shares and pre_shared_key extensions
> > - Authentication -- indicated the signature_algorithms and pre_shared_key
> >   extensions
> >
> 
> Tl;dr: I think this is a good approach because it eliminates much of the
> existing negotiation redundancy/complexity and combinatorial explosion in
> the 1.3+ ciphersuite menu.

I recently tried to write code to handle this ciphersuite negotiation, so
that it always negotiates a valid choice if any valid choice exists.

I think the end result was insane. The problem that makes it so difficult
is that legacy signature types, group types and protection/PRFs interact,
so not all supported offers that server has enabled are actually possible
to chose.

> The longer version: the argument I made in Prague (though IIRC not very
> clearly) was that while it would be nice to limit the ciphersuite options
> to agreed-upon "good" combinations based on some sane notion of
> forward-looking security margin (notwithstanding the practical inability to
> see the future), the reality on the ground is that authentication is based
> on something pre-existing---the server has one or two long-term keys of a
> fixed length (e.g., one RSA-2048 and one P-256) that it can't augment on
> demand---so it really only makes sense for the client to indicate what it
> supports and to deal with whatever the server chooses to send it on that
> basis. So I'd argue that this one is orthogonal based on that constraint,
> and so it should be negotiated separately.

If you are talking about "strength-matching", there is no sane notion of
security equivalence with protection, key exchange and signatures (due to
different sub-threshold, multi-key and period properties).

And coupling those in a way that doesn't lead to great difficulty (even
greater than currently) REALLY causes the ciphersuite space to
combinatorially explode.

> AEAD and PRF OTOH don't come with built-in keys, so they can always be
> chosen as a pair as a function of the desired security margin.

Except in some situations (e.g. 64-bit systems with hardware AES and
CLMUL) it actually would make some sense to use AES-128-GCM with SHA-384.

The "match security" is IMO about not having the weakest algorithm not
being too weak, or "paying too much" for algorithm that is much above
anything else.

But what it doesn't consider is what if the stronger algorithm is
actually cheaper? This actually happens on 64-bit on SHA-256 vs. SHA-384.

Or if on 32-bit hardware where you don't have hw AES? Then
X25519/Ed25519/Chacha20Poly1305/SHA256 is the cheapest (or ECDSA P-256
if you don't have Ed25519), nevermind that it has "256-bit" symmetric cipher,
but everything else at "128-bit" level...

> Key agreement is not clearly in either category: when it's PSK, it's based
> on what you have, so it's similar to authentication; but when it's (EC)DHE,
> it's not, and so ideally you'd like the chosen group to be tied to the
> AEAD/PRF security margin. But, since the client has to offer specific
> groups rather than specifying general support for ECDHE or EdDHE, both
> because ideally we want the client key share sent in the first flight and
> because unlike RSA or FFDHE a client can't generalize to key sizes it
> hasn't seen before, it actually still shares a lot in common with the auth
> case of being sort-of something you have rather than something you can
> choose on the fly. So I'm also in agreement that this is mostly orthogonal
> and should be negotiated separately.

"Security matching" between groups and symmetric ciphers is already highly
problematic, and depends on all sorts of assumptions (and is generally
biased towards symmetric ciphers being less secure than they seem).

Sure, the server might bias choices, but actually enforcing anything here
is IMO unwise.

> So now you have several grab bags and need to choose one from each. Is it
> necessary to tie the various bits together by security margin? Not clear.
> It's probably fine to assume a client isn't going to announce support for
> anything it doesn't think is secure enough, so the only practical downside
> to using e.g. AES256-GCM-SHA384 with P-256 ECDSA is the unnecessary
> additional CPU consumption of AES-256/SHA-384. The client was willing to
> accept P-256 server authentication, so presumably it's happy with that
> security margin; and anyway, the server could prefer ciphersuites and ECDHE
> groups that better match the available auth credentials.

IMO, no it is not necressary to tie the security margins. In case of
authentication and encryption, there is also the issue that authentication
is good if it is unbroken at that moment, whereas key exchange and encryption
must remain unbroken for long time since.

So that someone thinks ECDSA P-256 is OK for authentication does not mean
that the same entity thinks ECDHE P-256 is OK for key exchange. Or to think
that 128-bit symmetric encryption is OK.

> Or maybe prospective security margin is too complex and/or too ill-defined
> to bother with, and a server should just choose the least CPU-intensive
> combination of everything.

Well, yeah, it is ill-defined. Of course, there can be bad algorithms
that one wants to disable.

However, interactions between bad algorithms are much less likely than
actual bad algorithms causing problems by themselves.


-Ilari