3 ms·

Sorry, weak was perhaps the wrong term, it’s more the management that’s at issue. You can see the sibling comments that of course argue that perspective more ac

Sorry, weak was perhaps the wrong term, it’s more the management that’s at issue. You can see the sibling comments that of course argue that perspective more accurately.

teddyh 8y ago
> Sorry, weak was perhaps the wrong term, it’s more the management that’s at issue. “weak” was about half of your original argument: > The general argument is that X509 with TLS is enough authentication of a site one is connecting to, and therefor DNSSEC being somewhat weak, is something unnecessary. If we discount “weak”, let me then reply to the remainder of it: Firstly, DNSSEC is not only for web traffic, DNSSEC secures DNS for everything which uses domain names to locate services, not only HTTP. This is a big deal not only for more obscure (not to mention future) protocols, but also for sending e-mail, the MX lookup phase of which is otherwise unsecured. Secondly, the general problem with X.509 with rogue CA’s remain, and the only counter I have seen is akin to “but we can close those barn doors really well after each individual horses escape”, and I remain unconvinced. Thirdly, how do you prove you own a domain enough to get a X.509 certificate? You answer DNS requests, which is spoofable unless secured by DNSSEC.
- tptacek 8y ago
  One of the two major remaining use cases for DNSSEC was in protecting mail infrastructure, which has a less-sophisticated PKI (for lack of a better term) than the web. But the major mail providers --- including Google, Yahoo, and Microsoft --- have given up on DNSSEC (note that none of them are DNSSEC-signed) and have together generated SMTP-STS, which does for SMTP what HSTS does for websites: after a first rendezvous connection, all subsequent connections are protected by continuity rules rather than policy. The SMTP-STS standard is explicit that it is motivated by the desire not to rely on DNSSEC. The other major use case for DNSSEC is, as you suggest, protecting DV verification. But in the long term, DNS is going to get factored out of domain verification entirely. CAs will eventually (who knows how long it will take, even though the protocols are there) just verify domains directly with registrars using something built on RDAP. In the meantime, there are countermeasures against DNS spoofing (that have the virtue of also working against BGP spoofing, which DNSSEC doesn't fix) that the CAs can (and gradually do) deploy. It's hard to see the justification for rolling out an expensive, inferior protocol to mitigate attacks that we're already adequately mitigating today and will in the future decisively address through other means.
  - teddyh 8y ago
    The major providers also “gave up” on SRV records for HTTP/2, but that does not make it a bad idea – on the contrary, SRV for HTTP would be a good idea for the rest of us. But not for Google, since not having it cements their position. > But in the long term, DNS is going to get factored out of domain verification entirely. CAs will eventually (who knows how long it will take, even though the protocols are there) just verify domains directly with registrars using something built on RDAP. Get back to me when that actually happens, or looks likely to ever happen. Last I heard, the proposed replacement of WHOIS with RDAP has been put on very thick ice, and it is uncertain what will actually happen. > It's hard to see the justification for rolling out [DNSSEC] (…) In my world, that ship has long sailed. DNSSEC is fully rolled out. I work for a domain name registrar, and more than 30% of all the domains we manage are DNSSEC signed, and we could easily sign another 30% if we wanted to. DNSSEC has long been rolled out. It’s too late to argue that it shouldn’t be.
    - tptacek 8y ago
      People have been claiming DNSSEC is "rolled out" for almost a decade now (amusingly, they said so before the major TLDs were even signed). You're missing the point: nobody uses it. No major tech company even signs their zone. The browsers don't do DNSSEC lookups --- Firefox and Chrome actually removed their support for it. People affiliated with registrars are constantly pointing out how many zones they sign, as if that was any kind of argument at all. Look, nobody doubts that you can build a feature into your stack that automatically signs zones. 30%? Why not 100%? Who cares? That's just theater. What matters are companies actually relying on the protocol. Nobody does, today.
- bluejekyll 8y ago
  What comment of mine are you replying to exactly? You seem to have read an awful lot into something where I was trying to help someone understand why there is some conflict here. I only mentioned X509 as people are going to be more familiar with that than DNSSEC. The reason I mentioned it was to describe it as having a comparable method for validating the chain of certificates/signatures. It is very similar in that regard to X509 certificate chains. I’ve implemented DNSSEC in my own project, so I know the protocol, and I do agree that for MX records, as well as TXT and other record types that we need to validate that the records are authentic, in many contexts. Not just web and not just public internet, where we might want to pin custom trust anchors. I can see you are very concerned about this as am I, and if you want to reach out and discuss this in a different forum, I’d be happy to, as I think we have shared interests in seeing this succeed.
  - teddyh 8y ago
    > What comment of mine are you replying to exactly? I argued against the argument which you presented in a summarized form, nothing more.

Sorry, weak was perhaps the wrong term, it’s more the management that’s at issue. You can see the sibling comments that of course argue that perspective more accurately.

teddyh 8y ago

> Sorry, weak was perhaps the wrong term, it’s more the management that’s at issue. “weak” was about half of your original argument: > The general argument is that X509 with TLS is enough authentication of a site one is connecting to, and therefor DNSSEC being somewhat weak, is something unnecessary. If we discount “weak”, let me then reply to the remainder of it: Firstly, DNSSEC is not only for web traffic, DNSSEC secures DNS for everything which uses domain names to locate services, not only HTTP. This is a big deal not only for more obscure (not to mention future) protocols, but also for sending e-mail, the MX lookup phase of which is otherwise unsecured. Secondly, the general problem with X.509 with rogue CA’s remain, and the only counter I have seen is akin to “but we can close those barn doors really well after each individual horses escape”, and I remain unconvinced. Thirdly, how do you prove you own a domain enough to get a X.509 certificate? You answer DNS requests, which is spoofable unless secured by DNSSEC.

tptacek 8y ago
One of the two major remaining use cases for DNSSEC was in protecting mail infrastructure, which has a less-sophisticated PKI (for lack of a better term) than the web. But the major mail providers --- including Google, Yahoo, and Microsoft --- have given up on DNSSEC (note that none of them are DNSSEC-signed) and have together generated SMTP-STS, which does for SMTP what HSTS does for websites: after a first rendezvous connection, all subsequent connections are protected by continuity rules rather than policy. The SMTP-STS standard is explicit that it is motivated by the desire not to rely on DNSSEC. The other major use case for DNSSEC is, as you suggest, protecting DV verification. But in the long term, DNS is going to get factored out of domain verification entirely. CAs will eventually (who knows how long it will take, even though the protocols are there) just verify domains directly with registrars using something built on RDAP. In the meantime, there are countermeasures against DNS spoofing (that have the virtue of also working against BGP spoofing, which DNSSEC doesn't fix) that the CAs can (and gradually do) deploy. It's hard to see the justification for rolling out an expensive, inferior protocol to mitigate attacks that we're already adequately mitigating today and will in the future decisively address through other means.
- teddyh 8y ago
  The major providers also “gave up” on SRV records for HTTP/2, but that does not make it a bad idea – on the contrary, SRV for HTTP would be a good idea for the rest of us. But not for Google, since not having it cements their position. > But in the long term, DNS is going to get factored out of domain verification entirely. CAs will eventually (who knows how long it will take, even though the protocols are there) just verify domains directly with registrars using something built on RDAP. Get back to me when that actually happens, or looks likely to ever happen. Last I heard, the proposed replacement of WHOIS with RDAP has been put on very thick ice, and it is uncertain what will actually happen. > It's hard to see the justification for rolling out [DNSSEC] (…) In my world, that ship has long sailed. DNSSEC is fully rolled out. I work for a domain name registrar, and more than 30% of all the domains we manage are DNSSEC signed, and we could easily sign another 30% if we wanted to. DNSSEC has long been rolled out. It’s too late to argue that it shouldn’t be.
  - tptacek 8y ago
    People have been claiming DNSSEC is "rolled out" for almost a decade now (amusingly, they said so before the major TLDs were even signed). You're missing the point: nobody uses it. No major tech company even signs their zone. The browsers don't do DNSSEC lookups --- Firefox and Chrome actually removed their support for it. People affiliated with registrars are constantly pointing out how many zones they sign, as if that was any kind of argument at all. Look, nobody doubts that you can build a feature into your stack that automatically signs zones. 30%? Why not 100%? Who cares? That's just theater. What matters are companies actually relying on the protocol. Nobody does, today.
bluejekyll 8y ago
What comment of mine are you replying to exactly? You seem to have read an awful lot into something where I was trying to help someone understand why there is some conflict here. I only mentioned X509 as people are going to be more familiar with that than DNSSEC. The reason I mentioned it was to describe it as having a comparable method for validating the chain of certificates/signatures. It is very similar in that regard to X509 certificate chains. I’ve implemented DNSSEC in my own project, so I know the protocol, and I do agree that for MX records, as well as TXT and other record types that we need to validate that the records are authentic, in many contexts. Not just web and not just public internet, where we might want to pin custom trust anchors. I can see you are very concerned about this as am I, and if you want to reach out and discuss this in a different forum, I’d be happy to, as I think we have shared interests in seeing this succeed.
- teddyh 8y ago
  > What comment of mine are you replying to exactly? I argued against the argument which you presented in a summarized form, nothing more.