Subject: [Ietf-krb-wg] WG Last Call: draft-lha-des-die-die-die-02

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 25 Mar 2010 12:05:28 -0700

This note announces the start of a two-week last call within the Kerberos
Working Group on whether to send the following document to the IESG:

Title:           Deprecate DES support for Kerberos
Filename:        draft-lha-des-die-die-die-02.txt
Intended Status: Standards Track

   A long long time ago DES was standardized.  Some 30 years later
   (2003) is was withdrawn as a standard by NIST, today 6 years later,
   its time for DES to finally die.  By 2008 it was possible to brute
   force DES keys in 6.4 days using less than USD 10k worth of hardware.
   So by 2008 DES had passed its sell-by date.  Use in Kerberos should
   therefore stop.

Due to the ongoing IETF meeting, I am extending this last call by a few 
days.  It will expire at 23:59 EDT on April 12, 2010.

Please review this document and send any comments to the Kerberos Working
Group mailing list, <[email-masked]>, by that date.  The file can be
obtained via

http://tools.ietf.org/html/draft-lha-des-die-die-die-02.txt

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Co-Chair, IETF Kerberos Working Group
   Carnegie Mellon University - Pittsburgh, PA

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

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 25 Mar 2010 21:58:57 +0100

Quoting section 3:

   Kerberos implementation and deployments SHOULD NOT implement the
   checksum type: CRC, RSA-MD4, RSA-MD4-DES, RSA-MAC, RSA-MAC-K, RSA-
   MD5, RSA-MD5-DES.

'CRC' should be 'CRC32'.

Add 'RSA-MD4-DES-K'.

'RSA-MAC' should be 'DES-MAC'.

'RSA-MAC-K' should be 'DES-MAC-K'.

Quoting section "5. Security Considerations":

   Removing support for single DES improves security since DES is
   considered to be insecure by most parties.

What parties considers DES secure?

/Simon

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Thu, 25 Mar 2010 14:38:37 -0700

Thanks,

Changed with your comments, also added the IANA assigned numbers to the list to make sure there is no confusion what I mean.

http://www.ietf.org/id/draft-lha-des-die-die-die-03.txt

Love

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 25 Mar 2010 19:08:23 -0700

> What parties considers DES secure?

I first read that as *in-*secure.  To answer the question as actually asked, I'd say nobody. 

(Unless, perhaps, they have some specific deployment scenario which would prevent off-line search.  Kerberos doesn't meet that requirement.)

------------------------------------------------------
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, 26 Mar 2010 09:04:01 +0100

> I first read that as *in-*secure.  To answer the question as actually

That was my point -- if we can get consensus around "nobody", the
document should say that instead of implying that some parties still
regard DES as secure.

/Simon

---

From: Tom Yu <[email-masked]>
Date: Fri, 26 Mar 2010 14:07:27 -0400

> document should say that instead of implying that some parties still

I'm sure some people still regard DES as secure.  After all, it's
better than cleartext or rot-13.  Though arguably, a false sense of
security is worse than no security.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 26 Mar 2010 18:21:04 -0700

Following are my comments from review of -03:

Abstract:

The acronym NIST must be expanded on first use.

The abstract should explicitly state what it updates:

OLD:
   Use in Kerberos should therefore stop.

NEW:
   This document updates RFC1964, RFC4120, and RFC4121 to deprecate
   the use of DES in Kerberos.

Section 2:

... and again here, as the abstract and body are independent.
Also, GSS-API needs to be expanded here.

Section 3:

>  This document removes the mandatory-to-implement types from
>  [RFC4120]: Encryption: DES-CBC-MD5(3)

That enctype is not mandatory-to-implement in RFC4120; it is only
RECOMMENDED.  Suggest s/mandatory-to-implement/RECOMMENDED/.

>  This document removes the mandatory-to-implement types from [RFC4120]
>  when used in conjunction with DES-CBC-MD5: Checksums: DES-MD5(7)

There is some confusion here.  RFC4120 refers repeatedly to a cksumtype
of the name "DES-MD5", but there is in fact no such cksumtype.  The
mandatory-to-implement cksumtype for DES-CBC-MD5 is actually named
RSA-MD5-DES and has cksumtype 8; this is not the same as RSA-MD5(7).

Further, RFC4120 does not actually make RSA-MD5-DES mandatory-to-implement
with DES-CBC-MD5; RFC3961 does that, and should continue to do so.  We
don't want people to use DES-CBC-MD5 with Kerberos any more, but if it
is implemented, then we still want implementation of RSA-MD5-DES to be
REQUIRED, for interoperability.

I suggest removing this paragraph entirely, and instead adding to the
previous paragraph:

   Checksums: DES-MD5 (8, RSA-MD5-DES from [RFC3961])

Once we've done this, I do not believe this document updates RFC3961.

>  Kerberos GSS mechanism implementation and deployments SHOULD NOT
>  implement the SGN ALG: DES MAC MD5, MD2.5, DES MAC.
>
>  Kerberos GSS mechanism implementation and deployments SHOULD NOT
>  implement the SEAL ALG: DES.

Heh.  This fully deprecates RFC1964 section 1.2.  Following this
recommendation should considerably simplify implementations.

Section 6:

>  There are no IANA Considerations for this document

Technically true, since the IANA registry does not record the state
of registered enctypes and cksumtypes.  I wonder if maybe it should,
but that's not really in scope of this.

Section 7:

This document updates RFC4121, and certainly one must have read that
document to understand why it is OK to deprecate all of the SGN and
SEAL algorithms defined in RFC1964.  Therefore, I believe the reference
to be normative.

The idnits tool found the following problems:

== You're using the IETF Trust Provisions' Section 6.b License Notice from
   12 Sep 2009 rather than the newer Notice from 28 Dec 2009.  (See
   http://trustee.ietf.org/license-info/)

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Fri, 26 Mar 2010 23:04:09 -0700

Jeff,

Thanks, merged in comments.

http://www.ietf.org/id/draft-lha-des-die-die-die-04.txt

Love