[gnso-rds-pdp-wg] Reputation systems are not just nice to have (was Re: What we want redux)
theo geurts
gtheo at xs4all.nl
Fri Sep 29 19:57:19 UTC 2017
Good info Allison,
I suspected that Let's Encrypt would take a huge beating reputation-wise
after the IDN browser display goof up, and over 15k certs issued for
domain names used in PayPal phishing attacks and god knows what.
Still, we are at the crossroads where privacy protection services are a
factor when it comes to risk scores and a lot more.
In the left corner, we have the contracted parties who understand that
abuse is an issue as they also deal with it, but those mighty fines from
Europe are a factor that cannot be ignored. Besides today it is the
GDPR, tomorrow it is China and next week some other country, the counter
just goes up here and doing business on a global level is getting very
hard. If this continues the "one world, one internet" slogan at ICANN
can be thrown into a dumpster over a few years, if we are not careful.
In the right corner, we have the folks who deal with abuse on a daily
basis, a factor that also weighs very heavy. Reading the legal memo, it
seems the GDPR makes that very difficult to factor that in. Again, other
countries will incorporate the same heavy data protection laws and not
always for protecting their citizens but for economic motives. We still
have come up with a solution that takes care of that.
I have the feeling the solution is not within the WG but more within the
Article 29 Working Party based on their recommendations when it came to
abuse and the Eprivacy draft a few months ago. We can argue till we are
blue in the face within the WG, that might produce some awesome selfies,
but will not solve anything.
Theo
On 29-9-2017 20:55, allison nixon wrote:
> Thank you Andrew, because you have articulated this problem in a much
> better way than I could have. Reputation systems are a fundamental
> part of the ability to connect to the Internet.
>
> re:Jeremy Malcolm's email:
>
> You are describing the current patchwork of reputation systems that
> exist today, and no one disputes that they are optional. However, the
> optionality here is on the part of the network that the domain owner
> wants to reach- a network that is a 3rd party to the entire registrar
> <-> registrant relationship, and the registrant gets no say. Those
> networks would be, for example corporate networks at banks or large
> email providers like Gmail. And if you are an operator of Internet
> infrastructure, you would be very concerned about what those
> reputation systems think of you. Like so many mean girls in
> highschool, they can all very quickly decide they don't want to talk
> to you.
>
> I'm going to mention some specific examples that anyone here can
> replicate on their own, and these are all connectivity problems that
> legitimate users will experience from reputation systems:
>
> * Fire up Tor, and try to visit any website. Chances are, it will
> demand a captcha or block you entirely.
> * From Tor, try to register a new Gmail/Twitter/Facebook account.
> Then, from your home IP, register a new account. One asks for SMS
> verification, and might just block you, while the other does not.
> * Register a new domain, configure everything perfectly to the
> technical specs, host the mailserver on your own machine, and try
> to send email from it to any Yahoo, Gmail, or corporate e-mail
> address.
> * Use any e-mail address to try to strike up a conversation relating
> to male enhancing medications, or certain opiates, and depending
> on specific phrasing, it won't make it past the spam filter.
> Especially on gmail.
> * Register a new domain on any TLDs widely regarded as malicious,
> like .XYZ or .science, host a regular website there, and in the
> first month of that domain's lifespan, see if anyone from
> different corporate networks can reach your website in their browsers
> * Purchase hosting space to host a legitimate website from any
> hosting provided regarded as a "bad" hoster, like Cyberbunker or
> Ecatel. See how many people from corporate networks can reach you
> in their browsers, or receive mail from you
>
> If you are a domain holder and website administrator, you cannot
> opt-out of this. Some blacklist operators will allow you to request
> removal, but they can refuse and often do if the IP or domain is still
> spamming. Other blacklist operators do not allow you to request
> removal, because you weren't specifically blocked, but the confluence
> of datapoints from your infrastructure resulted in the block.
>
> None of this is happening out of a deep seated hatred of privacy, or a
> bizarre desire to censor discussions about specific medications. They
> are the direct result of the abuse problem.
>
> And the abuse problem is so bad, it actually affects the value of
> these domains and IP ranges. It's part of normal practice to perform
> due-dilligence on domains or IP ranges under consideration for
> purchase- specifically reputation due-dilligence. If these reputation
> systems have a material impact on the value of these goods, and are a
> significant factor in their connectivity to the Internet, then we
> should take notice.
>
> Also, w/r/t your example with Let's Encrypt, some blocking systems use
> their company name itself in the cert as a negative factor, especially
> if the domain itself has strings belonging to commonly phished brands.
> It's Let's Encrypt's prerogative to take that approach, but their
> reputation is mud now.
>
>
> On Fri, Sep 29, 2017 at 1:47 PM, Jeremy Malcolm <jmalcolm at eff.org
> <mailto:jmalcolm at eff.org>> wrote:
>
> On 29/9/17 10:29 am, Andrew Sullivan wrote:
> > So, we can't treat reputation service support as something
> that's nice
> > to have. It's necessary for the functioning of domain names on the
> > Internet, and therefore we must provide for it.
>
> Interesting argument, but not convincing to me. The reputation
> systems
> that I'm aware of *are* optional to support. Some mail providers
> subscribe to certain blocklists that others don't, some search
> engines,
> browsers, and browser plugins will flag particular domains that others
> don't, and so on. In the similar context of certificate authorities
> that issue SSL certificates for domains, Let's Encrypt (which EFF is a
> sponsor of) is often asked to refuse to issue certificates for
> particular domains based on reputation, but has decided that
> that's not
> part of its job. Consider the domain amazonaws.com
> <http://amazonaws.com>, which host millions
> of Amazon S3 buckets. There's a lot of phishing content stored under
> that domain from time to time, but assigning a bad reputation to the
> registered owner of amazonaws.com <http://amazonaws.com> would be
> pointless and cause lots of
> collateral damage. It hardly seems that it's an essential part of the
> domain name system to be able to do that.
>
> --
> Jeremy Malcolm
> Senior Global Policy Analyst
> Electronic Frontier Foundation
> https://eff.org
> jmalcolm at eff.org <mailto:jmalcolm at eff.org>
>
> Tel: 415.436.9333 ext 161 <tel:415.436.9333%20ext%20161>
>
> :: Defending Your Rights in the Digital World ::
>
> Public key: https://www.eff.org/files/2016/11/27/key_jmalcolm.txt
> <https://www.eff.org/files/2016/11/27/key_jmalcolm.txt>
> PGP fingerprint: 75D2 4C0D 35EA EA2F 8CA8 8F79 4911 EC4A EDDF 1122
>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org <mailto:gnso-rds-pdp-wg at icann.org>
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
> <https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg>
>
>
>
>
> --
> _________________________________
> Note to self: Pillage BEFORE burning.
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20170929/79b74edf/attachment.html>
More information about the gnso-rds-pdp-wg
mailing list