Hello Brian

I think this proposal has 3 sections.
1. Unifing SSL behavior on browsers.
2. Altering the criteria for cipher suite selection in Firefox (actually NSS)
3. removing certain cipher suites from the default firefox ciphersuite.

On 1:
I dont see the point, but I am not against.

On 2:
The proposal is not clear. I want an algorithmic definition. For example in
nss we can see in sslenum.c :
-strong ciphers before weaker
- national ciphers before international
- faster ciphers before slow ciphers.

But your proposal it not clear. Here is my reverse engineering of the criteria to get to your list:

1. Message Authentication: MD5 last.
    rationale: security
2. Key exchange (round1): PFS before non-PFS suites
   rationale: privacy, goal stop supporting non-PFS suites.
3. Bulk encoding (round1): aes(all variations) before national ciphers before 3des before rc4 before des before export ciphers before null. rationale: security, aes is the most studied cipher both in implementation and theory. RC4 has shown
reationale2 performance: 3des is slow and does not provide much security over the other ciphers.
4. Authentication (round1) : DSS last
   rationale: it is not really used, want to deprecate.

5. Key Exchange (round2): ECDH before DHE.
   rationale: ECDH allows negotiation form client.
6. Bulk encoding (round 2): 128 AES before 256 AES
   rationale: performance and minimal security gains.
7. Message Authentication: authenticated encryption (GCM) before SHA before SHA256 before sha384
   a. AEAD before HMAC : performance
   b. sha ordering: performance
8. Authentication: RSA before ECDSA
    a. RSA before ECDSA : performance
    b. DSA last: not in use

This criteria gets to your ordering proposal. What do you think of re-framing your list in a criteria like this? (note national ciphers could go in step 6 instead of step 3).

On 3:
I understand the issues with small packets so I agree we need to prune. On this
national ciphers: concur with Gerv need to talk but I am inclined to remove them
(from the defaults, not from NSS).
removal of null encoding  and auth cipher suites: agreed.
Keeping TLS_DHE_DSS_WITH_AES_128_CBC_SHA and the only DSS for compatibility: agreed Keeping TLS_RSA_WITH_3DES_EDE_CBC_SHA as the only 3DES for compatibility: agreed
RC4 cipher agreed:removal agreed.
Not adding any TLS 1.2 cipher that does not use PFS agreed.

Not adding:
Disagree I dont think a potential performance issue should prevent us from deploying that suite as there could be sha1 attacks that we dont know of. If we have enough space in the handshake I see no problem in including them. Removal seems like a premature optimization.


On 8/15/13 10:15 AM, Chris Richardson wrote:
I believe this plan would have poor side effects.  For example, if Apple
ships clients with a broken ECDSA implementation [0], a server cannot
detect detect if a connecting client is an Apple product and avoid the use
of ECDSA in that subset of connections.  Instead, ECDSA suddenly becomes
unsafe for anyone to use anywhere.


On Thu, Aug 8, 2013 at 10:30 PM, Brian Smith <br...@briansmith.org> wrote:

Please see https://briansmith.org/browser-ciphersuites-01.html

First, this is a proposal to change the set of sequence of ciphersuites
that Firefox offers. Secondly, this is an invitation for other browser
makers to adopt the same sequence of ciphersuites to maximize
interoperability, to minimize fingerprinting, and ultimately to make
server-side software developers and system administrators' jobs easier.

Suggestions for improvements are encouraged.

Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
dev-tech-crypto mailing list

dev-tech-crypto mailing list

Reply via email to