[Collisions] "controlled interruption" - 127/8 versus RFC1918 space

[Warren Kumari]

On Fri, Jan 10, 2014 at 12:52 PM, Wayne MacLaurin <Wayne at demandmedia.com> wrote:
> I get the concerns about privacy and I certainly understand the reluctance
> to want ICANN managing yet another multi-month delay driven process….

AFAIR there were discussions about trial delegations in Beijing --
April 2013, 8 months ago. Often in the ICANN context we spend to much
time faffing about how long a process would take to accomplish that it
becomes a self-fulfilling prophecy :-)

All we are really talking about is a few well connected machines
running Apache and honeyd (or similar), an NS or two, a few scripts to
sanitize logs and someone to look at it and say "Yup, it ain't logging
cookies and passwords..."

>
> I’m also not a lawyer but my view on the privacy issue is that its just
> another piece of FUD being used as an excuse to delay progress.
>
> If a network is going to leak as a result of our proposal.  It is ALREADY
> leaking.  At the very least, their DNS queries are leaking.    If DNS is
> leaking then they are ALREADY subject to all sorts of undefined behaviour
> from the coffeehsop, home routers etc..   Huge swaths of that business
> already do DNS interception for security/access or monetization reasons so
> who knows what’s happening with their data.

Yup. If you are at a coffeshop / hotel / McDonalds / airport you are
already leaking the DNS -- and for the first while the captive portal
is intercepting your DNS / IP / HTTP and performing hijacks /
injection to redirect you to the login page.

>
> I have to believe that actually providing good feedback and a well defined
> privacy policy by whomever is running these proposed services is going to be
> far better than the completely undefined, unknown behaviour that is out
> there today.


Yup, +many lots.

As much as I'd prefer that my HTTP cookies for
intranet.nyc.example.com don't get sent to ICANN, it's way way better
than sending them to the blackhat who registers intranet.nyc.
Getting a page that says "WARNING!!!  You should have used a fully
qualified name, not just typed in just intranet.nyc... Go read more
[here] / pay your consultant to fix this for you..." gives me (an
average user) some idea that there is something scary / important
here...

If I just enter http://internet.nyc, press enter and get "Oops! Google
Chrome could not connect to 127.0.53.53" I'll may eventually discover
that typing "intranet.nyc.example.com" makes the page work -- but I
won't really know why... and I'll just try http://intranet.nyc again
in month or two... It also won't make it clear that entering
printer1.nyc will fail, etc...

W


>
> Wayne
>
>
> On Jan 10, 2014, at 9:12 AM, Jeff Schmidt <jschmidt at jasadvisors.com> wrote:
>
>
> It would not be hard for ICANN to host a webserver that:
> a: strips all parameters from the URL before logging it (anything
> after the /, anything of the form user:pass@, etc).
> b: throws away cookies, all other headers.
> c: Doesn't log usernames, etc for other protocols.
> d: performs other sanitization (only log AS#, strip / elide last octet,
> etc.)
> and have this behavior audited by <insert random auditor here>.
>
>
> Yes, but there is a problem before that too.  By returning an Internet
> routable IP, we've actually "caused" the host to send this juicy stuff
> over the open wifi at the coffee shop, through their compromised home
> router, over the hills and through the woods to Grandmas, etc.  This may
> actually making things worse than they are now - where NX means nothing is
> transmitted.  We want to keep it local.  Fail closed.
>
>
>
>
> ________________________________
> Please NOTE: This electronic message, including any attachments, may include
> privileged, confidential and/or inside information owned by Demand Media,
> Inc. Any distribution or use of this communication by anyone other than the
> intended recipient(s) is strictly prohibited and may be unlawful. If you are
> not the intended recipient, please notify the sender by replying to this
> message and then delete it from your system. Thank you.
>
> _______________________________________________
> Collisions mailing list
> Collisions at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/collisions
>