okTurtles DNSChain is a decentralized, blockchain-based DNS network that solves the problem of having to rely on a centralized network of CAs; thus, it is resistant to man-in-the-middle (MitM) attacks.
Why couldn’t Let’s Encrypt be decentralized like okTurtles so that there is no single point of failure (like “DST Root CA X3” or another centralized CA)?
Let’s Encrypt is about getting TLS out there, everywhere, right now. Technologies like DNSChain are interesting, but it’ll be decades before we even know if anything like it will ever replace TLS as we know it today. Just look at how long it has taken IPv6 or DNSSEC to get where it is today (and it’s still hardly used!). As of now, it looks more like the CA system + DANE + HPKP is the endgame (for now).
The Let’s Encrypt you’re suggesting would be an interesting technical project, but likely wouldn’t get used in production for decades.
@Geremia, we would need browser support in order to be decentralized this way because systems like okTurtles don’t work out-of-the-box with existing browsers.
I think this kind of decentralization is extremely valuable and appreciate that people are working on it, but Let’s Encrypt as a CA is not obviously in a position to do this. You might want to take this issue up with the browser developers.
We’re very focused on making the existing system work for every web site right away using the security technologies that are already built. That doesn’t mean that we think the existing system is perfect or that it couldn’t be replaced or supplemented by something different!
Considering that certificates just woks once there are emitted independently from the CA status (most browser will just ignore OCSP failure) and the zillion of CA out-here, one can not say there is a SPOF.
[quote=“Nit, post:4, topic:12325, full:true”]Considering that certificates just woks once there are emitted independently from the CA status (most browser will just ignore OCSP failure) and the zillion of CA out-here, one can not say there is a SPOF.[/quote]I was thinking in terms of a MitM attack. What prevents Let’s Encrypt’s root CA from being a SPoF? What if that CA gets compromised, and they start issuing spoof Let’s Encrypt certs? Is that possible?
[quote=“pfg, post:2, topic:12325, full:true”]The Let’s Encrypt you’re suggesting would be an interesting technical project, but likely wouldn’t get used in production for decades.
[/quote][quote=“schoen, post:3, topic:12325, full:true”]I think this kind of decentralization is extremely valuable and appreciate that people are working on it, but Let’s Encrypt as a CA is not obviously in a position to do this.[/quote]Not even by utilizing a longer and more interconnected certificate chain?
(cf. my question on Security StackExchange)
You think they may be a SPoF (single point of failure) for what exactly (what stop to work if what breaks) ? What having or not a SPoF has to do with a MitM attack (between which two parties ?).
Any CA can get compromise (It happen before) and then emit (valid) certificates for any domains. Yes it’s bad, and the only way to currently mitigate this at a protocol level is HPKP for https, dane for smtp, nothing for the rest (dane could work for everything, but its not currently deployed client side).
More generally, compromised CA can be detected by the Certificate Transparency system and be blacklisted, but I think this can take some times (someone has to see that this particular CA has emit a cert for his/her domain without being requested to do so by the domain owner).
The length of the cert chain doesn't really help for decentralization purposes, because in X.509 the signatures only relate to trust delegations from one entity to another, and not to checking the content of the cert (so when entity X appears in the middle of the trust chain, they're not saying "this end-entity cert is right", they're saying "we agree to delegate trust to entity Y; if you accept us as a CA, you can also accept Y as a CA").
For example, for the current Let's Encrypt chain, we might sign a cert for the end-entity example.com using our Let's Encrypt intermediate cert, which in turn is signed by IdenTrust. Now the chain contains three things: IdenTrust's root, our intermediate, and the end-entity example.com cert. However, IdenTrust not only didn't check the correctness of the example.com cert, it doesn't even know it exists! IdenTrust's role in this chain is limited to saying that Let's Encrypt is a real, trustworthy CA.
That structure doesn't change in a longer cert chain; if IdenTrust signed a certificate nominating SuperKeen CA as a certificate authority and SuperKeen signed a certificate nominating Great Security as a certificate authority and Great Security signed a certificate for Trusty Certificate Trust and Trusty Certificate Trust signed a certificate for you, Geremia, none of the entities in the chain would even know you exist or check or confirm the correctness of the Geremia cert except for the last one, Trusty Certificate Trust. There is no sort of day-to-day involvement or awareness or direct supervision of the content of the end-entity certs by the CAs earlier in the chain. The only thing the other folks in the chain can do is revoke their own signatures if they think that a downstream CA is misbehaving egregiously.
So the basic structure of X.509 really supports hierarchy, not decentralization. If you make chains long then anyone in the chain has a kind of veto power, but not over individual certs, just over the yes-or-no validity of the remainder of the chain. So again, IdenTrust could choose to revoke its signature for Let's Encrypt as a whole, but can't approve or disapprove individual certificates that Let's Encrypt issues.
One way of putting this issue is that X.509, as deployed and implemented, doesn't really allow for multiple signatures on the same cert, so there isn't a useful way that you could get certificates from 10 CAs in parallel (or 10 whoever or whatevers in parallel) and present them all to a user to help in making trust decisions and to confirm the same information via multiple sources. Instead, you get the signatures in series, in a delegation hierarchy. There are minor exceptions to this having to do with different entities having different views of what is a root vs. an intermediate CA, but I don't think they change the picture qualitatively.
There's an interesting PKI reform and decentralization project called Monkeysphere
that does directly aim to decentralize trust on the web; the big difficulty is that it means accepting new certs is much less automatic and requires much more conscious and explicit decisions by the relying party (the end user). The challenge of that is that most people don't currently understand exactly what these decisions mean, and if they come to understand, they're still not accustomed to spending a lot of time making these decisions in order to use the web, and don't necessarily even have a specific basis on which to make them. An advantage of the centralized PKI is that you can automatically have browsers make these decisions on behalf of the user (as "user agents") in a relatively automated and relatively predictable way. Of course the centralized PKI has other serious disadvantages which are well-known to advocates of decentralized communications systems.
The existing browser trust model and the technology behind it are really not adapted for decentralized trust decisions, so something significant will have to change on that end.
More ubiquitous cross-signing (RFC 5280, Section 3.2) might be more along the lines of what I was thinking.
Interestingly, Let’s Encrypt used cross-signing “to appear in major browsers before it’s actual root CA is deployed with browsers” (source).
Sure, but the system that incorporates the cross-signing is the same one I was describing before and has significant limitations in terms of decentralization. One of these is that there is still no mechanism to require more than one signature on an end-entity certificate; another is that the significance of the cross-signature is still an all-or-nothing hierarchical delegation of authority. IdenTrust’s cross-signature for Let’s Encrypt (not everyone uses the term in exactly this way) means that IdenTrust agreed that Let’s Encrypt can act as a CA for any name [except .mil] on the whole Internet, and IdenTrust has no direct supervision or awareness of Let’s Encrypt’s issuance decisions.
So what we have with cross-signatures is a world in which CAs can create more CAs, but by doing so they are also creating more attack surface within the CA system.
yep, the only thing that could be decentraized would be for example making different intermediates for different TLDs, but the all have to be signed by the main root centralizing that part again
Mainline DNS is decentralized too if it wasn’t you’d be seeing large scale blackouts every time a country or some group was pouting…
TLS is decentralized. Nothing is stopping you from using self-signed and disabling verification in a software lib or browser. In fact I see it done a lot with the static OpenSSL lib.
CAs are needed to verify identities because people want an identity from some name that is susceptible to accountability if it’s wrong or abused(like COMODO). If loosely verified or anonymous CAs existed TLS handshakes would need a redesign and you’d still end up with a small group that verifies everything.
Also, not even the BTC reference implementation devs can get along(probably cause they thought they’d get rich as the developers), so I wouldn’t invest too much in blockchain dependencies…
DNS is parrtly centralized, starting from the whois, aka who designates which nameservers are the authority for a given domain. DNSServers can literally answer anything but when we want to see real answers we either use DNSSec or contact the real dns server, and the lookup is centralized as well as the DNSSec signing.
Root servers are hardened and decentralized(I think there were eight last time I looked). Nameservers are private property usually in the hands of solution providers who’s philosophy is “how much money can we save?”. Much like those belonging to some CAs who handle TLS and UEFI certificates.
I’ll admit I don’t know the entire spec of DNSSec though. I’d imagine it has some form of cryptography validation using signature distribution or it’d be pointless.
DNSSec basically works the following.
there is once root key which basically has all the trust.
to stay safely offline (at 2 locations btw) the root key (which is a so-called key-signing-key, KSK) signs a batch of Zone signing keys (ZSK) every 3 months at a “Key Signing Ceremony” which then actually sign the root zone, which then can be rotated every few weeks.
the root Zone has signatures about all the TLDs including so-called DS (Delegation Signer) records, which works a bit like the certificate in TLS but in reverse.when you for example want to checck the signature for cloudflare.com you see that cloudflare.com for example has a DNSKEY record (which is the public key) and to check the trust they go to the .com zone (the parent zone,or the intermediate CA) to check for a DS record that matches the DNSKEY provided, also the validity of each set of records (RRSET) is validated using the Record Signatures (RSIG) to check that nothing’s been tampered with.
the same thing happens at the com zone, check for key check signatures and DS from root to .com, and lastly the ZSK of the root Zone is checked against the RSIG which was made at the Key Signing Ceremony using the root key.
the best thing is the tree-like structure of the System. Unlike CAs where any CA can seriously damage the whole system, in DNSSec even a leakage of the .com Zone Private key or whatever wont affect my domains because they are at other TLDs.
so each registry has a “DNSSec CA” which only works for their own TLD.
and each Domain owner has (as we could say) a tecnically restricted “DNSSec CA” because with the DS Record the DNSSec control of the zone is completely given to the registrant, meaning, they could even create subzones and more keys and DS records under his zone, and Using TLSA they technically could even go as and make an own CA for their domain (even if browsers wont support DANE/TLSA CAs yet)
There are 13 ipv4 and 13 ipv6 of dns root servers:
$ host -t NS .
. name server a.root-servers.net.
. name server b.root-servers.net.
. name server c.root-servers.net.
. name server d.root-servers.net.
. name server e.root-servers.net.
. name server f.root-servers.net.
. name server g.root-servers.net.
. name server h.root-servers.net.
. name server i.root-servers.net.
. name server j.root-servers.net.
. name server k.root-servers.net.
. name server l.root-servers.net.
. name server m.root-servers.net.
but theses ip point to hundred of servers all around the world.
okay.well they can sync and stuff, but with CAs and the “I trust you completely and dont care what you issue” model of x509.
also decntralizing is probably pretty complex because each one has to stay up to date etc
I dare say it’s impossible to be decentralized more than having an array of authority nodes. The closest thing would be some system where a majority signoff on a massive scale would be validation and that is susceptible to attack by botnets.
But then again so are bitcoin(50% total throughput) and TOR(using API calls to brute-force chain placement). There could just be monitoring, but then you have an authority again…
Hi Nit,
Hi Geremia,
Hi Schoen
I agree with you! We should indeed avoid a SPoF to protect the integrity of our infrastructure. In my opinion what is still missing is a sound Content Security Policy (CSP) for Letsencrypt systems like Github has it:
Github e.g. got an A+ on Security Headers and Let’s Encrypt did obviously better than most sites (nearly everybody sadly has an F…), but as a trusted CA Let’s Encrypt should thrive for the best web server security rating, meaning A+ not just B grade 
Let’s Encrypt has:
Hi Nit,
Hi Geremia,
Hi Schoen,
I would love to see that fixed on the website. We wrote two posts on how to do it:
Secure Your Web Server against Attacks via XSRF/CSRF/XFS: How to Design a Content Security Policy
https://www.cloudinsidr.com/content/secure-your-web-server-against-attacks-via-xsrfcsrfxfs-how-to-design-a-content-security-policy/
Fixing your Web Server’s Security Headers: From Hall of Shame to Hall of Fame
https://www.cloudinsidr.com/content/fixing-your-web-servers-security-headers-from-hall-of-shame-to-hall-of-fame/
Speaking of Public-Key-Pins: this could be a feature of the LetsEncrypt certificate setup software.