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

From: Sean Turner <[email-masked]>
Date: Thu, 10 Jun 2010 09:05:12 -0400

(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]
To: [email-masked]
Date: Wed, 9 Jun 2010 15:00:02 -0700 (PDT)
List-Id: Internet Draft Announcements only <i-d-announce.ietf.org>

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: Peter Gutmann <[email-masked]>
Date: Fri, 11 Jun 2010 01:37:08 +1200

Simon Josefsson <[email-masked]> writes:

>1) MD2 is not on the standards track, it is Informational.  I agree with
>   wishes to move "poor" documents from the Standards Track to Historic,
>   but I'm not sure I see such a big difference between having a "poor"
>   document as Informational or Historic.  Especially for a crypto
>   algorithm, which the IETF typically does not put on the standards
>   track at all.  Is there some precedent for moving Informational to
>   Historic?

It helps to have something like this formally retired so you have a document
to point to when someone wants to use (or continue to use) MD2.  Trying to
explain to them the difference between "Informational" and "Standards Track"
when their requirement is "must be specified in an RFC" isn't generally
useful.

(We really need an RFC equivalent of the UK's Great Repeal Bill at some
point...).

Peter.

---

From: Sean Turner <[email-masked]>
Date: Thu, 10 Jun 2010 10:01:04 -0400

Simon Josefsson wrote:
> Sean Turner <[email-masked]> writes:
> 
> In general I support this: MD2 should simply not be used.
> 
> However I see two concerns:
> 

To be honest I'm not sure there's a precedent.  I don't think RFC 2026 
says that this can't be done; the definition of Historic is as follows:

A specification that has been superseded by a more recent
specification or is for any other reason considered to be obsolete is
assigned to the "Historic" level.  (Purists have suggested that the
word should be "Historical"; however, at this point the use of
"Historic" is historical.)

I think if it was just for standards track specifications, it would 
have said that.

But, what I was thinking was that if we've got an informational 
specification of an algorithm that's broken (i.e., obsolete) we should 
wave red flags announcing this.  One way to do that is to write this 
document and an another flag is to put it on a different track than 
ones we don't think are broken.  This might just be a process thing, 
but I think we should be doing this.

> 2) MD2 is still used.  In GnuTLS I recall _adding_ support for MD2 as
>    recently as (according to NEWS logs) in 2005.  If I recall correctly,
>    some Verisign root certificates are MD2.  Note that in GnuTLS,
>    verifying a certificate involving a MD2 digital signature will fail
>    because MD2 is insecure, but the algorithm is still implemented and
>    supported.
> 
>    Thus the text in your document "many TLS implementations, OpenSSL,
>    Network Security Services, and GNUTLS, have disabled support for MD2"
>    may not be the entire story.  GnuTLS "supports" MD2 even though it
>    does not consider it secure.  I can't speak for OpenSSL or NSS, but I
>    suspect they implement MD2 too and can verify such digital hashes,
>    even if they don't consider them secure.

Yeah that might have been a bit strong.  Maybe:

Additionally, many TLS implementations, OpenSSL, Network Security 
Services, and GNUTLS, support MD2 but recommend it only for backwards 
compatibility.

> Even if these concerns cannot be fully addressed, I would likely still
> support this document though.  So they are "soft" concerns for me.

Thanks,

spt

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Jun 2010 15:31:26 +0200

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Jun 2010 15:44:57 +0200

> when their requirement is "must be specified in an RFC" isn't generally

Sure, but MD2 is not used in isolation, it is used in a protocol like
TLS, S/MIME, etc.  Isn't it sufficient, even preferable, to move uses of
MD2 in these protocol to Historic?  That would seem to carry much more
weight -- then people cannot continue to support MD2 in these protocol
and claim to be compliant with the latest specifications.

Note that there are other uses of MD2 that are still fine even if MD2 is
not collision resistant.  Compare how rsync still uses MD4 for checksum
computations, and that won't stop it being a reasonable choice.

I'm mostly playing the devil's advocate here, and want to make sure we
consider the consequences before giving a flippant +1.

/Simon

---

From: Len Sassaman <[email-masked]>
Date: Thu, 10 Jun 2010 15:49:17 +0200 (CEST)

>   because MD2 is insecure, but the algorithm is still implemented and

Verisign had a root cert that was self-signed by MD2. When Dan Kaminsky 
and I found that, Dan talked to Versign, and they reissued the cert signed 
with SHA-1. The original cert is still valid in older browsers, but there 
should no longer be any MD2 certs in use in the public CA system. (Who 
knows about private enterprise deployments, however.)

I support deprecating MD2. We are one incremental improvement in MD2 
attack speed away from a massive break.

--Len.

---

From: Joe Touch <[email-masked]>
Date: Thu, 10 Jun 2010 07:00:56 -0700

Hi, all,

I agree with Simon. I don't know what it means to move a doc like the MD2 spec
to historic even means. It's not standards track. It's not a protocol. AFAICT,
it's just a description of an algorithm.

