On Mon, Jul 18, 2016 at 5:07 PM, Ilari Liusvaara <ilariliusva...@welho.com> 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...@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. > > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
