On Mon, Jan 27, 2014 at 09:26:20AM -0800, ripber...@aol.com wrote: > > 2) NIST is a US government standards board that drives a lot of compliance > regulation. There are companies what will want to be able show that they > are NIST compliant.
I'm sure it is important to some. But I think it would be more important to get the server to be compliant rather than the client. The client currently has to work in a lot of different environments where it can't be sure that the other end is compliant with those standards. NIST is, like you said, a US government standard, and as such doesn't have any official status outside the US. That doesn't mean that if it has good recommendations that we shouldn't try to follow them. But we have to live in the real world, and it's more complicated. > 4) I think the flaws in the TLS 1.1 CBC definition (no random IV) drove > folks away from > AES and to use RC4 - it was the best thing left in TLS 1.1 - or Camellia > which is probably as good or better than AES though rather new and > therefore risky - but better than a broken AES-CBC implementation. I think you mean TLS 1.0? > 5) I'm trying to tell you what the standard says - not whether I agree with > it. I don't get to pick. The standard does not allow Camellia (because > it is too new). But the standard does support and justify taking away > the set of suites that Marlen suggested. I was just giving a more > explicit rational for dropping them. AES is from 1998, Camellia from 2000. I wouldn't call that too new. But it is used less. > > > Digital Signature Generation: > > > RSA with n>=2048 - 112 bit > > > > > This generally affects what type of certifcates you need. Notice > > > RSA-2048 now required (no RSA-1024). > > > > > > Following CA/Browser baseline requirements, everything should now be > > 2048 bit or more, but some CAs aren't ready for this. 1024 bits is > > now below 1%. I think all ECDSA are 256 bit or more, and DSA isn't used. > > The standard is telling you what you should use, not whether anyone does or > not support it. The standard is saying everyone should already be at 112 > security bit strength now. > Agree you might as well ignore DSA if no one implemented it which means > you can forget about TLS_DH, TLS_DHE_DSS suites. > I understand some sites may not use RSA-2048 keys in certificates. However > using RSA-1024 bit keys has only 80 bits of security strength which is no > longer secure (NIST worries about it saying secure for say another 20 > years). Even worse than RSA-1024 I suspect will be the use of SHA-1 in > certificate signatures. The CA/Browser requirements are good in changing the certificates being generated. It resulted in the 1024 bits keys going from 10% last year to 1% now, and with the current rate should be near 0% in a few months. I would also like to see them to change the SHA-1 requirement to SHA-2, and some CAs are working on that. But there seems to be existing software that still can't handle it. SHA-1 is known to be only providing about 60 bit of security for a collision attack, which is a problem. To make it more hard the CAB requirements state that the CA should add at least 20 bit of entropy and at least some people say that that is not enough. > The client is not obligated to enforce NIST 800-131a. But I > would suggest two things: > 1) There should be a visible indication whenever a web site ends up with a > connections that has less than 112 bit security. Perhaps even ask the > user if he really wants to connect to a site with 'weak' security. This > might motivate some of these sites to fix their security. > 2) There should be a configuration control to block connection to a weak > sites period. > Weak = See description at end of post. You can actually disable things like MD5, RC4 and 3DES and set the minimum version to TLS 1.2. You will just run into many sites that just don't work. It will show you that it's weak or strong if you first click the icon and press more info. Not sure on what that is based. > > > I think in general, you could say the shorter the key or hash, the faster > > > it runs, so if all you are trying to get to as 112 bit security (all that > > > is required in 2014), I'd consider preferring suites with AES_128 > > > encryption and SHA MACs over > > > > > AES_256 or SHA-256 or SHA-384. > > > > We prefer GCM, and AES128 over AES256. But GCM doesn't use a HMAC and > > > so needs SHA256. > > > There's not much point in having one algorithm with more security than > another - the least secure algorithm determines the security level of the > implementation and the higher security algorithm just burns performance. > AES-128 and SHA-256 hashes are same strength. AES-192 and SHA-384 hashes are > same strength. AES-256 and SHA-512 hashes are the same strength. > For 112 bit security strength - AES-128 is sufficient so don't need AES-256. > HMAC with SHA-1 is good with AES-128. GMC with SHA-256 is good with AES-128. The SHA-256 in combination with GCM only provides 128 bit, not 256 bit. > > > Might also ask why you didn't include any DH key negotiation cipher > > > suites (e.g. C004, C003, 0031, 0030, 000D, 0010)> > > > It's OK for the server to have a static DH key provided the client uses > > > an ephemeral DH key.> > > > If the answer is no one uses them or not in NSS - that's fine. However > > > the above ones would be OK for NIST 800-131a. > > > > static (EC)DH keys do not offer forward security. They do cause you to > > spend more time on the key exchange. So what is the advantage of them? > > I might be wrong, but I thought as long as the client and the server do not > BOTH use a static key, then you still have forward perfect secrecy. And I > thought the definition in TLS provided for the certificate owner to have a > static DH key and for the authenticator to use an ephemeral key when DH or > ECDH was used. If this is correct, I'd guess the static key on the server > side might save some time. Anyway I'm on shaky ground here perhaps - in my > mind, I like it when there are fewer options and clearer choices about what > to use. I do notice that the Suite B cipher suites only use ECDHE so that > might be some indication that DH or ECDH are not a strategic path. Again - > the only point is the standard allows them if there is any reason to support > them. The client DH key is not encrypted. If a client sends the same DH key to the same server it will end up with the same session key. Anybody that monitored the communication and later has access to the servers key will be able decipher everything, and so it does not provide forward secrecy. Kurt -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