It might be useful to create a "security algorithms roadmap" doc, which lists
all known alg RFCs, and describes which are useful in various ways, and which
are no longer typically used, but singling out MD2 (vs. MD5 except as an HMAC)
seems not particularly useful.

Joe

Simon Josefsson wrote:
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Jun 2010 16:01:52 +0200

Len Sassaman <[email-masked]> writes:

> Verisign had a root cert that was self-signed by MD2. When Dan
> Kaminsky and I found that, Dan talked to Versign, and they reissued
> the cert signed with SHA-1. The original cert is still valid in older
> browsers, but there should no longer be any MD2 certs in use in the
> public CA system. (Who knows about private enterprise deployments,
> however.)
>

A self-signed trust root with MD2 is not a security problem by itself:
it is not the digital signature that is trusted, it is the public key in
the certificate.  The MD2 roots are still shipped and trusted in several
modern packages (e.g., Ubuntu 10.04 LTS ca-certificates).

I support deprecating MD2 for any purpose that requires a collision
resistant function.  The current proposal goes further and deprecates
MD2 for any use.  I don't see much argumentation for deprecating it for
non-collision resistant use-cases.

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Jun 2010 16:05:43 +0200

> but I think we should be doing this.

One alternative would be to supersede (or update) the original RFC with
your document, and still have it on Informational status.

That approach permits use-cases where a collision resistant function is
not required, but still raises the red flags we all want to be there.

/Simon

---

From: Len Sassaman <[email-masked]>
Date: Thu, 10 Jun 2010 16:12:02 +0200 (CEST)

> modern packages (e.g., Ubuntu 10.04 LTS ca-certificates).

No, it absolutely *is* a security problem. Should someone develop a 
preimage attack on MD2, all they need do is move the (valid) MD2 signature 
to an intermediate cert with BasicConstraints CA=yes, and then they have 
themselves a CA.

--Len.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Jun 2010 16:20:05 +0200

Len Sassaman <[email-masked]> writes:

> preimage attack on MD2, all they need do is move the (valid) MD2
> signature to an intermediate cert with BasicConstraints CA=yes, and
> then they have themselves a CA.

I don't see how that gains you anything: you still need to make clients
place trust in the new CA, and if the attacker has that ability, all
bets are off.

/Simon

---

From: Len Sassaman <[email-masked]>
Date: Thu, 10 Jun 2010 18:59:08 +0200 (CEST)

> place trust in the new CA, and if the attacker has that ability, all

The clients trust the new CA because it is an intermediate CA chained to 
the original, MD2-signed top-level CA. The intermediate cert is then 
treated with the same validity as *any* intermediate cert generated by 
that top-level cert -- since the top-level cert's signature verifies 
correctly on the intermediate cert, of course.

Do you understand the attack now?

This isn't *quite* such an issue, since after we brought it to the 
attention of CERT and the browser vendors, they either eliminated MD2 
support entirely, or restricted it so that if an intermediate CA cert 
signed with MD2 would be rejected. (At least, I personally verifed Chrome 
and FireFox. I *think* IE and Opera were patched, too -- they should be.) 
So now we hope that browsers released prior to mid-2009 are retired from 
use before MD2 is broken in practice. Given the longevity of browsers, 
it's going to be close.

--Len.

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 10 Jun 2010 18:57:57 +0100

>    even if they don't consider them secure.

OpenSSL implemented MD2 but has since disabled its use in digital signatures and
generally attempting to lookup a digest called "MD2" will fail.

The self signed root CA issue was worked around by disabling the signature check
on the root CA by default, since it is redundant. The result is that a self
signed trusted root can be signed using MD2withRSA but never subordinate CAs.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 10 Jun 2010 22:19:43 +0200

Len Sassaman <[email-masked]> writes:

> The clients trust the new CA because it is an intermediate CA chained
> to the original, MD2-signed top-level CA. The intermediate cert is
> then treated with the same validity as *any* intermediate cert
> generated by that top-level cert -- since the top-level cert's
> signature verifies correctly on the intermediate cert, of course.
>

Yes, I do, but that attack is not caused by a MD2 root.  The attack is
caused by software trusting MD2 to verify digital signatures.  I believe
the latter has been resolved in most security libraries already (it
certainly has been resolved in GnuTLS, since January 2009, which treats
both MD2 and MD5 as insecure).

The former case (a MD2 root) is not a problem by itself, as far as I can
tell, which is what I originally stated.

As long as MD2 roots have not been shown to be a problem, by themselves,
protocols and software will need to continue implement MD2 for
operational reasons.  There are still several MD2 roots in recently
shipping operating systems.  For example, my Ubuntu 10.04 LTS system has
these RSA-MD2 roots:

./mozilla/Verisign_Class_1_Public_Primary_Certification_Authority.crt:
        Issuer: C=US,O=VeriSign\, Inc.,OU=Class 1 Public Primary Certification Authority
./mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt
        Issuer: C=US,O=VeriSign\, Inc.,OU=Class 3 Public Primary Certification Authority
./mozilla/Verisign_RSA_Secure_Server_CA.crt
        Issuer: C=US,O=RSA Data Security\, Inc.,OU=Secure Server Certification Authority
