<div dir="ltr">Forwarding on behalf of Andrew Ayer<div><br></div><div>On Thu, Dec 10, 2015 at 1:54 PM, Andrew Ayer <span dir="ltr"><<a href="mailto:agwa@andrewayer.name" target="_blank">agwa@andrewayer.name</a>></span> wrote:<br><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"><br>On Wed, 9 Dec 2015 18:11:30 -0500<br><a href="mailto:eric@konklone.com">eric@konklone.com</a> (Eric Mill) wrote:<br><br>>    - This proposal also adds operational constraints to site owners --<br><span class="">>    their eligibility for an LV cert requires them to maintain<br>> downgrade-proof, thoughtfully designed code to provide different<br>> certs to different clients. To the extent the BRs apply operational<br>> constraints to CAs, these are accompanied by a system of audits that<br>> provide some degree of assurance the operational constraints are<br>> being carried out. CloudFlare and Facebook have both released, or<br>> pledged to release, the code that executes their<br>> certificate-switching.<br><br></span>This is a good point, but I think it's worthwhile to take a step back<br>and assess whether the downgrade-proof certificate switching logic<br>that would be mandated by LV even mitigates the risk of SHA-1 in the<br>first place.  I argue that it does not.<br><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><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><br>The LV requirements would not hinder this attack.  LV doesn't stop the<br>attacker from getting a SHA-1 certificate from the CA; to the contrary,<br>LV would allow SHA-1 certificates to be issued past the Dec 31, 2015<br>sunset.  And the downgrade-proof cert switching logic wouldn't stop the<br>MitM attack, since the victim will be talking to the attacker's server,<br>not to a server employing downgrade-proof cert switching logic. The<br>downgrade-proof server doesn't even need to be contacted for the attack<br>to work.<br><br>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><br>Regards,<br>Andrew<br><br>[1] <a href="https://www.win.tue.nl/hashclash/rogue-ca/" rel="noreferrer" target="_blank">https://www.win.tue.nl/hashclash/rogue-ca/</a></blockquote></div><div class="gmail_extra"><div class="gmail_quote"><br></div></div></div>