On Wed, Jul 13, 2016 at 7:12 PM, Eric Rescorla <e...@rtfm.com> 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
