>>>>> "Martin" == Martin Rex <mrex@xxxxxxx> writes:
Martin> Sam Hartman wrote:
>>
> 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.
Martin> The use of MD5 _is_ a security problem in integrity
Martin> protection scenarios.
Agreed. My point was close but not identical to yours. My point was
that even when you think you're just talking about error detection, it
takes effort to tell whether you are really talking about error
detection (OK) or integrity protection (not OK).
Martin> When used for checksums when mirroring sites, a
Martin> "contributor" could precompute a collision for a file he
Martin> contributed in order to perform an MITM attack on specific
Martin> downloads (substituting a trojaned package with the same
Martin> md5sum into the download while leaving the file on the
Martin> Download servers clean.
An excellent point! In my original long message on this topic I pointed
out that if the checksums are ever separated from the file then you're
talking about integrity protection not error detection in most threat
models. I was thinking of the case where you have a mastersite listing
checksums and a bunch of mirror sites. (That is, the checksums in
something like a Debian Packages file are very much integrity checksums
not just error detection checksums; there's a reason we no longer rely
on MD5.)
However you point out that even if there is only one site, when there
can be separation--even after the fact--then MD5 may be problematic.
Some threat models may reject the case where the original distributor
performs a precomputation attack, but for other threat models, this is a
realistic attack.
After this discussion, I continue to believe that determining whether a
particular use of MD5 is safe is quite tricky. Therefore, it is very
reasonable to ask that the security assumptions be described and
analyzed.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf