4 ms·

> What I don't get, with DNSSEC getting rolled out more and more, why can't every site operator simply stick the fingerprint of their HTTPS cert in DNS and have

> What I don't get, with DNSSEC getting rolled out more and more, why can't every site operator simply stick the fingerprint of their HTTPS cert in DNS and have DNSSEC take care of the trust chain? This question is extremely relevant given how DNS-based authentication is the preferred way to authenticate with letsencrypt. If DNS is good enough for letsencrypt to validate you and give you a cert, why can't DNS be good enough for the browser alone, without needing to rely on some third party service? Letsencrypt has certainly made HTTPS easier in practice, but we really need to get rid of the whole CA-model entirely.

sarakayakomzin 6y ago
>Letsencrypt has certainly made HTTPS easier in practice, but we really need to get rid of the whole CA-model entirely. solve the root trust problem and claim your nobel prize.
moray 6y ago
A DKIM like service? For emails I find it very convenient, publish your public key with DNS and sign outgoing emails, outgoing emails are now "certified" coming from your server and the recipient can easily verify it, no CAs involved.
mytailorisrich 6y ago
What Letsencrypt does (and all other providers of certificates to end users do) is verify that you control the domain you are requesting a certificate for. That's well and good, but who are those Letsencrypt guys, anyway? That's why there is a chain of trust and Certificate Authorities. You, and your browser, cannot know everyone out there so you pick a few 'authorities' that are well-known and deemed serious enough to be trusted and go from there. DNSSEC operates on the same principle of a chain of trust from root.
- josteink 6y ago
  > What Letsencrypt does Letsencrypt is run by Mozilla. So lets instead make that: > What Mozilla does ... is that you control the domain you are requesting a certificate for. So Mozilla trusts me based on me controlling the DNS of my domain, and can issue me a security-token which Mozilla's browser (and other browsers) then can trust. Note: It does not trust me or verify me to be non-malicious, honest or have good intentions of any kind. It merely verifies that I control the DNS of the domain I request a certificate for. That's it. That is all. So why can't Mozilla's browser simply instead of trusting these magic tokens, instead just verify that the cert for the site matches the cert pinned in DNS, thus validating that the site-operator is indeed in control of the DNS of his domain? It will be exactly the same validation, except now we don't have to rely on a third-party service to do that for us. And then the web can finally be autonomous and decentralized again.
  - tialaramex 6y ago
    > Letsencrypt is run by Mozilla. Let's Encrypt is a service of ISRG, a public benefit corporation https://www.abetterinternet.org/about/ https://www.abetterinternet.org/about/ Some key ISRG people were from Mozilla, but so what? > So why can't Mozilla's browser simply instead of trusting these magic tokens, instead just verify that the cert for the site matches the cert pinned in DNS Poor deployability and interoperability. Now your browser mysteriously doesn't work on a lot of the world's networks and the site doesn't work with other browsers.
- xoa 6y ago
  But isn't the point here (and a source of confusion I share with all the other posters) that DNS is the actual root of trust? Heck, forget DNSSEC even, because it's not like Let's Encrypt demands it. You say that LE verifies >that you control the domain you are requesting a certificate for but it mostly seems to do it the exact same way any random person browsing to an HTTP site would: it checks the DNS records. It's not like there's an out of band channel here where they actually verify business records separately or something. So what exactly is the value of the middle man in this? Why not just have public sigs in the DNS records too? When DNS is the root of trust anyway and "Certificate Authorities" are reduced to fully automated systems, what value to "Certificate Authorities" even bring anymore in this context? It seems like a hack from a time when CAs were expected to provide some out of band verification that would actually be useful. But on the web that mostly hasn't happened or has been rendered moot (witness the death of EV). I can see how central CAs could still be useful in many other circumstances. But for anything where control of DNS directly correlates with control of the entire chain, it seems like it'd be a lot better to just decentralize into DNS.
  - mytailorisrich 6y ago
    The value of certificate authorities is to be the roots of trust, as said. The exact same applies to using DNS as chain of trust. You have to start with a well-known root of trust because it's impossible to know all the DNS servers or registrars out there. In fact that's exactly how DNSSEC works. It seems that the question is whether DNS and HTTPS certificates are converging to provide the same service. Perhaps, though I'm not sure, but that wouldn't change the system fundamentally.
    - xoa 6y ago
      >The value of certificate authorities is to be the roots of trust, as said. But they aren't, DNS is. That's my question. If someone controls my domain, they can point it wherever and get all the Let's Encrypt CA signed certs they want. So how exactly is the CA being a root of trust there if the CA itself is basing trust off of domain control? In neighbor comment it seems that maybe the CA is basically acting as a hack to bypass an inability by clients to check DNS? I can see why that would have some practical value in the near term but it'd be good to do away with it as soon as possible. Apple/Google/Microsoft (and maybe Mozilla) may be in a position to do so if no one else.
herio 6y ago
This was proposed already in 2012 with RFC6698. DNS based Authentication of Domain Entries, DANE. Hasn't really gone anywhere of importance. I personally think there's been a few factors as to why: * Distrust of DNSSEC and centralized authority. * Lagging DNSSEC deployment, not just in DNS but also in clients and applications. * Needs another DNS lookup on connection to validate certs, adding lag. I think it probably needs stapling support in some form just like cert validity checking. There's also been follow up RFC detailing it's use for SMTP, SRV records and PGP.
ameliaquining 6y ago
Let's Encrypt doesn't have to worry about firewalls and middleboxes blocking their DNS queries. Browsers do.
- marcosdumay 6y ago
  Yes, and browsers solution has been to tunnel those queries over some protocol that middleboxes can not mess with. Because losing the DNSSEC fields is the lesser of the problems they cause.

