Re: [TLS] security levels for TLS

[Eric Rescorla <[e-mail]>]

At Thu, 11 Oct 2007 21:26:19 -0700,
Mike wrote:
> You've said that this is not possible because, for instance,
> DES3 does not have a single value for the key length since
> one attack renders its effective strength at 168 bits, while
> another weakens it to 112 bits. I would say that you would
> have to go with the lower 112 bits, and perhaps you wouldn't
> even allow it at level 1.

Well, I consider 168 bits a lot more accurate under most
threat models--which is of course the point. As for "level 1",
I don't even understand what you're saying here. 3DES is
plenty secure for any known application. The difference between
112 and 168 is basically insignificant for any practical 
application. The existence (or nonexistence) of known (or unknown)
analytic attacks is much more important.


>  I have to admit I don't know the
> subtleties of elliptic curve cryptography to know how to
> translate "level 2" to a list of acceptable curves and key
> lengths, but I'm sure someone on this list does.

No, it's not clear that it's known, actually. As another example,
how do you compare 1024 bits with PFS to 1024 bits without?


> Right now all cipher suites are under-specified.  If we had,
> for example:
> 
>      TLS_DHE_1024_RSA_2048_WITH_AES_128_CBC_SHA
> 
> we would probably not be talking about this.  I proposed that
> we let clients "fill in the blanks" that the cipher suites
> don't specify.  Isn't it better to tell the server exactly
> what you want in terms of security, than to leave it up to
> chance?

Arguably, it would have been, but it's not the way that the
system is now, and I haven't seen an argument that this
needs to change..


> I'm an interface designer, and believe that the average
> application developer has only a boolean view of security:
> either security (TLS) is enabled, or it isn't.  It's easy
> to extend that to a 3 or 4 level security model, but beyond
> that, you're asking for trouble.  (A TLS toolkit would still
> provide a security expert full control of course.)

You should feel free to do this in your implementation. I'm only
objecting to TLS-WG being involved.


[Yngve's report of extremely weak DH keys deleted].
> As far as Opera is concerned, I am considering a few options, including 
> automatically disabling the ephermal ciphersuites or re-sorting the 
> cipher suite list toplace them last, and renegotiate the connection.
> 
> [Apparently my memory was incorrect and the session was
> renegotiated instead of the close->reconnect->negotiate
> sequence I stated; however, support for renegotiation is
> optional, so it may not always work.]

Yes, yes, I know about all this. But as I said, use of a 256-bit 
DH group (and probably 512-bit) is a clear implementation error.



> >> The folks at Opera Software have expressed how difficult
> >> it was to secure their browser, and how insecure some
> >> servers are (256-bit DH parameters!).
> > 
> > Yes that's interesting but irrelevant. Those are pretty
> > clearly mistakes on the server side, as are RSA e values
> > of 1. Neither is likely to be fixed by specifying security
> > levels in the way you suggest.
> 
> This proves my point -- lots of application developers and/
> or server operators don't understand this stuff to the level
> required to make all the right choices.

Yes, I agree that they don't but it's not clear to me why
you think that having the client express its opinion improves
the situation, given that the problem is that the server is
misconfigured. 


> >> Another issue I've been meaning to bring up is that
> >> if you want forward secrecy, you need to use Diffie-
> >> Hellman; however, there is no way to tell the server
> >> the size of the parameter p you want.  Increasing the
> >> size of p has significant performance implications,
> >> so servers will typically use 1024 bits.
> >> [...] It would be better if those
> >> who want to use 4096 bits could ask for it.
> > 
> > Again, please present some evidence that this is a real
> > practical issue outside of a very small population of 
> > keylength fetishists.
> 
> RSA key exchange provides up to 368 bits of security, but
> doesn't provide forward secrecy. 

As does DH with appropriate key sizes. RSA and DH have approximately
equivalent strengths with the same modulus size. 


> If I want forward secrecy,
> then I need to use Diffie-Hellman.  A server that has 1024-
> bit Diffie-Hellman parameters only provides me with some-
> where in the neighborhood of 70-80 bits of security
> (extrapolated from the data in RFC 3526).  You are saying
> that I am a "keylength fetishist" because I want better
> than 70-80 bits of security?  So I'm allowed either lots
> of "strength" *or* forward secrecy, but not both?  That's
> irresponsible.

Nobody is stopping you from using any DH key size you want with 
TLS (or RSA, for that matter.) It's just that the server controls
the key size with no input from the client. I have yet to see
any evidence that there's substantial demand from clients for
input on the key size. That said, if you really care, you can
use ECC, which *does* permit the client to advertise the groups
it wants.

-Ekr


_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls