Re: [TLS] security levels for TLS

[Nicolas Williams <[e-mail]>]

On Fri, Oct 12, 2007 at 02:41:51PM -0700, Mike wrote:
> >>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

It can do things like this today.

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

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

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

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

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

> 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.  We're telling you this is not
needed and that fixed absolute cryptographic strength numbers are
neither feasible nor a good idea.

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

Eric points out that local policy is sufficient to achieve what you
want.  I do think that a standard way to describe security policies for
TLS and other protocols might be useful for distributing policy, but at
the end of the day that'd still be _local_ policy, with no changes to
TLS being required.

Nico
-- 


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