On Fri, Mar 28, 2014, Viktor Dukhovni wrote: > On Fri, Mar 28, 2014 at 07:27:59PM +0100, Dr. Stephen Henson wrote: > > > One possibility I'd considered is to move levels 1 and above along one. Then > > you'd have... > > > > Level 0: anything goes. > > Level 1: almost anything goes but stupid stuff like DH, RSA keys < 512 bits > > excluded. > > And the corresponding EXPORT algorithms I suppose. This level 1 > might well be a sensible default. I am not aware of any systems > that don't support at least 80-bit crypto (with SHA1 being the > 80-bit anchor, the rest is generally closer to 128-bit). >
Well the current level 1 (this could get confusing rather quickly) has 80 bits. > I should note that nothing in RFC 5077 requires AES128 for the > ticket bulk crypto, the ticket IV is limited to 128-bits but that's > a constraint on the block size, not key length. Furthermore the > security of HMAC-SHA-256 is not 128-bits, it is 256 bits, since > attacks on this are pre-image attacks, not collision attacks. > > Therefore, implementations can over time move to encrypt session > tickets with 256-bit keys. So I would not exclude session tickets > at any of the security levels, this adds no security, but makes > the use of security less likely (more expensive handshakes, more > server hardware, ...). > Some applications generate a long term key which is then shared among mutiple servers. That defeats PFS if an atatcker could just steal that key and then decrypt any session tickets protected with it. If an application implements key rollover and uses 256 bit AES keys then there are no issues with using tickets at any security level. Unfortunately not many applications do AFAIK. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
