I don't want to go too far OT, but had a question if someone wouldn't mind answering it or pointing me to some materials.
I've been digging into DNS and TLS lately. Given the way ACME works (essentially using DNS to verify you own a domain before giving you a cert), what's the reason you can't just put your public key in a DNS record? I'm assuming it has something to do with security issues at the DNS level, but don't really know.
This is basically the idea behind DANE. The problem is that DNS was historically unauthenticated and so just as vulnerable to on-path attacks as HTTP - perhaps more so due to the distributed, hierarchical nature which enables certain types of takeovers.
DANE assumes that DNSSEC is in place, so that the DNS records are authenticated. This allows the DNS records to be used to deliver TLS trust information in a way that is still ultimately rooted in a certificate authority (whoever operates DNSSEC for the TLD).
Adoption has been limited, mostly because adoption of DNSSEC itself has been limited, arguably because DNSSEC is overcomplicated and high-maintenance, but also just due to a lack of motivation. Similarly, users couldn't care less about how TLS trust is delivered and DANE has never really gotten a big corporate champion to push for it, so there just hasn't been the drive. Industry seems to have chosen DNS-over-HTTPS as the long-term solution to many of DNS's problems, and it clashes somewhat with DANE - I'm sure you could make them work together but it would definitely become awkward
As other comments said, DNS is vulnerable to man-in-the-middle attacks without DNSSEC, and DNSSEC is not widely adopted.
However, even with DNSSEC, bob could obtain domain.tld's keys and then use them to MITM alice's DNS requests, getting her browser to show a malicious site for domain.tld complete with a trusted certificate. Furthermore, bob can do this for alice and only alice, decreasing the odds of detection by a large margin.
With LE you gain:
- Targeted attacks harder to pull off, since you would need to successfully attack the LE servers/networks first and then your actual target.
- LE participates in the certificate transparency initiative, meaning every time a certificated is emitted for a domain it gets recorded.
These things are particularly relevant when you consider that in most cases the DNS is either directly or indirectly controlled by state actors at their root. With DNS-only, they could pull off such targeted attacks without anybody noticing. With LE, they can still pull off these attacks, but there would be a papertrail when that happened.
DNSSEC is not about protecting MITM attacks against DNS traffic. DNSSEC is about validating that DNS records have not been tampered with. Are you thinking about DNS over HTTPS and DNS over TLS?
MITM involves monitoring and/or altering the traffic between two endpoints which believe they are talking directly. If DNS traffic between Alice's client and configured DNS server can be intercepted DNSSEC provides no real protection because unlike TLS all information to verify signed records are provided in band via DNS. Once the traffic can be intercepted and return traffic spoofed the attacker can return the appropriate records to make it appear that the response is properly signed without any need of having the DNSSEC keys being used at the authoritative DNS server for that domain.
DNS over HTTPS, DNS over TLS and DNSCurve are intended to protect against this type of interception/tampering and should be used along side DNSSEC.
I think you are incorrect here. DNSSEC protects from the root servers' (.) keys downward. If you have a compliant DNSSEC resolver it should authenticate the entire chain using the pre-shared keys for the root domain.
For a MITM attack to work in this scenario, the attacker would have to first get fake keys for the root domain (that normally come with the OS) into your computer, at which point not even DNS over anything would work because they should be able to install TLS certs too.
As far as I know, all these DNS-over-TLS flavors' advantage is that they prevent eavesdropping, not spoofed traffic (because DNSSEC can do that too as per my explanation above).
The parent comment is more right than not: end-systems in fact don't perform DNSSEC validation, but rather rely on their DNS servers to do it for them. On the network path between an end-system and its DNS server, no cryptography is deployed to protect DNS records; rather, a single bit in the header signals to DNS resolvers that some DNSSEC validation has been performed, somewhere. Along that network path, any middlebox can tamper with the DNS.
It's not an academic concern, because the two most common modes of deployment for DNS are "with ISP DNS servers", in which case one of your most important and active DNS adversaries is on-path, and "with services like 8.8.8.8", in which case the whole Internet is between you and the thing that validated DNSSEC for you.
It's not a good system, and it's true that DoH does a better job at addressing this problem.
It's certainly true that if you want your resolver to live on a separate node that you trust, yet there's a network you don't trust between you and that node, DPRIVE attempts to solve that and DNSSEC does not.
But without DNSSEC a middlebox still gets to tamper anyway, since there's no authenticity of the answers you receive, you're just moving your trustworthy source of these potentially bogus answers for whatever that's worth.
Thomas believes your ISP is "one of your most important and active DNS adversaries" and yet astonishingly he trusts them to provide you with authentic DNS answers.
If you do local validation, which you're free to, DNSSEC solves the problem.
If you do remote validation but you trust the remote DNS server to do that on your behalf correctly, DNSSEC solves the problem and then any DPRIVE protocol brings those correct answers home intact.
If you believe there are certainly authentic answers where Google is (I have a lot of used iron available, central Paris area, it's in the form of a big tower so you can't miss it, buyer collects) then just DPRIVE lets you get their authentic answers. Notice that Google does not warrant that this is true, and "where Google is" might mean a data centre controlled by your country's censors.
I don't understand why you think I trust residential ISPs with the DNS, since that's the opposite of what I believe --- residential ISPs are actively monetizing the DNS.
The example you cited is "with ISP DNS servers". But if you in fact don't trust them, DPRIVE on its own doesn't help you.
Same way upgrading from HTTP to HTTPS doesn't prevent you getting misinformation from Conservapedia. The answers on the site are bad, so ensuring nobody "tampers" with those bad answers doesn't really help you.
DPRIVE is good stuff, and one of the things that great about it is that it unsticks the deployability problem for DNSSEC client validation, but I'm guessing that's not the part you're keen on.
I'm lost. The point of using DOH (which isn't DPRIVE, which is itself a moribund project) is not using ISP DNS servers in the first place. Can you maybe rephrase this somehow?
DPRIVE is the working group that owns all the ongoing DNS privacy work, including RFC 7226 (upon which RFC 8484 DoH depends and a bis document for which is probably to be expected next year) and the forthcoming BCP document describing best practices for all these privacy preserving DNS services. The existence of a short WG to spin up, consume a good first draft and spit out a single DoH document RFC 8484 doesn't change that. I have no idea which "moribund project" you're referring to and I doubt it's relevant here.
As to "not using ISP DNS servers in the first place" I guess you do not consider Comcast to be an ISP?
Or perhaps you didn't hear. Both Chrome and Firefox will automatically give Comcast's customers Comcast DNS over HTTPS. Mozilla secured a TRR agreement from Comcast in exchange, and presumably Google feels that this agreement plus any undisclosed paperwork from Comcast that they were shown as part of their onboarding process is enough to likewise trust it automatically in Chrome. We expect to see more ISPs doing this over the next few years. If you cannot beat them, join them, eh?
I understand what you're trying to do with that mic-drop snark about Comcast, but obviously I don't think it's a good idea to direct your DoH queries to Comcast.
There's a working group that hopes to own everything on the Internet, but DoH happened outside that process, and was deployed (thankfully) over the objections of people involved in the group.
I wouldn't characterize it as "mic-drop snark" it's just that your assumptions were wrong.
There's actually a pretty big contingent on HN that wanted this, they see the alternatives as either my DNS query goes to the ISP I've already chosen and contracted with, or to Google/ Cloudflare/ OpenDNS who I maybe don't like and don't deal with otherwise - and they'd prefer the former.
The "point" of DoH is actually that it sidesteps ossification. One of the big differences from Mozilla's user privacy focused TRR is that Google's programme cuts to the chase immediately. Your DoH service must work for well formed queries you don't understand, in particular HTTPSSRV. Why? Because the "point" is to get to a world where we can actually use technologies like QUIC and ECH and we can't deploy those technologies at scale in a world where your 1990s ad-tech DNS server responds to anything other than an A query with confused silence.
One of the things DoH allowed them to throw in is a way to express "I won't tell you the answer because censorship" as distinct from just giving bogus answers. Again Google's programme is specific that it's fine to censor stuff, but Comcast are obliged to use this mechanism so that Chrome can tell users "No, you aren't allowed to look at Porn Hub" rather than "Huh, Porn Hub doesn't exist". And again, even though I'd guess you're like me and don't want censorship lots of people do so defeating censorship is not "the point" either.
You continue to make a strong case for not using Comcast's DNS servers. Since I entered this conversation believing nobody should use Comcast's DNS servers, I'm confused why you're making that case to me personally, but whatever, I agree.
What happens if both DNS requests are hijacked? Could an attacker return both a different IP and a different public key that correspond to a malicious server?
Edit: I should clarify, I think the issue stems from DNS being a potential attack vector itself. You can't blindly trust what DNS tells you. This is precisely the problem that certificate chains (issued by a trusted third party) purport to resolve-- one of trust.
Well there's DNSSEC. Implementation details (such as lack of practice in key rotation, TTL, etc) aside, DNSSEC works and LetsEncrypt validates it.
Then there is Certificate Transparency logs. It will be passive action at this point, but it's an action regardless.
Let's Encrypt checks DNS validation and DNS CAA from multiple PoPs, but I don't think it's enforced by CA/B requirements to do so (happy to be corrected).
One possible reason is that its more likely that your individual dns is being modified/tampered with than it is for LEs servers. This way your individual ISP can't mess with things.
I've been digging into DNS and TLS lately. Given the way ACME works (essentially using DNS to verify you own a domain before giving you a cert), what's the reason you can't just put your public key in a DNS record? I'm assuming it has something to do with security issues at the DNS level, but don't really know.