Subject: Last Call: <draft-turner-md5-seccon-update-07.txt> (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC

From: <[email-masked]>
Date: Wed, 1 Dec 2010 22:53:35 +0000

forwarding comments as per last call request.

Lloyd Wood
http://tinyurl.com/lloydwood-ccsr
________________________________________
From: Wood L  Dr (Electronic Eng)
Sent: 01 December 2010 07:56
To: [email-masked]; [email-masked]; [email-masked]
Cc: Wood L  Dr (Electronic Eng)
Subject: Last Call draft-turner-md5-seccon-update

http://datatracker.ietf.org/doc/draft-turner-md5-seccon-update/?include_text=1

says

   The attacks on HMAC-MD5 do not seem to indicate a practical
   vulnerability when used as a message authentication code.

or, when used for error detection, which is not discussed.

MD5 is still perfectly acceptable in non-security contexts, for detecting e.g. file corruption, as in checking that the .iso disk image downloaded is good to use.

I've spent a lot of time in the IETF dealing with security types who believe that, because MD5 has flaws that affect security use, it should therefore not be used at all in any context -- although it's fine in a reliability-only context and very useful for detecting errors. (This topic has derailed protocol development, and has also been the subject of more than one IETF talk.) The document should imo indicate that MD5 remains acceptable in non-security contexts, and indicate clearly and verbosely that the document is limiting its scope to security applications only, not non-security applications. Security Fear, Uncertainty and Doubt should not be allowed to spill over into non-security contexts.

I understand that this issue has been raised with the authors privately previously by others, but has not been addressed.

Lloyd Wood
[email-masked]
http://sat-net.com/L.Wood

The IESG has received a request from an individual submitter to consider
the following document:
- 'Updated Security Considerations for the MD5 Message-Digest and the
   HMAC-MD5 Algorithms'
  <draft-turner-md5-seccon-update-07.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2010-12-22. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

---

From: Sean Turner <[email-masked]>
Date: Fri, 03 Dec 2010 10:56:12 -0500

> http://tinyurl.com/lloydwood-ccsr

Lloyd,

Thanks for you comments.  I remember the original comment from Wes.  My 
response (which may have been more terse) was to add in to the draft 
that familiarity with RFC 4270 (the reference to HASH-Attack in the last 
paragraph of Section 1 of the md-seccon-update draft) is assumed.  RFC 
4270 Section 3 says:

   Of the above methods [there are 7], only the first two
   [non-repudiable signatures and digital signatures in
   certificates] are affected by collision attacks, and
   even then, only in limited circumstances.

Based on the "new" #s for collision attacks and what's in RFC 4270 that 
means to me that using MD5 for anything that requires collision 
resistance (2 of the 7 uses) is bad but if they're using it for the 
other 5 they're okay.

Do you think that's too many dots for people to connect?

I'm not in favor or repeating everything in RFC 4270 (i.e., I'd rather 
not be verbose).

spt

---

From: <[email-masked]>
Date: Fri, 3 Dec 2010 17:32:23 +0000

Sean,

thanks for your reply.

As you suggest, that is too many dots for people to connect.

I also take issue with RFC4270's claim that:

   The Internet protocol community needs to
   migrate in an orderly manner away from SHA-1 and MD5 -- especially
   MD5 -- and toward more secure hash algorithms.

which is rather broad, and entirely without the context and qualifiers we're discussing. RFC4270 was not written for a general audience, but for a security audience. The Internet _security protocol_ community may well need to migrate from these for certain uses (despite there not yet being obvious things to move _to_), but RFC4270 and your draft's sum take-away message that MD5BADDONOTUSE overstates the case. 

