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

[Mark Nottingham <[e-mail]>]

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


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


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


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