Re: des-die-die-die and RC4

Tom Yu <[email protected]> writes:

> 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.

That would work for me, as would the simpler 'Kerberos implementations
and deployments SHOULD not implement/deploy ...' if you are unhappy with
the -02 variant.

> We can split hairs about whether to "provide" means to implement at
> all, versus to enable by default

I support the document being as clear as possible what is intended
rather than leaving such interpretations up to readers.

Saying that "implementations SHOULD NOT implement" makes it easy to test
whether a particular implementation has code for a particular algorithm
or not.  Saying "implementaters SHOULD NOT provide" appears weaker to
me.  I read "provide" to permit implementing but disabling by default.

I thought we had consensus on the stronger wording to "SHOULD NOT
implement" which also seems preferrable, thus this change surprised me.

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