[cabfpub] Serial Number Entropy
Erwann Abalea
erwann.abalea at opentrust.com
Tue Aug 12 01:20:46 MST 2014
That was a collision attack, not a pre-image one (MD5 is still pre-image
resistant -- or not a useful enough target anymore).
notBefore/notAfter isn't a good place to add entropy to: 16bits max for
time components of one of notBefore/notAfter, if a CA is allowed to play
with the date part, it is then implicitely allowed to play with
information that will be compared to effective and hard sunset dates;
something already known to be problematic.
The necessary entropy was added to mitigate collision attacks while
allowing legacy hash functions as a transition. That raised the
attacker's bar from "collision attack" to "random prefix collision
attack". It's strictly not necessary *while* the hash function is
collision resistant. Nevertheless, I think it's best to be conservative
and keep this requirement, and let browsers set sunset dates for
declining crypto functions/parameters (<2048 bits RSA, MD5/SHA1, ...)
based on theoretical results.
(If we allow for Ed25519 or similar schemes, we'll have this "collision
protection" for free, AIUI.)
--
Erwann ABALEA
Le 11/08/2014 21:46, Ben Wilson a écrit :
>
> Thanks, Ryan. I wasn't trying to raise resurrect MD5 (or SHA1), I'm
> just saying that we ought to revisit what we say about serial number
> entropy and the reasons for it. I had forgotten that CAs were told
> not to place entropy into the Date fields---someone on this other call
> (Federal PKI) suggested that it was a better place to embed entropy.
> As you note, there are more sophisticated methods to address
> this---which leads to my underlying intent -- is the CA/B Forum ready
> to tackle a more sophisticated or complex formulation of the entropy
> requirement that takes into account current information and hashing
> algorithm strengths? Or should we hold off on discussing this until
> after January 2016 when SHA1 certificates are no longer issued ?
>
> *From:*Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Monday, August 11, 2014 1:24 PM
> *To:* Ben Wilson
> *Cc:* CABFPub
> *Subject:* Re: [cabfpub] Serial Number Entropy
>
> On Mon, Aug 11, 2014 at 11:53 AM, Ben Wilson <ben.wilson at digicert.com
> <mailto:ben.wilson at digicert.com>> wrote:
>
> The purpose of this email is just to place a reminder for us or get
> the conversation going if anyone wants to discuss this suggestion from
> a call I was on today --
>
> Could the CA/B Forum (and Browser root programs) revise/update its
> response to the 2008 Sotirov MD5 pre-image attack?
>
> I'm not sure what you expect from the Browser Root Programs, or what
> call you were on, but
>
> - OS X / Safari (and Chrome on OS X) - Has disabled MD5 support since
> OS X 10.9 - http://support.apple.com/kb/HT6011
>
> - Chrome (on all platforms) - Treats MD5 the same as untrusted root /
> any other cert with errors since Chrome 18 (aka December 2011) -
> https://code.google.com/p/chromium/issues/detail?id=101123
>
> - Firefox (on all platforms, except where a distro/sys admin
> overrides) - Disallows MD5 in signatures since FF16 -
> https://bugzilla.mozilla.org/show_bug.cgi?id=650355
>
> - IE - As of February 2014, Windows Vista+ won't allow MD5 for
> signatures for CAs in their root program -
> https://technet.microsoft.com/library/security/2862973
>
> The commenter's point was that today there are other ways to
> reduce the risk of this pre-image attack in addition to 20-bit
> entropy in serial numbers (which we specify in the Baseline
> Requirements for SSL and the Code Signing draft). Those include-
> variable issuance/expiration times (e.g. minutes, seconds, etc.)
> and better hash algorithms (not SHA1).
>
> Sure. But MD5 is dead. Why would the commenter wish to revive it?
>
> As a reminder for CAs, SHA-1 is also not long for this world. While
> there may be attempts to prolong it's life, it's better to start
> transitioning away. For example, it's highly likely that a future
> version of Chrome will treat certificates with validity periods
> (measured by NotAfter) beyond the *hard* sunset date (1/1/2017) that
> Microsoft has proposed as certificates with errors, warning the user
> and treating such resources as mixed content (requiring user
> interaction).
>
> Let's also keep in mind that these mitigations are not sanctioned by
> the root programs. For example, 20-bits of entropy is insufficient for
> the Microsoft Root Program (
> http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx
> ) , which requires 64-bits (eight bytes)
>
> In the same section, Microsoft also makes it clear that CAs are no
> longer allowed to place entropy into the Date fields. See
> http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx#_edn12
> for a further discussion.
>
> So really, the ONLY acceptable mitigation is move to better hash
> algorithms, and if you're doing that, it SHOULD be SHA-256, not SHA-1.
>
> As a final reminder, the Baseline Requirements state SHA-1 "MAY be
> used with RSA keys until SHA-256 is widely supported by
> *browsers* used by a substantial portion of relying-parties
> worldwide". Given that Windows XP, a historical complaint from CAs,
> supports SHA-256 since SP3, I think the burden is on CAs to
> demonstrate that there exists a population sizeable enough that
> SHA-256 support cannot be called "substantial".
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20140812/aaa21047/attachment-0001.html
More information about the Public
mailing list