Re: [TLS] security levels for TLS

[Mike <[e-mail]>]

>> How long do you think it would take
>> to add this extension to a TLS toolkit?  In my own code, I could
>> probably do it in less than a day, with time left over to get in a
>> round of 18 holes.
> 
> No doubt. Of what positive and negative value would such code be?

Positives:

   - 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
   - a server could support multiple sets of Diffie-Hellman
     parameters, such as all of the groups in RFC 3526; a client
     could choose the parameters rather than being forced to
     accept the server's default (which is probably chosen more
     for performance than security)
   - 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
   - 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
   - hash agility (or now signature algorithm agility) is being
     added to TLS; this is cryptographic strength agility
   - a client is free to develop its own security profiles; no
     "standard" profiles would be defined
   - 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

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?

> Confusing and/or giving users false senses of security are definitely 
> negative.

Fully agreed.  I don't see how this would be confusing or give
a false sense of security.  The client still has to check that
the requested key lengths (and other parameters it cares about)
are satisfied in the negotiated session.

Mike


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