Subject: [Ietf-krb-wg] des-die-die-die and RC4

From: Sam Hartman <[email-masked]>
Date: Wed, 15 Feb 2012 12:56:08 -0500

My read is that the rough consensus of the working group is that
deprecating RC4 at this time is not desirable.

I think whether to deprecate export grade RC4 is still an open issue.  I
think that there are no objections at this point, although I'm not
entirely sure of that.  In particular, I think Simon was OK with the
latest proposal from Tom although it sounded like he might prefer to be
silent on the entire issue.

I'd really appreciate comments on whether people want to deprecate
rc4-exp. I think we have a couple of yes's and several nervous
not-quite-objections.  I think that's replacing a couple of yeses, two
objections and several not-quite-objections from earlier in the week.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Wed, 15 Feb 2012 12:18:47 -0600

I am in favor of deprecating RC4-EXP.  I am opposed to deprecating
RC4.  I would be happy to see text saying that RC4 will be deprecated
next or something to similar effect.

Nico
--

---

From: Thomas Maslen <[email-masked]>
Date: Wed, 15 Feb 2012 18:22:46 +0000

> deprecating RC4 at this time is not desirable.

I too am in favour of "at this time, don't deprecate RC4".

> [...] comments on whether people want to deprecate rc4-exp

I don't have a strong preference, but I am mildly in favour of
deprecating rc4-hmac-exp.

Part of the reason I say that is:

