[cabfpub] Concerns with the proposal for LV certificates

[Sigbjørn Vik]

CloudFlare states that 1.69% of users do not use browsers which support
SHA-2, Facebook that up to 7% don't. During 2016 sites will gradually
stop working in those browsers, and those users will be forced to
upgrade to more secure browsers. This is a good thing, and something we
want to encourage.

For Windows XP SP2 and older, there are e.g. Firefox, Chrome and Opera
which all support SHA-2. For the vast majority of phones, there is e.g.
Opera Mini. All of these are free.

The question is not how many browsers do not support SHA-2, but how many
devices do not support SHA-2 browsers.

On 10-Dec-15 23:12, Ryan Sleevi wrote:
> 
> 
> On Thu, Dec 10, 2015 at 2:05 PM, Ryan Sleevi <sleevi at google.com
> <mailto:sleevi at google.com>> wrote:
> 
> 
>         This is how a SHA-1 collision attack would work (based on the MD5
>         attack[1]):
> 
>         1. Attacker finds a SHA-1 collision.
> 
> 
> It's worth noting that the proposed LV suggestion includes changing the
> SHOULD to a MUST with respect to serial entropy.
>  
> 
> 
>         2. Attacker requests a SHA-1 certificate from a CA, with a CSR
>         based on
>         the collision they found in step 1.
> 
>         3. Attacker forges a SHA-1 certificate by replacing the subject name
>         in the cert that was obtained in step 2.  Because of the collision,
>         the signature is still valid.
> 
>         4. Attacker uses the forged SHA-1 certificate to impersonate a
>         server in a MitM attack.
> 
> 
> It's worth noting that the attack would be not to impersonate a single
> server, but to modify the extensions on the certificate such that they
> would become a CA (basicConstraints with CA=true)
> 
> As discussed in the past on the Forum, the attacker gains significant
> control from the point of the SPKI and onwards.
>  
> 
>         Also note that the attacker can forge a certificate for _any_
>         domain,
>         not just domains which have opted into LV certificates.
> 
>         Hash collision attacks are primarily attacks on the certificate
>         issuance process so that's where the problem is best addressed.
>         Downgrade-proofing the TLS handshake is important when dealing with
>         weak ciphers and protocols (e.g. RC4, SSLv3), but it doesn't
>         help with
>         SHA-1 collisions.  An attacker can forge and use a SHA-1 certificate
>         without the downgrade-proof logic ever coming into play.
> 
> 
> Yes, although the LV argument is such that 'modern browsers' / 'secure
> browsers' would reject SHA-1, and thus the downgrade would not, in fact,
> be a practical attack.
> 
> Among other issues I have with the LV proposal, as suggested, is that it
> fails to appreciate the economies of scale and how we got here. That is,
> it (in effect) calls the deprecation of SHA-1 short-sighted (or, worse,
> self-centered to serve Silicon Valley), and seeks to extend it. It does
> so with the caveat that every modern browser will or should disable
> SHA-1, and thus not be at risk.
> 
> However, the only reason we're able to get to a point where disabling
> SHA-1 is viable - which doesn't happen until 2017 and will still be
> painful - is precisely because SHA-1 is no longer permissible starting
> in 2016, and the Forum's adoption of the SHA-1 ballot gave clear signals
> to the industry and webmasters that SHA-1 itself is not viable/secure.
> 
> So, in effect, it presumes the benefits of the existing hard
> deprecation, while attempting to propose a soft deprecation - but this
> unfortunately doesn't offer a model for future deprecations, because
> without a hard deprecation, you suffer the first mover problem and can't
> get enough traction to secure the browser.
> 
> We'll inevitably see this with post-quantum crypto and the death of RSA
> and ECDSA, but I don't feel that LV offers a viable model forward,
> either for SHA-1 or future migrations.
> 
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
> 


-- 
Sigbjørn Vik
Opera Software