6 ms·

> domain (which you control, right?) You never control a domain - ICANN, your TLD registry and your immediate domain registrar do. So, technically, it's just r

> domain (which you control, right?) You never control a domain - ICANN, your TLD registry and your immediate domain registrar do. So, technically, it's just replacing one trust vector with another. However, given that we don't have a proper crypto in DNS (not even DNSSEC which many don't like and urge to abolish), it would be terrible. Anyone who can feed you spoofed DNS responses (i.e. starting from a cafe hotspot) would be able to impersonate just anything.

okket 10y ago
> You never control a domain Then don't use DNS if you can't trust it? You have to trust at some point. Or create your own infrastructure and convince others to trust you, if you want more than a private network. > Anyone who can feed you spoofed DNS responses The tendency goes towards running your own local DNS resolver. It was not possible in the 90s, but since then both the network and computer got a lot faster and smarter. DNSSEC has also evolved quite a bit and is the best we will get for long time. I really encourage to have a look again before dismissing it outright. http://blog.easydns.org/2015/08/06/for-dnssec/ http://blog.easydns.org/2015/08/06/for-dnssec/
- drdaeman 10y ago
  > Then don't use DNS if you can't trust it? Same with CAs, but I believe it's easier to distrust a rogue CA than a rogue name registry. I mean, if there's a news that some .example TLD is in bed with NSA, Chinese government and Russian FSB - there isn't much we can do about that, isn't it? And I guess most businesses won't go as far as changing their domain name. At the same time, on most devices I saw, distrusting a CA wasn't terribly complicated. And can be done by a browser or OS vendor, with a version upgrade, as well. > http://blog.easydns.org/2015/08/06/for-dnssec/ http://blog.easydns.org/2015/08/06/for-dnssec/ Thanks for the link. Looks like an interesting reading.
  - 0x0 10y ago
    If you can't trust your TLD operator, then you should definitively change your domain name. Otherwise they could fake their NS query responses for your domain at any time and obtain certificates from other CAs during DNS/HTTP validation. You've already lost if your TLD operator is out to get you. Pick a more trustworthy TLD next time. As a bonus, determining the shadyness of a domain based on the TLD is something even many regular end users can be capable of, because it is so visible. End users never look at SSL CA chains, but the TLD is visible front and center.
    - throwawayReply 10y ago
      Modern browsers have been hiding more and more of the URL. Yes, the domain with tld is still visible for now, but the trend is to cut out anything that might confuse a user. Eventually it wouldn't surprise me if that included cutting out the URL completely for EV and just showing the validated name. It also wouldn't surprise me if the TLD gets greyed out and diminished compared to the domain below that sooner rather than later.
      - 0x0 10y ago
        No way. They might as well remove the entire URL bar then. It'd be way too easy to phish if you couldn't tell the difference between .com/.net/.org, never mind all the ridiculous new TLDs like .plumber and .guru.
        throwawayReply 10y ago
        Mobile phones already don't show the URL bar most the time.
- mtgx 10y ago
  I don't know if adopting DNSSEC at a time when Russia and China will control ICANN, too. But in a way, I hope this makes everyone trust the whole CA/DNS system even less, and they start coming up with real, more decentralized and trust-less systems.
  - okket 10y ago
    > when Russia and China will control ICANN Until then I am very much against start mistrusting DNS as a precautionary measure based on FUD. > they start coming up with real, more decentralized and trust-less systems Sounds intriguing, how should this work? There are some ideas out there, but they all have major drawbacks. So it will take time and a real, present threat for people to start using it regardless of the drawbacks.
- tptacek 10y ago
  Among many other problems, DNSSEC+DANE permanently concedes .COM, .NET, .ORG, .CO.UK, and .IO to the FVEY Intelligence Community --- the TLDs are controlled by world governments, as we all know from watching the DOJ use that control to attack file sharing sites. Not only that, but DNSSEC+DANE does this without eliminating CAs. It can't, because browsers can't rely on DANE in the real world, for technical reasons. Previous discussion: https://news.ycombinator.com/item?id=12383795 https://news.ycombinator.com/item?id=12383795
  - Kadin 10y ago
    > Among many other problems, DNSSEC+DANE permanently concedes .COM, .NET, .ORG, .CO.UK, and .IO to the FVEY Intelligence Community That's not new; it just makes plain what has always been the case. Better to have it out in the open, IMO. The legacy non-CC TLDs (.COM, .NET, etc.) are essentially US territory for historical reasons -- .COM should really be ".CO.US" but the latter will probably never catch on, and the ship has sailed at this point -- and anything under .UK is the UK's, obviously. If you don't want your DNS controlled by a FVEYs country, probably best not to use a TLD that's under one of those countries' control. Setting up something in .COM that's likely to be objectionable to the US government is as unwise as setting up something that the Chinese government is going to find objectionable in .CN DNS space. The idea that the Internet would ever somehow transcend nations, when it relies on infrastructure that lives in the physical world which is dominated by nation-states, was a naive piece of 1990s idealism. The fact that the Internet lets you basically choose your jurisdiction is a great thing, and shouldn't be undervalued. I don't think there has ever been a time when a person in the US could so easily set up a publication that's protected under the laws of (say) Finland, or Russia. (Of course, they do so at their own personal peril, if they live in the US; again, there's no escaping nations, just choosing between them or hiding.) I am not totally sold on the DNSSEC+DANE concept, but the fact that it admits reality as it exists on the ground, which is that the Internet exists of and in the world and not above it, does not strike me as a particularly compelling criticism.
    - tptacek 10y ago
      It is simply not true that in the status quo, setting up a site under .COM gives the USG access to your TLS keys. As long as you're pinning certificates, governments can't generate fake certificates for your site without burning the CA that they suborned. If we adopted DNSSEC+DANE --- and, make no mistake, we have not adopted it --- this status quo would no longer be the case. The DNS hierarchy has no trust agility. You can't burn .COM; if you do that, you break the whole Internet. The browser vendors can, will, and repeatedly have torched misbehaving CAs, and forced still more into Certificate Transparency programs. That's a capability we actually have today, without anyone doing anything, that we would lose in DANE-land. This isn't a complicated argument. I'm surprised it's stayed live on this site for so long. There are lots of other dealbreaker problems with DNSSEC! But this is the simplest of them.
