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).
> Level n: same as current level n-1.
That may well be better, plus warnings about blindly playing the "my
level is higher than yours" game. And I think session ticket support
not be dropped at 128-bit strength.
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, ...).
There are important trade-offs here, and adhering to SP-800 too
closely can cause more harm than good.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
