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
weakness.
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
regard:
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:
TLS_(EC?)DHE_RSA_WITH_AES_(128|256)_CBC_SHA256
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.
Camilo
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.
[0]:
https://github.com/agl/openssl/commit/0d26cc5b32c23682244685975c1e9392244c0a4d
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.
Cheers,
Brian
--
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