AndyMcConachie 10y ago
> Anyone who can feed you spoofed DNS responses (i.e. starting from a cafe hotspot) would be able to impersonate just anything. Run a stub DNSSEC validator and no one can feed you spoofed DNS responses if they're signed. DNSSEC doesn't require that validation only happen at the recursive server.
- rocqua 10y ago
  That isn't going to work for the general public though. Not because it is too difficult to set up (that can be fixed by sane defaults). Instead the issue is dealing when you can't get DNSSEC responses. If you want DNSSEC to actually secure you, you need to reject any DNS answer that should have a signature, but doesn't. This means sites not working if there is a slight mistake upstream. Unless this shit becomes really rare, it seems unlikely people will accept this. If you ignore this, you are vulnerable to anyone who can spoof DNS and refuse to server RSIG records.
  - AndyMcConachie 10y ago
    DNS records tend to hang around in caches, and people query the same RRs regularly. Thus, it's pretty hard to spoof a RR that you're regularly requesting. This doesn't help for those zones that are not DNSSEC enabled, but there's nothing you can really do about that. If a zone is DNSSEC signed and I query its records regularly(i.e. they stay in the cache) it would be very hard to spoof their records. If I also use a recursive resolver that does DNSSEC validation(e.g., 8.8.8.8) it's even harder. I'm not quite willing to say it would be impossible, but AFAIK no one has shown it to be possible.
