Re: [Arcing] A bit more on the problem statement

[Ted Hardie <[e-mail]>]

Howdy,

Replies, but not necessarily answers, in-line.

On Wed, Feb 3, 2016 at 6:55 PM, Mark Nottingham <[e-mail]> wrote:

> Hi Ted,
>
> Trying to work through this, please be patient with my potentially limited
> understanding / context.
>
>
> > On 4 Feb 2016, at 5:56 am, Ted Hardie <[e-mail]> wrote:
> >
> > In the draft I posted on resolution contexts, I called the overarching
> set of names "Internet names", following RFC 891.  Clearly things have
> moved on from then no little, but I wanted to get back to that terminology
> because I wanted to stress the internetworking aspect of the problem.
> >
> > For names or identifiers to be meaningful in multiple contexts (like
> different networks or administrative domains), those contexts have to see
> them as part of the same namespace.  That doesn't mean that there must be
> one unitary namespace for every use, but it does mean that each context
> that uses a name must share the same idea of what the namespace context is.
> >
> > You can resolve that problem by having all names in a single namespace
> context.  You can also resolve that by having context markers.
> >
> > The issue with the first approach is that it is trivial for people to
> mint new names.  If those are presumed to be within a single context, that
> also means that it is trivial for those new names to conflict either with
> each other or established names.  The only available point of control we
> have at the moment is in resolution using a specific set of resolution
> protocols.
> >
> > That is, a policy body may decline to allow a particular name to be
> resolved with the DNS, but anything that doesn't use that set of resolution
> protocols can still conflict.  I don't personally see any way to create a
> point of control on the minting of the names themselves without a complete
> architectural re-write of the entire Internet, so I don't think we can
> change the point of control.  That leaves this approach with a pretty big
> gap--any name that doesn't use the DNS as a resolution protocol is subject
> to squatting, collision, or confusion.
> >
> > The second approach, using context markers, is approximately where we
> are today, but we are using an implicit set of context marker rather than
> an explicit one.  But we're not using it particularly well.  As it stands,
> the context marker (pseudo-gTLDs) requires a priori knowledge to establish
> resolution context
>
> If applications don't (somewhere) have the ability to perform resolution
> in that context, they're not going to work anyway, and if they do, they
> have the a priori knowledge necessary.
>
> ​So, it doesn't have to be a priori.  If there were a protocol slot for
resolution context, they could derive the context from that protocol slot;
maybe that fails (without the knock-on effect you list below, since there
is no default), maybe it doesn't (if the context given uses a protocol
known to the resolution subsystem).  Several of the systems have methods
for determining how to resolve a name without a priori knowledge; they just
haven't scaled to the full Internet scale.​



> So, I think the problem here is largely what we saw with .onion -- if your
> application / resolver / etc. don't recognise it as a special name, it
> falls back to DNS resolution, and that may have various undesirable side
> effects (besides not working).
>
> Arguably the downsides of those side effects for .onion -- given its use
> cases -- are pretty extreme, and so it's very interesting to me that
> despite that limitation, its very privacy- and security-sensitive community
> still decided to go in that direction.
>
>
> > *and it doesn't allow you to mark namespaces that don't share the syntax
> of the DNS*.
>
> How big of a problem is this? There are issues with i18n and DNS names, of
> course, but I don't hear people in this space saying that a big driver for
> them is "names that don't look like hostnames." There's a LOT of shared
> understanding behind DNS-style names.
>
>
​There is a lot of shared understanding behind hostname-style names, but
there are also names that don't work in that context because of label
length restrictions or other DNS restrictions (names in ASCII distinguished
by case etc.).



>
> > If what we want is a single Internet namespace, with a marker for which
> resolution protocol is meant, this could be refined a bit to work.
>
> Are you thinking of something like a DNS record on the root zone of these
> domains, so that resolvers can check to see if it's meant for them?
>
>
​Warren Kumari and Andrew Sullivan proposed a pseudo-TLD, alt, which would
function this way; names under .alt would indicate the resolution context
in the delegations from .alt, and the names under that would use it (
draft-ietf-dnsop-alt-tld
<https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-03>)​.  You could
also do this other ways (special prefix like the Punycode prefix, etc.).
It partitions the single namespace into DNS context resolution and non-DNS
context resolution, but it remains a unitary namespace other than that.


> > But every single name delegation in any of the resolution contexts will
> remain a source of potential collision, squatting or confusion, because we
> still won't control the ability to mint names.
>
> I'm not sure how you got here, or why our (the IETF's?) control over the
> ability to mint names is important here. Each resolution context is going
> to need to control its own destiny (assuming it has a distinct name space
> of its own, a la .onion .home etc.)...
>
>
​If we get broad agreement to use a particular signal, like .alt, then
folks minting new namespaces in .alt can avoid collision with a simple FCFS
registry.  If everyone plays nice, there is no collision and you have no
big issues.  But we have no way of making that so, and we have seen in the
pseudo-TLD case that people mint these, use them, and then require updates
of others to deal with the collisions.  Depending on the usage of .alt or a
similar signal, that could remain a concern (at least version of the
proposal had no registry at all, just the reserved top label).



> > If we shift to an explicit set of markers, we get the following
> advantages:  we can use syntax different from the syntax of the DNS; we can
> avoid collision at the level of the tuple of namespace, name; we can avoid
> conflating resolution context and namespace.  (Note that resolution context
> is not a one-to-one mapping with protocol.  As David Conrad has been
> pointing out for years, having a cryptographically signed DNS root (or
> other zone) means the distribution channel for the information can change;
> the resolution context does not).
> >
> > The disadvantage is that every protocol that works across namespaces
> must now be updated to recognize both the explicit markers and the
> namespaces themselves.  That's a lot of work and, as IPv6 taught us, the
> network effects run against you the whole way.  It may, however, be
> something that is significantly easier to deploy incrementally than the
> core IP layer is.
>
> I'm not really sure what direction you're thinking of going here, but I am
> reminded somewhat of previous discussions to define how to transport
> DNSSEC-signed records inside HTTP/2 frames, thereby establishing an
> independent (albeit syntactically and semantically very similar) resolution
> protocol for the same context. That hasn't gone anywhere, but it's still
> lurking out there as a possibility, AIUI.
>
>
​That's a different protocol, but the same resolution context, at least in
my view.  If I sent a web server dns: URLs and it responded with the
appropriate records, I am still get DNS resolution (and demonstrably
correct resolution, with DNS​SEC), just not using the DNS protocol.  That's
the point I was making when I mentioned David Conrad's long history of
comments on this topic.


> > My first question to this group is:  do folks agree with this
> characterization?  If not, what's wrong?
> >
> > If they do agree with the characterization of the problem, does this
> sketch of solution spaces look right?
> >
> > And, most importantly, which level of the problem do we think we can
> solve:  the multiple namespaces one or the unitary namespace/multiple
> resolution contexts one?
> >
> > regards,
> >
> > Ted
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/
>
> ​regards,

Ted​