4 ms·

Wouldn’t it make more sense to design a new, simple API and glue for doing secure DNS lookups just for certificate issuance? It could look more like dnscurve o

by amluto 7mo ago

Wouldn’t it make more sense to design a new, simple API and glue for doing secure DNS lookups just for certificate issuance? It could look more like dnscurve or even like HTTPS: have a new resource, say NSS, in parallel with NS. To securely traverse to a subdomain, you would query the parent for NSS and, if the record is present, you would learn an IP address and a public key hash or certificate hash that you can query via HTTPS to read the next domain. And this whole spec would say that normal HTTPS clients and OS resolvers SHOULD NOT use it. So if you mess it up, your site doesn’t go offline. (HTTPS really needs a way to make a URL where the URL itself encodes the keying information.)

tptacek 7mo ago
Yes. WebPKI people have been talking about doing that for a long time. There's a couple different angles you can come up with on it, including things like RDAP to directly query registrars for ownership of a domain, and speaking DoH all the way up to authorities. Presumably the problem is that it just takes for-fucking-ever to make anything happen inside CA/BForum. Case in point: we were all today years old before CA/BForum required CAs to actually use DNSSEC if it's set up.
gzread 7mo ago
Basically reinventing DNSSEC?
- amluto 7mo ago
  Nope. DNSSEC is a complex scheme that is designed to allow queries to be answered with no secrets know to the answering nameserver: everything is signed offline and signed records are served up. My (vague) suggestion is to use a much simpler online scheme with correspondingly lower performance, but to use it only for security-critical queries such as those made by CAs.
  - gzread 7mo ago
    So a whole alternative DNS tree just for verifying domain ownership to CAs? Or would it be the same tree? If it's the same tree why not extend it to all records, all the time?
    - amluto 7mo ago
      For better or for worse we have a system designed for exceptional scalability and performance for verifying that you’re talking to the domain name that you think you’re talking to: WebPKI. It’s all kinds of outdated, baroque, and crappy, but it works and is supported by basically everything. We keep taking little baby steps toward making it suck less (dns-persist-01 is an upcoming one that I’m excited about). And all these little baby steps can be deployed worldwide without modifying client software. DNSSEC tries to fit in a weird corner of the performance envelope. It requires modifying client software to get more than a token benefit. Approximately zero clients use it for anything worthwhile. The technology is terrible. It’s really not fit for any particular purpose. About the best one can say for using it to help with domain validated certificate issuance is that it exists, but, as widely noted, it’s so awful that even major high-budget websites don’t use it. At the end of the day, domain validation is a heavyweight process that needs to be reliably but not fast. All it’s doing is, in effect, asking the DNS hierarchy whether the certificate requester is authorized. A much MUCH simpler solution would be to … just ask the chain of authoritative DNS servers. This query does not need to be scalable. It does not need to be fast. It does not need to meet almost any of the ridiculous pile of requirements that led to DNSSEC. Heck, it doesn’t even need to be possible for unauthenticated users to issue queries at all. Sometimes specific problems deserve specific, narrowly tailored solutions.

by amluto 7mo ago

tptacek 7mo ago

Yes. WebPKI people have been talking about doing that for a long time. There's a couple different angles you can come up with on it, including things like RDAP to directly query registrars for ownership of a domain, and speaking DoH all the way up to authorities. Presumably the problem is that it just takes for-fucking-ever to make anything happen inside CA/BForum. Case in point: we were all today years old before CA/BForum required CAs to actually use DNSSEC if it's set up.

gzread 7mo ago

Basically reinventing DNSSEC?

amluto 7mo ago
Nope. DNSSEC is a complex scheme that is designed to allow queries to be answered with no secrets know to the answering nameserver: everything is signed offline and signed records are served up. My (vague) suggestion is to use a much simpler online scheme with correspondingly lower performance, but to use it only for security-critical queries such as those made by CAs.
- gzread 7mo ago
  So a whole alternative DNS tree just for verifying domain ownership to CAs? Or would it be the same tree? If it's the same tree why not extend it to all records, all the time?
  - amluto 7mo ago
    For better or for worse we have a system designed for exceptional scalability and performance for verifying that you’re talking to the domain name that you think you’re talking to: WebPKI. It’s all kinds of outdated, baroque, and crappy, but it works and is supported by basically everything. We keep taking little baby steps toward making it suck less (dns-persist-01 is an upcoming one that I’m excited about). And all these little baby steps can be deployed worldwide without modifying client software. DNSSEC tries to fit in a weird corner of the performance envelope. It requires modifying client software to get more than a token benefit. Approximately zero clients use it for anything worthwhile. The technology is terrible. It’s really not fit for any particular purpose. About the best one can say for using it to help with domain validated certificate issuance is that it exists, but, as widely noted, it’s so awful that even major high-budget websites don’t use it. At the end of the day, domain validation is a heavyweight process that needs to be reliably but not fast. All it’s doing is, in effect, asking the DNS hierarchy whether the certificate requester is authorized. A much MUCH simpler solution would be to … just ask the chain of authoritative DNS servers. This query does not need to be scalable. It does not need to be fast. It does not need to meet almost any of the ridiculous pile of requirements that led to DNSSEC. Heck, it doesn’t even need to be possible for unauthenticated users to issue queries at all. Sometimes specific problems deserve specific, narrowly tailored solutions.