NetStrikeForce 10y ago
Exactly this. These days we even trust our neighbours accepting their BGP routing advertisements, which are easily modified to bring traffic to our infrastructure and intercept it. It happens every day all over the world...
Arnt 10y ago
How? There's a well-known key for the root, which vouches for the key for the .org TLD, which vouches for the key for the example.org domain, which vouches for the A/AAAA/TLSA RRs for www.example.org. What part of the chain can the café hotspot break?
- tptacek 10y ago
  Any of them, since DNSSEC validation doesn't occur in stub resolvers, but is instead delegated to the caches (the "DNS servers" you or DHCP configures). DNSSEC was designed in the mid-1990s, before protocol designers understood crypto, and it was carefully designed to minimize cryptography. Several other bad attributes fall out of that decision as well.
  - stephenr 10y ago
    > Any of them, since DNSSEC validation doesn't occur in stub resolvers. By that logic, because someone could write a browser that will accept invalid certificates and/or show everything as secure etc, TLS in general is fundamentally broken so we should never use it. A bad implementation isn't reason to abandon the concept.
    - AnimalMuppet 10y ago
      In what ways is TLS fundamentally broken? (Not arguing, I really want to know. We're looking at moving to it from SSLv3 as I write this.)
      - stephenr 10y ago
        Edit: TL;DR: I'm not saying TLS is fundamentally broken. Also: Unless you need to support fucking ancient client devices/user agents, I urge you to drop SSL (and upgrade to as recent a TLS version as possible) Re-read what I wrote, and what I replied to. A lot of DNSSEC/DANE detractors claim that its effectively useless and unusable, because currently a lot of DNS stub resolvers (e.g. home routers) don't do DNSSEC verification. My response is that you can use the same argument to make anything useless, if you introduce a terrible implementation. Let's try a different example separated from certificates to make it clearer: IE6 was a fucking terrible web browser as far as web standards go. Therefore, web standards are useless and should be abandoned.
makomk 10y ago
Technically, it's replacing two groups of people you have to trust with one, since gaining control of a site's DNS is sufficient to issue certificates for that sites under the current system.

okket 10y ago

> You never control a domain Then don't use DNS if you can't trust it? You have to trust at some point. Or create your own infrastructure and convince others to trust you, if you want more than a private network. > Anyone who can feed you spoofed DNS responses The tendency goes towards running your own local DNS resolver. It was not possible in the 90s, but since then both the network and computer got a lot faster and smarter. DNSSEC has also evolved quite a bit and is the best we will get for long time. I really encourage to have a look again before dismissing it outright. http://blog.easydns.org/2015/08/06/for-dnssec/ http://blog.easydns.org/2015/08/06/for-dnssec/

drdaeman 10y ago
> Then don't use DNS if you can't trust it? Same with CAs, but I believe it's easier to distrust a rogue CA than a rogue name registry. I mean, if there's a news that some .example TLD is in bed with NSA, Chinese government and Russian FSB - there isn't much we can do about that, isn't it? And I guess most businesses won't go as far as changing their domain name. At the same time, on most devices I saw, distrusting a CA wasn't terribly complicated. And can be done by a browser or OS vendor, with a version upgrade, as well. > http://blog.easydns.org/2015/08/06/for-dnssec/ http://blog.easydns.org/2015/08/06/for-dnssec/ Thanks for the link. Looks like an interesting reading.
- 0x0 10y ago
  If you can't trust your TLD operator, then you should definitively change your domain name. Otherwise they could fake their NS query responses for your domain at any time and obtain certificates from other CAs during DNS/HTTP validation. You've already lost if your TLD operator is out to get you. Pick a more trustworthy TLD next time. As a bonus, determining the shadyness of a domain based on the TLD is something even many regular end users can be capable of, because it is so visible. End users never look at SSL CA chains, but the TLD is visible front and center.
  - throwawayReply 10y ago
    Modern browsers have been hiding more and more of the URL. Yes, the domain with tld is still visible for now, but the trend is to cut out anything that might confuse a user. Eventually it wouldn't surprise me if that included cutting out the URL completely for EV and just showing the validated name. It also wouldn't surprise me if the TLD gets greyed out and diminished compared to the domain below that sooner rather than later.
    - 0x0 10y ago
      No way. They might as well remove the entire URL bar then. It'd be way too easy to phish if you couldn't tell the difference between .com/.net/.org, never mind all the ridiculous new TLDs like .plumber and .guru.
      - throwawayReply 10y ago
        Mobile phones already don't show the URL bar most the time.
mtgx 10y ago
I don't know if adopting DNSSEC at a time when Russia and China will control ICANN, too. But in a way, I hope this makes everyone trust the whole CA/DNS system even less, and they start coming up with real, more decentralized and trust-less systems.
- okket 10y ago
  > when Russia and China will control ICANN Until then I am very much against start mistrusting DNS as a precautionary measure based on FUD. > they start coming up with real, more decentralized and trust-less systems Sounds intriguing, how should this work? There are some ideas out there, but they all have major drawbacks. So it will take time and a real, present threat for people to start using it regardless of the drawbacks.
tptacek 10y ago
Among many other problems, DNSSEC+DANE permanently concedes .COM, .NET, .ORG, .CO.UK, and .IO to the FVEY Intelligence Community --- the TLDs are controlled by world governments, as we all know from watching the DOJ use that control to attack file sharing sites. Not only that, but DNSSEC+DANE does this without eliminating CAs. It can't, because browsers can't rely on DANE in the real world, for technical reasons. Previous discussion: https://news.ycombinator.com/item?id=12383795 https://news.ycombinator.com/item?id=12383795
- Kadin 10y ago
  > Among many other problems, DNSSEC+DANE permanently concedes .COM, .NET, .ORG, .CO.UK, and .IO to the FVEY Intelligence Community That's not new; it just makes plain what has always been the case. Better to have it out in the open, IMO. The legacy non-CC TLDs (.COM, .NET, etc.) are essentially US territory for historical reasons -- .COM should really be ".CO.US" but the latter will probably never catch on, and the ship has sailed at this point -- and anything under .UK is the UK's, obviously. If you don't want your DNS controlled by a FVEYs country, probably best not to use a TLD that's under one of those countries' control. Setting up something in .COM that's likely to be objectionable to the US government is as unwise as setting up something that the Chinese government is going to find objectionable in .CN DNS space. The idea that the Internet would ever somehow transcend nations, when it relies on infrastructure that lives in the physical world which is dominated by nation-states, was a naive piece of 1990s idealism. The fact that the Internet lets you basically choose your jurisdiction is a great thing, and shouldn't be undervalued. I don't think there has ever been a time when a person in the US could so easily set up a publication that's protected under the laws of (say) Finland, or Russia. (Of course, they do so at their own personal peril, if they live in the US; again, there's no escaping nations, just choosing between them or hiding.) I am not totally sold on the DNSSEC+DANE concept, but the fact that it admits reality as it exists on the ground, which is that the Internet exists of and in the world and not above it, does not strike me as a particularly compelling criticism.
  - tptacek 10y ago
    It is simply not true that in the status quo, setting up a site under .COM gives the USG access to your TLS keys. As long as you're pinning certificates, governments can't generate fake certificates for your site without burning the CA that they suborned. If we adopted DNSSEC+DANE --- and, make no mistake, we have not adopted it --- this status quo would no longer be the case. The DNS hierarchy has no trust agility. You can't burn .COM; if you do that, you break the whole Internet. The browser vendors can, will, and repeatedly have torched misbehaving CAs, and forced still more into Certificate Transparency programs. That's a capability we actually have today, without anyone doing anything, that we would lose in DANE-land. This isn't a complicated argument. I'm surprised it's stayed live on this site for so long. There are lots of other dealbreaker problems with DNSSEC! But this is the simplest of them.

