RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
Posted Nov 24, 2023 8:38 UTC (Fri) by jamesh (guest, #1159)In reply to: RFC 9498: The GNU Name System by rrolls
Parent article: RFC 9498: The GNU Name System
Posted Nov 24, 2023 10:20 UTC (Fri)
by ms-tg (subscriber, #89231)
[Link] (12 responses)
Posted Nov 24, 2023 14:12 UTC (Fri)
by pizza (subscriber, #46)
[Link] (11 responses)
No, because once the IP is resolved, GNS (and DNS's) role in the connection has ended; the rest is in the application's hands. If the correct IP has been taken over (or is being MITM'd) by a hostile actor, data sent back or forth will be compromised. Even if TLS is used as another protection layer, if the attacker has the resources to hijack IP addresses, they probably have access to a dodgy CA that allows them to also forge TLS certificates (various national TLAs have these resources, and it's also how well-documented national firewalls tend to work too)
(But wait, you might say, one can serve HTTPS/TLS keys via GNS! But you can do this with DNS too, via the DANE proposal. Which I really wish browsers would support so we could ditch the dumpster fire that is the 3rd-party CA infrastructure)
Posted Nov 25, 2023 0:04 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (10 responses)
* All forms of DANE require DNSSEC, whose deployment is (to put it charitably) less than complete, at least in some regions. This is getting better over time, but it certainly has not encouraged browsers to rush into supporting DANE.
Posted Nov 25, 2023 3:59 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
DNSSEC is deployed for all the major TLDs, so you can use it anywhere for these domains. It's not an issue.
The main issue is the end-user support. For some reason, operating systems and browsers resist supporting DNSSEC. It _needs_ to be done on the client side to make a difference.
But once you have DNSSEC, you can easily use DANE alongside the normal CA. A nation-state can still MITM you by forging a certificate, but they won't be able to fool the clients that do DNSSEC resolution themselves. So it's strictly better security.
> Why would anyone even bother configuring one in the first place?
Mostly because nobody validates DANE records as of now.
Posted Nov 25, 2023 4:12 UTC (Sat)
by NYKevin (subscriber, #129325)
[Link] (8 responses)
This is incomplete. There's a third piece, which is the recursive resolvers. Many of them don't actually validate/return DNSSEC results. Furthermore, as of 2015, the Chrome developers were seeing failure to retrieve a simple TXT record on a small but significant percentage of clients,[1] and if that doesn't reliably work, then DANE has no hope of working (DANE records are larger and more recently-specified than TXT records).
In short: You can only have DANE if you have good DNS resolution, and a small but significant portion of clients do not have good DNS.
Chrome could fix this by, for example, unconditionally sending DoH requests to Google or Cloudflare's public DNS servers (which do validate and return DNSSEC, to my understanding) and validating DANE that way, but I imagine that people would freak out if they did that.
Interestingly, there was also talk of putting DANE-signed objects into the TLS handshake and bypassing DNS altogether. Then you really would be able to get away with not having DNSSEC. Unfortunately, the DANE people wanted to prohibit fallback to CA-signed certificates, or at least implement TOFU-based pinning, similar to HPKP. The browser people responded that they had just finished putting out the fire that was HPKP (it turns out that irrevocable pinning is a great way to shoot yourself in the foot), and they were not eager to start a second one, so the whole thing fizzled out.[2]
[1]: https://www.imperialviolet.org/2015/01/17/notdane.html
Posted Nov 25, 2023 7:18 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
You don't need them to. Just ask them to give you RRSIG, DSKEY, and NSKEY records, and do the validation yourself. The recursive resolver will simply act as a dumb cache in this case.
The browsers don't (yet?) want to do that, and there will be some networks that block DNS requests for anything that isn't an "A" or a "CNAME" record.
> Unfortunately, the DANE people wanted to prohibit fallback to CA-signed certificates, or at least implement TOFU-based pinning, similar to HPKP.
Not quite. The problem is that with concurrent deployment of DANE and CAs, there's still a possibility of the attacker simply stripping off the DANE information from the TLS request, leaving only the CA-issued certificate. The working recommended key pinning to fix this (yeah, a great idea).
Still, adding an X.509 field to signify that the certificate MUST be accompanied by a stapled DNSSEC reply can be an easy incremental improvement.
Posted Nov 26, 2023 18:58 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link] (6 responses)
Well, that's a showstopper. Browsers should not encourage the proliferation of technologies that only sometimes work. The web is meant to be a universal platform that works "everywhere."
> Still, adding an X.509 field to signify that the certificate MUST be accompanied by a stapled DNSSEC reply can be an easy incremental improvement.
Presumably, this is restrictive DANE. Your threat model is an attacker obtaining control of the certificate, and now you want to revoke it with DANE. It was previously a valid certificate issued by a CA (and not additive DANE).
(Must-staple provides little or no benefit for additive DANE, because if no DANE response is stapled, then additive DANE probably can't work reliably anyway.)
The obvious objection to this is that OSCP must-staple provides exactly the same benefit, but is actually a real formal specification already. I'm not aware of a spec for DANE must-staple. Unfortunately, nobody implements that one either, but it's a significantly lower technical barrier because the spec already exists, as does most of the necessary tooling.
Posted Nov 26, 2023 18:59 UTC (Sun)
by NYKevin (subscriber, #129325)
[Link]
(Of course, I meant OCSP must-staple.)
Posted Nov 26, 2023 20:42 UTC (Sun)
by Wol (subscriber, #4433)
[Link]
> Well, that's a showstopper. Browsers should not encourage the proliferation of technologies that only sometimes work. The web is meant to be a universal platform that works "everywhere."
Problem is, browsers are based on what is meant to be a universal platform that works "everywhere".
If the underlying Internet is not a real Internet, then browsers are going to "only sometimes work", and there's nothing the browser developers can do about that. Unfortunately, there are a lot of internet protocols that don't work (ping for example?), because the hardware is intentionally crippled, and there's not a lot software developers can do about it.
Cheers,
Posted Nov 27, 2023 14:08 UTC (Mon)
by immibis (subscriber, #105511)
[Link]
Every networking technology only sometimes works, because every network packet goes through several adversaries. If this was the logic, browsers should not use HTTP. Or TCP. Or UDP. Or DNS.
Posted Nov 27, 2023 18:46 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
That's not true. We have plenty of technologies that "sometimes" work, but being in a browser slowly pushes them to work everywhere. Example: WebRTC.
> Presumably, this is restrictive DANE. Your threat model is an attacker obtaining control of the certificate, and now you want to revoke it with DANE. It was previously a valid certificate issued by a CA (and not additive DANE).
No. The threat model is a hostile certificate issued by a government-controlled or a compromised CA. The attacker doesn't have access to my system. This is the main problem with the PKIs, any CA can issue a certificate for any domain.
DANE would require the attacker to not only compromise one CA somewhere, but to compromise my particular top-level domain registrar and my DNS provider.
So basically, you have the matrix:
1. A legacy CA certificate without stapled DANE. The browser will have to do a DNSSEC-secured query to verify that there is no DANE record for this domain name. A browser can cache the outcome ("no DANE record, verified via DNSSEC") for a reasonable time.
2. A CA certificate with "must staple" bit set and a stapled DNSSEC chain. The browser verifies them both, and everything works with zero overhead.
3. A CA certificate without "must staple", and an existing DANE record (that the adversary wasn't able to tamper with). This immediately means an attack.
4. A DANE record without a CA certificate, verified via a stapled DNSSEC chain. This is the optimal outcome.
Posted Nov 30, 2023 0:47 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (1 responses)
And *that* is why the stapling proposal fell apart. You can't hard-fail on that DNS query, because some ISPs will not serve it correctly and you would display a spurious warning. Such warnings do more harm in aggregate (by training users to ignore them) than the extremely limited number of MitM attacks you would realistically prevent.
Posted Nov 30, 2023 8:11 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I mean, you can. And with DoH/DoT it's pretty easy to do the query to work around broken ISPs.
Browsers also have a "bully pulpit" they can start with just silently ignoring DNSKEY query failures, then a couple years later start showing a banner like "your ISP is tampering with your DNS", then put the DNSKEY-failed connections behind the usual scary "certificate might be invalid" dialog.
> Such warnings do more harm in aggregate (by training users to ignore them) than the extremely limited number of MitM attacks you would realistically prevent.
The same statement could be made about deprecating HTTP.
Especially since it has caused half of the Internet to depend on one _service_ (Let's Encrypt). Its failure will basically cause an Internet-wide blackout, all to prevent occasional malicious MITM.
DANE will eventually allow to break this dependency.
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
* Restrictive DANE, in particular, requires the browser to hard-fail any connection where DNSSEC is not available, because a MitM attacker can probably induce that failure mode (unless using something like DoH for end-to-end encrypted DNS requests and responses, but most ISPs do not deploy DNS in that fashion).
* Restrictive DANE does not offer enough of a value-add over Certificate Transparency, at least from the browsers' perspective (i.e. they know they can reliably find and distrust CAs who issue rogue certs for large, well-known domains, and it is not too difficult for a small, less well-known domain to find and report such a rogue cert, so the browsers, somewhat credibly, believe that CAs will not be willing to attempt issuing such rogue certs at all).
* Additive DANE is, in practice, mostly or entirely redundant to Let's Encrypt. Also, any clients who don't have DNSSEC and/or DANE support won't be able to view your website, so in practice you would need a regular non-DANE certificate anyway (at least until those technologies are fully supported by everyone everywhere). At that point, the DANE certificate is dead weight. Why would anyone even bother configuring one in the first place?
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
>
> The main issue is the end-user support. For some reason, operating systems and browsers resist supporting DNSSEC. It _needs_ to be done on the client side to make a difference.
[2]: https://blog.apnic.net/2019/07/05/whither-dane/
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
Wol
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System