- From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- Date: Fri, 10 Oct 2014 22:04:47 +0300
- To: Brian Smith <brian@briansmith.org>
- Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Fri, Oct 10, 2014 at 11:49:19AM -0700, Brian Smith wrote:
> On Fri, Oct 10, 2014 at 10:13 AM, Martin Thomson
> <martin.thomson@gmail.com> wrote:
> >
> > So, I'm going to propose that we simply reduce the minimum to 112
> > bits. At 112 the elliptic curve is still stronger than the finite
> > field Diffie-Hellman minimum of 2048 (TLS 1.3 doesn't even permit the
> > use of something that weak). ECRYPT II estimates that 112 is good
> > until around 2030, and equivalent to 2432-bit finite field DH.
>
> I suggest that you avoid the subjective "security level" concept
> completely and just say that that an ECDSA and ECDHE keys must be at
> least 256 bits, and that an DHE, RSA, and DSA keys be at least 2048
> bits. I'm actually not sure you want to have that limit for DHE keys,
> but it seems like a good idea to have such a requirement for RSA keys.
> Specifying a minimum ECC key size in the draft actuallly have very
> little practicle effect since almost nobody is using ECC key sizes
> less than 256 bits, but specifying the minimum RSA modulus size would
> be a practical benefit, because quite a few servers are still using
> 1024-bit keys.
RSA key exchange is not PFS, so are you talking about RSA certificates?
Also, bit crazy idea would be to set the bar at 120 bits. All "128-bit
secure" ones easily reach that by any reasonable definition, whereas
the less secure ones ("112-bit") tends to be significantly below that.
-Ilari
Received on Friday, 10 October 2014 19:05:12 UTC