[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms
>>>>> "Paul" == Paul Hoffman </ VPNC <firstname.lastname@example.org>> writes:
Paul> Greetings again. The tables in
Paul> draft-ietf-ipsec-ikev2-algorithms have MUST, SHOULD, MUST-,
Paul> SHOULD+, SHOULD- (which I have proposed removing), and MAY. The
Paul> MAY designation is silly, since an implementation MAY do
Paul> whatever it pleases for non-mandatory algorithms.
Paul> The reason I bring this up was the proposal that DES should be
Paul> demoted to SHOULD NOT. That is somewhat harsh given that there
Paul> are places where DES is appropriate (low value transactions in
Paul> implementations that already have DES in them). Listing DES as
Paul> "MAY" gives the wrong impression.
So what is wrong with "SHOULD NOT"?
Two points. First, "SHOULD NOT" permits the implementation to do the
thing being discouraged, but it explicitly warns that one must first
consider whether it's wise to do so. I think that is exactly the
correct message for DES.
Second, what implementation already has DES that doesn't also have
3DES? I'm hard pressed to think of any. In a software
implementation, 3DES is of course quite slow, but if so, the sensible
answer is AES, which is faster than either. In a hardware
implementation, you're stuck with what's in the chip, but if so, you