Re: [TLS] security levels for TLS

[Mike <[e-mail]>]

>> Right now all cipher suites are under-specified.  If we had,
>> for example:
>>
>>      TLS_DHE_1024_RSA_2048_WITH_AES_128_CBC_SHA
>>
>> we would probably not be talking about this.  I proposed that
>> we let clients "fill in the blanks" that the cipher suites
>> don't specify.  Isn't it better to tell the server exactly
>> what you want in terms of security, than to leave it up to
>> chance?
> 
> Arguably, it would have been, but it's not the way that the
> system is now....

I thought of an easier way to achieve this that should be less
controversial and simple to implement.  As an extension, it
would be completely optional as well, but I believe it would
be widely implemented:

     enum {
         diffie_hellman_parameter (0),
         server_rsa_key           (1),
         ca_rsa_key               (2),
         server_dsa_key           (3),
         ca_dsa_key               (4),
         ....
         (65535)
     } KeyType;

     struct {
         KeyType    key_type;
         uint24     preferred_size;
     } PreferredKeySize;

     struct {
         PreferredKeySize sizes<0..2^16-1>;
     } PreferredKeySizeExtension;

A server that understands this extension would reply with an
empty extension_data.  The server would do its best to select
keys, certificate chains, and DH parameters to satisfy the
client's request.  If it is unable or unwilling to do so, the
negotiation should proceed giving the client the opportunity
to accept weaker parameters than it asked for.  (Or a boolean
value could be added to the extension indicating whether the
client might accept weaker parameters; if not, the server
could immediately send a fatal insufficient_security alert.)

 > and I haven't seen an argument that this
 > needs to change..

The server's response would let the client know that it would
be a waste of time to try negotiating again with different
cipher suites if it found the key lengths to be unacceptable.
Clients and servers would spend less time performing fruitless
renegotiations, which would reduce server throughput.  This
seems like a good argument to me.

Mike


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