Back in about 2005 I got someone to implement it, because I was
worried that we might need to handle it (e.g. maybe from old versions
of Internet Explorer that didn't have the better encryption pack added).
We never got around to actually shipping it in our product, because we
have never run into a case where we needed it;  in the seven years since
then I don't think we've ever seen it in the wild.

In other words, from my (admittedly very skewed) sample, it isn't in
widespread use, so deprecating it won't hurt too many people (anyone?),
and of course _not_ deprecating it may hurt security.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 15 Feb 2012 11:07:09 -0800

On Feb 15, 2012, at 10:18 AM, Nico Williams wrote:

> I am in favor of deprecating RC4-EXP.  

+1 (as long as it doesn't slow the overall draft adoption, which I guess isn't a big deal)

> I am opposed to deprecating
> RC4.  

ATM, concur.

> I would be happy to see text saying that RC4 will be deprecated

OK

> Nico

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

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 17 Feb 2012 01:25:10 +0100

> objections and several not-quite-objections from earlier in the week.

I'm fine with deprecating RC4-EXP and not RC4 if the security
considerations are modified to point at the security considerations of
RFC 4757 instead of saying that RC4 is secure.

/Simon

---

From: Tom Yu <[email-masked]>
Date: Thu, 16 Feb 2012 23:54:49 -0500

> RFC 4757 instead of saying that RC4 is secure.

Please let us know if the latest -03 revision text seems reasonable to
you.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 17 Feb 2012 09:17:08 +0100

> Please let us know if the latest -03 revision text seems reasonable to

The security considerations seems fine now, thank you.

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.

/Simon

---

From: Tom Yu <[email-masked]>
Date: Fri, 17 Feb 2012 08:46:10 -0500

> can do so as an exception to the SHOULD NOT rule and still be compliant

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-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Fri, 17 Feb 2012 08:48:01 -0500

Given Simon's objection we'd need to see support for a change from
implement to provide in order to reach rough consensus on that change.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Tom Yu <[email-masked]>
Date: Fri, 17 Feb 2012 09:36:37 -0500

> implement to provide in order to reach rough consensus on that change.

Even if I were to restore the previous wording (which I think is
equivalent to the current wording from an implementor's standpoint),
Simon seems to have brought up the previously unexplored issue of
distingushing the implementing of a capability at all versus
implementing a capability and disabling it by default.  Do we want to
say something as strongly worded as "implementations SHOULD NOT
implement, even if they disable it by default, and MUST NOT enable by
default"?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 17 Feb 2012 15:39:39 +0100

Tom Yu <[email-masked]> writes:

> 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

---

From: Sam Hartman <[email-masked]>
Date: Fri, 17 Feb 2012 10:42:08 -0500

>>>>> "Tom" == Tom Yu <[email-masked]> writes:

    Tom> Sam Hartman <[email-masked]> writes:
    >> Given Simon's objection we'd need to see support for a change
    >> from implement to provide in order to reach rough consensus on
    >> that change.

    Tom> Even if I were to restore the previous wording (which I think
    Tom> is equivalent to the current wording from an implementor's
    Tom> standpoint), Simon seems to have brought up the previously
    Tom> unexplored issue of distingushing the implementing of a
    Tom> capability at all versus implementing a capability and
    Tom> disabling it by default.  Do we want to say something as
    Tom> strongly worded as "implementations SHOULD NOT implement, even
    Tom> if they disable it by default, and MUST NOT enable by default"?

As chair, we want to say what 02 said unless we have consensus to do something
else.

As an individual, I support the text you and simon seem to be discussing.  I do not
support introducing MUST NOT enable by default at this time in the
document life cycle, assuming that my understanding that we've
previously discussed implementation is correct.

---

From: Tom Yu <[email-masked]>
Date: Fri, 17 Feb 2012 10:48:46 -0500

> me.  I read "provide" to permit implementing but disabling by default.

To me, a capability that is implemented but is disabled by default is
still available, and thus still provided.

Imagine changing the "SHOULD NOT" to a "MUST NOT".  I think it's
reasonable to say that given a specification that says "MUST NOT
provide DES", an implementation that implements DES capability but
disables it by default nevertheless still provides it and would _not_
conform.

> implement" which also seems preferrable, thus this change surprised me.

I think there's no difference between "implement" and "provide" from
the perspective of an implementor, but the fact that you appear to
think that there is a difference implies that we do not yet have
consensus about whether to specify that certain capabilities SHOULD
NOT or MUST NOT be enabled by default.  I suspect that if we have
consensus to say something about default behavior, we would also have
consensus to say "MUST NOT enable weak crypto by default".

Do you believe that we should say something explicit about
requirements for default behavior?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 17 Feb 2012 09:33:16 -0800

If it weren't for the need (for a little longer) to support a compile-time option for 1-DES compatibility with AFS, I'd be fine with an even stronger MUST NOT implement, provide, or on any other way allow kind of provision.  If AFS doesn't get workable rxgk support soon that alone may kill it.

---

From: Nico Williams <[email-masked]>
Date: Fri, 17 Feb 2012 12:54:13 -0600

There are still parts of the world where 1DES is in use because of
legacy reasons.

I want to deprecate 1DES.  I'm not sure I want to say MUST NOT implement.

I want MUST be disabled by default if implemented.  I'm happy with
SHOULD NOT implement.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Martin Rex <[email-masked]>
Date: Fri, 17 Feb 2012 20:28:23 +0100 (MET)

I'm fine with deprecating 1DES and RC4-40/RC4-56,
and believe the RC4-128 based enctype will still be needed for interop
for a couple of years.

Actually, I would prefer the document to use a different quoting:

   "export strength RC4"  or "40-bit RC4 (RC4_EXP)"

rather than

   "export strength" RC4

I'm strongly opposed to "MUST NOT implement".
Personally I prefer "SHOULD have disabled by default", but would be OK
with "MUST have disable by default", eg.

"The use of 1DES or "export strength RC" enctypes is strongly discouraged.
Implementations that provide these enctypes, MUST have them disabled by
default.

-Martin

---

From: Jeffrey Altman <[email-masked]>
Date: Fri, 17 Feb 2012 14:39:16 -0500

> If it weren't for the need (for a little longer) to support a compile-time option for 1-DES compatibility with AFS, I'd be fine with an even stronger MUST NOT implement, provide, or on any other wa…

Whether SHOULD NOT or MUST NOT is used should not be determined by the
needs of any one application that is currently deployed or might be
deployed in the future.

This specification only impacts software that is developed and deployed
after the specification is published.  Organizations are always going to
have to provide back level compatibility for existing deployments.

Jeffrey Altman

---

From: Tom Yu <[email-masked]>
Date: Fri, 17 Feb 2012 14:41:57 -0500

> and believe the RC4-128 based enctype will still be needed for interop

I am not recalling Microsoft releasing any RC4 variant that has a
40-bit key size, and RFC 4757 seems to specify a 56-bit variant, not a
40-bit variant.

>    "export strength RC4"  or "40-bit RC4 (RC4_EXP)"

What semantic difference would you want to imply by making such a
change?  (I assume you mean changing the quoting in both the title and
the body.)
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Simo Sorce <[email-masked]>
Date: Fri, 17 Feb 2012 14:46:00 -0500

> have to provide back level compatibility for existing deployments.

Well, implementations are also free to violate standards, but new
software may still need to interop. with old one.

The problem here is that a "MUST NOT implement" clause would have only
one possible escape for practical implementations: violation of the
standard.

I do not think it is reasonable for a standard to dictate a behavior
that it is know in advance no serious implementation can respect at
least for some time to come.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 17 Feb 2012 12:11:27 -0800

> needs of any one application that is currently deployed or might be

Other people have pointed out off-list that there are other things.  Also I must admit we have a lot of Solaris 9 machines around.

> have to provide back level compatibility for existing deployments.

My concern is that 1) we make the deprecation as strong as possible, but 2) we not label a new implementation "not Kerberos" just because it has some optional backward-compatibility feature needed e.g. by current AFS.  All of the discussed wordings are acceptable compromises IMO, however much I might want something stronger.

---

From: Martin Rex <[email-masked]>
Date: Fri, 17 Feb 2012 21:24:34 +0100 (MET)

> 40-bit key size, and RFC 4757 seems to specify a 56-bit variant, not a

I'm sorry, you're right.

I was confused by this statement:

          OCTET L40[14] = "fortybits";

but the actual truncation of the RC4 key is this:

          if (export) memset (K1+7, 0xAB, 9);

which flattens 9 of 16 octets (and therefore leave 7 octets = 56 bits).

> change?  (I assume you mean changing the quoting in both the title and

The latter could be interpreted that RC4 is "export strength",
although the term "export strength" is not an attribute to RC4 in
general, but to variants of RC4 with a purposely short (or truncated) key.

Not everyone is aware what "export strength" means.
With respect to RC4 export strength was originally 40(!) bit.

-Martin

---

From: Tom Yu <[email-masked]>
Date: Fri, 17 Feb 2012 16:58:51 -0500

> which flattens 9 of 16 octets (and therefore leave 7 octets = 56 bits).

I previously had the same sort of confusion, and wrote text pointing
out that 40 bits is small enough to be easily brute-forced by
consumer-grade hardware before realizing my mistake.

> With respect to RC4 export strength was originally 40(!) bit.

Right, because SSL originally had an exportable RC4 variant with
40-bit keys?  I guess the meaning of "export strength RC4" is clear in
the context of Kerberos, but ambiguous with respect to RC4 in general.

I could change the title to "Deprecate DES, RC4-HMAC-EXP, and other
weak cryptographic algorithms in Kerberos", along with a similar
change to the Abstract.  I could also add some disambiguating text to
other occurrences of "export strength" to emphasize that it's a
variant of RC4 that has 56-bit keys.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Fri, 17 Feb 2012 18:00:52 -0500

As an individual, I  support the clarification along the lines of what you and martin are requesting.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Martin Rex <[email-masked]>
Date: Sat, 18 Feb 2012 05:30:29 +0100 (MET)

Tom Yu wrote:
> Martin Rex wrote:
 
Clarifying it _somehow_ in title an abstract would be
sufficient to make me happy.  I'm not addicted to any
specific fashion or term.   RC4-HMAC-EXP sounds good to me. 

-Martin