7 ms·
There are a lot of real problems that DNSSEC can help solve. However, it is important to note that DNSSEC and DANE are two different things. Much of the recent
by msturgill 12y ago
There are a lot of real problems that DNSSEC can help solve.
However, it is important to note that DNSSEC and DANE are two different things. Much of the recent discussion here has lumped them together.
- tptacek 12y agoWhat would those problems be?
- msturgill 12y agoBroadly? General MITM, Kaminsky, etc. DANE as an application of DNSSEC is interesting (and based on the recent string of editorials, contentious as well). Using DANE to constrain CAs could add an additional layer of protection against a rogue CA. Using it as an additional CA could help facilitate moving towards "HTTPS-everywhere". The takeaway of course in implementing it in any manner is that it is just another layer, not a panacea. Outside of DANE, there are other applications such as IPSECKEY and SSHFP that have utility.
- tptacek 12y agoHow does securing DNS lookups solve the MITM problem if the underlying traffic remains unencrypted? If you encrypt the traffic, you don't need secure DNS anymore.
- msturgill 12y agoThe DNS traffic doesn't need to be secret ("encrypted"), it just needs to be authenticated (i.e. the payload has not been modified and there is a chain of trust). If a client is pre-seeded with trusted root keys, DNSSEC protected payload can be validated to the apex.
- tptacek 12y agoIf traffic is end-to-end protected with cryptography --- as, for instance, it is in the SSH protocol --- why does it matter if DNS records are authenticated? If you forge a DNS record, the SSH protocol will kill the session. SSH doesn't even need to care what the DNS says; all that matters are the cryptographic secrets.
- sarciszewski 12y agoI'm going to be generous here and assume they meant authenticated encryption rather than just encryption between the user and the first DNS server they hit. Which, given how DNSCurve was designed, is a non sequitur :)
- derf_ 12y agoThat depends on what your trust model is. Somebody is resolving the DNS query, and then the result gets transmitted to you. If all you're worried about the result being MITM'd during transit, then encryption is sufficient. You can set up DNSCrypt to deal with this today [1]. But often the provider resolving the query is itself untrustworthy. Most providers these days (including OpenDNS) redirect invalid queries to their own landing pages (which poisons caches and has other bad effects). Providers may "censor" certain domains. Or be subverted by state-level actors (see: Belgacom). In DNSSEC, the root of trust is the administrator of the DNS root zone (e.g., Verisign, whom you're probably already trusting anyway). [1] But encryption is not a panacea. As soon as you visit the address(es) returned, someone will get a pretty good idea what you looked up.
- tptacek 12y agoIt doesn't matter if you can MITM someone through the DNS. Stipulate that it's trivial to do that. You still can't get in the middle of my SSH connection, because SSH authenticates itself, bidirectionally.
- derf_ 12y agoIn that case, DNSSEC probably isn't doing much for you (besides the systemic effects of discouraging providers from returning false DNS results in the first place), but sadly not everything on the internet is so well-designed as ssh. Being unable to specify a port in MX records, leaving SMTP on port 25 with only STARTTLS for encryption being one good example.
- Panino 12y ago> Most providers these days (including OpenDNS) redirect invalid queries to their own landing pages OpenDNS stopped doing this on June 6 2014: http://blog.opendns.com/2014/05/29/no-more-ads/ http://blog.opendns.com/2014/05/29/no-more-ads/
- derf_ 12y agoSomething about which I'm glad to be wrong.
- asuffield 12y agoISPs who routinely intercept all DNS traffic and rewrite some of the records.