There is actually a fifth type of name, escaped names. Right now, the only names we have of this type are SRV protocol tags, (_http._tcp.example.com) and internationalized names (xn—wev.com)
I want to add a third set of escaped names, one that has similar functionality to .onion but does not leak as much information. example.com.mf--b2gk6-duf5y-gyyl-jn5ed This is a strong domain name and to interpret it we require a policy that is validated under the UDF fingerprint b2gk6-duf5y-gyyl-jn5ed. This in turn is a base 32 encoding of 92 bits of digest value plus an 8 bit version string. The fingerprint is over a content type identifier plus some content as specified here. https://tools.ietf.org/html/draft-hallambaker-udf-03 <https://tools.ietf.org/html/draft-hallambaker-udf-03> The content is typically going to be some sort of cryptographic key (PGP, PKIX, SSH, JOSE, whatever) that signs some sort of assertion that states how the address ‘example.com’ is to be interpreted. The trick here is that we can now bind security policy direct to any DNS name without having to muck about with DNSSEC, or for that matter any other PKI standard other than the particular standard we want. Lets say that Alice is using OpenPGP and her OpenPGPv5 key is mw83i-32ri4-83klq-3odp3. We can form an address from that: al...@example.com.mf--mw83i-32ri4-83klq-3odp3 Now that isn’t an address that we can interpret without access to Alice’s public key. Which is actually what I kinda want because I am fed up of spam. The fact that I give you my address does not mean I want just anyone being able to use it. In the ordinary course of business, my ‘strong name aware’ mailer knows that it has to resolve mf--mw83i-32ri4-83klq-3odp3 somehow before it can use that email address. If I just type it into Outlook, the client will happily pass it on to my mail server and then it will get ‘stuck’ unless the mail system can figure out how to use that address. Which is exactly what you would want to happen with confidential mail. If the address can be resolved, the result is normally going to be a policy that says what protocols the address can be used with and how. Now, naturally, a split horizon DNS would be one natural place to provide access to a resolution service, but it need not be the only one. The use of strong DNS names represents a major step forward in achieving a genuinely decentralized Web. Instead of there being an institution at the trust apex of the Internet, there is a digest function and a PKI scheme. > On Sep 16, 2016, at 2:13 PM, John Levine <jo...@taugh.com> wrote: > >> The drafts are: >> https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/ >> >> https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/ > > Having read them both, neither one thrills me but I'd give the nod to > adpkja. The "Internet Names" in tldr seems to me a bad idea, since > there are a lot of other names on the Internet such as URIs and handle > system names, and this is about domain names. > > It seems to me there are four kinds of names we have to worry about, and > neither draft calls them all out clearly: > > * Names resolved globally with the DNS protocol, i.e. > ordinary DNS names > > * Names resolved globally with an agreed non-DNS protocol, e.g. > .onion via ToR > > * Names resolved locally with an agreed non-DNS protocol, e.g, > .local via mDNS > > * Names resolved locally with unknown protocols, e.g. .corp and > .home, the toxic waste names > > R's, > John > > > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
