Re: [TLS] Refactoring the negotiation syntax

[Eric Rescorla <[e-mail]>]

On Mon, Jul 18, 2016 at 5:07 PM, Ilari Liusvaara <[e-mail]>
wrote:

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

Can you say more about this?

I spent some time mocking up an implementation locally and it was pretty
clean.

Perhaps what made it easier is that I did:

1. Define new cipher suites that were totally agnostic about the key
exchange
and signature.

2. Assume everything was orthogonal except for the PSK/signature/key
exchange
interaction...

-Ekr



-Ekr


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