<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 10, 2015 at 2:05 PM, Ryan Sleevi <span dir="ltr"><<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5"><br>This is how a SHA-1 collision attack would work (based on the MD5<br>attack[1]):<br><br>1. Attacker finds a SHA-1 collision.<br></div></div></blockquote></div></div></blockquote><div><br></div><div>It's worth noting that the proposed LV suggestion includes changing the SHOULD to a MUST with respect to serial entropy.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5"><br>2. Attacker requests a SHA-1 certificate from a CA, with a CSR based on<br>the collision they found in step 1.<br><br>3. Attacker forges a SHA-1 certificate by replacing the subject name<br>in the cert that was obtained in step 2.  Because of the collision,<br>the signature is still valid.<br><br>4. Attacker uses the forged SHA-1 certificate to impersonate a<br>server in a MitM attack.<br></div></div></blockquote></div></div></blockquote><div><br></div><div>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)</div><div><br></div><div>As discussed in the past on the Forum, the attacker gains significant control from the point of the SPKI and onwards.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div class="h5">Also note that the attacker can forge a certificate for _any_ domain,<br>not just domains which have opted into LV certificates.<br><br>Hash collision attacks are primarily attacks on the certificate<br>issuance process so that's where the problem is best addressed.<br>Downgrade-proofing the TLS handshake is important when dealing with<br>weak ciphers and protocols (e.g. RC4, SSLv3), but it doesn't help with<br>SHA-1 collisions.  An attacker can forge and use a SHA-1 certificate<br>without the downgrade-proof logic ever coming into play.<br></div></div></blockquote></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div>