./mozilla/Verisign_Class_2_Public_Primary_Certification_Authority.crt
        Issuer: C=US,O=VeriSign\, Inc.,OU=Class 2 Public Primary Certification Authority

Right now, I think my preference would be to update RFC 1319 with
something like Sean's document, to alert everyone of the security
issues, but let the status of the algorithm description remain
Informational.

/Simon

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 10 Jun 2010 21:18:33 -0400

Len,

I agree with Simon.  Security strength of hash in self-signed
certificate is irrelevant.  It is an untrusted object.  You might use
the world's weakest hash or not sign it at all.

That said, if you process that MD2, you may end up invoking it for other
certificates.  But, as Open SSL folks posted in this thread, they do not
verify signatures on self-signed certificates, obviating the need for
MD2.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Simon Josefsson
> Sent: Thursday, June 10, 2010 4:20 PM
> To: Len Sassaman
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-
> 00.txt]
>

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 11 Jun 2010 14:50:17 +1200

Dr Stephen Henson <[email-masked]> writes:

>The self signed root CA issue was worked around by disabling the signature
>check on the root CA by default, since it is redundant.

What about catching accidental data corruption?  It still acts as an integrity
check, even if it's not an authenticity check.

(I recently ran into a situation where mangled PEM-encoding had corrupted
portions of CA root certs, and in some cases only the sig check would have
caught it).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 11 Jun 2010 14:58:49 +1200

Len Sassaman <[email-masked]> writes:

>(At least, I personally verifed Chrome and FireFox. I *think* IE and Opera
>were patched, too -- they should be.) So now we hope that browsers released
>prior to mid-2009 are retired from use before MD2 is broken in practice.
>Given the longevity of browsers, it's going to be close.

I assume you're thinking of IE6 there :-).  Was the fix done in CryptoAPI or
in the browser itself?  If it was an update to CryptoAPI then even IE6 should
be OK (can anyone from MS comment on this?).

Peter.

---

From: Len Sassaman <[email-masked]>
Date: Fri, 11 Jun 2010 17:54:06 +0200 (CEST)

> be OK (can anyone from MS comment on this?).

I *think* the fix was in CryptoAPI. Dan was the one who notified the 
vendors (OpenSSL, Mozilla, Verisign, etc.) about the MD2 signature 
transfer problem as well as the other flaws, so he'd be the person to ask 
(unless someone from MS wants to chime in.)

--Len.

---

From: Tom Gindin <[email-masked]>
Date: Sun, 13 Jun 2010 23:54:13 -0400

Where in TLS (or even SSL v3) is MD2 used in a cipher suite?  I 
realize that it's in the document list for TLS 1.0.  In RFC's 2459 and 
3279 (11 and 8 years old) it gives OID's and says "the use of MD2 for new 
applications is discouraged.  It is still reasonable to use MD2 to verify 
existing signatures".
        I also can't find any current MD2 intermediate certificates.  You 
are right that the signature of a root certificate is not a relevant 
exercise of trust, since one trusts either the public key of the root 
certificate or the content of the entire root certificate with the 
signature no more relevant to a trust decision than any other field in it.

                Tom Gindin

From:
Simon Josefsson <[email-masked]>
To:
Peter Gutmann <[email-masked]>
Cc:
[email-masked], [email-masked], [email-masked], [email-masked]
Date:
06/10/2010 10:19 AM
Subject:
Re: [pkix] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt]
Sent by:
[email-masked]

/Simon
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: SM <[email-masked]>
Date: Thu, 17 Jun 2010 10:18:38 -0700

Hi Simon,
>    track at all.  Is there some precedent for moving Informational to

There's RFC 4223, for example, that reclassifies a non-Standards 
Track document to Historic.  This is more about saying that MD2 
should not be used and "Historic" is generally the way to say that.

Regards,
-sm

---

From: Andrea Caccia <[email-masked]>
Date: Thu, 17 Jun 2010 19:55:44 +0200

I think it's hard to say that an algorithm is not to be used at all for any purpose.
Can MD5 be moved to Historic? I do not think so even if it has since some time to be avoided for digital signatures but is still useful for other purposes.
The solution should be a document, regularly updated and specific for electronic signature that list the algorithms, their correct identification (e.g. for asn.1 and xml) and their suitability for typical usages.

Regards,
Andrea Caccia

Il giorno 17/giu/2010, alle ore 19.18, SM ha scritto:

> There's RFC 4223, for example, that reclassifies a non-Standards Track document to Historic.  This is more about saying that MD2 should not be used and "Historic" is generally the way to say that.
> 
> Regards,
> -sm

---

From: Sean Turner <[email-masked]>
Date: Tue, 22 Jun 2010 17:50:32 -0400

> Services, and GNUTLS, support MD2 but recommend it only for backwards 

I went back and looked at this a little closer.  I found that GNUTLS 
now turns MD2 off by default:
https://rhn.redhat.com/errata/RHSA-2010-0166.html

I also found that NSS does also have MD2 turned off, but it looks you 
can turn it back on by setting an environment variable.

spt