On Mon, Jul 18, 2016 at 5:07 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> > 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. > It may also be that combinatorial explosion in ciphersuites just isn't a problem in reality: that there should be so few choices offered in the standard, with those believed to be secure, and new ones introduced only when they are actually needed, not simply when there is something shiny and new. > 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). > .... > 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. > Yeah, this is a really good point. This argues for a complete separation of authentication (over which the client has no control) from the rest of the security parameters. In some sense, the KX and symmetric cipher are still tied together as a break in either in the future will reveal confidential data, but I'll concede the point that there is no sane way to tie security margins between KX and cipher suite. > 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. > The combinatorial explosion I was referring to was that of consuming code points for multiple combinations of things that have a separate negotiation mechanism (e.g., SignatureAlgorithms). But maybe it's not a problem in practice. > 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. > I'm more concerned about the a la carte approach admitting bad ciphers or PRFs that then get implemented naïvely by completists, but I suppose that problem still exists when they are tied together. And maybe this won't be a problem in practice in the presence of a "recommended" column in the registry. Kyle
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
