8 ms·

> solves a problem nobody really cares about DNSSEC was designed to protect from using forged or manipulated DNS data. Including all other records, like TXT, M

> solves a problem nobody really cares about DNSSEC was designed to protect from using forged or manipulated DNS data. Including all other records, like TXT, MX, CERT records, SSH fingerprints, IPSec public keys and TLS Trust Anchors. I care that I can verify all this.

tptacek 8y ago
You're one of the few. And I can't imagine why anyone would want to enroll their personal keys --- SSH, IPSEC, whatever --- into a global PKI. Your VPNs and SSH connections are more secure, objectively, outside of DNSSEC.
- phicoh 8y ago
  Only if you have an out-of-band way of verifying SSH keys. In my experience, 9 out of 10 times that doesn't happen and people just accept a changed SSH key.
  - tptacek 8y ago
    So fuck it, let's let the United States Government cast the tiebreaking votes when we're not sure?
- Leace 8y ago
  To add to that, new protocols are designed not to rely on DNSSEC: MTA-STS for MX records (uses HTTPS), Web Key Directory for OpenPGP keys (uses HTTPS). Even old GnuPG deprecates DNS based key lookup: https://lists.gnupg.org/pipermail/gnupg-users/2018-October/061034.html https://lists.gnupg.org/pipermail/gnupg-users/2018-October/0...
  - phicoh 8y ago
    Putting user keys in DNS is an obvious mistake: deeply connected to DNS is the idea that the data in DNS is public. It requires heroic attempts like NSEC3 to keep data private and even NSEC3 is not enough. Trying to put list of users (mail addresses) in DNS is a mistake. That said, the only reason for MTA-STS seems to be that some people don't like DNSSEC. From RFC 8461 "Related Technologies The DNS-Based Authentication of a Named Entities (DANE) TLSA record [RFC7672] is similar, in that DANE is also designed to upgrade unauthenticated encryption or plaintext transmission into authenticated, downgrade-resistant encrypted transmission. DANE requires DNSSEC [RFC4033] for authentication; the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades."
    - tptacek 8y ago
      When you say "some people don't like DNSSEC", you're sort of dancing around the fact that the people who don't like it are some of the most important organizations on the Internet; to wit: all the major mail providers.
      - phicoh 8y ago
        Which is fine. Do I really care about the security of Gmail? Yahoo? Hotmail? For me the important thing is that all TLDs I care about support DNSSEC. So I can implement DNSSEC-based security locally. If other people want to play a different game, it is mostly fine with me. The only annoying part is that browsers refuse to do DANE validation but firefox somehow is very quick to jump on the DoH bandwagon.
        tptacek 8y ago
        I don't know. Do you ever email people? If so: yes, you do. It doesn't really matter that you can configure your own little island of DNSSEC since you'll inevitably depend on one of the resources in, like, the whole rest of the Internet, virtually none of which signs zones with DNSSEC. This really all is just security theater.
        phicoh 8y ago
        I assume that when you say 'virtually none', you are aware that more than 50% of the dot-nl domains (so around 3 million) are DNSSEC signed. Furthermore, more 60% of the DNS queries that reach the servers for the dot-nl zone are from validating resolvers.
        tptacek 8y ago
        I do not care about the thousands of European domains that are signed because domain hosting firms automatically enable it and sign zones for their customers, and neither should you, since that is obviously security theater. In the unlikely event that anyone is reading the thread this deeply, you can go to https://dnssec-name-and-shame.com https://dnssec-name-and-shame.com and try to find a big tech firm other than Cloudflare (which has a DNSSEC product) and (heh) Comcast that uses it.
- auslander 8y ago
  Not sure. Malicious ISP can forge DNS answers [0], the purpose of DNSSEC is to catch that. [0] https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_ISPs https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_...
  - tptacek 8y ago
    False. DoH, DNS over TLS, and DNSCrypt/DNSCurve address that problem. DNSSEC does not.
phicoh 8y ago
One of the nice things about DNSSEC is that it is both optional and it actually works. It being optional means that everybody who doesn't like DNSSEC can just ignore it. Just don't sign your zones, don't run a validating resolver. DNSSEC doesn't get in the way. At the same time, because Google's public resolvers have been validating DNSSEC for quite a long time, it is safe to run a validating resolver. Anybody who signs a zone is forced to do it correctly, otherwise the zone will be unreachable for a significant fraction of the people on the the internet.
- auslander 8y ago
  > Google's public resolvers have been validating DNSSEC for quite a long time Quad9 also provides DNSSEC validation on our primary resolvers. Better for you privacy :)
tialaramex 8y ago
And being verifiable this means we don't need to care about how it gets transported to clients, which is a recurring theme in Internet design. The TLS WG has a piece of work for how you shove the DNSSEC RRs into a TLS setup, so you can say "OK, I know DNSSEC but my resolver sucks, so, can you prove who you are with DNSSEC?" as an alternative to doing the Web PKI or some similar setup but with a private CA. For example we saw this previously with OCSP in two ways: Firstly, any issuer working at scale does OCSP by pre-generating answers and shoving them into an ordinary CDN / reverse cache. The CA knows they issued cert X, and it was still good on Friday, they sign an OCSP response that says "I'm the issuer, cert X was still good as of today" dated Friday and they shove that into the cache. Now the CDN can deliver OCSP responses quickly and at scale without scattering OCSP signer keys all over the Internet. Clients can trust them because they're signed, even though the client talked to some CDN, not the issuer at all. Secondly OCSP stapling. Instead of clients doing OCSP (and most often failing open since it's unreliable) let's have the server collect OCSP responses for its certificates periodically, and then "staple" the response to the certificate when delivering it. The OCSP signer and OCSP client never communicate at all, but since it's a signed message the client can trust that it's genuine.
tedunangst 8y ago
But you don't care at all about confidentiality?

