3 ms·

It doesn't seem like there's any reason DANE is incompatible with Certificate Transparency. Support could potentially even be integrated with public revolvers t

by easrng 5y ago

It doesn't seem like there's any reason DANE is incompatible with Certificate Transparency. Support could potentially even be integrated with public revolvers to automatically submit certs to a CT log when a TLSA record is looked up[1]. You can use both DANE and a CA-issued certificate at the same time if you want. With Let's Encrypt and the CA system, you have to trust Let's Encrypt, the DNS servers[2] Let's Encrypt uses, every router between Let's Encrypt and the DNS servers[2], and in most setups every other CA Mozilla/Google/your OS vendor ships too. With DANE, you need to trust the people with the keys for the DNS servers[2] still, but you don't have the MITM risk, assuming local validation which is the only thing that makes sense with modern computers. What features are possible with the CA system but not DANE? [1]: This would require making a TLS connection to the server since only the hash is in the TLSA record which isn't ideal, but it would be possible. [2]: I'm talking about the DNS servers needed for recursive resolution, so the root servers, the domain's TLD's namesevers, and the authoritative nameserver for the domain.

tptacek 5y ago
There's nothing about DANE that is fundamentally incompatible with Ed25519 signatures. But DANE is going to be an RSA ecosystem for the foreseeable future, because merely saying "DANE should be Ed25519" doesn't accomplish anything, and the installed base of DNS is firmly wedged into RSA (about once a year, Geoff Huston publishes a survey of how much of DNSSEC breaks when you try to use NIST P-curve signatures with it). And there is a major organizational incompatibility with DANE and CT. The CA's don't do CT because they want to (in fact, many of them actively hate it, for reasons 'tialaramex discusses downthread). They do it because Google and Mozilla forced them to, and because Google and Mozilla will nuke them from the skies if they try to stop. The same is emphatically not the case with the operators of the DNS hierarchy, who are absolutely unaccountable to Google, which cannot revoke or even productively leave .COM. But, of course, the simplest bit of evidence for an argument about why CT doesn't work with DANE is that CT doesn't work with DANE. The system you're discussing in generalities does not exist. CT works today for the WebPKI.
- easrng 5y ago
  P-256[1] and P-384[2] just have 2.1% less support than RSA with SHA-256[3] and ed25519 has 15.6% less[4], which isn't ideal, but with client-side validation, which is needed for security and browsers would implement, ed25519 would work fine. I agree that the CA system is better right now, but I think DANE is conceptually a better solution and with some effort from browser vendors it could easily become a viable alternative. Also, browser vendors don't need to pressure TLDs, they're mostly already set up well enough for DANE to work. I misunderstood CT (I didn't realize CAs had to submit certificates to logs) but it still should work if: 1) The DNSSEC chain is embedded in the certificate. The problem is there's no standard way of doing so. RFC 9102 defines a serialization format, but not a way to include the chain in a certificate. Chrome had an implementation a while ago, but it was removed and never documented as far as I can tell. 2) SPKI mode is used for the TLSA record. (Using the certificate hash would be impossible.) 3) Someone runs a CT log that accepts certificates verified with DANE and not just ones signed by a (semi-)trusted CA. Once the DNSSEC-chain-in-certificate problem is solved, Let's Encrypt (or some other CA) could single-handedly solve the rest of the issues by making a new challenge type (dns02?) that is more or less equivalent to dns01 but uses a TLSA record instead of a TXT record. This would allow DANE/CA hybrid certificates that would be in CT logs and be accepted by browsers (and other clients) already, as a stopgap measure. Browsers could then also implement DANE (Potentially using the embedded DNSSEC chain to avoid the DNS lookup, allowing for faster client-side validation and bypassing misbehaving resolvers), removing the need for CAs, and it should all just work. [1]: https://dnsthought.nlnetlabs.nl/#ecdsa256 https://dnsthought.nlnetlabs.nl/#ecdsa256 [2]: https://dnsthought.nlnetlabs.nl/#ecdsa384 https://dnsthought.nlnetlabs.nl/#ecdsa384 [3]: https://dnsthought.nlnetlabs.nl/#rsasha256 https://dnsthought.nlnetlabs.nl/#rsasha256 [4]: https://dnsthought.nlnetlabs.nl/#ed25519 https://dnsthought.nlnetlabs.nl/#ed25519

by easrng 5y ago

tptacek 5y ago

There's nothing about DANE that is fundamentally incompatible with Ed25519 signatures. But DANE is going to be an RSA ecosystem for the foreseeable future, because merely saying "DANE should be Ed25519" doesn't accomplish anything, and the installed base of DNS is firmly wedged into RSA (about once a year, Geoff Huston publishes a survey of how much of DNSSEC breaks when you try to use NIST P-curve signatures with it). And there is a major organizational incompatibility with DANE and CT. The CA's don't do CT because they want to (in fact, many of them actively hate it, for reasons 'tialaramex discusses downthread). They do it because Google and Mozilla forced them to, and because Google and Mozilla will nuke them from the skies if they try to stop. The same is emphatically not the case with the operators of the DNS hierarchy, who are absolutely unaccountable to Google, which cannot revoke or even productively leave .COM. But, of course, the simplest bit of evidence for an argument about why CT doesn't work with DANE is that CT doesn't work with DANE. The system you're discussing in generalities does not exist. CT works today for the WebPKI.

easrng 5y ago
P-256[1] and P-384[2] just have 2.1% less support than RSA with SHA-256[3] and ed25519 has 15.6% less[4], which isn't ideal, but with client-side validation, which is needed for security and browsers would implement, ed25519 would work fine. I agree that the CA system is better right now, but I think DANE is conceptually a better solution and with some effort from browser vendors it could easily become a viable alternative. Also, browser vendors don't need to pressure TLDs, they're mostly already set up well enough for DANE to work. I misunderstood CT (I didn't realize CAs had to submit certificates to logs) but it still should work if: 1) The DNSSEC chain is embedded in the certificate. The problem is there's no standard way of doing so. RFC 9102 defines a serialization format, but not a way to include the chain in a certificate. Chrome had an implementation a while ago, but it was removed and never documented as far as I can tell. 2) SPKI mode is used for the TLSA record. (Using the certificate hash would be impossible.) 3) Someone runs a CT log that accepts certificates verified with DANE and not just ones signed by a (semi-)trusted CA. Once the DNSSEC-chain-in-certificate problem is solved, Let's Encrypt (or some other CA) could single-handedly solve the rest of the issues by making a new challenge type (dns02?) that is more or less equivalent to dns01 but uses a TLSA record instead of a TXT record. This would allow DANE/CA hybrid certificates that would be in CT logs and be accepted by browsers (and other clients) already, as a stopgap measure. Browsers could then also implement DANE (Potentially using the embedded DNSSEC chain to avoid the DNS lookup, allowing for faster client-side validation and bypassing misbehaving resolvers), removing the need for CAs, and it should all just work. [1]: https://dnsthought.nlnetlabs.nl/#ecdsa256 https://dnsthought.nlnetlabs.nl/#ecdsa256 [2]: https://dnsthought.nlnetlabs.nl/#ecdsa384 https://dnsthought.nlnetlabs.nl/#ecdsa384 [3]: https://dnsthought.nlnetlabs.nl/#rsasha256 https://dnsthought.nlnetlabs.nl/#rsasha256 [4]: https://dnsthought.nlnetlabs.nl/#ed25519 https://dnsthought.nlnetlabs.nl/#ed25519