This is an instance of embedding. {th...@example.com}.{non-DNS-part}
is not subject to special delegation rules in some sense, because the
test of {non-DNS-part} requires no DNS action. If its synonymous with
_special_label_.{non-DNS-part}.{example.com} then its about a
conversation with upper systems to perform the transformation. If
{non-DNS-part} doesn't obey domain rules, and is not deterministically
structured, it can be {non-DNS-part}.some.sub.dom.ain eg .ALT and work
fine. It doesn't have to be a terminal on the RHS.For .onion we were told this was non-negotiably not available. So now we have the generic problem: upper name handling systems 'above' the DNS don't want to be required to do work, to mangle apparent-names, purported-named (whatever they are) according to any proscriptive ruleset, to determine what to do: They want the DNS to do the work, that drives them into a state to handle the exceptions. Thats where my primary complaint in shut-it-down came in: This is an unreasonable burden on the hierarchy of domain-names, as a thing in itself. "we" can't have it both ways. We can't have clean domain-name models and coerce the domain-name model to cope with non-domain-name concepts. And "we" can't keep it simple up in applications/URI space, if we have to do special-case handling up there. Shame we did think 6761 fixed this: it doesn't. On Mon, Sep 19, 2016 at 11:57 AM, Ted Lemon <mel...@fugue.com> wrote: > Okay, this is an interesting application that would certainly require some > sort of 6761-style action. Do you believe that it is not covered by the > current problem statement? > > On Sun, Sep 18, 2016 at 9:00 PM, Phill <hal...@gmail.com> wrote: >> >> 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.m >> f-- >> b2gk >> 6 >> - >> duf5 >> y >> - >> gyyl >> - >> jn5e >> d >> >> >> This is a strong domain name and to interpret it we require a policy that >> is validated under the UDF fingerprint b2gk >> 6 >> - >> duf5 >> y >> - >> gyyl >> - >> jn5e >> d. 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 >> >> 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 >> > > > _______________________________________________ > 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