sarakayakomzin 6y ago

>Letsencrypt has certainly made HTTPS easier in practice, but we really need to get rid of the whole CA-model entirely. solve the root trust problem and claim your nobel prize.

moray 6y ago

A DKIM like service? For emails I find it very convenient, publish your public key with DNS and sign outgoing emails, outgoing emails are now "certified" coming from your server and the recipient can easily verify it, no CAs involved.

mytailorisrich 6y ago

What Letsencrypt does (and all other providers of certificates to end users do) is verify that you control the domain you are requesting a certificate for. That's well and good, but who are those Letsencrypt guys, anyway? That's why there is a chain of trust and Certificate Authorities. You, and your browser, cannot know everyone out there so you pick a few 'authorities' that are well-known and deemed serious enough to be trusted and go from there. DNSSEC operates on the same principle of a chain of trust from root.

josteink 6y ago
> What Letsencrypt does Letsencrypt is run by Mozilla. So lets instead make that: > What Mozilla does ... is that you control the domain you are requesting a certificate for. So Mozilla trusts me based on me controlling the DNS of my domain, and can issue me a security-token which Mozilla's browser (and other browsers) then can trust. Note: It does not trust me or verify me to be non-malicious, honest or have good intentions of any kind. It merely verifies that I control the DNS of the domain I request a certificate for. That's it. That is all. So why can't Mozilla's browser simply instead of trusting these magic tokens, instead just verify that the cert for the site matches the cert pinned in DNS, thus validating that the site-operator is indeed in control of the DNS of his domain? It will be exactly the same validation, except now we don't have to rely on a third-party service to do that for us. And then the web can finally be autonomous and decentralized again.
- tialaramex 6y ago
  > Letsencrypt is run by Mozilla. Let's Encrypt is a service of ISRG, a public benefit corporation https://www.abetterinternet.org/about/ https://www.abetterinternet.org/about/ Some key ISRG people were from Mozilla, but so what? > So why can't Mozilla's browser simply instead of trusting these magic tokens, instead just verify that the cert for the site matches the cert pinned in DNS Poor deployability and interoperability. Now your browser mysteriously doesn't work on a lot of the world's networks and the site doesn't work with other browsers.
xoa 6y ago
But isn't the point here (and a source of confusion I share with all the other posters) that DNS is the actual root of trust? Heck, forget DNSSEC even, because it's not like Let's Encrypt demands it. You say that LE verifies >that you control the domain you are requesting a certificate for but it mostly seems to do it the exact same way any random person browsing to an HTTP site would: it checks the DNS records. It's not like there's an out of band channel here where they actually verify business records separately or something. So what exactly is the value of the middle man in this? Why not just have public sigs in the DNS records too? When DNS is the root of trust anyway and "Certificate Authorities" are reduced to fully automated systems, what value to "Certificate Authorities" even bring anymore in this context? It seems like a hack from a time when CAs were expected to provide some out of band verification that would actually be useful. But on the web that mostly hasn't happened or has been rendered moot (witness the death of EV). I can see how central CAs could still be useful in many other circumstances. But for anything where control of DNS directly correlates with control of the entire chain, it seems like it'd be a lot better to just decentralize into DNS.
- mytailorisrich 6y ago
  The value of certificate authorities is to be the roots of trust, as said. The exact same applies to using DNS as chain of trust. You have to start with a well-known root of trust because it's impossible to know all the DNS servers or registrars out there. In fact that's exactly how DNSSEC works. It seems that the question is whether DNS and HTTPS certificates are converging to provide the same service. Perhaps, though I'm not sure, but that wouldn't change the system fundamentally.
  - xoa 6y ago
    >The value of certificate authorities is to be the roots of trust, as said. But they aren't, DNS is. That's my question. If someone controls my domain, they can point it wherever and get all the Let's Encrypt CA signed certs they want. So how exactly is the CA being a root of trust there if the CA itself is basing trust off of domain control? In neighbor comment it seems that maybe the CA is basically acting as a hack to bypass an inability by clients to check DNS? I can see why that would have some practical value in the near term but it'd be good to do away with it as soon as possible. Apple/Google/Microsoft (and maybe Mozilla) may be in a position to do so if no one else.

herio 6y ago

This was proposed already in 2012 with RFC6698. DNS based Authentication of Domain Entries, DANE. Hasn't really gone anywhere of importance. I personally think there's been a few factors as to why: * Distrust of DNSSEC and centralized authority. * Lagging DNSSEC deployment, not just in DNS but also in clients and applications. * Needs another DNS lookup on connection to validate certs, adding lag. I think it probably needs stapling support in some form just like cert validity checking. There's also been follow up RFC detailing it's use for SMTP, SRV records and PGP.

ameliaquining 6y ago

Let's Encrypt doesn't have to worry about firewalls and middleboxes blocking their DNS queries. Browsers do.

marcosdumay 6y ago
Yes, and browsers solution has been to tunnel those queries over some protocol that middleboxes can not mess with. Because losing the DNSSEC fields is the lesser of the problems they cause.