On 08/19/2013 11:06 AM, Kurt Roeckx wrote: > On 08/09/2013 04:30 AM, Brian Smith 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. > > So I think there are a whole bunch of things where we have 2 options, > and it's not always clear which is more important. We have: > - PFS or not > - ECC or not > - RSA or DSA > - GCM or CBC > - keysize (128 vs 256) > - cipher itself > - The used MAC > > As far as I understand things, most of those don't have a big impact > on security, but do on the speed. It's not that simple. Which individual algorithm is faster is often platform and key size dependent. The traditional ordering has been security first, then performance among equivalent. Things like Camellia and SEED were placed high assuming that server support for them would be rare, so the would be negotiated on those servers that needed them. > > I think it makes sense to have PFS when the other side supports it, so > that part of the order looks good to me. We clearly want (EC)DHE when > possible. DH should probably be avoided.
So, to be clear about ECDHE and DHE, the server *CAN* provide perfect forward secrecy, but it doesn't have to. The "ephemeral key" could simple be another permanent key (or one of several thousands). It's important to note that a properly implemented DHE/ECDHE is 3 times slower than DH or ECDH (The latter does a signature, key gen, and key derive (each doing one group operation), the former simply does a derive). This cost is born by the server. > > I understand that ECC might be more secure and is faster, so you want > to prefer ECC. But currently there aren't many servers that have ECDHE > yet, so we should be careful what the order is in case it's not > available and try to use DHE in that case. The current list didn't do > that but this one does. This is ECC marketing. When we did the measurements (10 years ago), RSA was significantly faster on modern 64-bit machines than ECC at the 1024 bit level, and a push at the 2048 bit level (this is measuring SSL connection performance). That is assuming ECDH. ECDHE is 3 times slower than ECDHE. RSA gets a one for one performance boost every time you increase the speed of the modular multiply. where as ECC only gets 20% or so of that. The ECC win is that ECC is more secure at lower key sizes, and it's security profile is linear. RSA's security profile is exponential: Example of typical equivalences: Symmetric 80 ECC 160 RSA 1024 Symmetric 128 ECC 256 RSA 2048 Symmetric 192 ECC 384 RSA 4096 Symmetric 256 ECC 512* RSA 8K (The actual prime ECC curve is 521 simply because 2^521-1 is prime) ECC is faster than RSA at low key sizes on restricted hardware (once ECC is optimized, that is). On faster hardware RSA holds it's own into the 2K range. to double your security, RSA needs to go up about 4x. Also doubling your key size increase the cost to do the RSA operation by 4x. ECC is linear in both cases. So if RSA is 16x faster than RSA at one strength level, doubling it would make them equivalent. The upshot is that ECC will always eventually win the performance race at the top end, but for any given hardware and key strength, RSA may actually be faster. > > I'm not sure which of RSA and DSA is better, but clearly people use > RSA more. DSA is signature only, so it's DHE/DSA versus DHE/RSA versus RSA. Both algorithms are have different speed characteristics. In RSA signing is more expensive verification, but still cheaper than DSA signing (unless you precalculate several k/r/k^-1 values, which hardware may do, but most software does not bother with). For verification RSA is significantly faster (why, you may ask, since the math for both is exactly the same: S =H^priv mod N, H = S^pub mod N? It's because we can choose the value of the public key and greatly reduce our work to calculate X^pub mod N). DSA verification is actually slower than DSA signing, involving 2 group operations (modular exp in the case of DSA), and invert and 3 multiplies. Of core RSA is much faster than any of the DHE/DSA, DHE/RSA for both the client and the server. It's also faster than DH_ for the same key sizes (RSA private key ops can use the Chinese remainder theorem to reduce it's work by 4x, verses DH of the same key size). > > I understand that GCM is faster, but the implementations might have > side channel attacks. So I'm not sure if GCM or CBC is better, but > we should probably prefer GCM or CBC. Again, GCM is not necessarily faster than CBC, though GCM doesn't have to do the hash. Certainly on a 64 bit intel machines with hardware assist, it's likely to be. GCM isn't vunerable to BEAST attacks. > > I understand that for a 2048 bit public key a 128 bit symmetric key > should be good enough, but for a 4096 you should have a larger key. I > see that about 2% is using keys of 4096 bit. It's a question of where your weakest link is. 2048 matches better with 256 than 128. 4096 bit keys are overkill for a server leaf certificate. > > As far as I understand it, there is nothing wrong with 3DES other than > that it's slower. RC4 should clearly be deprecated, but is currently > popular because BEAST and that it's the only stream cipher we have. > Since we know we're not vulnerable to that, it make sense to order > this as late as possible. 3DES is a block cipher like AES, except with a smaller block size. All the AES attacks have been general block cipher attacks. The smaller block size of 3DES makes it more vunerable to those attacks. RC4 is also popular because it is far and away the fastest cipher, in general. > > It might not be obvious, but camellia is currently used a lot when > connecting to sites because it's the first non-ECDHE in the current > list. And the RSA key-exchange was even before the DHE version. > > I understand that the MAC itself doesn't make much difference, but we > should probably avoid MD5. I see no SHA256 MACs except for GCM which > probably isn't a problem. SHA256 is tls 1.2 only. GCM doesn't use HMACs. GCM is actually the MAC algorith (AES-GCM is AES counter mode with a builtin GCM MAC). > > So I can mostly follow the reasoning behind the proposed order, but I'm > a little bit surprised that we used to have all the 256 bit before the > 128 bit, and it's now the other way around. I don't really see this as > a problem except for people that want to use 4096 bit public keys. > They should probably disable 128 bit keys on their server. yeah, I would like to see performance data on the cost of 256 bit versus 128 bit before we make this trade off. This may be the flaw in this plan. A normal desktop machine probably couldn't even see the cost between the 2, but maybe a tablet with a 2013 vintage arm processor can. Yet by 2015, that tablet is perfectly happy with 256 bit. I'm not sure that we should let the least common denominator drive, but if we do we should be very sure it's really the cost we need. > > I'm not sure why you keep > TLS_DHE_DSS_WITH_AES_128_CBC_SHA > and drop > TLS_DHE_DSS_WITH_AES_256_CBC_SHA > > I'm concerned that DHE_RSA_WITH_3DES_EDE_CBC_SHA is dropped, since > it's the only one with PFS that some sites support. Can I suggest you > add that before the ECDHE_*_RC4 ciphers? > > > Kurt
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
