Re: [TLS] security levels for TLS

At Fri, 12 Oct 2007 17:18:45 -0700,
Mike wrote:
> >>   - knowing exactly what the client is looking for helps the
> >>     server select the appropriate cipher suite without the need
> >>     for the client to renegotiate the connection; for example,
> >>     if the server only supports 1024-bit DH parameters, and the
> >>     client asks for 1536-bit, the server can skip past the DHE_*
> >>     cipher suites and select maybe an RSA-based cipher suite
> >>     that the client would accept
> > 
> > The server and client already know how to negotiate properly.
> 
> No, they don't.  If a server sees a DHE_* cipher suite in the
> ClientHello, but doesn't know that the client wants 1536-bit
> (or larger) parameters, it may select it, even though it only
> has 1024-bit parameters.  The client would have to renegotiate
> the session without including the DHE cipher suites, which is
> an avoidable waste of computing resources.

Look, this scenario is basically bogus now, and I suspect
in the future.

Nearly all servers have 1024-bit RSA keys signed by 1024-bit
RSA CA keys. If they have DHE, then that's 1024-bit too.
If the client wants 1536-bit anything, it's SOL, and neither
asking for it in its ClientHello nor dropping DHE from its
cipher suites and reconnecting will help. And even if the
server *did* have multiple DHE groups, why would it be
OK from the client's perspective to have those authenticated
with a long-term 1024-bit RSA key? That's part of what 
people have been trying to tell you about absolute security
levels.

Now, one could certainly argue that in the future servers
may have a variety of ephemeral DH parameters, but they're
going to in general want to use the weakest one that's
acceptable to them. Either this extension is mandatory
to comply with (like ECC groups), in which case the client
basically can't set it above 1024 or he won't be able to
talk to most servers, or it's optional, in which case
I would expect servers to ignore it, since it will reduce
their performance and if they wanted stronger keys they
would just use them.

-Ekr

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