I see that RFC4270 was published in November 2005, which predates (and possibly even caused) the MD5-always-bad-don't-use-it-at-all-ever security kerfluffles that Wes and I have run into by several years. The fact that MD5 is being marked DEPRECATED by your draft, coupled by this sentence in RFC4270, _will_ lead to security types using it as justification to remove MD5 from, well, everywhere. Despite the fact that, as you say, it's still good for five of seven uses, including integrity protection (which gets a mere sentence in 4270 as the last of the seven - it's imo an area that is often neglected in protocol design). I hope you can see how your 'good for five of seven' assessment doesn't match with the messages in DEPRECATED and the quote above.

We need some clear language setting the boundaries for areas of concern where MD5 should not be used, and areas where it is still considered highly useful - language that is unambiguous to both security and non-security experts. Repeating the  bullet list of the seven uses, if you like, and providing a short summary of why MD5 is and is not currently considered useful in each case.

RFCs are not written solely for an audience competent in security matters, and the security audience is not always as competent as it likes to believe. Some explicit text to join the dots for the readers would be helpful.

thanks,

L.

is not claiming any particular expertise in security.

Lloyd Wood
[email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Fri, 03 Dec 2010 16:07:58 -0500

So, I'm sympathetic to the idea that we in the security community can be
overly paranoid.  however I'm more sympathetic to the idea that it's
hard to figure out what uses are security sensitive and what uses are
not. At least in the case of md5, where backward compatibility concerns
don't dictate otherwise, I'd say that moving away is better than not.

Let me take a specific example from earlier in this discussion.  The
claim was made that using md5 to verify the checksum of ISOs downloaded
off the Internet is still good.  That depends entirely on what you're
trying to protect against.  If your concern is simply errors in the
download and concerns that the TCP checksum may be inadequate, then I
agree.  However it's also fairly common to have md5 checksums on an
initial page and then direct people to mirrors for the actual
ISO. There, you're also protecting against substitution attacks mounted
between the original page and the iso.

If md5 is used in exactly the same context as the data, I agree it is
still fine.  However, the moment you separate the checksum from the
data--by putting one in e-mail, one on a post-it note, one on a
different mirror, you have made the hash security sensitive.

For this specific use, I think the extra length of SHA-1 is worth it,
and I think it is reasonable for us to recommend that something stronger
than MD5 is appropriate.  (SHA-2 would be better, although the length of
SHA-2 starts to get prohibitive.)

It's very easy for the security of a hash function to become
important. I at least find it difficult to easily determine whether a
particular use of a hash is security sensitive. I find that I disagree
with the results from people who claim that this analysis is easy often
enough that I'm reluctant to conclude that I'm simply unusually slow at
thinking through these sorts of issues.  So, I suggest that the problem
of deciding whether the security of a hash is important may be a bit
tricky. While we should not spread panic and we should be sensitive to
these issues, I also would rather us err on the side of security in our
recommendation.

---

From: Martin Rex <[email-masked]>
Date: Fri, 3 Dec 2010 22:40:59 +0100 (MET)

[email-masked] wrote:
> which is rather broad, and entirely without the context and qualifiers
> we're discussing. RFC4270 was not written for a general audience,
> but for a security audience.  The Internet _security protocol_ community
> may well need to migrate from these for certain uses (despite there not
> yet being obvious things to move _to_), but RFC4270 and your draft's
> sum take-away message that MD5BADDONOTUSE overstates the case. 

I agree that the above wording of rfc-4270 is BAD.

It should have said:

  The Internet community needs to migrate in an orderly manner away from
  SHA-1 and MD5 -- especially MD5 -- and toward more secure hash algorithms
  for all security-related usages of hash functions in all protocols.

> 
> Despite the fact that, as you say, it's still good for five of seven uses,
> including integrity protection (which gets a mere sentence in 4270 as the
> last of the seven - it's imo an area that is often neglected in protocol
> design).

IMHO there is a serious defect in rfc-4270.  The "integrity protection"
bullet ought to be bullet three, and MD5 is definitely _NOT_ suitable
for anything with the term "integrity" in it.

Integrity protection is terminology that is used in the
security&cryptographic area and this defect of rfc-4270 is going
to create misunderstandings.

MD5 (and SHA-1) are hash functions, and as such, they exhibit probabilistic
collisions for different inputs.  MD5 is still useful for detection of
"accidental" errors due to noise or distortion, but it is not suited
to protect against intentional modification of data by an attacker.

There are other algorithms for detecting "accidental" errors, like
"ECC bits", or CRCs of various sizes, e.g.
   http://en.wikipedia.org/wiki/Cyclic_redundancy_check

Think of MD5 as an alternative to CRC128.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Sat, 4 Dec 2010 04:23:23 +0100 (MET)

[email-masked] wrote:
> 
> > and MD5 is definitely _NOT_ suitable
> That depends imo on whether "integrity" is used as a term in a security
> context by a security person, or by anyone else. (I am not using the
> term as a security person, but have been forced to use it when talking to
> security people who have little notion of protection against errors or of
> reliability.)
> 
> 
> Yes.
> We've actually run into this problem previously, and had to carefully use the
> terms when talking to those who focus on terminology used, rather than the
> overall point that is trying to be made. This leads to verbal gyrations
> and a degree of doubletalk.
> 
> 'Integrity' and 'protection' do have meanings outside security, and were used
> long before their specific use in a security context (cf database integrity,
> system integrity, even integrity protection in chemical plants). From context
> here and the rest of the sentence, it's imo clear that reliability is what
> is being referred to.

I've been focused so much on security over more than a decade that
myself I am actually unfamiliar with uses of "integrity protection"
in a sense that is _not_ security-related.

Although the attacks against MD5 published so far are practical only
for creating collision pairs, there has not been published a practical
preimage attack against MD5.  But the practical collision attack alone
is devastating for several integrity protection usage scenarios.

   see this here: http://www.win.tue.nl/hashclash/rogue-ca/

Open the "Certificate Manager" of a newer Firefox/Mozilla browser
(Menu:  Tools->Options, Section "Advanced", Tab "Encryption",
 Button "View Certificates", Tab "Authorities")

Under "Equifax Secure Inc." you will probably find a CA certificate
labelled "MD5 Collisions Inc. (http://www.phreedom.org/md5)"
signed by Equifax Secure Global eBusiness CA-1, expired in Sep-2004
and that cert is pre-configured to be _not_ trusted for any purpose.
(a somewhat non-obvious way of blacklisting a certificate).

The MD5-based RSA signature in that cert still contains the original
MD5 checksum that Equifax calculated when it issued a different
(but fairly similar) end-entity cert with a different validity.

This fake CA certificate was created with the help of the MD5 collision
attack, not by a preimage attack.

But if you look at the purpose / usage scenario of the MD5 hash here,
then it is about some SSL client ("Bob") receiving an assertion of identity
for a server "i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org"
integrity protected by an RSA-encrypted MD5 hash from Equifax ("Alice"),
which can be successfully substitued by an attacker ("mallory") with
an intermediate CA certificate (plus an end-entity cert for any arbitrary
server created at will by mallory), and the Equifax-signed
MD5 checksum does not protect against this substitution, because
the fake CA cert has the exact same MD5 checksum as the cert
originally issued by Equifax.

The details are described in section 5.3 (but only 5.2 has an anchor tag):

   http://www.win.tue.nl/hashclash/rogue-ca/#sec52

Admittedly it isn't trivial to use a collision attack to do achieve
something that normally requires a preimage attack, but it is going to
be possible much more often than you will want it to for a creative
attacker.  And a lot of PDUs that are digitally signed these days
provide wiggle room for "binary random stuffing" necessary to precompute
collision attacks and will be ignored by recipients.  Especially in
protocols using ASN.1.

According to this report:

  http://www.eff.org/files/DefconSSLiverse.pdf

there appear to exist almost 1500 "trustworthy" SSL CAs, and
and attacker only needs to find a single one among them where
such an attack still works...

-Martin

---

From: <[email-masked]>
Date: Fri, 3 Dec 2010 22:59:19 +0000

>  for all security-related usages of hash functions in all protocols.

That wording is better, though I would also add a qualifier
on the front by saying 'away from reliance for security purposes on SHA-1
and MD-5...'. This should imo be filed as an erratum on RFC4270.

> bullet ought to be bullet three,

The list isn't explicitly ranked. But putting the reliability point last
does say something interesting about the security mindset... if it's
not a deliberate attack, it's just not interesting or worthy of note.

Yes.

I don't think this is necessarily a second erratum, but then I'm not
a security type, and think that this is an example of why mathematicians
often invent new terms, rather than overloading old ones.

> "accidental" errors due to noise or distortion,

or segmentation/reassembly overwriting bugs or... it can be used to support the
the end-to-end-principle.

> but it is not suited

agreed.

> Think of MD5 as an alternative to CRC128.

Well, MD5 is not a cyclic code, and CRC128 wouldn't cope well with checking
across anywhere near the sizes that MD5 can support; 128-bit MD5 has
been compared in error-detection strength (nb not crypto strength!) to CRC2048++,
which would be a rather complex polynomial. But I'm not so much of a purist that
I would stall at nitpicking your terminology here. Instead, I agree that the
overall point that you're making here is expressing exactly the point about MD5
that I've been trying to make, in relatively simple language for laymen.

To come back to where we came in, MD5 is fine for detecting errors in
a non-security context - but readers of RFC4270 and draft-turner-md5-seccon-update
are not going to pick that up from a casual read, and will come away
with 'MD5 bad, do not use' (and what's the alternative?).

draft-turner-md5-seccon-update needs to be much, much clearer on this and in
setting scope for use of MD5.

regards,

L.

Lloyd Wood
[email-masked]

---

From: <[email-masked]>
Date: Sat, 4 Dec 2010 11:43:27 +0000

> is devastating for several integrity protection usage scenarios.

I am wondering how the authors of RFC4270 wound up misusing the 'integrity
protection' term to cover both intentional (attack) and unintentional 
modifications, whereas reliability checking covers only the latter.
But, to the security mindset, everything is an attack.

I've now filed two errata on RFC4270.

regards,

L.

Lloyd Wood
[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 08 Dec 2010 15:55:43 +0100

I have a concern about no security usages of MD5 for practical reasons:
in some environments, including US Gov, crypto implementations (e.g.,
FIPS 140-2 HSMs) are required to not support MD5 so you can have to
choose between a compliant application and a conformant crypto,
for instance for DNS TSIG...

So IMHO it is still a good idea to avoid MD5 in any uses, even when
it is still far to have been proved insecure or for an use which is
not about security.

This could be caught by the "DEPRECATED" keyword in the registry
but this registry doesn't seem to have usage entries?!

To conclude I am fine with the implicit conclusion of the I-D to
not use MD5 or HMAC-MD5 in new protocols.

Thanks

[email-masked]

PS: I am the gen-art reviewer for this document too.

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Wed, 8 Dec 2010 14:08:03 -0600

The logic doesn't make sense in this position.  "Crypto modules can't use MD5, thus no protocols at all should use MD5."

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Francis Dupont [[email-masked]]
Sent: Wednesday, December 08, 2010 9:55 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Last Call: <draft-turner-md5-seccon-update-07.txt> (Updated        Security Considerations for the MD5 Message-Digest and the      HMAC-MD5 Algorithms) to Informational RFC

Thanks

PS: I am the gen-art reviewer for this document too.
_______________________________________________
Ietf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ietf

---

From: Christian Huitema <[email-masked]>
Date: Wed, 8 Dec 2010 21:25:05 +0000

The issue would be a whole lot easier to resolve if we had an agreed upon algorithm for the "non security" usages. CRC64 comes to mind.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
Sent: Wednesday, December 08, 2010 12:08 PM
To: Francis Dupont; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Last Call: <draft-turner-md5-seccon-update-07.txt> (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC 

I have a concern about no security usages of MD5 for practical reasons:
in some environments, including US Gov, crypto implementations (e.g., FIPS 140-2 HSMs) are required to not support MD5 so you can have to choose between a compliant application and a conformant crypto, for instance for DNS TSIG...

So IMHO it is still a good idea to avoid MD5 in any uses, even when it is still far to have been proved insecure or for an use which is not about security.

This could be caught by the "DEPRECATED" keyword in the registry but this registry doesn't seem to have usage entries?!

To conclude I am fine with the implicit conclusion of the I-D to not use MD5 or HMAC-MD5 in new protocols.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Dec 2010 00:33:43 +0100

In your previous mail you wrote:

   The logic doesn't make sense in this position.  "Crypto modules
   can't use MD5, thus no protocols at all should use MD5."
   
=> this is a silly/bad/... consequence of the crypto label
attached to the MD5 name. I understand you are not happy with
this but what do you propose?

Regards

PS: BTW I'd like to apply the argument only to *new* protocols.

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Wed, 8 Dec 2010 21:01:32 -0600

I think a published update to MD5 security considerations should clearly say what it's still fine to do with MD5, in addition to what it's not safe to do.  This would mean adding a couple sentences, and that's about all it would really take to be clear on the issue:

"Since RFC 1321 was published, MD5 found popular use in checksuming large file transfers.  This use of MD5 is still reasonable, as the level of collision resistance is of less importance in this application and MD5 may be significantly more efficient than cryptographically stronger algorithms.  Communications, networking, and storage systems prone to errors (e.g. due to faulty hardware, drivers, bit-errors, faulty NAT/ALG algorithms, etc) do not implement the known MD5 collision-finding algorithms, and MD5 remains highly effective at detecting such errors."

________________________________________
From: [email-masked] [[email-masked]]
Sent: Wednesday, December 08, 2010 6:33 PM
To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Last Call: <draft-turner-md5-seccon-update-07.txt> (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC

Regards

---

From: Francis Dupont <[email-masked]>
Date: Thu, 09 Dec 2010 23:00:46 +0100

I think a published update to MD5 security considerations should
   clearly say what it's still fine to do with MD5, in addition to
   what it's not safe to do.  This would mean adding a couple
   sentences, and that's about all it would really take to be clear on
   the issue:
   
   "Since RFC 1321 was published, MD5 found popular use in checksuming
   large file transfers.  This use of MD5 is still reasonable, as the
   level of collision resistance is of less importance in this
   application and MD5 may be significantly more efficient than
   cryptographically stronger algorithms.  Communications, networking,
   and storage systems prone to errors (e.g. due to faulty hardware,
   drivers, bit-errors, faulty NAT/ALG algorithms, etc) do not
   implement the known MD5 collision-finding algorithms, and MD5
   remains highly effective at detecting such errors."
   
=> you are trying to amplify the practical issue so I can't see
how it solves it (:-)...

Regards

PS: BTW IMHO a dedicated function should be better than MD5 for this use,
of course to reuse MD5 is easier (and I did it too :-).

---

From: Francis Dupont <[email-masked]>
Date: Sat, 11 Dec 2010 14:20:09 +0100

I add a third option: enforce the fact the document is about "security
considerations" and add nothing about not security uses, one way or
the other.

Regards

---

From: Sean Turner <[email-masked]>
Date: Tue, 21 Dec 2010 12:14:10 -0500

Wes,

I'm sympathetic to your concern, but I also think we need to specify 
that this particular use needs to be "in-line" with the protocol (as 
noted by Sam). How about the following changes in the introduction:

OLD:

[HASH-Attack] summarizes the use of hashes in many protocols and
discusses how attacks against a message digest algorithm's one-way
and collision-free properties affect and do not affect Internet
protocols.  Familiarity with [HASH-Attack] is assumed.

NEW:

[HASH-Attack] summarizes the use of hashes in many protocols and
discusses how attacks against a message digest algorithm's one-way
and collision-free properties affect and do not affect Internet
protocols.  Familiarity with [HASH-Attack] is assumed.  One of the
uses of message digest algorithms in [HMAC-Attack] was integrity
protection.  Where the MD5 checksum is used inline with the
protocol solely to protect against errors an MD5 checksum is still
an acceptable use.  Applications and protocols need to clearly
state in their security considerations what security services, if
any, are expected from the MD5 checksum.  In fact, any application
and protocol that employs MD5 needs to clearly state the expected
security services from their use of MD5.

spt

On 12/8/10 10:01 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] wrote:
> Subject: Re: Last Call:<draft-turner-md5-seccon-update-07.txt>  (Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms) to Informational RFC
>

---

From: Francis Dupont <[email-masked]>
Date: Tue, 21 Dec 2010 18:55:09 +0100

I'm OK with this text.  I tried to come up with a way to briefly discuss
   how error detection is very related to things like protecting against
   substitution of content (the internet mirror case) but failed to come up
   with something brief.
   So, I'm fine with what you have.
   
=> can I conclude you are in the "they are security considerations so
don't talk about not-security uses" side?

Thanks

PS: to summary the issue, we can do 3 things about new not-security uses:
 - not discourage them as they don't raise any security problems
 - discourage them as they can raise operational problems because
  some crypto regulations banish MD5 by itself
 - write nothing
Note the last option solves the issue only for this document,
i.e., each time a document will propose a new use of MD5 the issue
will be re-opened.

---

From: "Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[email-masked]>
Date: Tue, 21 Dec 2010 11:59:25 -0600

That looks good to me.

--
Wes Eddy
MTI Systems

>From: Sean Turner [mailto:[email-masked]]
>Sent: Tuesday, December 21, 2010 12:14 PM
>Cc: Francis Dupont; [email-masked]; [email-masked];
>[email-masked]; [email-masked]; Sam Hartman
>Subject: Re: Last Call: <draft-turner-md5-seccon-update-07.txt> (Updated
>Security Considerations for the MD5 Message-Digest and the HMAC-MD5
>Algorithms) to Informational RFC
>
>Wes,
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Dec 2010 12:24:40 -0500

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Dec 2010 12:58:31 -0500

>>>>> "Francis" == Francis Dupont <[email-masked]> writes:

    Francis>  In your previous mail you wrote:
    Francis>    I'm OK with this text.  I tried to come up with a way to
    Francis> briefly discuss how error detection is very related to
    Francis> things like protecting against substitution of content (the
    Francis> internet mirror case) but failed to come up with something
    Francis> brief.  So, I'm fine with what you have.
   
    Francis> => can I conclude you are in the "they are security
    Francis> considerations so don't talk about not-security uses" side?

No.
Especially for something like md5 you need to talk about it enough so
that we can evaluate whether it's actually a security use or not.
I sent a moderately long message to the ietf list about this.

---

From: Martin Rex <[email-masked]>
Date: Tue, 28 Dec 2010 17:17:08 +0100 (MET)

> So, I'm fine with what you have.

The use of MD5 _is_ a security problem in integrity protection scenarios.

When used for checksums when mirroring sites, a "contributor" could
precompute a collision for a file he contributed in order to perform
an MITM attack on specific downloads (substituting a trojaned package
with the same md5sum into the download while leaving the file on the
Download servers clean.

-Martin