[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Interoperability (was: Death to AH?)

  I wasn't proposing to accept 3des when configured for des, that's
a simple == or != issue, what I was proposing is some guidelines
for those variables that aren't simple == or !=, those that can
be >, <, >= or <= like keylength or lifetime. Diffie-Hellman
groups got added on but they seem to be a simple == or !=
issue too.

  Dan.

On Mon, 05 Jun 2000 14:02:50 EDT you wrote
> >>>>> "Scott" == Scott G Kelly <skelly@redcreek.com> writes:
> 
>  Scott> Paul Koning wrote:
>  >>  >>>>> "Dan" == Dan Harkins <dharkins@cips.nokia.com> writes:
>  Dan> Quite a while ago I attempted to define an approach to deal with
>  Dan> things like lifetimes and key lengths and other attributes that
>  Dan> do not have a simple boolean acceptance criteria and
>  Dan> failed. There was no consensus.  But I'm willing to try again:
>  >>
>  Dan> If someone offers you a keylength for a variable-keylenght
>  Dan> cipher which is greater than or equal to what you have
>  Dan> configured, accept it. If it's less reject it.
> 
>  >>  I'd support that.
> 
>  Scott> I argued this point at length with Dan around a year ago (or
>  Scott> so). My original position was that we shouldn't write the ike
>  Scott> standard such that the admin could not control whether this
>  Scott> occurred or not. Dan argued that In the case of Blowfish, it
>  Scott> requires no more work to use a longer key than a shorter
>  Scott> one. We never finished the debate. I think I agree with Dan
>  Scott> when it comes to crypto algorithms like Blowfish, i.e. when
>  Scott> increasing the key length does not affect the load on the
>  Scott> machine. On the other hand, I'm not sure that increasing to
>  Scott> 3des when des is configured is the right thing to do, though
>  Scott> I'm willing to consider other points of view.
> 
>  Scott> I think there is a definite issue with DH values though: if I
>  Scott> am configured to accept group 2, sending me group 5 most
>  Scott> definitely affects my work load in a significant way. This has
>  Scott> DoS implications. That being the case, it might be better to
>  Scott> make this a local decision.
> 
> Fair enough.  And for some implementations the same would be true for
> DES vs. 3DES (while for others it would not be -- if you have a
> hardware assist that's bus or network bound, for example).
> 
> Is the only problem one of specifying that this "allow upgrading to
> stronger ciphers" may be enabled or disabled as a policy matter if the
> implementation wishes to do that?  If so, that sounds entirely
> reasonable to me.  The impression I got from Dan's comment is that
> there was some opposition to the entire notion, which is harder to
> understand. 
> 
> Right now there's no text at all that describes this stuff.  I suppose
> you could argue that it's a local matter -- people are allowed to do
> this if they feel like it.  Probably so... but it seems useful to make
> it a recommended practice subject to some caveats about possible
> performance issues in at least some of the cases.
> 
>     paul
> 
> PS. Dan, your return address is not working... email to it keeps
> bouncing.
-- 

John C. Kelley
Computer Scientist
NAILabs at Network Associates, Inc.
Glenwood, MD
Follow-Ups: References: