Subject: Working Group Last Call: draft-melnikov-digest-to-historic-00.txt

From: Tom Yu <[email-masked]>
Date: Wed, 05 Dec 2007 19:06:43 -0500

This message commences a Working Group Last Call period for the
following document:

	Title           : Moving DIGEST-MD5 to Historic
	Author(s)       : A. Melnikov
	Filename        : draft-melnikov-digest-to-historic-00.txt
	Pages           : 7
	Date            : 2007-09-08

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-melnikov-digest-to-historic-00.txt

This Last Call will expire on Friday, December 21, 2007.  Please
review this document and address feedback to the Working Group mailing
list.

Tom Yu, SASL co-chair

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 06 Dec 2007 09:25:01 +0100

> http://www.ietf.org/internet-drafts/draft-melnikov-digest-to-historic-00.txt

I have read the document and support it.  Two concerns though:

1) One of the main disadvantages with DIGEST-MD5 for me is that its
   cryptographic primitives are sub-standard by today's standard.  The
   text in 7.B touches on this, but seems misplaced as 7 is about
   missing features.  I suggest adding to section 1:

   8. The cryptographic primitives in DIGEST-MD5 are not up to today's
   standards, in particular:

      A. The MD5 hash is sufficiently weak to make a brute force attack
      on DIGEST-MD5 easy with common hardware.

      B. Using the RC4 algorithm for the security layer without
      discarding the initial key stream output is prone to attack.

   And consequently removing the text in 7.B (which is the same as 8.A),
   except that it fixes a typo and adds a leading 'The'.

2) There should be better recommendations on what users should use
   instead.  There is the following text:

     Note that despite DIGEST-MD5 seeing some deployment on the
     Internet, this specification recommends obsoleting DIGEST-MD5
     because DIGEST- MD5, as implemented, is not a reasonable candidate
     for further standardization and should be deprecated in favor of
     one or more new password-based mechanisms currently being designed.

   I think there should be a reference to PLAIN+TLS here.  I think a
   recommendation to wait for some future protocol to materialize, while
   best from security perspective, should be amended with a practical
   recommendation.

Thanks,
/Simon

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 06 Dec 2007 08:30:50 -0700

> I have read the document and support it.  Two concerns though:

<snip/>

>    best from security perspective, should be amended with a practical

Agreed. The DIGEST-MD5 mechanism has seen wide deployment in Jabber/XMPP
systems because it is recommended in RFC 3920. In rfc3920bis we will
recommend TLS + SASL PLAIN instead.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 6 Dec 2007 22:34:27 +0100

> on DIGEST-MD5 easy with common hardware.

If "can identify the first three or four characters of the secret"
is still state of the art (and IFF I recall that correctly), then
"easy" might be slightly exaggerated.  From my POV various _other_
issues with DIGEST-MD5 are predominant, not its weakness.

 Frank

---

From: Chris Newman <[email-masked]>
Date: Thu, 06 Dec 2007 17:31:54 -0800

I have read this document and would support publication of version -00.

The suggestions Simon Josefsson made are reasonable and I would also support 
publication of a document including those suggestions.  The issue of PLAIN + 
TLS as mandatory-to-implement does have the subtlety that it's not appropriate 
as mandatory-to-implement mechanism for all protocols although it has been used 
by several standards track protocols for that purpose.  It may make it easier 
to get the document published if such text is omitted or conservative.

                - Chris

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 07 Dec 2007 02:29:21 +0000

Chris Newman wrote:

> The suggestions Simon Josefsson made are reasonable and I would also 
> support publication of a document including those suggestions.

Agreed.

> The issue of PLAIN + TLS as mandatory-to-implement does have the 
> subtlety that it's not appropriate as mandatory-to-implement mechanism 
> for all protocols although it has been used by several standards track 
> protocols for that purpose.

Indeed. It has different properties, so I would rather not actively 
recommend it as a replacement.

> It may make it easier to get the document published if such text is 
> omitted or conservative.

---

From: Abhijit Menon-Sen <[email-masked]>
Date: Fri, 7 Dec 2007 10:27:30 +0530

> I have read this document and would support publication of version

I have also reviewed the document, and sent Alexey a number of minor
editorial comments in private mail. I agree with the substance of the
document, however, and support its publication (with or without the
addition of a qualified suggestion to use TLS+PLAIN instead).

-- ams

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 07 Dec 2007 12:29:51 +0100

> issues with DIGEST-MD5 are predominant, not its weakness.

That text is already in the document.  I agree it isn't the major
concern, that's why I listed it last. ;)

/Simon

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 08 Dec 2007 19:41:38 +0000

>I have read the document and support it.  Two concerns though:
Simon, thank you for your comments.

>      discarding the initial key stream output is prone to attack.
I've added this.

>   except that it fixes a typo and adds a leading 'The'.
I retained "Lack of hash agility" in 7, but removed text about MD5 
(which is now in 8)

---

From: Paul Leach <[email-masked]>
Date: Sun, 9 Dec 2007 19:00:55 -0800

While I ver

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Saturday, December 08, 2007 11:42 AM
To: Simon Josefsson
Cc: [email-masked]
Subject: Re: Working Group Last Call: draft-melnikov-digest-to-historic-00.txt

>      discarding the initial key stream output is prone to attack.

[Paul Leach] While I certainly agree that MD5 is suspect, I'm not aware that there are any known attacks on the usage in DIGEST. The bad usage is: given a hash and a known input, it is possible to find other inputs that yield the same hash. However, given an input part of which is unknown (secret) and a hash, I wasn't aware that it is computationally feasible to do better than to try to test all possible secrets. Have I missed the relevant paper?

(The above is just in the interest of accuracy -- I have no objection to moving DIGEST to historic.)

---

From: Abhijit Menon-Sen <[email-masked]>
Date: Mon, 10 Dec 2007 09:10:33 +0530

At 2007-12-09 19:00:55 -0800, [email-masked] wrote:
>
> The bad usage is: given a hash and a known input, it is possible to
> find other inputs that yield the same hash.

As far as I know, even that is not possible.

For a given input, you can construct a pair of messages that hash to the
same value and have the input text as a prefix, but you cannot target a
specific hash value, and neither colliding message is identical to the
input (i.e. no preimage attacks are possible).

-- ams

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 10 Dec 2007 15:14:01 +0100

Paul Leach <[email-masked]> writes:

> [Paul Leach] While I certainly agree that MD5 is suspect, I'm not
> aware that there are any known attacks on the usage in DIGEST. The bad
> usage is: given a hash and a known input, it is possible to find other
> inputs that yield the same hash. However, given an input part of which
> is unknown (secret) and a hash, I wasn't aware that it is
> computationally feasible to do better than to try to test all possible
> secrets. Have I missed the relevant paper?

That text is already in the document, so they aren't my words.

However, I recall that there were a presentation at an appsarea meeting
a few IETF meetings ago, where CRAM-MD5 (dictionary?) attacks were
discussed and the practical consequences weren't pretty.  I wasn't there
and don't recall more details though, maybe someone else know of a
better reference.

/Simon