> On 18 Mar 2015, at 1:49 am, David Conrad <d...@virtualized.org> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
