Re: [DNSOP] discussion for draft-appelbaum-dnsop-onion-tld-00.txt

[David Cake <[e-mail]>]

> On 18 Mar 2015, at 1:49 am, David Conrad <[e-mail]> wrote:
>> 	As per that document, ICANN security team have been among the groups pressuring to have the local namespaces loophole closed for at least a couple of years now. And the problem has scuttled some gTLD applications that are regarded as too tainted by the issue already (e.g. .corp).
> 
> To be clear, the CA stuff isn't the sole reason applied for gTLDs like .corp were 'scuttled' -- the large number of queries for .corp and .home (in particular) seen at the root suggested the risk of name collision was too high (see https://datatracker.ietf.org/doc/draft-chapin-additional-reserved-tlds/ <https://datatracker.ietf.org/doc/draft-chapin-additional-reserved-tlds/>).

	Yes, quite right, there are a lot of issues with name collision in general, and those three in particular leak a lot. Decision not to delegate was wise.

> The risk of information leakage will remain as long as the query leaves the local machine (making the assumption that the local machine can be trusted).  This risk will remain as long as APIs/libraries do not consult the Special Names Registry and don't forward names in that registry to the DNS for lookup (read: a very long time). Qname Minimization may help in the future (assuming it moves forward), but given the circumstances of folks who rely on .onion, I don't think that can be relied upon.

	Yes, and in this respect .onion would be no different to other names on the Special Use Names list, so the list can be regarded as mitigating the issue at best.
	It isn’t the worst information leakage issue for most .onion users, and in general those issues, like this one, result from users using services that they intended to only access when tor is running when it is not ( e.g. associating a P2P GUID with non-TORed IP). There is a limited amount that can be done about that. The best communications security is still vulnerable to operational security failure. Which is no reason not to try.

	David