Re: [TLS] security levels for TLS

[Mike <[e-mail]>]

>>   - this would allow a server to maintain multiple sets of keys
>>     and certificate chains of varying cryptographic strength;
>>     clients with differing requirements could ask for the level
>>     they desire, instead of being stuck with the lowest common
>>     denominator
> 
> It can do things like this today.

How?  The ClientHello only has a list of cipher suites to go by,
and they don't specify the sizes of the asymmetric keys.

[You removed the benefit of being able to specify the size of DH
parameters, so I'll assume you know you can't currently do that
today.  That alone is worth adding this extension, in my opinion.]

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

>>   - this mechanism would give power to the client that it
>>     currently doesn't have, to directly influence the crypto-
>>     graphic strength of the connection beyond simply listing
>>     acceptable cipher suites
> 
> The client already can negotiate from what it's willing to accept, and
> that's sufficient.

Instead of "sufficient" I would say it is "tolerable, but lacking."

>>   - hash agility (or now signature algorithm agility) is being
>>     added to TLS; this is cryptographic strength agility
> 
> You're ignoring everything we've been telling you about why absolute
> security measurements of ciphersuites are not a good idea.

I've never said anything about absolute security measurements.
Why are all the security experts against specifying the relevant
parameters?  Why is it wrong for a TLS client to tell the server
that it wants to use 2048-bit RSA keys?

>>   - a client is free to develop its own security profiles; no
>>     "standard" profiles would be defined
> 
> The client and server are already free to do so.

Right, but if the profile says, "accept 2048-bit RSA keys,"
there is no way for the client to tell the server that that is
what it wants.

>>   - a server can keep statistics on the values it receives,
>>     allowing an administrator to know when it would make sense
>>     to add support for longer keys, based on actual demand
> 
> The server can already do this.

How can it do that if this extension doesn't even exist?

>> Negatives:
>>
>>   - effort is needed to write a specification and approve it
>>   - a server may not support the extension, so a client may
>>     have to implement an inefficient renegotiation scheme in
>>     addition anyway
>>   - Eric doesn't like it ;-)
>>   - Others?
> 
> This is not about personal preferences.

That's why I put a wink after it.

> We're telling you this is not
> needed and that fixed absolute cryptographic strength numbers are
> neither feasible nor a good idea.

Again with the "fixed absolute cryptographic strength numbers."
I have never said anything about that.

Need is a crazy thing.  Nobody needed a camera in their cell
phone just a few years ago, but it's now hard to find one
without a camera (in the U.S. at least).

Mike


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