<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
Good info Allison, <br>
<br>
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. <br>
<br>
Still, we are at the crossroads where privacy protection services
are a factor when it comes to risk scores and a lot more.<br>
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.<br>
<br>
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. <br>
<br>
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. <br>
<br>
Theo <br>
<br>
<br>
<div class="moz-cite-prefix">On 29-9-2017 20:55, allison nixon
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACLR7wKLpTR3TFPeqi6GTmomfk=jF3c7_LXHCP-vzkARp1Q88w@mail.gmail.com">
<div dir="ltr">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.
<div><br>
</div>
<div>re:Jeremy Malcolm's email:</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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:</div>
<div>
<ul>
<li>Fire up Tor, and try to visit any website. Chances are,
it will demand a captcha or block you entirely. </li>
<li>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. </li>
<li>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.</li>
<li>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.</li>
<li>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</li>
<li>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</li>
</ul>
<div>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.</div>
</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Fri, Sep 29, 2017 at 1:47 PM, Jeremy
Malcolm <span dir="ltr"><<a href="mailto:jmalcolm@eff.org"
target="_blank" moz-do-not-send="true">jmalcolm@eff.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">On 29/9/17 10:29 am, Andrew Sullivan wrote:<br>
> So, we can't treat reputation service support as
something that's nice<br>
> to have. It's necessary for the functioning of
domain names on the<br>
> Internet, and therefore we must provide for it.<br>
<br>
</span>Interesting argument, but not convincing to me. The
reputation systems<br>
that I'm aware of *are* optional to support. Some mail
providers<br>
subscribe to certain blocklists that others don't, some
search engines,<br>
browsers, and browser plugins will flag particular domains
that others<br>
don't, and so on. In the similar context of certificate
authorities<br>
that issue SSL certificates for domains, Let's Encrypt
(which EFF is a<br>
sponsor of) is often asked to refuse to issue certificates
for<br>
particular domains based on reputation, but has decided that
that's not<br>
part of its job. Consider the domain <a
href="http://amazonaws.com" rel="noreferrer"
target="_blank" moz-do-not-send="true">amazonaws.com</a>,
which host millions<br>
of Amazon S3 buckets. There's a lot of phishing content
stored under<br>
that domain from time to time, but assigning a bad
reputation to the<br>
registered owner of <a href="http://amazonaws.com"
rel="noreferrer" target="_blank" moz-do-not-send="true">amazonaws.com</a>
would be pointless and cause lots of<br>
collateral damage. It hardly seems that it's an essential
part of the<br>
domain name system to be able to do that.<br>
<br>
--<br>
Jeremy Malcolm<br>
Senior Global Policy Analyst<br>
Electronic Frontier Foundation<br>
<a href="https://eff.org" rel="noreferrer" target="_blank"
moz-do-not-send="true">https://eff.org</a><br>
<a href="mailto:jmalcolm@eff.org" moz-do-not-send="true">jmalcolm@eff.org</a><br>
<br>
Tel: <a href="tel:415.436.9333%20ext%20161"
value="+14154369333" moz-do-not-send="true">415.436.9333
ext 161</a><br>
<br>
:: Defending Your Rights in the Digital World ::<br>
<br>
Public key: <a
href="https://www.eff.org/files/2016/11/27/key_jmalcolm.txt"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.eff.org/files/<wbr>2016/11/27/key_jmalcolm.txt</a><br>
PGP fingerprint: 75D2 4C0D 35EA EA2F 8CA8 8F79 4911 EC4A
EDDF 1122<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
gnso-rds-pdp-wg mailing list<br>
<a href="mailto:gnso-rds-pdp-wg@icann.org"
moz-do-not-send="true">gnso-rds-pdp-wg@icann.org</a><br>
<a
href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://mm.icann.org/mailman/<wbr>listinfo/gnso-rds-pdp-wg</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="gmail_signature" data-smartmail="gmail_signature">_________________________________<br>
Note to self: Pillage BEFORE burning.</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
gnso-rds-pdp-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></pre>
</blockquote>
<br>
</body>
</html>