Hello everyone, I’d also like to jump in the conversation and say that I believe Let’s Encrypt’s move here is good, in my opinion, and will lead to an overall increase in security for the entire ecosystem.
When they began operations, back when certificates weren’t free, I remember asking them what their challenge validation IP addresses were, so I could implement some logic involving them. Their response back then was that they don’t publish that list, so they can maintain agility, and avoid ossification. Although it made my life a little bit more difficult at the time, I am grateful they did this after all those years. The pros clearly outweighed the cons in the long run. I am confident that this decision is going to lead to similar results: a few people are going to be a little bit inconvenienced today, maybe a few things will break, but it’s for the overall good. This has happened many times in the WebPKI’s history: Cloudflare made HTTPS broadly available and free, but they required ECDSA. Due to them sticking to this for the Free plans, and only using RSA for the more expensive offerings, we now have broad ECDSA support across all devices, such as computers, mobile phones, IoT, etc. They knew things would break, but they also knew that was the only way to move forward. Let’s Encrypt’s (and other CAs’) Root Migrations also highlighted an important problem: we need all devices to have upgradeable trust anchors. Shipping a trust store and then having no ability to update this is not a smart move, and the opposite increases security on many fronts: cryptographic agility, inclusion and removal of CAs based on practices, etc. I know everyone’s busy, and they have important things to do, which is respectable, but sometimes asking for an exception just shouldn’t be possible or granted. Especially if that “exception” is keeping everyone else back. I’ve personally seen exception requests for prolonging X.509 certificates’ lifetime, I guess with magic or time machines… Regarding key pinning, as the others expressed before me, this is an outdated practice that we now understand was not the best idea. Especially at the browsers. For mobile applications, that’s recommended or practiced, but it’s a different landscape. I still see multiple solutions there. For example, Signal, the popular messaging app, is using a self-signed certificate, bypassing WebPKI entirely. For users of the WebPKI, there are three main models: 1) Pin the leaf (key) If you pin the key of the leaf certificate, and not the certificate itself, you can keep issuing with the same key if you’d like, or set of keys, and there’s no problem. You can always shoot yourself in the foot, but that it a risk you hopefully understand and accept. 2) Pin the Intermediate CA If you do that, you don’t have the same security properties: now everyone who can issue Let’s Encrypt certificates will be able to get past the pin check, so what you’re effectively doing is limiting issuance to one CA only (maybe enforced with CAA too). That’s good, because I may only trust Let’s Encrypt, and no other CA, but: 3) Pin the Root CA If you pin the Root, it’s true that it’s at a higher level, but for this case it’s no different: if Let’s Encrypt has 1 SubCA, like now, then pinning the Root or the SubCA is the same thing. You don’t lose or gain anything. As Amir said however, the SubCA carries the risk of being much more easily revocable, replaceable, shorter-lived. You’re setting yourself up for tighter monitoring, outages, incidents, etc. To summarize, I would say that the benefits to the WebPKI are significant here, having the largest CA use dynamic chains, and it’s worth the small changes that will be needed here and there. It will position all of us for an improved and better WebPKI that can bring more trust and security to all connections. We’ll get to pay back some technical debt, and we’ll be more effective moving forward. Maybe one day we can also get dynamic Roots too! :P Thanks, Antonis -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/AE85193A-5FAD-43FB-AC54-4B9BB5CA04C8%40gmail.com.
