Re: [TLS] Refactoring the negotiation syntax

[Kyle Rose <[e-mail]>]

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.

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.

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.

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.

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.

Additionally, aside from the situation in which a paucity of ciphersuites
is offered by a client, the one situation with no good resolution is
security margin of PSK vs. authentication in PSK+signature: both are based
on pre-existing credentials, one offered by the client and one offered by
the server, so if they disagree there's nothing to be done about it. So
maybe the server then just prefers ciphersuites (and group in PSK+DHE) that
match the minimum of the security margin of the PSK and available auth
credentials.

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.

In other words, we just eliminate the redundancy with the cipher suite
> indications. This leaves is with the question of how to handle the
> existing TLS 1.2 cipher suites. We can either assign new cipher suites
> or say that any cipher suite with *_aead_alg_hash means that we
> support aead_alg_hash. Matter of taste.
>

Meaning that if a 1.3 client offers TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
and the server has only TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 in its
list, that they would internally map to the same ciphersuite and so the
server would agree on and offer up the client's code point? It might be
cleaner just to have new suites for 1.3, if for no other reason but to
reduce confusion when someone looks at this ten years from now.

Kyle