Re: [TLS] security levels for TLS

[Mike <[e-mail]>]

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);

and know that the resulting connection will either meet
the (implementation-dependent) criteria for that level of
security, or the TLS negotiation will fail?

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

This is inefficient and error-prone, and makes it much
harder to know how secure your IT infrastructure as a
whole is since there are as many points of failure as
there are applications.  Also as attacks improve and the
security requirements change, every application needs to
be reexamined and modified.

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.

> 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!).  The W3C is also
attempting to solve this problem, but the need extends
beyond HTTPS.

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.

Mike


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