Re: Determining strength of encryption provided by a GSS-API mechanism

[Alexey Melnikov <alexey.melnikov at isode.com>]

Nicolas Williams wrote:

> On Tue, Aug 11, 2009 at 11:42:53PM +0200, Love Hörnquist Åstrand wrote:
>  
>
> > 11 aug 2009 kl. 14:10 skrev Alexey Melnikov:
> >
> >    
> >
> > > Is such API already available
> > >      
> > no
> >    
> Though we've discussed designs for APIs that allow applications to
> request / determine which strength profiles to use / are in use.
>  
Can you provide a pointer?

> > > and if the answer is no, are people interested in working on  
> > > defining it?
> > >      
> > sure, I think the definition of SSF is broken, and its not simple to  
> > understand, racing to yet another higher number seems bad.
> >    
> Indeed.  SSF is bad, bad, bad.
>
> It's not possible to permanently assign a "strength" number to a
> mechanism or "enctype".  Strength is in the eye of the beholder and may
> vary with time.  And users shouldn't, and likely don't, care about
> numeric strength representations -- they should, and probably do, care
> about strength representations in their language, such as "strong",
> names of standards (e.g., "fips140-1"), and so on.
>
> IMO only relative strength should matter,
This is how SSF is used, for the most part. But you are right, there is 
no way to reclassify a cipher as weak using SSF.

> and rather than use numbers we
> should use names of policies, policies that can be created and
> maintained locally or, in the case of policies that correspond to
> standards, delivered by vendors and updated as those standards are
> updated.
>  
Well, if the WG can provide a way to control and determine which ciphers 
are supported, this would be great.

> No, that's not helpful to you: even if we had such GSS APIs you'd still
> have to introduce equivalent SASL APIs and you'd still have to do
> something about SSF for backwards compatibility.
>