Re: [DNSOP] moving forward on special use names

[Ted Lemon <[e-mail]>]

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
>
>