Zoogtfyz <zoogt...@protonmail.com> wrote: > This is my recommendation for changes to the supported ciphersuits in > Mozilla Firefox. I performed rigorous compatibility testing and everything > works as advertized. I used Firefox telemetry data, SSL Pulse data, and my > own tests to verify that *not a single* publicly accessible website would > get handshake errors compared to today. >
Awesome. > > Reasoning: > 1) Too many people put 256bit CBC cipher suits at higher priority than > 128bit AEAD cipher suits because they don't know what they are doing. > Agreed. > 2) 256bit AES cipher suits have known issues compared to 128bit AES cipher > suits. It is not well studied yet how much those issues apply to the cipher > suit implementation in TLS. Given that 256bit GCM cipher suits will not be > added to Firefox, it is better to disable 256bit AES cipher suits > completely. > When I the part of https://briansmith.org/browser-ciphersuites-01 regarding AES-256, I didn't do a good job. A lot of people have interpreted what I wrote as saying AES-256 is bad or worse cryptographically than AES-128. That isn't what I meant to write. AES-256 still has some significant advantages over AES-128. In particular, the larger key size helps w.r.t. quantum computers. Further, the larger key size helps in preventing some multi-user attacks. Even if we think that these merits are small, others do not think they are small, and so there will always be websites that prefer AES-256. Also, with AES-NI and similar optimizations on CPUs, AES-256 is not too much slower than AES-128. So, I don't think that dropping AES-256 is the right thing to do. Instead, the ECDHE-AES-256-GCM cipher suites should be added to Firefox. Note that they were just recently added to Google Chrome. > 3) DHE (not ECDHE) cipher suits are far too often implemented incorrectly, > most often with default common DH primes, DH parameter reuse, or generally > weak bitstrenght (equivalent to 1024bit RSA, which is already considered > insecure in Firefox). Hence it's better to remove support for DHE (not > ECDHE) cipher suits rather than give false sense of security. > I agree. I think if people want non-ECC DHE cipher suites, then at a minimum we need to define new cipher suite IDs for them that imply keys of at least 2048 bits. Unless/until that happens, they are more trouble than they are worth. Note that Chrome recently reached the same conclusion. > Additionally, Firefox 45esr currently supports these signature algorithms > in this ordering: > SHA256/RSA, SHA384/RSA, SHA512/RSA, SHA1/RSA, SHA256/ECDSA, SHA384/ECDSA, > SHA512/ECDSA, SHA1/ECDSA, SHA256/DSA, SHA1/DSA > > I recommend changing it to these in this ordering: > SHA512/ECDSA, SHA512/RSA, SHA384/ECDSA, SHA384/RSA, SHA256/ECDSA, > SHA256/RSA, SHA1/ECDSA, SHA1/RSA > I suggest you read the text that Google's David Benjamin added to the TLS 1.3 draft regarding this. Also, see https://groups.google.com/d/msg/mozilla.dev.security.policy/smAUN2Rtc78/EuQoSyvmAwAJ where I argued something similar. Reasoning: > 1) *not a single* publicly accessible website uses DSA (not ECDSA) > signatures anymore. I agree DSA should be dropped > 3) Ordering from strongest to weakest, as opposed to what it is today. > There are other considerations to take into account other than "strength", as David Benjamin's proposal and my suggestion linked above show. > Additionally, Firefox 45esr currently supports these elliptic curves in > this ordering: > secp256r1, secp384r1, secp521r1 > > I recommend removing support for secp521r1 since it is not supported in > the wild, Chrome does not support it, and we should be moving away from > secp curves to e.g. x25519. Once again, *not a single* publicly accessible > website breaks with this change. > I agree. See https://bugzilla.mozilla.org/show_bug.cgi?id=1128792. Is your test data set and code available somewhere? It sounds interesting. Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
