Re: [TLS] security levels for TLS

[Eric Rescorla <[e-mail]>]

At Fri, 12 Oct 2007 18:14:38 -0700,
Mike wrote:
> 
> >> 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.
> > 
> >     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 said above that I reject the idea of standardizing levels.  Why
> don't you believe that? 

Maybe because your writing has been fairly unclear. I read the following
as such an endorsement:

    I think there is good reason to try to solve this problem
    in the TLS layer.  The alternative is to force every TLS-
    enabled application to solve it (and likely they won't
    solve it and be less secure).  Wouldn't it be ideal if an
    application could just say:

         TLS::SetSecurityLevel (3);

If you say it's not, I believe you.

> > 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 said in one of my first messages that this would be implementation
> dependent.

That wasn't clear to me, but fine.


> > 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. 
> 
> Well if you implement TLS 1.1 and expect to connect to anyone,
> you will be disappointed, and yet we're working even on TLS 1.2.

Yes, because it was felt that the attacks on MD5 and SHA-1 
created an important need. Prior to those attacks, I had
every intention of taking TLS 1.1 to draft standard without
change.

-Ekr


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