Why not DANE in browsers(imperialviolet.org)
imperialviolet.org
Why not DANE in browsers
https://www.imperialviolet.org/2015/01/17/notdane.html
6 comments
The fact that TXT records don't work for some people shouldn't stop us. Anything that isn't currently widely used is broken for lots of people, because that's how networks are administered. Once it gets deployed and people start complaining, any specific network problem will get fixed.
Delaying proper network security because it won't currently work for a few percent of people seems like a recipe for never getting there.
Delaying proper network security because it won't currently work for a few percent of people seems like a recipe for never getting there.
It's a cost-benefit issue. Do you believe DNSSEC is so valuable that it's worth (a) breaking connectivity for a significant number of people and (b) incurring the expense of replacing/upgrading the middleboxes that are breaking connectivity? If so, why?
I don't have a strong opinion on DNSSEC itself. It seems like it might be a good idea for email, at least.
I don't have much sympathy for network admins who block TXT records because it doesn't currently seem to break anything. TXT records are part of the spec, and if some of them have configured something to block them, that's not a good reason for everyone to not have secure systems.
I don't have much sympathy for network admins who block TXT records because it doesn't currently seem to break anything. TXT records are part of the spec, and if some of them have configured something to block them, that's not a good reason for everyone to not have secure systems.
I'm reading these blogged opinions on DNSSEC and DANE and I notice that they never state the problem(s) that these "solutions" are meant to address. At least not explicitly.
Somehow I doubt it, but if by chance there is only one true problem being addressed and that problem is simply how do we authenticate another computer as being who we believe her to be, then my second question is: what is wrong with SSH authentication?
Somehow I doubt it, but if by chance there is only one true problem being addressed and that problem is simply how do we authenticate another computer as being who we believe her to be, then my second question is: what is wrong with SSH authentication?
> what is wrong with SSH authentication?
You need some secure, out-of-band, communication means to transfer the key fingerprint to be able to verify it. The whole aim of the CA structure is so I don't need to somehow find a secure means to contact Amazon to verify their key fingerprint prior to first connecting to their website.
You need some secure, out-of-band, communication means to transfer the key fingerprint to be able to verify it. The whole aim of the CA structure is so I don't need to somehow find a secure means to contact Amazon to verify their key fingerprint prior to first connecting to their website.
What if I do not want to transfer the key over an insecure network of computer networks that are trivial to tamper with?
What if I would prefer to look up or obtain the key via some other means (that I deem more trustworthy that the internet)?
What if I would prefer to look up or obtain the key via some other means (that I deem more trustworthy that the internet)?
What key are you referring to here? The CA’s root certificate?
SSH authentication works fine.
It does. But as we all know that model can’t just be lifted over to WWW.
Note sure what "lifted over" means exactly.
I once explained PKI to someone in their 70's who grew up without the personal computer and at one point they stopped me and asked "Why don't they just publish their public key in the newspaper or some directory like a telephone book?"
Later, as an experiment I printed a public key and then used OCR to reproduce it electronically.
Of course a key intended for www usage can also be retrieved over SSH, after the sending computer is authenticated (via SSH authentication). I have also done this, again as an experiment.
I once explained PKI to someone in their 70's who grew up without the personal computer and at one point they stopped me and asked "Why don't they just publish their public key in the newspaper or some directory like a telephone book?"
Later, as an experiment I printed a public key and then used OCR to reproduce it electronically.
Of course a key intended for www usage can also be retrieved over SSH, after the sending computer is authenticated (via SSH authentication). I have also done this, again as an experiment.
What I mean is that SSH and WWW have very different usage patterns.
I guess it is technically possible to verify every TLS certificate out-of-band. But would you really be willing to do that for every TLS-enabled web site you connect to? And even if you were willing to do that, the average user would never do it.
I guess it is technically possible to verify every TLS certificate out-of-band. But would you really be willing to do that for every TLS-enabled web site you connect to? And even if you were willing to do that, the average user would never do it.
[deleted]
I'm using the browser plugin available at https://www.dnssec-validator.cz/ to validate dnssec/dane.
Thomas: Would you agree that DNSSEC is a solution looking for a problem?
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.
However, it is important to note that DNSSEC and DANE are two different things. Much of the recent discussion here has lumped them together.
What would those problems be?
Broadly? 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.
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.
How 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.
That 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.
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.
It 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.
In 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.
> 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/
OpenDNS stopped doing this on June 6 2014:
http://blog.opendns.com/2014/05/29/no-more-ads/
The 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.
If a client is pre-seeded with trusted root keys, DNSSEC protected payload can be validated to the apex.
If 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.
I'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 :)
Which, given how DNSCurve was designed, is a non sequitur :)
ISPs who routinely intercept all DNS traffic and rewrite some of the records.
Attackers control connectivity. Connectivity is expensive. Connectivity is also unreliable: captive portals, proxies, and firewalls break it. These factors make OCSP certificate revocation unworkable. For similar reasons, they make DANE's ostensible safeguard against malicious CAs unworkable. In practice, DANE would probably only be usable as an additional CA; it would not be able to effectively overrule any of the 1482 existing CAs.