[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ipsec-ike-01.txt (long)
>>>>> "Sandy" == Sandy Harris <sandy.harris@sympatico.ca> writes:
Sandy> I may be in another minority. One question asked was:
>> should vendors be prohibited from accepting a key length greater
>> than what they have configured?
Sandy> My query would have been whether they should be prohibited
Sandy> from REJECTING a key length greater than they've configured.
Sandy> You configure for, say 128-bit Blowfish. I offer 448. The
Sandy> algorithm costs no more to run with the longer key. Clearly
Sandy> you SHOULD accept. I'd like to see the standard say you MUST
Sandy> accept.
Sandy> This applies to things like Blowfish or RC4, where key size
Sandy> does not affect overhead. It clearly does not apply to things
Sandy> like DES vs. 3DES. I don't think it applies to the groups,
Sandy> since those involve a security.overhead trade-off.
Sandy,
As you well know, some of us (fortunately not you) have to deal with
government restrictions on key length. That means that a particular
product may be required to reject (for example) RC4 keys longer than
56 bits even though longer keys require no more processing. The
reason is not technical but political.
Similarly, in other countries a customer may be prohibited from using
keys longer than, say, 128 bits, so again the implementation would
have to reject your hypothentical proposal of a 448 bit key.
So while I'm comfortable with "should", I cannot accept "must".
paul
Follow-Ups:
References: