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

["Adrien de Croy" <[e-mail]>]

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

>
>In message <em8bf94e58-4db5-4277-86ce-c0c5c0dc893f@bodybag>, "Adrien de 
>Croy" writes:
>>
>>  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.
>
>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
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
>any string of characters will form a valid DNS name.
as long as it's only alphanumerics and -.

>
>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: [phone] INTERNET: [e-mail]
>  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.
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?


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

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

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

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

>
>>  Adrien
>
>--
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: [phone] INTERNET: [e-mail]