Re: des-die-die-die and RC4

Simon Josefsson <[email protected]> writes:

> I noticed another change in -03 though.  Instead of saying that
> implementions and deployments SHOULD NOT "implement" the deprecated
> ciphers the document now says they SHOULD NOT "provide" them.  What is
> the difference?  It strikes me as "provide" is more ambigious than
> "implement".  For example, is it OK to "provide" these ciphers as a
> non-default and still be compliant with the SHOULD NOT?  The document
> didn't use to allow that.  I don't recall any discussions around this
> change.  Since we use SHOULD NOT instead of MUST NOT I believe we could
> use the harder language of "implement" instead of "provide".
> Implementations that wants to provide optional backwards compatibility
> can do so as an exception to the SHOULD NOT rule and still be compliant
> with the document.

I could reword it to "implementers SHOULD NOT implement, and deployers
SHOULD NOT deploy..." if people would prefer.  We can split hairs
about whether to "provide" means to implement at all, versus to enable
by default, but I believe we typically use SHOULD NOT to mean "don't
do this at all unless you have a good reason" (my paraphrase of RFC
2119).  It would be up to the judgment of the implementor whether to
implement a SHOULD NOT capability that they disable by default, or
whether they omit that capability completely.

Implementors implement.  Deployers deploy.  Despite the phrasing that
many people in IT like to use, deployers do not implement[1] software
functionality; they deploy it, and the document used to say
"implementors and deployers SHOULD NOT implement...".  I view the word
"provide" as encompassing both.  In practice, I believe we in the IETF
care mostly about how the deployed implementations _behave_ on the
network, and care less about the details of the implementation.

Developers can't provide a capability in software if the the software
doesn't implement it.  I suppose, by some definitions, developers
could implement a capability in software but not provide it, by
leaving no way for a deployer to enable the capability, but that would
involve leaving dead code in the software, which is typically not a
software development best practice.

[1] I guess technically, deployers can implement a deployment plan for
a piece of software, and this is typically what IT managers mean when
they say things like "XYZ organization implemented SAP" (when the
organization isn't actually SAP itself), but I strongly dislike that
usage.
_______________________________________________
ietf-krb-wg mailing list
[email protected]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg