[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Interoperability (was: Death to AH?)
>>>>> "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.
Follow-Ups:
References: