On 08/16/2013 03:05 PM, Wan-Teh Chang wrote: > 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. So looking at this list, I think we have a major inconsistency.
We put Ephemeral over non-ephemeral, but we put 128 over 256. While I'm OK with Ephemeral (PFS) over non-ephermal (non-pfs), I think in doing so we are taking a much more significant performance hit we get back by putting 128 over 256. The attack profile protection of PFS versus non-PFS is basically two points: 1) some government agency could force a server to give up it's private keys and decrypt all the traffic sent to that server. But we already know that government agencies with such power simply ask for the the data on the server. 2) some well funded attacker could spend the resources to attack the server's private key and get all the traffic sent to it. However, we don't actually check to see that the server is giving us a unique key in the ephemeral case. A way to cut some of the server cost of DHE/ECDHE is to generate a single them key as use it for all connections. We have know way of knowing the server is doing this, which brings back this particular attack. I still think PFS algorithms are useful and agree with preferring them, but compared to 128 versus 256 it seems like the cost/security tradeoffs are actually less for the PFS algorithms. If we are making performance tradeoffs, we really should measure the real cost rather than just randomly say one is too expensive. >> 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. Agreed SHA256 HMAC, like PFS, is really marketing. SHA1 is weak right now for signatures because of collision, but HMAC depends on pre-image resistance, which even MD-5 is still strong against. At some point marketing wins, as well as the security principle "attacks only get better". As Brian points out, however, AEAD cipher suites solve both problems. bob > > Wan-Teh
smime.p7s
Description: S/MIME Cryptographic Signature
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
