Hi, > More details on the dangers associated with these certificates in the > context of an active gTLD expansion especially in ICANN SSAC document SSAC057 > https://www.icann.org/en/system/files/files/sac-057-en.pdf > <https://www.icann.org/en/system/files/files/sac-057-en.pdf> Yes.
> 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/>). > I agree with Richard Barnes that the special purpose behaviour of > .onion always returning an NXDOMAIN where possible to prevent information > leakage is enough to justify its inclusion on the Special-Use List. While it > will be difficult to update all resolver implementations everywhere it > shouldn’t be hard to achieve significant compliance (can’t you implement this > requirement with a very small amount of RPZ config?), and thus significant > mitigation of the information leakage issue can be achieved. 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. > I’m generally in favour of this proposal. +1 Regards, -drc
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
