Subject: RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 1 Oct 2008 17:29:31 -0400

We could put something like the following in the security considerations
section:

Cryptographic algorithms will be broken or weakened over time.  Implementers
and users need to check that the cryptographic algorithms listed in this
document continue to provide the expected level of security.  For example,
some consider MD2 and MD5 weak cryptographic algorithms due to collisions
[RC95] and [YU05], repsectively.

Informative references (found this in old RFCs and on web):
[RC95] Rogier, N. and P. Chauvaud, "The compression function  of MD2 is not
collision free," Presented at Selected Areas in Cryptography '95, May 1995.
[XY05] Wang, X., and H. Yu, "How to Break MD2 and Other Hash Functions",
EUROCRYPT 2005, LNCS 3494, pp. 19–35, 2005. 

spt

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Russ Housley
>Sent: Tuesday, September 30, 2008 5:23 PM
>To: Jim Schaad; 'Alfred HÎnes'; [email-masked]
>Subject: RE: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
>
>
>There was a long discussion a few years ago, and the PKIX WG 
>decided that the various applications that make use of 
>certificate should select the mandatory to implement 
>algorithms.  In this way, the algorithms in the protocol and 
>in the certificates can be aligned.
>
>Russ
>
>At 03:17 PM 9/30/2008, Jim Schaad wrote:
>>Alfred,
>>
>>That is an interesting question.  I don't believe that there 
>have ever 
>>been any required algorithms for PKIX certificates as defined by the 
>>PKIX working group.  You have documents such as the S/MIME 
>certificates 
>>draft which says you need to use these algorithms for S/MIME 
>type certificates instead.
>>
>>I think that it would make sense to put a section into the security 
>>considerations that make statements about what we consider to be the
>>suitability of other groups adopting these algorithms.   I 
>don't however
>>believe we can actually call these algorithms depreciated however.
>>
>>Jim
>>
>>
>> > -----Original Message-----
>> > From: [email-masked] [mailto:owner-ietf- 
>> > [email-masked]] On Behalf Of Alfred HÎnes
>> > Sent: Sunday, September 28, 2008 7:08 PM
>> > To: [email-masked]
>> > Subject: ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5
>> >
>> >
>> > Folks,
>> > the current version of draft-ietf-pkix-ecc-subpubkeyinfo contains 
>> > unqualified ASN.1 definitions for the digest algorithms MD-2 and 
>> > MD-5, as well as for  RSA with MD-2 and MD-5.
>> >
>> > Other WGs already have deprecated MD-2 and/or MD-5 and/or 
>are in the 
>> > process of deprecating these older hash functions (generally 
>> > believed to be insecure today), for use in the protocols 
>they maintain.
>> >
>> > So the question arises what to do with these old algorithms in the 
>> > context of PKIX in general, and in particular in the above draft.
>> >
>> > I see four possible options:
>> >
>> >   A)  leave the draft unchanged
>> >
>> >   B)  leave the related ASN.1 definitions intact,
>> >       but add ASN.1 comments  ' -- DEPRECATED'
>> >
>> >   C)  keep the related ASN.1 definitions in the document
>> >       for the purpose of documentation and historical record,
>> >       but comment them out and add the above note
>> >
>> >   D)  remove he related ASN.1 from the new/upated ASN.1
>> >       modules in Appendix A.2 and Appendix A.4 of the draft
>> >
>> > This question should be decided upon (almost independently):
>> >
>> >     (1)  for  MD-2  and  RSA with MD-2  ... choices (1A), ... (1D) 
>> > and
>> >     (2)  for  MD-5  and  RSA with MD-5  ... choices (2A), ... (2D)
>> >
>> > Any opinions?
>> >
>> > Please indicate support for
>> > - one of:            (1A) / (1B) / (1C) / (1D)
>> > - and one of:        (2A) / (2B) / (2C) / (2D)
>> >
>> >
>> > Kind regards,
>> >   Alfred.
>> >
>> >
>> > P.S.:  My personal preference is  (1C) + (2B) .
>> > --
>> >
>> > 
>+------------------------+--------------------------------------------+
>> > | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., 
>Dipl.-Phys.  |
>> > | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: 
>-18         |
>> > | D-71254  Ditzingen     |  E-Mail:  [email-masked]          
>           |
>> > 
>+------------------------+--------------------------------------------+
>>
>>
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 1 Oct 2008 15:35:32 -0700

At 5:29 PM -0400 10/1/08, Turner, Sean P. wrote:
>EUROCRYPT 2005, LNCS 3494, pp. 19-35, 2005.

I do not agree with putting this text into this document, as compared to well, um, every single document coming out of the Security Area. It's both obvious and insufficient advice. Without context, it will seem that the advice is more important here than in other Security Area documents.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Thu, 2 Oct 2008 12:35:59 -0400

