Re: [TLS] security levels for TLS

>> 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.

Right, and I want to fix that.

> 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.

Everyone uses 1024-bits because everyone else uses 1024-bits,
and they feel a sense of security in numbers.  In other words
they can't be fired if something goes wrong because the whole
industry does it.

> 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.

As we've both noted there are performance/security tradeoffs,
and I believe the client is in a better position to decide
what level of security is desired for any given transaction.
The server doesn't know what operations the client is going
to be requesting until after TLS is negotiated.

Mike

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