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
> 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).
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:
> 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.
dev-tech-crypto mailing list