Re: [TLS] security levels for TLS

At Fri, 12 Oct 2007 16:15:22 -0700,
Mike wrote:
> 
> >>> Confusing and/or giving users false senses of security are definitely
> >>> negative.
> >> Actually I think the latter sentence describes the current situation!
> > 
> > How so? Nothing at all stops you from putting any indicator you
> > like in your code. Why does IETF have to standardize it?
> 
> I think there is some mis-communication going on.  I have never
> even mentioned the IETF standardizing an "indicator" of security
> level.  Someone else may have, but I reject that idea as well.

Well, two things seem to be being discussed simultaneously:

1. Standardizing simplified "levels" of security which correspond to 
   cipher suites and key sizes.

   E.g., STRONG would be symmetric algorithm X or Y with asymmetric
	 algorithm A and key size a or asymmetric algorithm B with
	 key size b.

	 MEDIUM is symmetric algorithm W with asymmetric algorithm
	 A with key size a' or asymmetric algorithm B with key size
	 b'.

    This is purely a documentation issue and doesn't require any
    on-the-wire changes to TLS. 

2. Modifying TLS to allow the client to indicate the size of the
   keys/group it would like for each asymmetric algorithm. This
   is an on-the-wire protocol change. 

As I understand your messages, you've been endorsing both of these.

I'm against both of these, for related, but distinct reasons.

I'm against the former because I think it's actually very hard to
produce any reasonable standardized account of which algorithms and
key sizes fit into which level. In any case, this is something that an
implementation can easily offer without any standard, it simply will
not necessarily have the same level->algorithm mapping as another
implementation.

I'm against the second because I believe it adds marginal benefit
at a significant cost to interoperability and complexity. An 
extension like this only makes sense if:

1. Servers have a number of different kinds of keying material
   of different strengths.
2. Clients are in a position to make intelligent choices about
   which asymmetric key strengths are appropriate.

In my experience, neither is true. Moreover, it's worth noting
that in the current environment any client which attempts to
request a key > 1024 bits will find that it can connect to
practically nobody. To a first order, this is just another
way to create interop problems. 

With regard to key lengths: as I indicated before, the dominant
security issue in systems of this kind is quality of implementation
and maintenance. If you don't trust the server to choose appropriate
key sizes, why on earth would you trust that it's not chock full
of remote vulnerabilities?

-Ekr

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