At 3:35 PM -0700 10/1/08, Paul Hoffman wrote:
>I do not agree with putting this text into this document, as 
>compared to well, um, every single document coming out of the 
>Security Area. It's both obvious and insufficient advice. Without 
>context, it will seem that the advice is more important here than in 
>other Security Area documents.
>
>--Paul Hoffman, Director
>--VPN Consortium

Paul,

I agree that the wording might be improved, but I do think that PKIX 
is a special case vs. most of the crypto-related RFCs in the security 
area.  The reason is that we don't define specific algorithm suites 
as do IPsec, TLS, SMIME, SSH, etc. Since we don't specify default or 
preferred algorithms, our standards that do mention specific 
algorithms are more susceptible to misinterpretation by readers 
unfamiliar with that aspect of PKIX standards.

I support Sean's efforts to try to avoid such confusion, in response 
to Jim's comments. I hope Sean can tweak the words a bit to make this 
more acceptable. I do think the MD2 MD5 references may be helpful as 
well.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Oct 2008 13:50:05 -0700

At 12:35 PM -0400 10/2/08, Stephen Kent wrote:
>I agree that the wording might be improved, but I do think that PKIX is a special case vs. most of the crypto-related RFCs in the security area.  The reason is that we don't define specific algorithm suites as do IPsec, TLS, SMIME, SSH, etc. Since we don't specify default or preferred algorithms, our standards that do mention specific algorithms are more susceptible to misinterpretation by readers unfamiliar with that aspect of PKIX standards.

We have not seen that someone reading RFC 3279 would tend to think that the IETF is suggesting that all of its algorithms are equally strong or useful. In fact, we have seen the opposite. I do not think that this document will be any different.

Or, are you proposing that we update RFCs 3279, 4055, and 4491 to have wording similar to what Sean proposed?

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Thu, 2 Oct 2008 17:33:58 -0400

At 1:50 PM -0700 10/2/08, Paul Hoffman wrote:
>>I agree that the wording might be improved, but I do think that 
>>PKIX is a special case vs. most of the crypto-related RFCs in the 
>>security area.  The reason is that we don't define specific 
>>algorithm suites as do IPsec, TLS, SMIME, SSH, etc. Since we don't 
>>specify default or preferred algorithms, our standards that do 
>>mention specific algorithms are more susceptible to 
>>misinterpretation by readers unfamiliar with that aspect of PKIX 
>>standards.
>
>We have not seen that someone reading RFC 3279 would tend to think 
>that the IETF is suggesting that all of its algorithms are equally 
>strong or useful. In fact, we have seen the opposite. I do not think 
>that this document will be any different.

Paul,

I've become confused about the essential disagreement at this stage :-).

RFC 3279 has clear language that says that MD2 is problematic, and 
that MD5 is of concern as well. So, relative to the discussion I 
thought we were having, it seems to have appropriate language.

What I thought Jim suggested, and that Sean offered to do, was to put 
similar language into his document, specifically with regard to 
MD2/5, because Sean's document includes OIDs that references those 
hash functions. If so, then  3279 is a good example of alerting folks 
to concerns about algorithms in a document where OIDs for those 
algorithms are described.

>Or, are you proposing that we update RFCs 3279, 4055, and 4491 to 
>have wording similar to what Sean proposed?

As I noted above, the text on 3279 re MD2 and MD5 seems appropriate. 
Neither 4055 nor 4491 have any MD2/5 OIDs, so they do not need to 
include a warning.

Perhaps a better way to address this issue is not to include text 
about the fact that, over time, the perceived strength of algorithms 
may change. Instead, we should note that the fact that a document 
includes OIDs for algorithms does not imply endorsement of the 
strength of the algorithms, and when appropriate, we can note 
specific algorithms that, at the time of publication, are of concern 
but are nonetheless included for completeness.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Oct 2008 15:38:44 -0700

At 5:33 PM -0400 10/2/08, Stephen Kent wrote:
>RFC 3279 has clear language that says that MD2 is problematic, and that MD5 is of concern as well. So, relative to the discussion I thought we were having, it seems to have appropriate language.

Sure, "appropriate language" might be good to steer people away from MD2 and MD5. But what Sean proposed is not similar at all to what is in RFC 3279 about MD2 and MD5.

>[RC95] and [YU05], repsectively.

In this case, MD2 and MD5 are *examples* of algorithms that have weakened over time. Further, there is nothing like his first two sentences in the Security Considerations of RFC 3279. Telling people that they need to check that algorithms are still good, without saying what to check or when, is not of any value.

>Perhaps a better way to address this issue is not to include text about the fact that, over time, the perceived strength of algorithms may change. Instead, we should note that the fact that a document includes OIDs for algorithms does not imply endorsement of the strength of the algorithms, and when appropriate, we can note specific algorithms that, at the time of publication, are of concern but are nonetheless included for completeness.

That would work for me. We could simply re-use the actual words from RFC 3279:
   The use of MD5
   for new applications is discouraged.  It is still reasonable to use
   MD5 to verify existing signatures.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Kent <[email-masked]>
