Re: [TLS] security levels for TLS

On Thu, Oct 11, 2007 at 08:58:27AM -0700, Eric Rescorla wrote:
> At Thu, 11 Oct 2007 08:39:05 -0700,
> Mike wrote:
> > 
> > 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);
> 
> No, it would not, because, I've now said several times, security is
> not expressible via a single metric, making this a complete rathole.

Agreed.  SASL used to have a notion of "security strength factor" (SSF),
and that was a disaster.

You cannot calculate an _absolute_ and _objective_ measure of security
for anything, least of all cryptographic algorithms subject to future
cryptanalytic advances (i.e., all of them).  (Don't even mention future
quantum computers.)

Basically, the best you could do is have an application choose a
cryptographic profile by descriptive names like "strong" and "fast," but
where the content of such profiles is subject to change over time, and
perhaps even a local matter.  Today "strong" might mean AES-128 is OK,
and tomorrow it might mean only AES-256 is OK, and the next day it might
mean something else, and so on.

> > Currently an application has to do the following:
> > 
> 
> Again, do you have any evidence this is a problem in practice.
> I appreciate it's a potential problem *in theory* but that's
> not the same thing.

The easy answer is to give the application fewer choices, namely a
choice of locally-configured profiles (see above).

In fact, I strongly urge TLS API developers to provide such a facility.

> And again, this is an API/local isssue. IETF doesn't do
> those.

There you go again.  The IETF most certainly deals in APIs.  Though in
this case I think the IETF need not have any specifications requiring or
recommending a facility like I describe above.  If it helps ward off
requests for silly things like "security strength factors" and those are
common enough, then perhaps we should indeed have an information RFC
explaining why we can't and what developers can do instead.

Nico
-- 

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