Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt]

From: Sean Turner <[email-masked]>
Date: Tue, 06 Jul 2010 12:40:21 -0400

To summarize the comments I received on this I-D:

1) Finally!

2) Is there any precedent with moving informational to historic.

Russ suggested I ask Scott Bradner what he thought about this.  His
response (repeated here with permission):

"1/ my personal view is that historic should be only used for
  cases where we want to say 'do not use'

  2/ seems like a reasonable thing to do in this case

  fwiw, I have always felt that it is important to document
  any such move that is done for a real reason (not just because
  people think it is not used) with a RFC"

I'd consider this support for moving informational RFCs to historic.

3) Why target MD2?

This was really a trial balloon.  I'm planning on doing something with
MD4 and MD5 too ;)

4) It's better to have a security algorithms roadmap.

I tend to agree, but I thought I was shooting for the low hanging fruit.

5) Remove keywords and delete obsolete references.

Anything to track less references is a good thing!

6) Do an updates document instead, because there might still be other
uses for MD2/MD4/MD5 that don't require collision resistance (e.g., HMAC).

I'd like to treat MD2/MD4/MD5 the same, but some HMAC uses are
probably still okay for a little while (at least that what's I'm
turning up through research). But, I can't really see us saying that
HAMC-MD2 and HMAC-MD4 are okay to keep using in the mid/long term.  I
think we ought to be saying "jump off the sinking ship now" because it
takes a while for crypto to go away just like it does to get fielded.
  Luckily, there are only a few places where HMAC-MD2 or HMAC-MD4 are
specified.  MD5/HMAC-MD5 is another story.  I like the idea of just
updating MD5's security considerations to say don't use MD5 if you
need collision resistance and that it is (or is probably) okay for HMAC.

I updated the md2-to-historic I-D
(http://datatracker.ietf.org/doc/draft-turner-md2-to-historic/) to
actually talk about attacks against MD2 and submitted a similar draft
for MD4 (http://datatracker.ietf.org/doc/draft-turner-md4-to-historic/).
  I also submitted one that updates the MD5 security considerations
(http://datatracker.ietf.org/doc/draft-turner-md5-seccon-update/).
Comments on all are welcome.

spt

Sean Turner wrote:
> (apologies if you get this multiple times)
> 
> I'm looking for feedback on this draft that proposes moving MD2 to 
> historic status.
> 
> Thanks,
> 
> spt
> 
> ------------------------------------------------------------------------
> 
> Subject:
> I-D ACTION:draft-turner-md2-to-historic-00.txt
> From:
> [email-masked]
> Date:
> Wed, 9 Jun 2010 15:00:02 -0700 (PDT)
> To:
> [email-masked]
> 
> To:
> [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> 	Title		: MD2 to Historic Status
> 	Author(s)	: S. Turner
> 	Filename	: draft-turner-md2-to-historic-00.txt
> 	Pages		: 6
> 	Date		: 2010-6-8
> 	
>    This document recommends the retirement of MD2 and discusses the 
>    reasons for doing so.  This document recommends RFC 1319 be moved to 
>    Historic status. 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-turner-md2-to-historic-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 7 Jul 2010 13:17:14 -0400

Sean,

It may be worth discussing DSSC (RFC 5698) from LTANS WG that provides a
capability to specify suitable crypto algorithms.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Sean Turner
> Sent: Tuesday, July 06, 2010 12:40 PM
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-
> 00.txt]
> 
---------------------------------------------------------------------
> ---
---------------------------------------------------------------------
> ---
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Jul 2010 13:58:38 -0400

Sean, I've mentioned this in private mail, but I believe your draft
should discuss the Microsoft uses of md4 particularly for converting
passwords to key and discuss the impact of attacks on this use before it
is published. I am not intending to imply you're ignoring my comment: it
was made recently. I just wanted to get it into the public discussion so
others could think about it.

It's not entirely clear what properties are desired of a cryptographic
function in these uses.

In the Kerberos string-to-key operation, I think there are at least two
 goals:

1) Take a password of sufficient quality and produce a good key

2) Make it difficult to recover the password given the key.

There may be other goals. This is an area where the Kerberos community
has struggled to come up with security requirements.

It's clear that md4 fails at the second goal. However, it's not clear
that the Microsoft protocol uses of md4 actually try to achieve this
goal.  In the case of Kerberos, one of the main reasons you want to
prevent recovery of the password is so you can use the same password in
different realms without exposing it. For this reason, an identifier of
the principal and realm is included in the key computation. However,
rc4-hmac-md5 (the Kerberos enctype that uses md4 for string2key)
explicitly does not produce different keys for different realms.

So, I'm not actually sure whether one-way is a security goal or not for
this use of md4.

I have not been able to determine the impact of attacks on md4 on its
use as a funtion to produce high-quality keys from high-quality
passwords.

In conclusion, I think we need to be able to tell people what the impact
of the attacks on md4 is on widely deployed uses before publishing.

---

From: Sean Turner <[email-masked]>
Date: Thu, 08 Jul 2010 09:24:56 -0400

Sam,

Definitely not ignoring the comment.  I just wanted to get the -00 
version out before the deadline.  I haven't heard back from the folks 
I queried about this topic.

At least one person has suggested that we can't change this status of 
this I-D (or the MD2 I-D) because it probably came via the independent 
stream (i.e., RSA was just publishing an open publication of 
proprietary specifications).  They suggested it might be better to 
just update the security considerations and not try to move it to 
historic.  Any thoughts?

spt