3 ms·

I think is a pretty rough mischaracterization to say “lots of people are wrongly confident that it’s for the best [that we stay in that ‘dark period’]”. Speakin

by akerl_ 7y ago

I think is a pretty rough mischaracterization to say “lots of people are wrongly confident that it’s for the best [that we stay in that ‘dark period’]”. Speaking as one of those “people”, I’m confident that DNSSEC doesn’t meaningfully improve the security of DNS. The root of trust for DNSSEC is TLD operators, who are in many cases direct subsidiaries of governments and in other cases are effectively controlled by governments, and it uses woefully outdated crypto to provide the chain of trust. And the failure more for when anything goes wrong is that your site drops off the internet at the DNS resolution step, which is pretty gnarly. I’d be happy for a proposal that aimed to improve the threat model for network connections, but DNSSEC does not do that.

tialaramex 7y ago
> Speaking as one of those “people”, I’m confident that DNSSEC doesn’t meaningfully improve the security of DNS Yes, as I said, you are indeed confident you're right. That won't help by the way, but I don't expect that to have any impact on you because you have confidence and facts are a poor substitute. It does actually matter which government. My sister's web site undoubtedly could be interfered with by the government of the country she lives in as it controls the registry her domain name is in, but if they have got it in for her then she has bigger problems than a web site. On the other hand, the status quo today without DNSSEC is that another government she's barely aware exists has the resources to intercept her traffic, because there is no cryptographic obstacle to them doing so at the DNS level. Not to mention plenty of non-government entities, we're hardly talking about Apollo programme levels of resources. Now, in truth today what you see a lot of is lower hanging fruit. Back when I worked for the last startup we spent a bunch of time looking at cases where DNS for sensitive domain mail servers gets changed and then for a few hours or days all the email to some domain is going via a different country. Sometimes the hijackers would get themselves a TLS certificate, sometimes they wouldn't bother (presumably the targets didn't do name checks or didn't make TLS mandatory). DNSSEC wouldn't help here because the bad guys literally just broke into a registrar DNS account which was poorly secured, their new answers would have been signed. But of course even though bad guys won't pick your locks when there's a fire door left open that's not a reason to use crappier locks, it's a reason to shut the fire door. The existence of lower hanging fruit is not a defence, if anything it means you're likely to underestimate the risks you face and be unprepared. The fail closed behaviour is desirable. Soft-fail is, to use Adam Langley's preferred metaphor, "a seat-belt that snaps when you crash". If there's a way to have a config that isn't secure but seems to work, that's exactly the config bad guys will rely on to attack you. This was an understandable mistake when Netscape made it in the 1990s, less understandable when Microsoft did it at the turn of the century, and unforgivable today.
- akerl_ 7y ago
  It’s difficult to have a discussion when in both your comments here, you’ve proposed that people who disagree with you aren’t discussing in good faith (in the first case by attempting to cast it as the politically correct opinion, and in the latter case by suggesting I’m not interested in facts). The status quo today is that DNS interference is being mitigated by the CA system, which is no hero but does have the benefit that rogue CAs (or CAs which have been forced to behave badly by other actors) can be delisted. The push to increase TLS deployment, detect TLS cert shenanigans, and move additional technologies behind TLS (DNS-over-HTTPS, for example) all work to move the needle on the risks in the current threat model for the vast majority of internet-based workflows. These changes are what’s actually making things better for your example of your sister’s website. Regarding fail-closed, I didn’t say that security controls should fail open. I said that unlike other security controls, DNSSEC fails by dropping the site off the internet. As an end user, you don’t even know it’s a DNSSEC problem, you just know the site has disappeared.
  - tialaramex 7y ago
    > DNS interference is being mitigated by the CA system Such mitigations (e.g. 0x20 or multi-perspective) are not enough to outrun the metaphorical bear. So they only work until you are slowest again. Putting such mitigations in place for those who can't or more often won't deploy DNSSEC makes sense, but somebody will get eaten by the bear this way. > unlike other security controls, DNSSEC fails by dropping the site off the internet You could do some small UX work here to have an explicit error like the ones for TLS version interference, but it's of dubious value. Also you're probably thinking this is valuable feedback to site owners but unfortunately it'll be choked with noise. TLS version interference, for example, mostly means your crappy anti-virus or other middlebox garbage is causing problems. But it might be an attack, or a dodgy cable... who knows. As with certificate expiry the right thing for a site owner to do is have their own alerting in place.
  - deleted 7y ago
    [deleted]
