Re: [DNSOP] moving forward on special use names

[George Michaelson <[e-mail]>]

This is an instance of embedding. {[e-mail]}.{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 <[e-mail]> 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 <[e-mail]> 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:
>>
>> [e-mail]--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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>>
>>
>> _______________________________________________
>> DNSOP mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>