AndyMcConachie 10y ago

> Anyone who can feed you spoofed DNS responses (i.e. starting from a cafe hotspot) would be able to impersonate just anything. Run a stub DNSSEC validator and no one can feed you spoofed DNS responses if they're signed. DNSSEC doesn't require that validation only happen at the recursive server.

rocqua 10y ago
That isn't going to work for the general public though. Not because it is too difficult to set up (that can be fixed by sane defaults). Instead the issue is dealing when you can't get DNSSEC responses. If you want DNSSEC to actually secure you, you need to reject any DNS answer that should have a signature, but doesn't. This means sites not working if there is a slight mistake upstream. Unless this shit becomes really rare, it seems unlikely people will accept this. If you ignore this, you are vulnerable to anyone who can spoof DNS and refuse to server RSIG records.
- AndyMcConachie 10y ago
  DNS records tend to hang around in caches, and people query the same RRs regularly. Thus, it's pretty hard to spoof a RR that you're regularly requesting. This doesn't help for those zones that are not DNSSEC enabled, but there's nothing you can really do about that. If a zone is DNSSEC signed and I query its records regularly(i.e. they stay in the cache) it would be very hard to spoof their records. If I also use a recursive resolver that does DNSSEC validation(e.g., 8.8.8.8) it's even harder. I'm not quite willing to say it would be impossible, but AFAIK no one has shown it to be possible.

NetStrikeForce 10y ago

Exactly this. These days we even trust our neighbours accepting their BGP routing advertisements, which are easily modified to bring traffic to our infrastructure and intercept it. It happens every day all over the world...

Arnt 10y ago

How? There's a well-known key for the root, which vouches for the key for the .org TLD, which vouches for the key for the example.org domain, which vouches for the A/AAAA/TLSA RRs for www.example.org. What part of the chain can the café hotspot break?

tptacek 10y ago
Any of them, since DNSSEC validation doesn't occur in stub resolvers, but is instead delegated to the caches (the "DNS servers" you or DHCP configures). DNSSEC was designed in the mid-1990s, before protocol designers understood crypto, and it was carefully designed to minimize cryptography. Several other bad attributes fall out of that decision as well.
- stephenr 10y ago
  > Any of them, since DNSSEC validation doesn't occur in stub resolvers. By that logic, because someone could write a browser that will accept invalid certificates and/or show everything as secure etc, TLS in general is fundamentally broken so we should never use it. A bad implementation isn't reason to abandon the concept.
  - AnimalMuppet 10y ago
    In what ways is TLS fundamentally broken? (Not arguing, I really want to know. We're looking at moving to it from SSLv3 as I write this.)
    - stephenr 10y ago
      Edit: TL;DR: I'm not saying TLS is fundamentally broken. Also: Unless you need to support fucking ancient client devices/user agents, I urge you to drop SSL (and upgrade to as recent a TLS version as possible) Re-read what I wrote, and what I replied to. A lot of DNSSEC/DANE detractors claim that its effectively useless and unusable, because currently a lot of DNS stub resolvers (e.g. home routers) don't do DNSSEC verification. My response is that you can use the same argument to make anything useless, if you introduce a terrible implementation. Let's try a different example separated from certificates to make it clearer: IE6 was a fucking terrible web browser as far as web standards go. Therefore, web standards are useless and should be abandoned.

makomk 10y ago

Technically, it's replacing two groups of people you have to trust with one, since gaining control of a site's DNS is sufficient to issue certificates for that sites under the current system.