<div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 13, 2017 at 5:11 PM, Viktor Dukhovni <span dir="ltr"><<a href="mailto:cryptography@dukhovni.org" target="_blank">cryptography@dukhovni.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Sep 13, 2017, at 4:55 PM, Perry E. Metzger <<a href="mailto:perry@piermont.com">perry@piermont.com</a>> wrote:<br>
><br>
> Note my security caveat isn't about the certificates being somehow<br>
> less good than other certificates. It is that someone gaining<br>
> temporary control of a server for your domain is in a good position to<br>
> also get a cert for your domain signed. Of course, absent a system<br>
> like Certificate Transparency, or cert pinning, that's the case<br>
> anyway, so perhaps I'm being paranoid.<br>
<br>
</span>Let's Encrypt just makes it ever more clear that the WebPKI (a few<br>
EV certificates aside along with the few users who notice the<br>
difference) is and has been a leap of faith by the DV-issuing CA.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">​I can't parse that.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The objective of Let's Encrypt is to go to a 100% encrypted Web. That has obvious benefits if all you care about is stopping mass surveillance. But that is not the only effect.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Once you decide that every Web site has to have a certificate, it follows that either CAs become censors or there must be some class of certificate that can be obtained by any party with a valid ICANN domain name. This is very problematic because the WebPKI was not developed for confidentiality, it was developed to provide authentication and accountability. If you recall, we were limited to 40 bit crypto in the early days of SSL.</div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thus certificate issuance is fundamentally vulnerable to MiTM<br>
attacks on the CA by folks in position to launch active attacks<br>
on the network backbone.  You're really only protected from<br>
WiFi and similar attacks at cafes, airports, ... by attackers<br>
who can MiTM the end-users network connection.<br>
<br>
With BGP attacks and the like, a determined adversary will<br>
be able to get a DV certificate for most domains from some<br>
DV-issuing CA.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">​The rather subtler issue with LE is that the single most effective check in the DV system for consumer protection is the pre and post issue checks on the credit card. Phishing sites didn't like using DV certs because they had to use phished credentials to get the cert. If the fraud was discovered, they would lose the site.​</div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I tried to suggest at a recent IETF meeting that CAs should<br>
use DNSSEC-validating resolvers when querying CAA records,<br>
to reduce this MiTM risk, but got rather strange pushback<br>
from PHB on behalf of Comodo.  FWIW, Let's Encrypt does in<br>
fact do validated DNS resolution.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">​You were unclear then. The specification makes clear that CAs are required to perform DNSSEC validation if a zone is signed. However a zone is not required to have DNSSEC to publish a CAA record. That is intentional because conflating the two is what killed DANE.</div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"></div></blockquote></div><br></div></div>