<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 6 May 2020, at 19:57, Danny McPherson <<a href="mailto:danny@tcb.net" class="">danny@tcb.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 2020-05-06 17:42, Rubens Kuhl wrote:<br class=""><br class=""><blockquote type="cite" class="">This is WPAD, which I already mentioned as suggested by then<br class="">applicants as a string to be blocked at the 2nd level and as one of<br class="">the few discovery protocols not using _.<br class=""></blockquote><br class="">But it's not blocked Ruben and those same queries are still leaking post CI and users are at risk that's precisely the point! -- it's not blocked in the example domains they have in their attack and exploitation blueprint and it's actually being sold as.a premium in some new gTLDs and for sale all over the new gTLD retail and secondary market -- this precisely illustrates the issue here where users and consumers are at risk.<br class=""></div></div></blockquote><div><br class=""></div>Which for me suggests either an advisory or policy blocking WPAD from registration at all TLDs, not something specific to new gTLDs. For instance, <a href="http://wpad.com" class="">wpad.com</a> and <a href="http://wpad.net" class="">wpad.net</a> are much more harmful since those TLDs have lots more registrations... they are registered, and for now we depend on the good intentions of the registrant of those domains (it's the same organisation), the same situation we had with <a href="http://corp.com" class="">corp.com</a>. </div><div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class="">But WPAD is the obvious one, there are thousands of DNS Service Discovery protocols and others that are problematic for reasons outlined in numerous peer-reviewed research that's been cited here (and that ICANN funded early on, even) - you can continue to ignore it for whatever reason you choose but these protocols and namespace collisions result in billions of queries to the root and can be exploited to enable MiTM attacks well after delegation and CI - e.g., precisely the same as the <a href="http://corp.com" class="">corp.com</a> coffee shop example that is an artifact of .CORP and search list processing.<br class=""></div></div></blockquote><div><br class=""></div>As I mentioned before, except WPAD, all the ones I've seen it the wild use underline compositions (like _tcp and _udp), making those vectors non-exploitable with domain names. So I will ask again: how many and how harmful are those that do not use _ ? </div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">I don't believe "Let's let law enforcement solve the problem nothing to see here" is an answer the board would want to hear or this working group should offer.<br class=""></div></div></blockquote><div><br class=""></div>I mentioned that in the past, as in we would have known thru LEAs after the many years of the program if something was exploited in the wild. </div><div>The detection cycle would be too slow for us to decide on future endeavours, but fact is that with so many years behind us, we know that the TLDs delegated in the 2012 round didn't cause it. </div><div>But, the delegation of .web might cause it, since Web is very meaningful and largely used. Shall we stop the path to .web delegation to prevent the risks you mentioned ? </div><div><br class=""></div><div><br class=""></div><div>Rubens</div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div></body></html>