Re: [saag] [Cfrg] Further MD5 breaks: Creating a rogue CAcertificate

Paul,

I disagree in the matter of trust anchors, assuming you mean self-signed
ones.

Signatures on Trust anchors are inherently useless from security
viewpoint.  Thus, they could be signed using even MD4.

Their security relies on protecting them from unauthorized modification.

-----Original Message-----
From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of
Paul Hoffman
Sent: Tuesday, December 30, 2008 3:53 PM
To: ietf-pkix@imc.org; ietf-smime@imc.org; saag@ietf.org; cfrg@irtf.org
Subject: Re: [Cfrg] [saag] Further MD5 breaks: Creating a rogue
CAcertificate

At 1:33 PM -0500 12/30/08, Jeffrey Hutzelman wrote:
>This is a practical application of an approach that I remember being
brought up during discussions about MD5 at a saag meeting some time ago.
I also recall someone mentioning at the time that many/most CA's were
already issuing certificates with random rather than sequential serial
numbers, which would have thwarted this particular attack.

Your recollection may be off. I believe I was the person who brought up
the serial number hack at the mic, and I'm pretty sure I said "some",
not "many" (and certainly not "most"!). When I looked at a handful of
popular CAs earlier this week, I only found a few who are using
randomization in their serial numbers.

Regardless of that, the authors of the MD5 paper are correct: trust
anchors signed with MD5 are highly questionable as of today (well,
actually, since they published their last paper). Hopefully, the
maintainers of the popular trust anchor repositories (Microsoft,
Mozilla, etc.) will yank out the trust anchors signed with MD5 (and
MD2!) as soon as possible.

At 3:10 PM -0500 12/30/08, Russ Housley wrote:
>RFC 5280 does not include this advice.  It is sound advice that was
discussed in PKIX and other venues.  Perhaps a BCP is in order.

Man, that is really stretching the definition of "best".

For one, it is only needed in signatures that use known-attackable hash
functions. A "best practice" in that case is to use a better hash
function in the signature. Also, it relies on the ability of the
software using the random number to be sure that the result is a
positive integer in ASN.1, which seems overly optimistic.

If the IETF feels that adding randomization to signatures is important,
we should define randomized signature functions. We could start with
NIST Draft SP 800-106
(<http://csrc.nist.gov/publications/drafts/800-106/2nd-Draft_SP800-106_J
uly2008.pdf>). However, I think that doing so is sending the wrong
message: we should instead be encouraging the use of non-broken hash
functions.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag