Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

From: Robert Edmonds <[email-masked]>
Date: Sat, 2 Apr 2016 16:11:37 -0400

You are complaining about the following text:

   In [RFC2826] the IAB noted that

      "To remain a global network, the Internet requires the existence
      of a globally unique public name space.  The DNS name space is a
      hierarchical name space derived from a single, globally unique
      root."

Abley, et al.           Expires September 9, 2016               [Page 7]
 
Internet-Draft     Top-Level/Special-Use Domain Names         March 2016

      "Maintaining a globally-unique public namespace that supports
      different name resolution protocols is hence an architectural
      requirement, and some facility for reservation of top-level
      domains in the DNS is necessary."

   If [...]

>From the context it would appear the second paragraph surrounded by
double-quotes is actually part of the main text of the document and not
a quote.

Note the indentation in the markup:

https://github.com/ableyjoe/draft-adpkja-dnsop-special-names-problem/blob/bd566c665630c96b415ed28caec48f27267d57c9/draft-adpkja-dnsop-special-names-problem.xml#L342-L354

Probably there is a missing <t> at the beginning of line 351.

Adrien de Croy wrote:
> sorry, that second reference should have also been RFC 2826
> 
> neither the word "Maintaining" nor "architectural" are present in 2826
> according to the search function in Chrome.
> 
> Adrien
> 
> 
> ------ Original Message ------
> From: "Adrien de Croy" <[email-masked]>
> To: "Paul Hoffman" <[email-masked]>; "[email-masked]"
> <[email-masked]>
> Sent: 1/04/2016 9:25:07 a.m.
> Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
> 
> >
> >
> >------ Original Message ------
> >From: "Paul Hoffman" <[email-masked]>
> >To: "[email-masked]" <[email-masked]>
> >Cc: "[email-masked]" <[email-masked]>
> >Sent: 1/04/2016 12:31:53 a.m.
> >Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01
> >
> >>On 30 Mar 2016, at 18:49, John Levine wrote:
> >>
> >>>Isn't it a little late to be refighting this argument?
> >>
> >>+1.
> >
> >I guess now we have some hindsight maybe we could learn from the
> >experiences with .onion and maybe look differently at a proposal for .alt.
> >
> >
> >>
> >>Folks: this thread is about a specific document, not every other thing
> >>we have discussed before now. If you want to rediscuss (as I sometimes
> >>do), please at least reference in the document where your argument fits.
> >>That way, the document authors can maybe amend the document if there is
> >>consensus to do so.
> >Well I would start with what is presented as a quote from RFC 2826 which
> >isn't actually in RFC 2686 and which seems to be the basis for a claim of
> >even doing a special use names registry at all.
> >
> >In Section 4. Architectural considerations
> >
> >"Maintaining a globally-unique public namespace that supports different
> >name resolution protocols is hence an architectural requirement..."
> >
> >Adrien
> >
> >
> >>
> >>--Paul Hoffman
> >>
> >>_______________________________________________
> >>DNSOP mailing list
> >>[email-masked]
> >>https://www.ietf.org/mailman/listinfo/dnsop
> >
> >_______________________________________________
> >DNSOP mailing list
> >[email-masked]
> >https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Robert Edmonds

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 03 Apr 2016 02:51:40 +0000

that's correct.  It looks in that document like a quote from the IAB, 
but if you're saying it's not, I then would have to challenge the 
logical conclusion asserted in that second paragraph.

I don't see why it necessarily follows that having a single tree with a 
single root creates a requirement for support for multiple resolution 
protocols.

The thousands of authors of other protocols and systems don't seem to 
have had too much trouble so far just using DNS where required, and 
putting resolution into their own protocols outside the tree.  Why break 
the whole tree for some nebulous result which surely in all cases can be 
worked around with a smaller consequence than having to deploy new DNS 
to the entire world.

Even a DSL/NAT box does DNS forwarding, do we expect all those cheap 
router box vendors to patch out the firmware for this any time soon?

Adrien

------ Original Message ------
From: "Robert Edmonds" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Paul Hoffman" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 3/04/2016 8:11:37 a.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

>>different

---

From: Mark Andrews <[email-masked]>
Date: Sun, 03 Apr 2016 14:47:20 +1000

> single root creates a requirement for support for multiple resolution

Because the only other way to be able to distingish between a onion
address and a DNS name would be to have onion use labels with a
wire representaion that are longer that 63 octets or with overall
lengths greater that 255 wire octets or you have to prefix all names
with DNS and ONION to identify the resolution namespace.  Almost
any string of characters will form a valid DNS name.

This was my signature back in 1995.  Note you had to NAME the NAMESPACES.

	Mark Andrews, CSIRO Div Maths & Stats
	Locked Bag 17, North Ryde, NSW 2113, Australia.
	PHONE:  +61 2 325 3148                       INTERNET: [email-masked]
	UUCP: ....!uunet!syd.dms.csiro.au!marka

None of us grey beards want to go back to those days.

We could have added "*.onion 604800 IN NULL" to the root zone and
fixed all the resolvers to stop searching on NOERROR but that does
not stop the fact that you want to use TOR alone with who you want
to talk to leaking unintentionally.

> router box vendors to patch out the firmware for this any time soon?

No.  The expectation is that future boxes that they ship will
implement the protocol and not pass on the leaked name.  The
expectation is that any update issued will also address this.

The RFC allows DNS only resolvers, proxies and recursive servers
to all generate NXDOMAIN responses in the event of a leak.  This
will result in SERVFAIL in some cases as the validation of the
response will fail but it will still prevent the leak spreading.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 03 Apr 2016 21:20:12 +0000

------ Original Message ------
From: "Mark Andrews" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Robert Edmonds" <[email-masked]>; "[email-masked]" 
<[email-masked]>; "Paul Hoffman" <[email-masked]>
Sent: 3/04/2016 4:47:20 p.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

>lengths greater that 255 wire octets
It looks like you're talking about making a name that can't be encoded 
on a DNS packet and so therefore can't be looked up with DNS, but that's 
not necessarily going to achieve any specific distinction between DNS 
any any other specific name space, it's just a broken (in a DNS-centric 
POV) name, rather than onion name specifically.

>or you have to prefix all names
>with DNS and ONION to identify the resolution namespace.
Prefixing with some kind of protocol identifier is what is done with 
URIs. There's pretty good recognition out there for that kind of thing?
>  Almost
as long as it's only alphanumerics and -.

>to talk to leaking unintentionally.
OK this is the nub of it.  You want to connect to a global privacy 
network and from there privately access services.  Fundamentally you're 
still connecting over IP, so you need to resolve an IP address of the 
network entry point.  This is still a DNS name. You then connect to 
that.

Once you're connected, you're talking your own protocol, and then you 
can resolve names within your system any way you please, even LDAP.  I 
don't see why DNS has to even be involved there.

Or is the problem about antispam doing lookups on onion names embedded 
in emails?  What about a URI format?

>expectation is that any update issued will also address this.

I wouldn't be surprised if the people making these boxes are mostly 
unaware of this added requirement on them.

>response will fail but it will still prevent the leak spreading.

The proposed deployment methods make me uneasy as well.

For example.  Some smart DNS developer, looks at special use names, sees 
that there's now a sanctioned mechanism to get new root namespaces into 
the DNS, and figures hey I should check some central location 
occasionally for a list of root level domains I should return NXDOMAIN 
for.

Someone hacks that list to include .com

Since there is no machine-readable repo for this, vendors will make 
their own, and those may/will be hackable.

Maybe would be better if just the root servers returned NXDOMAIN, but 
the leak is already occured by that stage.

In any case I think it's foolhardy to rely on there being no leak, and 
TOR would have done better by its customers to whom it is promising 
privacy, to not rely for privacy/security on changes being made to a 
system which has a vast inertia.

And that inertia means we should avoid at all costs any new feature 
which means we have to change out all DNS.  Not create new mechanisms 
for it.

Adrien