Re: [TLS] security levels for TLS

At Thu, 11 Oct 2007 08:39:05 -0700,
Mike wrote:
> 
> I think there is good reason to try to solve this problem
> in the TLS layer.  The alternative is to force every TLS-
> enabled application to solve it (and likely they won't
> solve it and be less secure).  Wouldn't it be ideal if an
> application could just say:
> 
>      TLS::SetSecurityLevel (3);

No, it would not, because, I've now said several times, security is
not expressible via a single metric, making this a complete rathole.

> Currently an application has to do the following:
> 
>     1) configure TLS layer with acceptable cipher suites
>     2) connect to server
>     3) negotiate a TLS session
>        (many applications will stop here)
>     4) check that the negotiated parameters meet the
>        application's idea of good security
>     5) if not, abort TLS session, disconnect, remove
>        some cipher suites from the acceptable list and
>        goto step 1

Again, do you have any evidence this is a problem in practice.
I appreciate it's a potential problem *in theory* but that's
not the same thing.

> It would be much better if all that was needed was to
> replace the TLS library with an updated version.  Or
> better yet, the TLS library may have a plain text
> configuration file for its security levels that could
> be replaced, and all you need to do is restart your
> applications.

And again, this is an API/local isssue. IETF doesn't do
those.

> > Absent some significant evidence that this is a problem in 
> > practice, I'm against the TLS WG doing anything along these
> > lines.
> 
> 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.

> 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.  On my Windows
> machine, it takes 0.02 seconds to generate a public key
> and another 0.02 seconds to compute the secret using
> 1024-bit parameters.  Moving to 2048-bit parameters,
> the computation time increases to 0.15 seconds each.
> 4096-bit computations take 1.1 seconds.  No server
> operator will decrease throughput by a factor of 50
> for everyone, just to accommodate the few who want
> this level of security.  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.

-Ekr

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls