[cabfpub] Concerns with the proposal for LV certificates

[Ryan Sleevi]

On Thu, Dec 10, 2015 at 2:05 PM, Ryan Sleevi <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20151210/d37c4f3a/attachment.html