Subject: [Ietf-krb-wg] des-die-die-die -- "implement" vs "provide", and default behavior

From: Tom Yu <[email-masked]>
Date: Mon, 20 Feb 2012 16:20:59 -0500

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 believe that we have consensus that the "SHOULD NOT" applies to
making the weak crypto available at all in an implementation, even if
the default configuration disables the weak crypto.  I think that at
this time, practical implementations that need to provide backward
compatibility will probably implement the weak crypto and disable it
by default.

I think it would help the document move more quickly if we continue to
say nothing about default behavior (even though it might be
interesting or helpful to do so), because I'm not sure we can quickly
reach consensus on whether an implementation "SHOULD NOT" or "MUST
NOT" enable weak crypto by default if implements it.

Simon and Chairs, does the above seem reasonable?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 20 Feb 2012 17:44:46 -0500

On Mon, 2012-02-20 at 16:20 -0500, Tom Yu wrote:
> the default configuration disables the weak crypto.

Yes; I believe we have a preexisting consensus on the language which was
in -02.  This certainly was not an issue that was raised during the
first WGLC.

>   I think that at

Sam is on vacation at the moment.

Reverting to the language in -02, which used "SHOULD NOT implement", is
reasonable.  As Sam already mentioned, doing anything else requires an
explicit consensus for the change.  That includes...

- Adding deployment advice
- Adding advice about default behavior

Anyone want to speak up on these points?

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Tue, 21 Feb 2012 16:41:53 +0100 (MET)

> 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

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 29 Feb 2012 09:18:01 +0100

> Simon and Chairs, does the above seem reasonable?

The -04 document seems fine to me, thank you.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 29 Feb 2012 09:22:07 +0100

>    on implementors where the method is not required for

I believe implementing and deploying single-DES has the potential for
causing harm, so a MUST NOT imperative would be acceptable as far as my
reading of RFC 2119 is concerned.  I'm hoping the only reason we use the
weaker SHOULD NOT instead of MUST NOT in this document is that there are
still some legacy environments around.

/Simon

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 29 Feb 2012 10:50:43 -0800

I'm OK with any of the proposed wordings.

I really don't want to drag this out with endless discussions.  Whatever the exact phraseology, I think the intent to get rid of single-DES is clear.  I also expect the implementations will keep sufficient (undesirable) backward compatibility capabilities around somewhere for as long as is needed.

That said, and given the liklihood of non-native-english speakers reading the spec, if there is further disagreement we should not rely on precise interpretation of 2119 language.  We should just write a paragraph on the subject and spell out what we mean.

> still some legacy environments around.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 Feb 2012 12:59:13 -0600

> still some legacy environments around.

Agreed, there's nothing in RFC2119 to prevent deprecation and even
MUST NOT.  However, I do believe that interop with legacy is still
important in many cases, enough to warrant the SHOULD NOT instead of
MUST NOT.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Mar 2012 02:21:35 +0100 (MET)

I'm OK with the current SHOULD NOT in the document.

> still some legacy environments around.

You interpretation of "potential for causing harm" is _far_ outside
of the intended meaning of rfc2119 section 6, and not having a protocol
feature enabled by default that provides interop with an old installed
base is perfectly sufficient to prevent harm, an the latter is what
is meant by "they must not be used to ry to impose a particular
method on implementors".

If the spec says "must not enable by default", then it is at the discretion
of the implementor whether to implement it for backwards interop with
an old installed base or whether to not implement it at all, while
a spec saying "MUST NOT implement" imposes a particular method on
an implementor that is unnecessary.

With your reading, the IETF would have to publish an RFC that says
"MUST NOT implement HTTP over TCP without TLS".

And further it would have to specify "MUST NOT use TLS with several
dozens of trust anchors preconfigured by software vendors",
because we have proof just how much serious harm that may cause.

-Martin

---

From: Thomas Maslen <[email-masked]>
Date: Thu, 1 Mar 2012 02:29:36 +0000

On Wed, Feb 29, 2012 at 10:59 AM, Nico Williams <[email-masked]> wrote:
[...]
> However, I do believe that interop with legacy is still

I agree.