Re: des-die-die-die -- "implement" vs "provide",

Tom Yu wrote:
> 
> Simon (and perhaps others) interpret "provide" so that an implementor
> can implement functionality while not providing it, by disabling the
> functionality by default.  I interpret "provide" in this context to
> mean making available in any way, even if the implementor disables it
> by default.  I've replaced "implementations and deployments SHOULD NOT
> provide..." with "implementations and deployments SHOULD NOT implement
> or deploy..." in my copy to avoid any further confusion with "provide".

I'm personally opposed to make any requirements on implementation
details, and I believe that "SHOULD NOT implement" or much worse
"MUST NOT implement" is a clear violation of rfc2119 Section 6
guidance on the use of Imperatives in RFCs.

http://tools.ietf.org/html/rfc2119

   6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.


The imperatives MUST only be applied to behaviour, so
"MUST NOT be enabled by default" because of the potential of causing
harm is OK with rfc2119, but imposing a particular method on an
implementor is *not*, such as "SHOULD NOT implement" or much worse
"MUST NOT implement".

Deployment issues should be dealt with in the security considerations,
and there, a "SHOULD NOT enable single-DES" is perfectly sufficient.


-Martin
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg