RFC 9498: The GNU Name System
GNS addresses long-standing security and privacy issues in the ubiquitous Domain Name System (DNS). Previous attempts to secure DNS (DNSSEC) fail to address critical security issues such as end-to-end security, query privacy, censorship, and centralization of root zone governance. After 40 years of patching, it is time for a new beginning.
| From: | "Schanzenbach, Martin" <schanzen-AT-gnunet.org> | |
| To: | info-gnu-AT-gnu.org, gnunet-developers-AT-gnu.org, help-gnunet-AT-gnu.org, info-gnunet-AT-gnu.org | |
| Subject: | RFC 9498: The GNU Name System | |
| Date: | Tue, 21 Nov 2023 08:45:17 +0100 | |
| Message-ID: | <d0b404d8-8337-4bf7-99b9-fbaf029b9a8d__16301.3111612358$1700576117$gmane$org@gnunet.org> |
We are happy to announce that our *The GNU Name System* (GNS) specification is now published as RFC 9498 [0]. GNS addresses long-standing security [1] and privacy [2] issues in the ubiquitous Domain Name System (DNS) [3]. Previous attempts to secure DNS (DNSSEC [4]) fail to address critical security issues [5] such as end-to-end security, query privacy, censorship, and centralization of root zone governance. After 40 years of patching, it is time for a new beginning. The GNU Name System is our contribution towards a decentralized and censorship-resistant domain name resolution system that provides a privacy-enhancing alternative to the Domain Name System (DNS). As part of our work on RFC 9498, we have also contributed to the specification of the .alt top-level domain [6] to be used by alternative name resolution systems and have established the GANA registry for ".alt" [7]. GNS is implemented according to RFC 9498 in GNUnet 0.20.0. It is also implemented as part of GNUnet-Go [8]. We thank all reviewers for their comments. In particular, we thank D. J. Bernstein, S. Bortzmeyer, A. Farrel, E. Lear, and R. Salz for their insightful and detailed technical reviews. We thank J. Yao and J. Klensin for the internationalization reviews. We thank Dr. J. Appelbaum for suggesting the name "GNU Name System" and Dr. Richard Stallman for approving its use. We thank T. Lange and M. Wachs for their earlier contributions to the design and implementation of GNS. We thank J. Yao and J. Klensin for the internationalization reviews. We thank NLnet [9] and NGI DISCOVERY [10] for funding work on the GNU Name System. The work does not stop here: We encourage further implementations of RFC 9498 to learn more both in terms of technical documentation and actual deployment experiences. Further, we are currently working on the specification of the R^5N DHT [11] and BFT Set Reconciliation [12] which are underlying building blocks of GNS in GNUnet and not covered by RFC 9498. [0]: https://www.rfc-editor.org/rfc/rfc9498.html [1]: https://www.wired.com/2014/03/quantum/ [2]: https://roarmag.org/essays/nsa-leak-domain-name-system/ [3]: https://www.rfc-editor.org/rfc/rfc882 [4]: https://www.rfc-editor.org/rfc/rfc9364 [5]: https://www.rfc-editor.org/rfc/rfc8324 [6]: https://www.rfc-editor.org/rfc/rfc9476.html [7]: https://gana.gnunet.org/dot-alt/dot_alt.html [8]: https://git.gnunet.org/gnunet-go.git/ [9]: https://nlnet.nl [10]: https://nlnet.nl/project/GNS/ [11]: https://lsd.gnunet.org/lsd0004 [12]: https://lsd.gnunet.org/lsd0003
Posted Nov 21, 2023 21:05 UTC (Tue)
by simon.d (guest, #168021)
[Link] (23 responses)
Posted Nov 21, 2023 21:52 UTC (Tue)
by pizza (subscriber, #46)
[Link] (22 responses)
And how exactly are you supposed to query a global namespace without having _some_ notion of a "trusted root" to start your searches from? What's to stop multiple orgs from claiming the same domain name? How can you trust that the record for "www.lwn.net" that you get is authentic?
The problems with the existing DNS infrastructure aren't technical, and thus can't be solved via technical means.
Posted Nov 22, 2023 2:53 UTC (Wed)
by NYKevin (subscriber, #129325)
[Link] (21 responses)
> It follows from the above that GNS does not support names that are simultaneously global, secure, and memorable. Instead, names are either global and not memorable or not globally unique and memorable. An example for a global name pointing to the record "example" in a zone is as follows:
In short, you can only have "nice" names by doing some local configuration to decide where the nice name should point, which in turn implies that the end user is required to make all trust-related decisions about who gets which "nice" name. Strictly speaking, the user applies "labels" to "zones," which is roughly analogous to needing entries in your hosts file for each TLD you want to use.
The obvious problem with this (and I can't believe I have to explain this) is that DNS was designed to produce short, human-readable, globally unique names that can be shared with absolutely anyone, no setup required, and GNS simply does not attempt to provide that combination of features at all. I'm sure it's useful for some purpose, but a DNS competitor it is not.
Posted Nov 22, 2023 5:59 UTC (Wed)
by ErikF (subscriber, #118131)
[Link]
I think I'll stick with DNS for now.
Posted Nov 22, 2023 9:09 UTC (Wed)
by ballombe (subscriber, #9523)
[Link] (14 responses)
The fact that the DNS returns human-readable strings means that it is subject to artificial scarcity, trademark law, priority, domain squatting, typo domain, IDN abuse, etc.
Posted Nov 22, 2023 10:05 UTC (Wed)
by farnz (subscriber, #17727)
[Link]
The only reason that we have a single DNS, and not multiple, is that there's value from us all agreeing that when I talk about "LWN.net", I mean this site, and not a different host (which is exploited by - for example - TLS's use of X.509 certificates that tie the identity to DNS name). In theory, though, my DNS servers could have their own private TLD, and rewrite lwn.net.iana to lwn.net before asking the IANA roots to resolve it.
Posted Nov 22, 2023 13:07 UTC (Wed)
by dvrabel (subscriber, #9500)
[Link] (12 responses)
I don't think a long random string of characters is really equivalent to a 11-digit phone number.
Posted Nov 22, 2023 21:25 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Nov 23, 2023 7:39 UTC (Thu)
by rrolls (subscriber, #151126)
[Link]
Posted Nov 22, 2023 21:38 UTC (Wed)
by ballombe (subscriber, #9523)
[Link] (9 responses)
Posted Nov 23, 2023 1:09 UTC (Thu)
by pizza (subscriber, #46)
[Link] (6 responses)
So, when folks click on "bigcorp,com" in their google/facebook/whatever search results, how will their computer know what IP address to connect to?
DNS underpins *everything* on the internet. And ironically, that includs GDNS as well, as evidenced by its GNS2DNS redirection records.
Posted Nov 23, 2023 10:18 UTC (Thu)
by ballombe (subscriber, #9523)
[Link] (5 responses)
Posted Nov 23, 2023 14:17 UTC (Thu)
by pizza (subscriber, #46)
[Link] (4 responses)
So.... who sets up and then maintains this "user directory"?
Posted Nov 23, 2023 19:55 UTC (Thu)
by ballombe (subscriber, #9523)
[Link] (3 responses)
Posted Nov 23, 2023 20:30 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
You forget that for phone numbers, there is an authoritative registry (ie the phone company) that tells you the legal name associated with a given number.
> The only thing readable names provide is a false sense of familiarity that make some hostname looks 'legit',
So how does the user know (in advance) what hostname for "linux weekly news" is "legit" and thus should go into their address book?
> when the DNS system does not at all assure in any way they point to a legit website.
GNS is no better in this respect.
> With the GNS, all unknown hostnames look equally dodgy.
Again, how do you determine which of these "equally dodgy" unknown hostnames is the legitimate "lwn.net"?
I don't doubt that GNS has some niche use cases, but it is in no way a general replacement for DNS. Indeed, given the degree of manual configuration/delegation needed for a GNS resovler to accomplish anything, I'm far from convinced that GNS has anything to offer over doing a similar degree of manual configuration/delegation to an off-the-shelf DNS resolver.
Posted Nov 23, 2023 22:44 UTC (Thu)
by ballombe (subscriber, #9523)
[Link] (1 responses)
About exactly the same way you do it with DNS, really.
Posted Nov 24, 2023 0:10 UTC (Fri)
by pizza (subscriber, #46)
[Link]
With DNS you'd query the global authoratative root, with records signed by DNSSEC, and connect to an IP that uses a TLS certificate that matches the domain name. But with GNS, you have to already know who to contact before you can ask them to resolve an address.
(If you can get a direct link via a search engine or some sort of 3rd-party directory, guess what, that same mechanism works with bog-standard DNS as well, and GNS has added nothing. Less than nothing, really, as it's made the user experience _worse_)
So, once again, how does GNS solve (or even improve upon) DNS's [in]ability to determine if a given site is "legit"? At best it's no different, but in practice it's going to be much, much worse.
Posted Nov 23, 2023 4:50 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Nov 23, 2023 10:51 UTC (Thu)
by paulj (subscriber, #341)
[Link]
Posted Nov 22, 2023 14:18 UTC (Wed)
by atnot (subscriber, #124910)
[Link] (4 responses)
We had people manually entering network adresses, then writing aliases, then copying around host files, then querying local trusted servers, then querying our current, globally distributed domain name system.
We had lists of useful dns names printed on paper, we had curated directories and web rings, we had ranking search engines that would correct your parents typos, we had link aggregators and now we have app stores and capital P Platforms where nobody that uses them could even tell you what their DNS name is.
It doesn't sound like the creators of GNS have any answers for the forces that caused these things to happen, apart from a desire to set the clock back half a century[1]. Instead they seem to have only added bad ideas created since.
From things like cryptocurrency and even PGP we have learned that few end users are capable of managing sensitive long lived key material and even fewer enjoy that sort of responsibility and just flock to unaccountable centralized services instead. We have learned that at a societal scale, flexibility and humans in the loop that can resolve conflicts and reverse mistakes are far more valuable than mathematical rigidity. It is actually quite good that if someone breaks into a server or registrar, the domain is not compromised forever.
We already have things like TOR hidden services or to a lesser extent IPFS, that deliberately accept these drawbacks for their narrow use cases. But GNS doesn't seem to have any of that.
[1] This appears to be GNU's signature move recently
Posted Nov 22, 2023 14:41 UTC (Wed)
by pizza (subscriber, #46)
[Link]
Yep. And if you want to create your own internal/private domains you can trivially do that with existing DNS servers and resolvers. Heck, everyone with a consumer-grade wifi router is already using such a setup [1], whether they realize it or not.
[1] via dnsmasq
Posted Nov 27, 2023 3:38 UTC (Mon)
by roffey (guest, #166590)
[Link]
It's not quite /etc/hosts which can only map local names to IPs. For example, it has nicknames and petnames.
> [1] This appears to be GNU's signature move recently
GNUnet was started by Christian Grothoff in 2001 and GNU Name System circa 2013 so it's hardly recent. The RFC is a recent move, just like the RFC for .onion.
Also GNU is a pretty loose collective, GNUnet really only just sits under that large umbrella but it is hardly a coordinated GNU effort.
Posted Nov 27, 2023 14:04 UTC (Mon)
by immibis (subscriber, #105511)
[Link] (1 responses)
Posted Nov 30, 2023 0:34 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link]
Disclaimer: IANA hates this.
Posted Nov 22, 2023 1:45 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
Posted Nov 22, 2023 21:05 UTC (Wed)
by rra (subscriber, #99804)
[Link] (2 responses)
I think there is a narrow use case where this is a useful solution (you want a unique name for some endpoint that may change IP addresses regularly and you don't care about it being human-readable), but it's not the DNS use case.
Posted Nov 22, 2023 21:37 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Nov 22, 2023 21:53 UTC (Wed)
by rra (subscriber, #99804)
[Link]
Like many Dan Bernstein ideas, it is possible, even likely, that it involved some combination of reduction to first principles and tongue-in-cheek, but he was definitely pushing it at the time. This was back before he gave up / got distracted from Internet protocols and focused mostly on encryption algorithms.
Posted Nov 23, 2023 8:02 UTC (Thu)
by rrolls (subscriber, #151126)
[Link] (14 responses)
But it doesn't seem to go much further than that. :\
Something I've been casually mulling over for years, that I've never seen anyone experiment with, but I'd love to see attempted, is a protocol/standard that achieves the following:
1. User configures their brand new device to trust a _single_ public key, for sake of argument, the pubkey of their favorite website.
If in step 1 we're talking a non-tech-savvy user here, it could be configured by the tech-savvy friend who gets them their new device; or by the computer shop; or whatever. Yes, if you're buying a device from a big name, they'd just configure their own, and people would then want some chain of trust back to that big name, so it'd be similar to the centralisation of DNS/TLS in that respect; but it would be trivial to remove the default root and add another, or have multiple roots; and far more importantly, _anyone_ can take the role of a "CA", simply by serving a good old-fashioned link.
Posted Nov 24, 2023 8:38 UTC (Fri)
by jamesh (guest, #1159)
[Link] (13 responses)
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.
Posted Nov 25, 2023 4:27 UTC (Sat)
by PengZheng (subscriber, #108006)
[Link]
I have a simple question to ask:
Posted Nov 30, 2023 6:18 UTC (Thu)
by fest3er (guest, #60379)
[Link] (1 responses)
Seems to me that part of the problem is verifying that an IP address has been (maybe statically) assigned to the entity claiming that address. While a miscreant might be able to fake controlling an FQDN, but she shouldn't be able to fake being the official assignee of the related address. For example, while I might be able to fake that I control the name 'google.com', I should not be able to fake that 192.0.2.10 is in the blocks of addresses assigned to Google. Would such a system have the same vulnerabilities as DNS?
Would Opportunistic Encryption (host2gateway » gateway2gateway » gateway2host) reduce the problem? (I know I connected to my gateway. My gateway knows it connected to the correct remote gateway. The remote gateway knows it connected to its correct internal host.) Or does it still boil down to "Exactly who are we to trust?"
Posted Nov 30, 2023 11:01 UTC (Thu)
by grawity (subscriber, #80596)
[Link]
There already is. When a registrar updates the 'nameserver' values for your domain, they use a restricted-access back-channel to whichever registry runs the respective TLD. (e.g. you get a .cz domain at Namecheap, and Namecheap sends a "foo.cz is hosted at us now" update to NIC.CZ over this back-channel.)
It seems you're thinking of the entire DNS 'system' as a single database with user accounts somewhere, though? That's not the case. Regular DNS updates are not submitted to 'the system'; they're submitted to some specific hosting provider that handles some specific domains.
So if you're using the free DNS hosting provided by your registrar, and you're making some regular DNS updates (changing IP addresses), there is no need for a back-channel "from registrar to DNS" because the registrar /itself/ is the 'DNS' – it just updates its own database and doesn't transmit anything anywhere further than that.
> 2FA seems to be nearly ubiquitous these days. Why isn't it part of the DNS system?
Because 2FA is used when authenticating to an 'active' system – a server that has user accounts (like a SQL database) and is able to verify your 2FA credential (which is usually one-time) – and DNS is not that kind of 'system'.
It's more of a passive 'system' in the same sense that the web is a system for publishing webpages, but you don't 2FA to your "web account" to publish a website, and likewise you don't 2FA to your "DNS account" to perform DNS updates – you authenticate to your Namecheap account, or to your personal BIND9 server, &c. (And those individual DNS hosting providers *do* have 2FA, most of the time.)
The equivalent of 2FA for passively published data would be digital signatures (e.g. PGP-signing a document), and DNS does have that – that's exactly what DNSSEC is.
> I should not be able to fake that 192.0.2.10 is in the blocks of addresses assigned to Google. Would such a system have the same vulnerabilities as DNS?
The issue is that "assigned to Google" does not necessarily mean "routed to Google". On a global scale, that's the problem that e.g. RPKI and BGPsec are trying to battle – obtaining a certificate for someone else's domain by BGP hijacking their IP prefix to your own server is already a known threat.
> Would Opportunistic Encryption (host2gateway » gateway2gateway » gateway2host) reduce the problem? (I know I connected to my gateway. My gateway knows it connected to the correct remote gateway. The remote gateway knows it connected to its correct internal host.)
How do you know it's the 'correct' gateway? Encryption is not a verification mechanism by itself – and that goes double for opportunistic encryption, which often specifically means "just encrypt even if there's no verification". Opportunistic encryption is a mechanism for improving privacy, not authenticity.
More importantly, a 'correct' gateway is not necessarily correct for that particular route; e.g. your ISP's gateway may legitimately be talking to Cogent's gateway and having the verified tunnel established, and Cogent may be legitimately talking to one of their customers' gateways, and that won't help in the slightest if the customer advertises the wrong prefix (by mistake or by malice) and Google's IP ranges get routed to them.
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
>> example.000G006K2TJNMD9VTCYRX7BRVV3HAEPS15E6NHDXKPJA1KAJJEG9AFF884
> Now consider the case where a user locally configured the petname "pet.gns.alt" for the zone with the "example" record of the name above. The name "example.pet.gns.alt" would then point to the same record as the globally unique name above, but name resolution would only work on the local system where the "pet.gns.alt" petname is configured.
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
Realistically bigcorp.com will be in the user directory.
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
The only thing readable names provide is a false sense of familiarity that make some hostname looks 'legit',
when the DNS system does not at all assure in any way they point to a legit website.
With the GNS, all unknown hostnames look equally dodgy.
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System
2. User goes to their favorite website. That public key they trusted allows getting to it, no central TLS/DNS required, in a similar manner to SSH (which doesn't require any central trust root, it just requires TOFU). Actually finding the website can be done by some kind of DHT, like GNS suggests.
3. Each link on the website isn't just a link: it also includes a public key. It's an assertion that the maintainer of the website trusts that the pubkey served with the link is correct for whatever the link points to. Clicking a link doesn't just navigate to it, it also caches the assertion, so that the link target can be served despite that the user didn't explicitly trust that pubkey yet. Instead, the user is trusting their favorite website's maintainer that their assertions are correct; and so on, for links from those websites, etc.
4. Those cached assertions would be maintained locally in some kind of graph "web-of-trust" representation; if any were later discovered to be incorrect (either by the user, or some kind of automatic revocation system), it could be updated accordingly, and invalid assertions stripped out.
RFC 9498: The GNU Name System
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
RFC 9498: The GNU Name System
When there are multiple websites claiming to be Google, how do users know which is the real one?
RFC 9498: The GNU Name System
RFC 9498: The GNU Name System