[NCAP-Discuss] Draft final Study 1 report

[Rubens Kuhl]

> On 24 Apr 2020, at 12:03, Matt Larson <matt.larson at icann.org> wrote:
> 
> <NCAP Phase 1 Report Draft 20200422-for-DG-review.docx>

As requested, my feedback on study 1 is:
- I liked the report and the depth it went into analysing previous materials on the theme. In SubPro we tried doing the same thing and although recording a good number of references, I found more in the report.
- I agree with including re-registration collisions, as I see them as the same intrinsic issue of new TLD delegations collisions
- I agree with the recommendation for not doing study 2. I believe the only new datasets we could collect are out of reach due to privacy regulations: more recursive resolver data. It would be nice to look at the data in Google DNS, Cisco Umbrella etc., but if we didn't get that in 2012 even when Google was an applicant for many strings, some of them in the Interisle report uncalculated risk classification, I don't see us getting that data now in a post-GDPR world. But if that turns out not to be true and strong recursive data comes, then it would probably be useful to do a study on it.
- I think we could get new some ideas of mitigation frameworks and then do a study that would be what study 3 called for. Simple controlled interruption did it for all strings except .corp, .home and .mail, but it's possible that some different frameworks could be used for complicated(in the name collision sense) strings. Let me give an example: since .mail collisions are mainly dotless, a possible mitigation could be a TCP port 25 listener that said "Your mail client should be configured with a FQDN" and closes, preventing any more data from being sent. Since SMTP is a known protocol that only sends data after receiving HELO/EHLO we can except no data leakage, which was the issue that made the current framework use loopback addresses. Besides this one, other possible frameworks for dealing with "polluted" strings could be proposed and studied. Considering that one of the Board questions was what to do with .corp, .home and .mail, perhaps aggregating those 3 strings with unconventional mitigation frameworks could be a worthwhile study.


Rubens



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20200506/e0e25ec4/signature.asc>