On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco <cvie...@mozilla.com> wrote: > 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).
Camilo, I think you reverse-engineered Brian's criteria correctly. The new criteria seem fine. I would prefer ECDSA over RSA for authentication. > 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. The way HMAC-SHA1 uses SHA1 is much more complicated than the way public key signatures use SHA1. This is why SHA1 collision attacks usually don't affect the security of HMAC-SHA1. Wan-Teh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