alwillis 7y ago
and it uses woefully outdated crypto to provide the chain of trust Turns out DNSSEC supports the modern algorithms you could want, including ECDSA P-256 and P-384. Most validating resolvers support ED25519 as well. Using P-256 creates smaller signatures and enables DNSSEC lookups to fit within the original DNS packet size of 512 bytes. It also turns out that Cloudflare's Universal DNSSEC has supported ECDSA P-256 since 2015; as a percentage of implementation, more DNSSEC users are using fast, modern crypto than not. And it turns out that the old, crappy algorithms are being deprecated and the DNSSEC eco-system is being updated to not sign zones using them or validate them: https://www.isc.org/docs/matthijs-mekking-oarc30-unsupported-algorithms.pdf https://www.isc.org/docs/matthijs-mekking-oarc30-unsupported... I'm sure there are TLDs and ccTLDs using older algorithms, but as a zone operator, you can use the latest, greatest crypto. And because operational guidelines suggest rolling Zone Signing Keys (and Key Signing Keys) regularly, everyone will be on the latest crypto soon. I just signed a zone I operate using ECDSAP256SHA256 even though the parent zone is using RSASHA1. So DNSSEC's crypto is good and getting better all the time.
- akerl_ 7y ago
  The crypto is as strong as the weakest link for each domain; if a root or intermediary for my domain is using old crypto, it doesn’t matter what I’m using as the end zone operator.
  - alwillis 7y ago
    Regarding outdated crypto, that’s a common DNSSEC trope that’s been debunked: https://easydns.com/blog/2015/08/06/for-dnssec/#weak https://easydns.com/blog/2015/08/06/for-dnssec/#weak
    - tptacek 7y ago
      Not only has it not been "debunked", but DNSSEC's own proponents openly acknowledge that the DNSSEC hierarchy is littered with 1024-bit RSA keys; see the chain-extension fiasco on the TLS working group mailing list. Or, see the stats you yourself posted to this thread a few days ago, which included key breakdowns. Further, despite the fact that DNSSEC uses outmoded P-curve ECC, and that modern signature schemes aren't even implemented for it, curve usage in DNSSEC is a tiny fraction of all keys. The author of this post is simply wrong; what's more, he was wrong five years ago, and the situation has not improved.

by akerl_ 7y ago

tialaramex 7y ago

> Speaking as one of those “people”, I’m confident that DNSSEC doesn’t meaningfully improve the security of DNS Yes, as I said, you are indeed confident you're right. That won't help by the way, but I don't expect that to have any impact on you because you have confidence and facts are a poor substitute. It does actually matter which government. My sister's web site undoubtedly could be interfered with by the government of the country she lives in as it controls the registry her domain name is in, but if they have got it in for her then she has bigger problems than a web site. On the other hand, the status quo today without DNSSEC is that another government she's barely aware exists has the resources to intercept her traffic, because there is no cryptographic obstacle to them doing so at the DNS level. Not to mention plenty of non-government entities, we're hardly talking about Apollo programme levels of resources. Now, in truth today what you see a lot of is lower hanging fruit. Back when I worked for the last startup we spent a bunch of time looking at cases where DNS for sensitive domain mail servers gets changed and then for a few hours or days all the email to some domain is going via a different country. Sometimes the hijackers would get themselves a TLS certificate, sometimes they wouldn't bother (presumably the targets didn't do name checks or didn't make TLS mandatory). DNSSEC wouldn't help here because the bad guys literally just broke into a registrar DNS account which was poorly secured, their new answers would have been signed. But of course even though bad guys won't pick your locks when there's a fire door left open that's not a reason to use crappier locks, it's a reason to shut the fire door. The existence of lower hanging fruit is not a defence, if anything it means you're likely to underestimate the risks you face and be unprepared. The fail closed behaviour is desirable. Soft-fail is, to use Adam Langley's preferred metaphor, "a seat-belt that snaps when you crash". If there's a way to have a config that isn't secure but seems to work, that's exactly the config bad guys will rely on to attack you. This was an understandable mistake when Netscape made it in the 1990s, less understandable when Microsoft did it at the turn of the century, and unforgivable today.

