Re: Cipher suits, signature algorithms, curves in Firefox

Zoogtfyz <[email protected]> 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
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto