[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on draft-ietf-ipsec-ike-01.txt (long)
"David W. Faucher" wrote:
> > >> So let me ask the entire working group: should vendors be
> > >> prohibited from accepting a key length greater than what they have
> > >> configured? Should they be prohibited from accepting a stronger
> > >> group?
> >
>
> I may be in the minority here but I see this as an implementation
> issue. I would argue that a system should be configured to provide
> a level of security comparable to the value of the information
> being protected. Overriding that configuration just because it is
> capable doesn't necessarily mean it should.
>
> I'm not arguing for prohibiting such behavior. I'm just not for
> recommending it. If an implementation chooses to accept such
> behavior that fine. On the other hand, an implementation could
> just as easily allow such behavior to be configured.
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?
My query would have been whether they should be prohibited
from REJECTING a key length greater than they've configured.
You configure for, say 128-bit Blowfish. I offer 448. The
algorithm costs no more to run with the longer key. Clearly
you SHOULD accept. I'd like to see the standard say you MUST
accept.
This applies to things like Blowfish or RC4, where key size
does not affect overhead. It clearly does not apply to things
like DES vs. 3DES. I don't think it applies to the groups,
since those involve a security.overhead trade-off.
Follow-Ups:
References: