[cabfpub] Ballot 152 - Issuance of SHA-1 certificates through 2016)

[Dean Coclin]

Thanks to you and Jacob for providing the relevant information. I’ll be sure to pass it on.  Does anyone have anything else to add?

 

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Monday, October 19, 2015 4:51 PM
To: Dean Coclin
Cc: public at cabforum.org
Subject: Re: [cabfpub] Ballot 152 - Issuance of SHA-1 certificates through 2016)

 

To the first matter, it seems the 2008 paper on exploiting RapidSSL/Verisign should provide adequate background to the issue - https://events.ccc.de/congress/2008/Fahrplan/attachments/1251_md5-collisions-1.0.pdf

 

The issue here is with a chosen-prefix collision, and obtaining a certificate signed with the choice of collision bits. That is, such attacks would primarily affect new issuance, since a new certificate signed with an attacker-chosen set of collision bits would be able to result in being accepted for an attacker-controlled prefix.

 

Given that a number of CAs, and their subCAs, are not properly following the Baseline Requirements requirements with respect to entropy, we cannot presume that entropy alone would be a sufficient mitigation against such an attack.

 

To the second matter, this is simply the traditional ecosystem/first-mover problem. Certainly, the majority of the Browser members in the Forum have significant interest in the ecosystem of WebPKI as a whole (Microsoft has concerns with respect to OS-level communication, Google has concerns with server-to-server communication and the use in non-browser environments such as Google App and Compute Engines, Mozilla has a stated mission concerning the Internet at large, Apple has concerns with non-browser application-level communication, etc). The bifurcation of Browser/non-Browser is thus perhaps a false division. It affects application developers when a browser can't access their site that the application can, as does the inverse. I think the division may be "Organizations that control communications end-to-end" and "Organizations that do not", with Browsers (and those that provide security runtimes) largely operating in that second camp.

 

The problem is one of ecosystem adoption - the 'enterprise' use case of using SHA-1, for example, can lead to language/security runtimes accepting insecure practice, which thus makes the non-enterprise case less secure. Even Browsers are subject to such discussions, as many times they're asked to relax security requirements for "intranet or internal" sites, even when such intranet/internal sites are publicly addressable and reachable. If Browsers relax their security requirements for these sites, they end up relaxing their security requirements for all sites, thus presenting an entire ecosystem security risk. This can be seen in the deprecations of MD5 and RC4, or in the removal of insecure TLS version downgrades to deal with poor enterprise TLS implementations.

 

Thus, as an ecosystem and an industry, the only viable solution that allows all users to be secured is one that moves the entire industry forward, as carveouts and exceptions end up affecting the entirity of the ecosystem. This is ultimately what the CA/Browser Forum is meant to help resolve, by solving the 'first mover' problem by building industry consensus in stakeholders, so that things that proceed in an orderly and phased approach.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151019/75f77645/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5747 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20151019/75f77645/attachment-0001.bin