Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Paul" == Paul Hoffman </ VPNC <paul.hoffman@vpnc.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
have 3DES.

     paul