Subject: [DNSOP] Some thoughts on special-use names, from an application standpoint

From: Mark Nottingham <[email-masked]>
Date: Thu, 26 Nov 2015 17:38:31 +1100

RFC7230 Section 2.7.1 says this about hostnames in HTTP URLs:

"""
If host is a registered name, the registered name is an indirect identifier for use with a name resolution service, such as DNS, to find an address for that origin server. 
"""

... which builds on how RFC3986 Section 3.2.2 talks about hostnames in URLs and URIs:

"""
The presence of a host subcomponent within a URI does not imply that the scheme requires access to the given host on the Internet.  In many cases, the host syntax is used only for the sake of reusing the existing registration process created and deployed for DNS, thus obtaining a globally unique name without the cost of deploying another registry.  However, such use comes with its own costs: domain name ownership may change over time for reasons not anticipated by the URI producer.  In other cases, the data within the host component identifies a registered name that has nothing to do with an Internet host.  We use the name "host" for the ABNF rule because that is its most common purpose, not its only purpose.
"""

So, the Web architecture already has baked in a notion of multiple mechanisms for location within a single name space. Indeed, the flexibility of multiple location mechanisms might be required to address issues like domain name ownership changes.

Given this context, I was disturbed to hear the design team presentation in Yokohama suggest that we "remove the value of a top-level domain" as a potential solution (around 49:30 in the meetecho recording).

To me, this fundamentally misses the point; the value of a single naming root with flexible location is a community good, and cannot be removed just to make life easier for DNSOPS. The impact goes far beyond DNS.

In the ensuing discussion, Andrew Sullivan's comments (at around 58:00) made the most sense to me. The problems that draft-adpkja-dnsop-special-names identifies (e.g., "what technical criteria should the evaluation body use to examine the merit of an application for such a reserved name/protocol switch", "With regard to the actual choice of name, [RFC6761] is silent") are already handled by our normal processes, where we invest technical authority to judge in bodies like the IESG, and document an appeals process. It's also far from clear that we *need* to have only one path to a new special-use name (as section 6.2.1 seems to desire).

While I appreciate that the .onion discussion was a prolonged headache for DNSOP, and that perhaps in the future other venues should be used, deciding how to handle the general issue of naming based upon its impact on *one* location protocol community doesn't seem appropriate. If this effort is to do more than make modest clarifications to RFC6761, I'd suggest that we consider moving it elsewhere.

Kind regards,

P.S. The draft begins:

"""
In recent years, using the last label of a domain name (aka TLD) as switch to indicate how to treat name resolution has been experimented using the framework of [RFC6761].
"""

This framing is incorrect. RFC6761 is a Proposed Standard, not Experimental. 

--
Mark Nottingham   https://www.mnot.net/

---

From: hellekin <[email-masked]>
Date: Thu, 26 Nov 2015 11:59:57 +0000

On 11/26/2015 06:38 AM, Mark Nottingham wrote:
> 
> Given this context, I was disturbed to hear the design team presentati
on
> in Yokohama

So you mean there's an already working team on the revision of RFC6761,
and that team had the time to prepare a presentation, while the DNSOP
chairs didn't have the time to respond to volunteers nor to announce
this team.  This is simply unacceptable.  I concur that the revision of
RFC6761 should go to another group where "Internet community" makes some
sense and corporate dissent is not silenced by ignoring legitimate
requests.  Please don't expect any apologies from me for telling the
truth.  This is a carnival of an inclusive process.

Thank you Mark for the heads up.

==
hk

---

From: George Michaelson <[email-masked]>
Date: Fri, 27 Nov 2015 12:18:11 +1000

I have a different perspective on this question Mark.

Firstly, I find use of .magic as the extreme RHS of a name, to force
special behaviour architecturally disqueting.

I really do worry about what we think we're building when we encode this
behaviour into name strings. It leads to all kinds of bad places. Some of
them, like the homoglyph problems John Klensin has raised, simply don't
have good answers (the assumption the string .onion is the literal ASCII
'o' 'n' 'i' 'o' 'n' is not well founded)

We were here a long time ago, when we had pre-Internet mail and used things
like .UUCP as magic break-out signals in email. This rapidly becomes the
problem: its bound to applications-level decisions about when to honour
magic, and when not, and it certainly doesn't avoid lower level
gethostbyname() calls everywhere. So the .magic label winds up being
half-true, depending.

Secondly, While I think  I now understand some of the problems you have in
web/apps layer (from talking to Wendy Seltzer) and I have sympathies about
the syntactic constructs welded into code around URL forms, I think these
problems are different to the architectural/layer violation explicit in
forcing .magic names into the namespace.

What really got me floored, was the qualities of cryptographic protection
which a project like TOR needs, and the implication a public/commercial CA
service embedded in the browser TA set is the right path. I'm frankly
horrified, even under certificate pinning, that we've gone to a space where
any TA can claim to sign over .onion, and excluding the pinned
applications, lead people into paths where their assumptions of TLS backed
security are simply not true.

As I understand things, TOR *wanted* .onion to get X509 PKI over the label
in a browser, and the CA community refused unless its TLD status was
confirmed. Is this the kind of rigour in technical process we expect, to
make technical calls to pre-empt the namespace? (which btw, we passed
otherwise to another body, reserving an RFC backed process to get names,
but I think that was a hugely unwise decision)

To protect .onion certs, the TOR developers are going to have to code in
cert pinning behaviour, all kinds of things, which frankly sound to me a
lot like the cost of not having the name, or having a name buried under a
2LD instead.

So I come to a different place. I come to a place where requests for magic
names look like violations of any spirit of an architectural view of the
network, and where retaining some technical basis to reserve them looks
like violations of the separation of functional roles between ICANN and
IETF, absent very very clear, strong reasons to have the name held back.

I don't entirely see these reasons emerging. I see the opposite. I see
expediency from apps communities, seeking to use .magic tricks to avoid
cost explicitly in their layer, but at a cost of polluting the public
commons.

I am pretty firmly in the camp which says the revision of the RFC should be
complete: we stop doing this, and people who want names go into ICANN
process to establish them.

-G

On Thu, Nov 26, 2015 at 9:59 PM, hellekin <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> -----BEGIN PGP SIGNATURE-----
>
> iQJ8BAEBCgBmBQJWVvQ8XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
> ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9ewoQALD1dF/Wqyh2Lo5qZ35PUANA
> bvq2k5BZd1UsN488+V4v7PnAHxO7XgR8IQSYYnp1oYNaZl5WbFEPjT6HOSR3O4lr
> 7iSVeSxPux8hssSxorkWtBVk8oAnImGEPyIlYunBLcTyasXLY5+2fzmR1+P4/9Kk
> ahjHvuQa6dOAXhqTMBizwb3kZ2PC2hFlM5LKMIBcf9GfTVmH//fbEalHYPYEwMCY
> AvX9mkMvvWcWhn15OXRi50r3kQl65d0KQA2euQ8mUIe5qafDHASBtZLc81t0rAXv
> fjaWT4REu+KUHexWKgI7NFF3uZ0M0Cm7imYN6+YG+AWFtPrr4SPh1BA0L4td93q8
> bGxGEJrDTWRVaW2c98UO5bFxm3kqcM4oTdBD1Rg4yC1OatvuKzZp6nPrFG09G5rn
> PjorrqoNx0MHxwejrTHkkhnmvmgTfPUTvkT/7zUYLTwRITDrjzOyj932COrZV+A3
> dak5M5hRLhR8jswx/lh+SmY1RFAtCuNDcoFuXTOJygwSpj7WvigIORiT6ATLFlfW
> mxYxkVP/Tc76anRTk5O/AIu87c5K9fr6TPiFRIL/0eKnFBEMn2qbaW7TLvAl6o89
> kgYYp4u59ve0vCL6gE2sn1w1EYnctFVxpzcg9HkFl/MFuQyWdc4yb5OdFWW8sema
> 8hpTT/KiW1/KDHGj0kcB
> =IZoh
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 28 Nov 2015 04:58:52 -0500

I'm not the WG Chair who is handling the day-to-day responsibilities (I 
just do all the other boring DNS stuff), but I do know this:

- design team is being put together but was not complete
- Ralph Droms (AD for 6761) is the head of the design team
- they are still looking for 1-2 people with experience in the 
application area

My co-chair has family obligations this weekend but I suspect we will 
hear next week from her or Ralph.

tim