[Ach] Ciphers

[L. Aaron Kaplan]

Hi Kurt,


On Dec 30, 2013, at 4:59 PM, Kurt Roeckx <kurt at roeckx.be> wrote:

> Hi,
> 
> I found your draft document yesterday.  I've participated in
> several other discussion about the same topic, so I would like
> to add some comments.

Thank you very much :)
Reviews and input is really essential.

> 
> As you note in the section in 3.2.3 about configuration B, it's
> not compatible with things that use schannel (like IE) from
> windows XP.  You need to enable either 3DES or RC4 for those
> users.  We all hope that they stop using it soon.  But since this
> is supposed to be a practicle document for that people can just
> use and it should just work, maybe we should also have a
> configuration C for those people that care about those users.

Yes, we were thinking of that. And since supporting Windows XP means including RC4 we were very very unhappy about that.
So, we then were discussing that there is one good argument against that: Win XP is end-of-life.

We could add a configuration C. But ... adding RC4 *really really* is a bad idea IMHO.


> 
> 3DES should have 156 bit of security but is known to only have
> 112 bit.  As I understand it, 112 bit also what is currently
> recommended as the minimum size, matching the 2048 bit RSA key.
> 3DES is slow, but there is no problems with it assuming
> BEAST isn't a problem.  There are patches for XP that fix it.

Could you provide us with links to those patches?

> 
> On the other hand you could use RC4, which has known weakness
> but is much faster and doesn't have the BEAST.
> 
See above, to the best of our knowledge RC4 was discouraged nearly everywhere.

> So people will have to choise between one of those, and depending
> on who you ask you get a different answer.  Some people are afraid
> of the inpack of 3DES on performance.  But I hope the number of
> users actually needing to use that should be low enough that it
> shouldn't have a big impact.
> 

It is a big problem yes, and I think you are hitting a weak spot.
Again thanks a lot for pointing this out. I *do* believe we have lots and lots of Win XP users worldwide.
Especially in developing countries (I dont like that word, but yes - countries where offices have copied old versions of Windows XP and they don't get security upgrades). We see lots of them at CERT.at

> 
> No version of internet explorer has an (EC)DHE cipher on the top
> of it's list of prefered ciphers, but about all other clients do
> have ECDHE as first in their prefered list.  If want all clients
> that support PFS to do PFS you might need force the server to
> their order of preference instead of the clients.
> 

> 
> It says the SHA-1 is broken.  But that's only for collision
> attacks.  It's always used as part of an HMAC and we care about
> the preimage resistance there and SHA-1 is fine there.
Yes, see section 3.6 A note on SHA-1

>  MD5 isn't
> even problematic in an HMAC, but there is no reason to keep using
> it.  So SHA-1 is safe in the cipher string, but we want to avoid
> it in the certificate.
>  I think the certificate part is being done
> by the browsers forcing the CAs to do that, but it of course
> wouldn't hurt to check what the used for your certificate.
> 
Okay, so your input - if I understood you correctly - is to point out the difference in a clearer way?

> It's unclear on what you recommend for RSA key sizes, other than
> smaller than 2048 should not be used.  For OpenVPN you say to use
> 4096 but in the text say 2048.
> 
okay, true that section on openvpn was inconsistent with the rest. 

> You seem to order AES256 above AES128 all the time.  I see no good
> reason for doing that.

Yes, see the quotation by Vincent in 3.4 Keylengths

>  I think we should recommend AES128 intead.
> That would also mean that the 256 bit EC curve should be good
> enough and there is no need for the 384 bit one.
> 
> You also seem to put DHE above ECDHE all the time.  But DHE is
> slow and I think people would prefer to use ECDHE over DHE.

Problem: there are currently some discussions on the trustworthyness of some EC curve parameters.
So far the choice was "rather slow but safe" - but... sure... if your application requires speed and you can live with the doubts towards EC, then... be free to re-order :)

> Apache 2.2 currently only supports 1024 bit DH and there are
> also clients that have problems with bigger sizes than 1024.  I
> think we should recommend ECDHE over DHE.
> 



> I know some people don't trust the nistp curves, but at the same
> time recommend to use ECC.  As alternative there is brainpool, but
> unfortuantly there is no released software available yet that
> supports it as far as I know.
> 
Yes.

Thanks for your feedback!  We'll have to discuss your input in the next meeting. Getting the cipher string list right was already a very long discussion :) And every change to the recommendation will for sure go through multiple steps and checks. I am also waiting for more input on this by some other cryptographers. Yes, we'll have to look at it again.
 
Do you think we should describe the choice of cipher strings and cipher string ordering in more detail?


Aaron.


--- 
// L. Aaron Kaplan <kaplan at cert.at> - T: +43 1 5056416 78
// CERT Austria - http://www.cert.at/
// Eine Initiative der nic.at GmbH - http://www.nic.at/
// Firmenbuchnummer 172568b, LG Salzburg




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.cert.at/pipermail/ach/attachments/20131230/63e54fab/attachment.sig>