ietf-smime
[Top] [All Lists]

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

2010-06-10 09:01:16
Simon Josefsson wrote:
Sean Turner <turners(_at_)ieca(_dot_)com> writes:

(apologies if you get this multiple times)

I'm looking for feedback on this draft that proposes moving MD2 to
historic status.

In general I support this: MD2 should simply not be used.

However I see two concerns:

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?

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
_______________________________________________
smime mailing list
smime(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/smime