Date: Fri, 3 Oct 2008 11:08:30 -0400

At 3:38 PM -0700 10/2/08, Paul Hoffman wrote:
>...
>
>Sure, "appropriate language" might be good to steer people away from 
>MD2 and MD5. But what Sean proposed is not similar at all to what is 
>in RFC 3279 about MD2 and MD5.

Which is why I said that the text could be improved.

>
>...
>In this case, MD2 and MD5 are *examples* of algorithms that have 
>weakened over time. Further, there is nothing like his first two 
>sentences in the Security Considerations of RFC 3279. Telling people 
>that they need to check that algorithms are still good, without 
>saying what to check or when, is not of any value.

Agreed.

>>about the fact that, over time, the perceived strength of 
>>algorithms may change. Instead, we should note that the fact that a 
>>document includes OIDs for algorithms does not imply endorsement of 
>>the strength of the algorithms, and when appropriate, we can note 
>>specific algorithms that, at the time of publication, are of 
>>concern but are nonetheless included for completeness.
>

OK, glad to see we're converging.

Steve

---

From: Tom Gindin <[email-masked]>
Date: Sun, 5 Oct 2008 23:26:41 -0400

I don't think that the decision is really independent.  I'm in 
favor of B for both.  The definitions need to remain in the standard for 
backwards compatibility, and their future use is indeed deprecated.

                Tom Gindin

Alfred Hönes <[email-masked]> 
Sent by: [email-masked]
09/28/2008 10:07 PM

To
[email-masked]
cc

Subject
ecc-subpubkeyinfo draft question: fate of MD-2 and MD-5

Folks,
the current version of draft-ietf-pkix-ecc-subpubkeyinfo contains
unqualified ASN.1 definitions for the digest algorithms MD-2 and MD-5,
as well as for  RSA with MD-2 and MD-5.

Other WGs already have deprecated MD-2 and/or MD-5 and/or are in the
process of deprecating these older hash functions (generally believed
to be insecure today), for use in the protocols they maintain.

Any opinions?

Kind regards,
  Alfred.

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: "Turner, Sean P." <[email-masked]>
Date: Wed, 15 Oct 2008 11:46:19 -0400

>[mailto:[email-masked]] On Behalf Of Paul Hoffman
>Sent: Thursday, October 02, 2008 6:39 PM
>To: Stephen Kent
>Cc: [email-masked]
>>>>I agree that the wording might be improved, but I do think 
>that PKIX is a special case vs. most of the crypto-related 
>RFCs in the security area.  The reason is that we don't define 
>specific algorithm suites as do IPsec, TLS, SMIME, SSH, etc. 
>Since we don't specify default or preferred algorithms, our 
>standards that do mention specific algorithms are more 
>susceptible to misinterpretation by readers unfamiliar with 
>that aspect of PKIX standards.
>>>
>>>We have not seen that someone reading RFC 3279 would tend to 
>think that the IETF is suggesting that all of its algorithms 
>are equally strong or useful. In fact, we have seen the 
>opposite. I do not think that this document will be any different.
>>
>>Paul,
>>
>>RFC 3279 has clear language that says that MD2 is 
>problematic, and that MD5 is of concern as well. So, relative 
>to the discussion I thought we were having, it seems to have 
>appropriate language.
>
>Sure, "appropriate language" might be good to steer people 
>away from MD2 and MD5. But what Sean proposed is not similar 
>at all to what is in RFC 3279 about MD2 and MD5.
>
>>Cryptographic algorithms will be broken or weakened over time.  
>>Implementers and users need to check that the cryptographic 
>algorithms 
>>listed in this document continue to provide the expected level of 
>>security.  For example, some consider MD2 and MD5 weak cryptographic 
>>algorithms due to collisions [RC95] and [YU05], repsectively.
>
>In this case, MD2 and MD5 are *examples* of algorithms that 
>have weakened over time. Further, there is nothing like his 
>first two sentences in the Security Considerations of RFC 
>3279. Telling people that they need to check that algorithms 
>are still good, without saying what to check or when, is not 
>of any value.
>
>>Perhaps a better way to address this issue is not to include 
>text about the fact that, over time, the perceived strength of 
>algorithms may change. Instead, we should note that the fact 
>that a document includes OIDs for algorithms does not imply 
>endorsement of the strength of the algorithms, and when 
>appropriate, we can note specific algorithms that, at the time 
>of publication, are of concern but are nonetheless included 
>for completeness.
>

Paul/Steve,

We already reference the security considerations in RFC 3279, but I'll also
add the following to the ietf-pkix-ecc-subpubkeyinfo-09 security
considerations:

As noted in [PKI-ALG], the use of MD2 and MD5 for new applications is
discouraged.  It is still reasonable to use MD2 and MD5 to verify existing
signatures.

spt