Brian Smith wrote: > A lot of people have interpreted what I wrote as saying AES-256 is bad. I was not really referring to what you wrote about AES-256. I was referring to for example https://eprint.iacr.org/2009/374 . Even though those are related key attacks (which should not be relevant to *proper* implementation in TLS), it gets people worried about the constructions in AES-256 compared to AES-128. We should be moving away from AES as it is currently standardized, due it's small number of rounds anyway (the internal NSA version of AES uses a larger number of rounds).
> the larger key size helps w.r.t. quantum computers. If quantum computers are currently on the level of breaking AES-128, then they are on the level of breaking any asymmetric cryptography (RSA, DHE or ECDHE key exchange) we are using - which makes support for AES-256 moot. Moving away from AES-256 will put even more pressure on the crypto community to come up with a solution as opposed to the *relative* complacency we are seeing now. > the larger key size helps in preventing some multi-user attacks. Given relatively widespread hardware acceleration, it makes no difference regarding AES-128 compared to AES-256. > Even if we think that these merits are small, others do dot think they are > small. And as is too often the case, people get crypto wrong :) > and so there will always be websites that prefer AES-256. Websites that prefer AES-256, such as internal websites, can always instruct their users/customers to toggle a switch in Firefox to enable AES-256. I am proposing having AES-256 ciphersuits toggled off by default. > Also, with AES-NI and similar optimizations on CPUs, AES-256 is not too much > slower than AES-128. My concerns are not much with respect to performance. AES-NI are common on desktops, but most mobile devices are not yet ARMv8 so they don't get hardware acceleration. > the ECDHE-AES-256-GCM cipher suites should be added to Firefox. They will be added to NSS, just to have support for them. The question is whether they will be toggled on by default in Firefox. > they were just recently added to Google Chrome. It was discussed on the Chrome mailing list. They are not yet enabled by default in Chrome stable, it is not yet decided if/when it will be enabled. > if people want non-ECC DHE cipher suites, then at a minimum we need to define > new cipher suite IDs. What is likely happening is new TLS extension to advertise support for that. In the meantime, we should not support DHE - note that Chrome stable currently does not advertise support for DHE ciphersuits (but they have a fallback mechanism). > There are other considerations to take into account other than "strength". True. My proposal is just something to change in the meantime while waiting for TLSv1.3. Most of these suggestions would help with a smoother transition to TLSv1.3 once it's out. Regarding the signature algorithms, supporting the ones that Chrome supports and ordering them the same way can help with hard-to-track-down compatibility issues, while we wait for TLSv1.3. Personally, I would even get rid of the SHA512 algorithms, but removing those does break *few* not *none* websites. > Is your test data set and code available somewhere? It sounds interesting. I will put in a request with legal on Monday to get the code opensourced and data publicly available. It will have to be redacted though, because it contains TLS applications that are accessible over the internet, but likely should not be public (such as many mailservers, xmpp servers, irc servers, webcams, and other applications running on non-standard ports). I used a subset of the data, only considering TLS servers running on TCP port 443, with a properly resolving DNS name, with a valid certificate for that domain (valid and trusted according to Firefox 45esr). In this subset of data, no new handshake errors were introduced by my proposed changes. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