tptacek 8y ago

You're one of the few. And I can't imagine why anyone would want to enroll their personal keys --- SSH, IPSEC, whatever --- into a global PKI. Your VPNs and SSH connections are more secure, objectively, outside of DNSSEC.

phicoh 8y ago
Only if you have an out-of-band way of verifying SSH keys. In my experience, 9 out of 10 times that doesn't happen and people just accept a changed SSH key.
- tptacek 8y ago
  So fuck it, let's let the United States Government cast the tiebreaking votes when we're not sure?
Leace 8y ago
To add to that, new protocols are designed not to rely on DNSSEC: MTA-STS for MX records (uses HTTPS), Web Key Directory for OpenPGP keys (uses HTTPS). Even old GnuPG deprecates DNS based key lookup: https://lists.gnupg.org/pipermail/gnupg-users/2018-October/061034.html https://lists.gnupg.org/pipermail/gnupg-users/2018-October/0...
- phicoh 8y ago
  Putting user keys in DNS is an obvious mistake: deeply connected to DNS is the idea that the data in DNS is public. It requires heroic attempts like NSEC3 to keep data private and even NSEC3 is not enough. Trying to put list of users (mail addresses) in DNS is a mistake. That said, the only reason for MTA-STS seems to be that some people don't like DNSSEC. From RFC 8461 "Related Technologies The DNS-Based Authentication of a Named Entities (DANE) TLSA record [RFC7672] is similar, in that DANE is also designed to upgrade unauthenticated encryption or plaintext transmission into authenticated, downgrade-resistant encrypted transmission. DANE requires DNSSEC [RFC4033] for authentication; the mechanism described here instead relies on certification authorities (CAs) and does not require DNSSEC, at a cost of risking malicious downgrades."
  - tptacek 8y ago
    When you say "some people don't like DNSSEC", you're sort of dancing around the fact that the people who don't like it are some of the most important organizations on the Internet; to wit: all the major mail providers.
    - phicoh 8y ago
      Which is fine. Do I really care about the security of Gmail? Yahoo? Hotmail? For me the important thing is that all TLDs I care about support DNSSEC. So I can implement DNSSEC-based security locally. If other people want to play a different game, it is mostly fine with me. The only annoying part is that browsers refuse to do DANE validation but firefox somehow is very quick to jump on the DoH bandwagon.
      - tptacek 8y ago
        I don't know. Do you ever email people? If so: yes, you do. It doesn't really matter that you can configure your own little island of DNSSEC since you'll inevitably depend on one of the resources in, like, the whole rest of the Internet, virtually none of which signs zones with DNSSEC. This really all is just security theater.
        phicoh 8y ago
        I assume that when you say 'virtually none', you are aware that more than 50% of the dot-nl domains (so around 3 million) are DNSSEC signed. Furthermore, more 60% of the DNS queries that reach the servers for the dot-nl zone are from validating resolvers.
        tptacek 8y ago
        I do not care about the thousands of European domains that are signed because domain hosting firms automatically enable it and sign zones for their customers, and neither should you, since that is obviously security theater. In the unlikely event that anyone is reading the thread this deeply, you can go to https://dnssec-name-and-shame.com https://dnssec-name-and-shame.com and try to find a big tech firm other than Cloudflare (which has a DNSSEC product) and (heh) Comcast that uses it.
auslander 8y ago
Not sure. Malicious ISP can forge DNS answers [0], the purpose of DNSSEC is to catch that. [0] https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_ISPs https://en.wikipedia.org/wiki/DNS_hijacking#Manipulation_by_...
- tptacek 8y ago
  False. DoH, DNS over TLS, and DNSCrypt/DNSCurve address that problem. DNSSEC does not.

phicoh 8y ago

One of the nice things about DNSSEC is that it is both optional and it actually works. It being optional means that everybody who doesn't like DNSSEC can just ignore it. Just don't sign your zones, don't run a validating resolver. DNSSEC doesn't get in the way. At the same time, because Google's public resolvers have been validating DNSSEC for quite a long time, it is safe to run a validating resolver. Anybody who signs a zone is forced to do it correctly, otherwise the zone will be unreachable for a significant fraction of the people on the the internet.

auslander 8y ago
> Google's public resolvers have been validating DNSSEC for quite a long time Quad9 also provides DNSSEC validation on our primary resolvers. Better for you privacy :)

tialaramex 8y ago

And being verifiable this means we don't need to care about how it gets transported to clients, which is a recurring theme in Internet design. The TLS WG has a piece of work for how you shove the DNSSEC RRs into a TLS setup, so you can say "OK, I know DNSSEC but my resolver sucks, so, can you prove who you are with DNSSEC?" as an alternative to doing the Web PKI or some similar setup but with a private CA. For example we saw this previously with OCSP in two ways: Firstly, any issuer working at scale does OCSP by pre-generating answers and shoving them into an ordinary CDN / reverse cache. The CA knows they issued cert X, and it was still good on Friday, they sign an OCSP response that says "I'm the issuer, cert X was still good as of today" dated Friday and they shove that into the cache. Now the CDN can deliver OCSP responses quickly and at scale without scattering OCSP signer keys all over the Internet. Clients can trust them because they're signed, even though the client talked to some CDN, not the issuer at all. Secondly OCSP stapling. Instead of clients doing OCSP (and most often failing open since it's unreliable) let's have the server collect OCSP responses for its certificates periodically, and then "staple" the response to the certificate when delivering it. The OCSP signer and OCSP client never communicate at all, but since it's a signed message the client can trust that it's genuine.

tedunangst 8y ago

But you don't care at all about confidentiality?