[cabfpub] Concerns with the proposal for LV certificates

[Ryan Sleevi]

Forwarding on behalf of Andrew Ayer

On Thu, Dec 10, 2015 at 1:54 PM, Andrew Ayer <agwa at andrewayer.name> wrote:

>
> On Wed, 9 Dec 2015 18:11:30 -0500
> eric at konklone.com (Eric Mill) wrote:
>
> >    - This proposal also adds operational constraints to site owners --
> >    their eligibility for an LV cert requires them to maintain
> > downgrade-proof, thoughtfully designed code to provide different
> > certs to different clients. To the extent the BRs apply operational
> > constraints to CAs, these are accompanied by a system of audits that
> > provide some degree of assurance the operational constraints are
> > being carried out. CloudFlare and Facebook have both released, or
> > pledged to release, the code that executes their
> > certificate-switching.
>
> This is a good point, but I think it's worthwhile to take a step back
> and assess whether the downgrade-proof certificate switching logic
> that would be mandated by LV even mitigates the risk of SHA-1 in the
> first place.  I argue that it does not.
>
> This is how a SHA-1 collision attack would work (based on the MD5
> attack[1]):
>
> 1. Attacker finds a SHA-1 collision.
>
> 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.
>
> The LV requirements would not hinder this attack.  LV doesn't stop the
> attacker from getting a SHA-1 certificate from the CA; to the contrary,
> LV would allow SHA-1 certificates to be issued past the Dec 31, 2015
> sunset.  And the downgrade-proof cert switching logic wouldn't stop the
> MitM attack, since the victim will be talking to the attacker's server,
> not to a server employing downgrade-proof cert switching logic. The
> downgrade-proof server doesn't even need to be contacted for the attack
> to work.
>
> 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.
>
> Regards,
> Andrew
>
> [1] https://www.win.tue.nl/hashclash/rogue-ca/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151210/b2ab23ea/attachment.html