akerl_ 7y ago
It’s difficult to have a discussion when in both your comments here, you’ve proposed that people who disagree with you aren’t discussing in good faith (in the first case by attempting to cast it as the politically correct opinion, and in the latter case by suggesting I’m not interested in facts). The status quo today is that DNS interference is being mitigated by the CA system, which is no hero but does have the benefit that rogue CAs (or CAs which have been forced to behave badly by other actors) can be delisted. The push to increase TLS deployment, detect TLS cert shenanigans, and move additional technologies behind TLS (DNS-over-HTTPS, for example) all work to move the needle on the risks in the current threat model for the vast majority of internet-based workflows. These changes are what’s actually making things better for your example of your sister’s website. Regarding fail-closed, I didn’t say that security controls should fail open. I said that unlike other security controls, DNSSEC fails by dropping the site off the internet. As an end user, you don’t even know it’s a DNSSEC problem, you just know the site has disappeared.
- tialaramex 7y ago
  > DNS interference is being mitigated by the CA system Such mitigations (e.g. 0x20 or multi-perspective) are not enough to outrun the metaphorical bear. So they only work until you are slowest again. Putting such mitigations in place for those who can't or more often won't deploy DNSSEC makes sense, but somebody will get eaten by the bear this way. > unlike other security controls, DNSSEC fails by dropping the site off the internet You could do some small UX work here to have an explicit error like the ones for TLS version interference, but it's of dubious value. Also you're probably thinking this is valuable feedback to site owners but unfortunately it'll be choked with noise. TLS version interference, for example, mostly means your crappy anti-virus or other middlebox garbage is causing problems. But it might be an attack, or a dodgy cable... who knows. As with certificate expiry the right thing for a site owner to do is have their own alerting in place.
- deleted 7y ago
  [deleted]

alwillis 7y ago

and it uses woefully outdated crypto to provide the chain of trust Turns out DNSSEC supports the modern algorithms you could want, including ECDSA P-256 and P-384. Most validating resolvers support ED25519 as well. Using P-256 creates smaller signatures and enables DNSSEC lookups to fit within the original DNS packet size of 512 bytes. It also turns out that Cloudflare's Universal DNSSEC has supported ECDSA P-256 since 2015; as a percentage of implementation, more DNSSEC users are using fast, modern crypto than not. And it turns out that the old, crappy algorithms are being deprecated and the DNSSEC eco-system is being updated to not sign zones using them or validate them: https://www.isc.org/docs/matthijs-mekking-oarc30-unsupported-algorithms.pdf https://www.isc.org/docs/matthijs-mekking-oarc30-unsupported... I'm sure there are TLDs and ccTLDs using older algorithms, but as a zone operator, you can use the latest, greatest crypto. And because operational guidelines suggest rolling Zone Signing Keys (and Key Signing Keys) regularly, everyone will be on the latest crypto soon. I just signed a zone I operate using ECDSAP256SHA256 even though the parent zone is using RSASHA1. So DNSSEC's crypto is good and getting better all the time.

akerl_ 7y ago
The crypto is as strong as the weakest link for each domain; if a root or intermediary for my domain is using old crypto, it doesn’t matter what I’m using as the end zone operator.
- alwillis 7y ago
  Regarding outdated crypto, that’s a common DNSSEC trope that’s been debunked: https://easydns.com/blog/2015/08/06/for-dnssec/#weak https://easydns.com/blog/2015/08/06/for-dnssec/#weak
  - tptacek 7y ago
    Not only has it not been "debunked", but DNSSEC's own proponents openly acknowledge that the DNSSEC hierarchy is littered with 1024-bit RSA keys; see the chain-extension fiasco on the TLS working group mailing list. Or, see the stats you yourself posted to this thread a few days ago, which included key breakdowns. Further, despite the fact that DNSSEC uses outmoded P-curve ECC, and that modern signature schemes aren't even implemented for it, curve usage in DNSSEC is a tiny fraction of all keys. The author of this post is simply wrong; what's more, he was wrong five years ago, and the situation has not improved.