Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Tobias S. Josefowitz via dev-security-policy]

On Fri, Aug 14, 2020 at 1:53 AM Ronald Crane via dev-security-policy
 wrote:
>
> On 8/13/2020 3:18 PM, Tobias S. Josefowitz via dev-security-policy wrote:
> > So then, assuming we don't know, I don't think it would be appropriate
> > to just wish for the best, task the CAs to do it anyway, with the
> > option of threatening them with distrust later on if they are just!
> > not! good! enough! at it for some reason.
>
> Given the origin of this thread (report of CA issuing cert for obvious
> phishing domain that could be used to cause extensive damage to many
> people), this is rather facile. You seem to be arguing that because some
> edge cases will arise that will cause CAs (and domain registrars) some
> heartburn , we should not require CAs (and domain registrars) to avoid
> issuing certs (and domains) that are obviously useful for phishing.
> Clearly this phisher thought that it was useful to register a "phishy"
> domain rather than a non-"phishy" domain. This is some evidence that
> "phishy" domains are bad. Should CAs and registrars filter them?
> Possibly. I see no reason to discard this idea out of hand.

"phishy" domains being used in itself really do not prove anything, as
long as there are plausible explanations as to why they might be used
that preclude deeper conclusions about them; unless these explanations
can be shown to be false or at least likely to not be true.

In addition, I would contest that the question of phishy vs.
non-phishy is extremely decidable. If I were to make the claim that
https://multiwebportal.hsbc.de/MULTIVERSA-IFP/faces/login/login.jsf
was a phishing site, actually, what other than maybe common sense
tells you it is not? Does that make it an edge case? How do you get
common sense into algorithms? After browsers made it
next-to-impossible to operate a web site without a trusted
certificate, it would change the web *forever*, for the worse, if
certificate cost would be driven up in any significant way.

>
> > Even if examining domains as
> > strings usefully *should* impede phishing, that still leaves the
> > questions of why browsers would have the CAs do that for them as
> > opposed to running the phish-decider themselves.
>
> Maybe because more than one layer of protection is usually better than
> only one? Maybe because registrars and CAs profit from the internet, and
> so they should also help proactively to improve its safety, rather than
> doing only the bare minimum that the BRs can be read to require?

Honestly I would be delighted if CAs collectively were anywhere near
doing the bare minimum that the BRs require. I do not see good reasons
for making CAs the content police, but many reasons against.

> It would be wonderful to have a single sovereign remedy for all the
> internet's problems. We haven't so far, and I doubt very much that we
> ever will (but please write an RFC if you think you do). The physical
> world is awash in whack-a-mole problems, and the internet, to all
> appearances, is the same.

I agree it would be wonderful, but I never suggested there could or
would be one. I am just not looking to waste my time, or anyones, on
efforts that provide no mid- or long term benefit.

Tobi
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Ronald Crane via dev-security-policy]

On 8/13/2020 3:18 PM, Tobias S. Josefowitz via dev-security-policy wrote:

On Thu, Aug 13, 2020 at 11:48 PM Ronald Crane via dev-security-policy
 wrote:

On 8/13/2020 2:25 PM, Tobias S. Josefowitz via dev-security-policy wrote:

Detecting phishing domains by "looking at them as strings" may thus be
futile, and "blocking obvious phishing domains" may be a not so
entertaining but ultimately pointless game of whack a mole for CAs;
and that is especially since there is not that much to actually
suggest that CAs are the best place to whack moles *to prevent users
from being phished* **in their webbrowsers**, which I believe is
actually what we are discussing here anyway.

But it could be that examining domains as strings usefully impedes
(though of course does not eliminate) phishing. Impeding internet
malefactors is _always_ a game of whack-a-mole. If it become harder
successfully to phish with official-appearing domains, phishers will try
something else, and the guardians of the internet (such as there are)
will have to counter that tactic. [1] It is not a question of what's
"the best place" to counter phishing, but whether it's useful for
registrars, CAs, and hosts to do some of the work.

So then, assuming we don't know, I don't think it would be appropriate
to just wish for the best, task the CAs to do it anyway, with the
option of threatening them with distrust later on if they are just!
not! good! enough! at it for some reason.


Given the origin of this thread (report of CA issuing cert for obvious 
phishing domain that could be used to cause extensive damage to many 
people), this is rather facile. You seem to be arguing that because some 
edge cases will arise that will cause CAs (and domain registrars) some 
heartburn , we should not require CAs (and domain registrars) to avoid 
issuing certs (and domains) that are obviously useful for phishing. 
Clearly this phisher thought that it was useful to register a "phishy" 
domain rather than a non-"phishy" domain. This is some evidence that 
"phishy" domains are bad. Should CAs and registrars filter them? 
Possibly. I see no reason to discard this idea out of hand.



Even if examining domains as
strings usefully *should* impede phishing, that still leaves the
questions of why browsers would have the CAs do that for them as
opposed to running the phish-decider themselves.


Maybe because more than one layer of protection is usually better than 
only one? Maybe because registrars and CAs profit from the internet, and 
so they should also help proactively to improve its safety, rather than 
doing only the bare minimum that the BRs can be read to require?



When it comes to whack-a-moling in general, on the internet, I
disagree. Not with the fact that it is maybe predominantly how
problems are attacked necessarily, but I do disagree in playing
whack-a-mole being the best, or even a good enough idea

In the same sense I believe we must seek to make improvements to
internet security that are fundamental, not an arms race, as an arms
race never really gets you far from where you started out anyway but
consumes tremendous resources.


It would be wonderful to have a single sovereign remedy for all the 
internet's problems. We haven't so far, and I doubt very much that we 
ever will (but please write an RFC if you think you do). The physical 
world is awash in whack-a-mole problems, and the internet, to all 
appearances, is the same.


-R


Along those lines, do you know of any research on whether "phishy"
domains are more effective than non-"phishy" ones?

I do not currently have any publicly available and/or sufficiently
"just the data/analysis we needed"-type material to reference,
unfortunately.

Tobi
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

CCADB Updates August 20-24: Policy Document Objects

[Kathleen Wilson via dev-security-policy]

All,

Currently CCADB only allows for one CP URL and one CPS URL per root 
certificate, so we are updating the CCADB to enable many-to-many mapping 
between policy documents and root certificates. One or more policy 
documents may be provided and associated with one or more root 
certificates and policy OIDs. Screenshots showing the changes are here:


https://docs.google.com/document/d/1bhlCSLhdAfLa1J-ek7N3jupLRE630XOjqeNaMQ9lSsU/edit?usp=sharing

We intend to migrate the changes to production August 20 to 24. You 
should be able to use the CCADB during this update, which will impact: 
CA Owner, Root Certificate, Audit Case, Root Inclusion Case.


There will be a one-time migration from existing fields to new Policy 
Document objects.


If you run into problems with the CCADB from August 20 to August 24, 
please try again later. If you run into problems with the CCADB after 
August 24, please send an email to supp...@ccadb.org.


Thanks,
Kathleen
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Paul Walsh via dev-security-policy]

I agree Eric. I apologize for those words, they’re beneath me and everyone else 
who strives for civil debate. It’s a terrible paragraph of text.

- Paul



> On Aug 13, 2020, at 4:09 PM, Eric Mill  wrote:
> 
> On Thu, Aug 13, 2020 at 10:20 AM Paul Walsh via dev-security-policy 
>  > wrote:
> "Every domain should be allowed to have a certificate ***regardless of 
> intent***.”
> 
> They are the most outrageously irresponsible words that I’ve heard in my 
> career on the web since 1996 when I was at AOL, and sadly, I’ve heard them 
> more than once. I just can’t get my head around it. To me, those words are 
> akin to someone saying that masks, Bill Gates, 5G and vaccinations are all 
> dangerous - totally stupid and not in the best interest of society. 
> 
> Calling someone else's contributions on the list "totally stupid" is to me a 
> pretty clear violation of the code of conduct of this list. Maybe you didn't 
> mean to do exactly that, but given that you also called them "outrageously 
> irresponsible" and made a direct comparison to 5G/vaccination conspiracy 
> theories, certainly the totality of your note was unnecessarily harsh.
> 
> 
>  
> 
> - Paul
> 
> 
> 
> > On Aug 13, 2020, at 1:37 AM, Burton mailto:j...@0.me.uk>> 
> > wrote:
> > 
> > Let's Encrypt hasn't done anything wrong here.
> > Let's Encrypt has issued the certificate according to the BR requirements 
> > and their own policies.
> > 
> > Every domain should be allowed to have a certificate regardless of intent. 
> > CAs must not be allowed to act as judges.
> > 
> > Remember, all server certificates have to go into CT log and therefore 
> > easily findable. That can be useful in many situations.  
> > 
> > On Thu, Aug 13, 2020 at 9:15 AM Matthew Hardeman via dev-security-policy 
> >  >  
> >  > >> wrote:
> > It’s actually really simple.
> > 
> > You end up in a position of editorializing.  If you will not provide
> > service for abuse, everyone with a gripe constantly tries to redefine abuse.
> > 
> > 
> > Additionally, this is why positive security indicators are clearly on the
> > way out.  In the not too distant future all sites will be https, so all
> > will require certs.
> > 
> > CAs are not meant to certify that the party you’re communicating with isn’t
> > a monster.  Just that if you are visiting siterunbymonster.com 
> >   > > that you
> > really are speaking with siterunbymonster.com 
> >   > >.
> > 
> > On Wednesday, August 12, 2020, Paul Walsh via dev-security-policy <
> > dev-security-policy@lists.mozilla.org 
> >  
> >  > >> wrote:
> > 
> > > [snip]
> > >
> > > >> So the question now is what the community intends to do to retain trust
> > > >> in a certificate issuer with such an obvious malpractise enabling
> > > >> phishing sites?
> > > >
> > > > TLS is the wrong layer to address phishing at, and this issue has
> > > already been discussed extensively on this list. This domain is already
> > > blocked by Google Safe Browsing, which is the correct layer (the User
> > > Agent) to deal with phishing at. I'd suggest reading through these posts
> > > before continuing so that we don't waste our time rehashing old arguments:
> > > https://groups.google.com/g/mozilla.dev.security.policy/search?q=phishing 
> > > 
> > >  
> > >  > >  
> > > >
> > >
> > >
> > > [PW]  I’m going to ignore technology and phishing here, it’s irrelevant.
> > > What we’re talking about is a company’s anti-abuse policies and how 
> > > they’re
> > > implemented and enforced. It doesn’t matter if they’re selling 
> > > certificates
> > > or apples.
> > >
> > > Companies have a moral obligation (often legal) to **try** to reduce the
> > > risk of their technology/service being abused by people with ill intent. 
> > > If
> > > they try and fail, that’s ok. I don’t think a reasonable person can
> > > disagree with that.
> > >
> > > If Let’s Encrypt, Entrust Datacard, GoDaddy, or whoever, has been informed
> > > that bad people are abusing their service, why wouldn’t they want to stop
> > > that from happening? And why would anyone say that it’s ok for any service
> > > to be abused? I don’t understand.
> > >
> > > - Paul
> > >
> > >
> > >
> > > >
> > > > Jonathan
> > > > ___
> > > > dev-secur

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Eric Mill via dev-security-policy]

On Thu, Aug 13, 2020 at 10:20 AM Paul Walsh via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> "Every domain should be allowed to have a certificate ***regardless of
> intent***.”
>
> They are the most outrageously irresponsible words that I’ve heard in my
> career on the web since 1996 when I was at AOL, and sadly, I’ve heard them
> more than once. I just can’t get my head around it. To me, those words are
> akin to someone saying that masks, Bill Gates, 5G and vaccinations are all
> dangerous - totally stupid and not in the best interest of society.
>

Calling someone else's contributions on the list "totally stupid" is to me
a pretty clear violation of the code of conduct of this list. Maybe you
didn't mean to do exactly that, but given that you also called them
"outrageously irresponsible" and made a direct comparison to 5G/vaccination
conspiracy theories, certainly the totality of your note was unnecessarily
harsh.




>
> - Paul
>
>
>
> > On Aug 13, 2020, at 1:37 AM, Burton  wrote:
> >
> > Let's Encrypt hasn't done anything wrong here.
> > Let's Encrypt has issued the certificate according to the BR
> requirements and their own policies.
> >
> > Every domain should be allowed to have a certificate regardless of
> intent. CAs must not be allowed to act as judges.
> >
> > Remember, all server certificates have to go into CT log and therefore
> easily findable. That can be useful in many situations.
> >
> > On Thu, Aug 13, 2020 at 9:15 AM Matthew Hardeman via dev-security-policy
>  dev-security-policy@lists.mozilla.org>> wrote:
> > It’s actually really simple.
> >
> > You end up in a position of editorializing.  If you will not provide
> > service for abuse, everyone with a gripe constantly tries to redefine
> abuse.
> >
> >
> > Additionally, this is why positive security indicators are clearly on the
> > way out.  In the not too distant future all sites will be https, so all
> > will require certs.
> >
> > CAs are not meant to certify that the party you’re communicating with
> isn’t
> > a monster.  Just that if you are visiting siterunbymonster.com <
> http://siterunbymonster.com/> that you
> > really are speaking with siterunbymonster.com <
> http://siterunbymonster.com/>.
> >
> > On Wednesday, August 12, 2020, Paul Walsh via dev-security-policy <
> > dev-security-policy@lists.mozilla.org  dev-security-policy@lists.mozilla.org>> wrote:
> >
> > > [snip]
> > >
> > > >> So the question now is what the community intends to do to retain
> trust
> > > >> in a certificate issuer with such an obvious malpractise enabling
> > > >> phishing sites?
> > > >
> > > > TLS is the wrong layer to address phishing at, and this issue has
> > > already been discussed extensively on this list. This domain is already
> > > blocked by Google Safe Browsing, which is the correct layer (the User
> > > Agent) to deal with phishing at. I'd suggest reading through these
> posts
> > > before continuing so that we don't waste our time rehashing old
> arguments:
> > >
> https://groups.google.com/g/mozilla.dev.security.policy/search?q=phishing
>  >
> > >
> > >
> > > [PW]  I’m going to ignore technology and phishing here, it’s
> irrelevant.
> > > What we’re talking about is a company’s anti-abuse policies and how
> they’re
> > > implemented and enforced. It doesn’t matter if they’re selling
> certificates
> > > or apples.
> > >
> > > Companies have a moral obligation (often legal) to **try** to reduce
> the
> > > risk of their technology/service being abused by people with ill
> intent. If
> > > they try and fail, that’s ok. I don’t think a reasonable person can
> > > disagree with that.
> > >
> > > If Let’s Encrypt, Entrust Datacard, GoDaddy, or whoever, has been
> informed
> > > that bad people are abusing their service, why wouldn’t they want to
> stop
> > > that from happening? And why would anyone say that it’s ok for any
> service
> > > to be abused? I don’t understand.
> > >
> > > - Paul
> > >
> > >
> > >
> > > >
> > > > Jonathan
> > > > ___
> > > > dev-security-policy mailing list
> > > > dev-security-policy@lists.mozilla.org  dev-security-policy@lists.mozilla.org>
> > > > https://lists.mozilla.org/listinfo/dev-security-policy <
> https://lists.mozilla.org/listinfo/dev-security-policy>
> > >
> > > ___
> > > dev-security-policy mailing list
> > > dev-security-policy@lists.mozilla.org  dev-security-policy@lists.mozilla.org>
> > > https://lists.mozilla.org/listinfo/dev-security-policy <
> https://lists.mozilla.org/listinfo/dev-security-policy>
> > >
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org  dev-security-policy@lists.mozilla.org>
> > https://lists.mozilla.org/listinfo/dev-security-policy <
> https://lists.mozilla.org/listinfo/dev-security-policy>
>
> 

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Tobias S. Josefowitz via dev-security-policy]

On Thu, Aug 13, 2020 at 11:48 PM Ronald Crane via dev-security-policy
 wrote:
>
> On 8/13/2020 2:25 PM, Tobias S. Josefowitz via dev-security-policy wrote:
> > Detecting phishing domains by "looking at them as strings" may thus be
> > futile, and "blocking obvious phishing domains" may be a not so
> > entertaining but ultimately pointless game of whack a mole for CAs;
> > and that is especially since there is not that much to actually
> > suggest that CAs are the best place to whack moles *to prevent users
> > from being phished* **in their webbrowsers**, which I believe is
> > actually what we are discussing here anyway.
>
> But it could be that examining domains as strings usefully impedes
> (though of course does not eliminate) phishing. Impeding internet
> malefactors is _always_ a game of whack-a-mole. If it become harder
> successfully to phish with official-appearing domains, phishers will try
> something else, and the guardians of the internet (such as there are)
> will have to counter that tactic. [1] It is not a question of what's
> "the best place" to counter phishing, but whether it's useful for
> registrars, CAs, and hosts to do some of the work.

So then, assuming we don't know, I don't think it would be appropriate
to just wish for the best, task the CAs to do it anyway, with the
option of threatening them with distrust later on if they are just!
not! good! enough! at it for some reason. Even if examining domains as
strings usefully *should* impede phishing, that still leaves the
questions of why browsers would have the CAs do that for them as
opposed to running the phish-decider themselves.

When it comes to whack-a-moling in general, on the internet, I
disagree. Not with the fact that it is maybe predominantly how
problems are attacked necessarily, but I do disagree in playing
whack-a-mole being the best, or even a good enough idea.

Not to bore anyone with my strange tales, but my goto example is
graylisting (emails), i.e. the practice of refusing email delivery
"the first time". As probably most everybody here knows anyway, at the
time, spammers rarely used actual mail server software to send their
SPAM emails, but simple scripts/programs that would not technically
properly understand the protocol involved in delivering email.
Discarding all emails with a temporary error at first would cause SPAM
to not reach you but real mail by real mailservers being re-sent after
a delay of a few minutes and eventually being accepted by your mail
server. And for a while, it was heaven! SPAM be gone! That is, unless
larger players in the mail game started doing it, too, incentivising
spammers to use real mail servers or otherwise requeue or re-send SPAM
mails. These days, graylisting is useless but gives us inconvenient
delays in email delivery.

It was obvious that graylisting had such an underlying tragedy of the
commons issue, but big players simply used it anyway. Really, they
should not have, for we are now in a worse place because of it than we
would have been without it.

In the same sense I believe we must seek to make improvements to
internet security that are fundamental, not an arms race, as an arms
race never really gets you far from where you started out anyway but
consumes tremendous resources.

> Along those lines, do you know of any research on whether "phishy"
> domains are more effective than non-"phishy" ones?

I do not currently have any publicly available and/or sufficiently
"just the data/analysis we needed"-type material to reference,
unfortunately.

Tobi
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Ronald Crane via dev-security-policy]

On 8/13/2020 2:25 PM, Tobias S. Josefowitz via dev-security-policy wrote:

On Thu, Aug 13, 2020 at 10:31 PM Ronald Crane via dev-security-policy
 wrote:

[...] Registrars (and CAs) are
in excellent positions to impede the use of phishing domains, since they
hand them out (registrars) or issue certificates for them (CAs). [...]

Things are rarely this static. The rise of new, efficient strategies
usually change how a game is played.

Suppose [software] and thus CAs/registrars, really any interested
party, could decide the question "Is X a phishing-domain?" with true
or false reasonably well. What would be the consequence? I for one am
reasonably convinced it is not "no phishing", but instead (this may
sound paradoxical at first) ... phishing will be conducted from
non-phishing-domains instead.

One of the more relevant questions in this regard is what influence to
phishing success "more phishy" domain names have over "less phishy"
domain names. We can probably assume that most phishing operations do
not apply bona fide scientific user testing for phishing success, as
well as that deeper psychological studies are not usually a precursor
to phishing campaigns. A "natural" starting point for one's first
phishing campaign might thus rather be to reproduce the experience of
the mimicked site as close as possible, explaining a drive for "more
phishy" domains to be used in phishing campaigns (if even).

It is not actually a given that "more phishy" domains increase a
phishing campaign's success. For example, you may remember hearing
from the general direction of Google/Chrome, "People have a really
hard time understanding URLs. They’re hard to read, it’s hard to know
which part of them is supposed to be trusted, and in general I don’t
think URLs are working as a good way to convey site identity.". It
also is the case that phishing victims often fall victim to selective
attention - i.e. clicking a link in a malicious mail and entering
information/credentials/... mostly on autopilot without ever even
checking the URL!

Detecting phishing domains by "looking at them as strings" may thus be
futile, and "blocking obvious phishing domains" may be a not so
entertaining but ultimately pointless game of whack a mole for CAs;
and that is especially since there is not that much to actually
suggest that CAs are the best place to whack moles *to prevent users
from being phished* **in their webbrowsers**, which I believe is
actually what we are discussing here anyway.


But it could be that examining domains as strings usefully impedes 
(though of course does not eliminate) phishing. Impeding internet 
malefactors is _always_ a game of whack-a-mole. If it become harder 
successfully to phish with official-appearing domains, phishers will try 
something else, and the guardians of the internet (such as there are) 
will have to counter that tactic. [1] It is not a question of what's 
"the best place" to counter phishing, but whether it's useful for 
registrars, CAs, and hosts to do some of the work.


Along those lines, do you know of any research on whether "phishy" 
domains are more effective than non-"phishy" ones?


-R

[1] Or we could just retire and let the crooks do their worst.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Tobias S. Josefowitz via dev-security-policy]

On Thu, Aug 13, 2020 at 10:31 PM Ronald Crane via dev-security-policy
 wrote:
>
> [...] Registrars (and CAs) are
> in excellent positions to impede the use of phishing domains, since they
> hand them out (registrars) or issue certificates for them (CAs). [...]

Things are rarely this static. The rise of new, efficient strategies
usually change how a game is played.

Suppose [software] and thus CAs/registrars, really any interested
party, could decide the question "Is X a phishing-domain?" with true
or false reasonably well. What would be the consequence? I for one am
reasonably convinced it is not "no phishing", but instead (this may
sound paradoxical at first) ... phishing will be conducted from
non-phishing-domains instead.

One of the more relevant questions in this regard is what influence to
phishing success "more phishy" domain names have over "less phishy"
domain names. We can probably assume that most phishing operations do
not apply bona fide scientific user testing for phishing success, as
well as that deeper psychological studies are not usually a precursor
to phishing campaigns. A "natural" starting point for one's first
phishing campaign might thus rather be to reproduce the experience of
the mimicked site as close as possible, explaining a drive for "more
phishy" domains to be used in phishing campaigns (if even).

It is not actually a given that "more phishy" domains increase a
phishing campaign's success. For example, you may remember hearing
from the general direction of Google/Chrome, "People have a really
hard time understanding URLs. They’re hard to read, it’s hard to know
which part of them is supposed to be trusted, and in general I don’t
think URLs are working as a good way to convey site identity.". It
also is the case that phishing victims often fall victim to selective
attention - i.e. clicking a link in a malicious mail and entering
information/credentials/... mostly on autopilot without ever even
checking the URL!

Detecting phishing domains by "looking at them as strings" may thus be
futile, and "blocking obvious phishing domains" may be a not so
entertaining but ultimately pointless game of whack a mole for CAs;
and that is especially since there is not that much to actually
suggest that CAs are the best place to whack moles *to prevent users
from being phished* **in their webbrowsers**, which I believe is
actually what we are discussing here anyway.

Tobi
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Ronald Crane via dev-security-policy]

On 8/13/2020 1:08 PM, Kurt Roeckx via dev-security-policy wrote:

On Thu, Aug 13, 2020 at 12:43:01PM -0700, Ronald Crane via dev-security-policy 
wrote:

I'd argue that domain registrars, CAs, and hosting services _should_ have an
obligation to deny services to obvious phishing domains. [1] (This is
independent of what (if any) obligations they might currently have.)
Phishing continues to be epidemic. It is not enough that some user agents
attempt to prevent users from following suspected phishing links.

How this obligation should be implemented is an involved question that I'm
not prepared to address. The first step, though, is establishing the
principle that registrars, CAs, and hosting services are not mere pipe
utilities with no obligations to prevent obvious malefactors from injecting
sewage into them.

-R

[1] No, electric utilities, etc., should not also be obligated to deny them
electricity, etc. This would require an impractical (and privacy-invading)
level of investigation. An electric-utility customer does not submit a list
of domain(s) to the electric utility to obtain service. A phisher _does_
submit such a list to its registrar, CA, and host.

It's possible that the host does not know the anything related to
the DNS name, for instance because it rents virtual machines and
assigns them an IP address. The registrar might be hosting the
DNS.


This is a good point, as far as it goes. Requirements need to be 
practical, and should avoid invading privacy. Registrars (and CAs) are 
in excellent positions to impede the use of phishing domains, since they 
hand them out (registrars) or issue certificates for them (CAs). As you 
point out, VPS hosts would have a more difficult time discerning whether 
a given phishing domain is resolving to a VM on their servers. On the 
other hand, most hosts maintain their own DNS, so they practically can 
(and should) weed out known phishing domains, or at least ones that 
their DNS indicates that they also host.


-R



You could also argue that the TLDs should be responsible for it.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Tobias S. Josefowitz via dev-security-policy]

On Thu, Aug 13, 2020 at 8:59 PM Paul Walsh  wrote:
>
>
> > On Aug 13, 2020, at 11:04 AM, Tobias S. Josefowitz via dev-security-policy 
> >  wrote:
> >
> > On Thu, Aug 13, 2020 at 7:20 PM Paul Walsh via dev-security-policy
> >  wrote:
> >>
> >> "Every domain should be allowed to have a certificate ***regardless of 
> >> intent***.”
> >>
> >> They are the most outrageously irresponsible words that I’ve heard in my 
> >> career on the web since 1996 when I was at AOL, and sadly, I’ve heard them 
> >> more than once. I just can’t get my head around it. To me, those words are 
> >> akin to someone saying that masks, Bill Gates, 5G and vaccinations are all 
> >> dangerous - totally stupid and not in the best interest of society.
> >
> > So in your opinion, what is wrong with every domain being allowed to
> > have a certificate? What are your opinions on every domain being
> > allowed TCP connections, IP addresses, its domain itself, and
> > electricity? Is the certificate somehow standing out in your opinion?
> > Why should it? If it was so easy for CAs to detect problematic
> > domains, why isn't it for the domain registries/registrars? Why isn't
> > the domain itself the problem but somehow the certificate is?
>
> [PW] Good questions. Perhaps you could answer mine first? That is, why would 
> a company not want to reduce the risk of their service being abused? Asking 
> me to explain why they should, seems counterproductive. It’s like asking me 
> why I should stop a man from kicking a child in the head. Answer = it’s the 
> right thing to do, even if I don’t have to.

"Asking me to explain why they should, seems counterproductive." -
Well, if that is what you prefer we can of course simply go back to
you being the arbiter of what is and is not to be likened to kicking a
child in the head, and everything else subsequently being black and
white and plain simple. Except of course, you know, for why what even
you must consider to be a lot of people that you ought to think ought
to be subject matter experts under normal circumstances have these
opinions and determinations you so much cannot explain or understand
that you liken them to "someone saying that masks, Bill Gates, 5G and
vaccinations are all dangerous". Or maybe you could just be the
arbiter of that, too.

The answer itself is maybe simple, but definitely not black and white.
It is also multifold. One aspect you might consider is that some might
consider CAs/certs to simply not be the most appropriate/effective
level to stop children from getting kicked in the head at, or actually
some may even consider it a pretty ineffective and inappropriate level
for trying to stop children from getting kicked in the head in
general. To entirely leave the comfy binary space of black and white,
one might also consider whether what is being discussed is actually an
abuse of a CA's services. You probably are back to your mental image
of a child getting its head kicked in by now, so let me work with
that. Who sold that ghastly offender their shoes? Oh the abuse of
service! If only the good merchant knew. Surely we must prevent the
offender from buying shoes again! The grocery stores and restaurants
surely should be informed as well, as the nourishment they sold to the
offender got later on converted into the energy required for
head-kicking! You know, while we're at it, what about the offender's
landlord? Surely having a good night's sleep on the landlord's
property before kicking a child's head in somehow must be abuse of
service?

That turned out surprisingly "cynical". Still, what constitutes abuse
of service, and such one that one has moral implications or strong
incentives to counteract at all or even some leveled cost is a bit of
a spectrum, not everyone will agree where exactly to place certain
things on this spectrum, and maybe that is why you just cannot get
your head around it.

> By deflecting the conversation to other stakeholders you’re participating in 
> “whataboutisim”. Let’s stick to why any company should not try to reduce the 
> risk of abuse.

Yeah or maybe I'm wrong and this is super easy and we even have a word
for it that, whether it applies here or not, allows us not to think
about this anymore. "whataboutism", convenient.

Tobi
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Kurt Roeckx via dev-security-policy]

On Thu, Aug 13, 2020 at 12:43:01PM -0700, Ronald Crane via dev-security-policy 
wrote:
> I'd argue that domain registrars, CAs, and hosting services _should_ have an
> obligation to deny services to obvious phishing domains. [1] (This is
> independent of what (if any) obligations they might currently have.)
> Phishing continues to be epidemic. It is not enough that some user agents
> attempt to prevent users from following suspected phishing links.
> 
> How this obligation should be implemented is an involved question that I'm
> not prepared to address. The first step, though, is establishing the
> principle that registrars, CAs, and hosting services are not mere pipe
> utilities with no obligations to prevent obvious malefactors from injecting
> sewage into them.
> 
> -R
> 
> [1] No, electric utilities, etc., should not also be obligated to deny them
> electricity, etc. This would require an impractical (and privacy-invading)
> level of investigation. An electric-utility customer does not submit a list
> of domain(s) to the electric utility to obtain service. A phisher _does_
> submit such a list to its registrar, CA, and host.

It's possible that the host does not know the anything related to
the DNS name, for instance because it rents virtual machines and
assigns them an IP address. The registrar might be hosting the
DNS.

You could also argue that the TLDs should be responsible for it.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Ronald Crane via dev-security-policy]

I'd argue that domain registrars, CAs, and hosting services _should_ 
have an obligation to deny services to obvious phishing domains. [1] 
(This is independent of what (if any) obligations they might currently 
have.) Phishing continues to be epidemic. It is not enough that some 
user agents attempt to prevent users from following suspected phishing 
links.


How this obligation should be implemented is an involved question that 
I'm not prepared to address. The first step, though, is establishing the 
principle that registrars, CAs, and hosting services are not mere pipe 
utilities with no obligations to prevent obvious malefactors from 
injecting sewage into them.


-R

[1] No, electric utilities, etc., should not also be obligated to deny 
them electricity, etc. This would require an impractical (and 
privacy-invading) level of investigation. An electric-utility customer 
does not submit a list of domain(s) to the electric utility to obtain 
service. A phisher _does_ submit such a list to its registrar, CA, and host.



On 8/13/2020 11:59 AM, Paul Walsh via dev-security-policy wrote:

On Aug 13, 2020, at 11:04 AM, Tobias S. Josefowitz via dev-security-policy 
 wrote:

On Thu, Aug 13, 2020 at 7:20 PM Paul Walsh via dev-security-policy
 wrote:

"Every domain should be allowed to have a certificate ***regardless of 
intent***.”

They are the most outrageously irresponsible words that I’ve heard in my career 
on the web since 1996 when I was at AOL, and sadly, I’ve heard them more than 
once. I just can’t get my head around it. To me, those words are akin to 
someone saying that masks, Bill Gates, 5G and vaccinations are all dangerous - 
totally stupid and not in the best interest of society.

So in your opinion, what is wrong with every domain being allowed to
have a certificate? What are your opinions on every domain being
allowed TCP connections, IP addresses, its domain itself, and
electricity? Is the certificate somehow standing out in your opinion?
Why should it? If it was so easy for CAs to detect problematic
domains, why isn't it for the domain registries/registrars? Why isn't
the domain itself the problem but somehow the certificate is?

[PW] Good questions. Perhaps you could answer mine first? That is, why would a 
company not want to reduce the risk of their service being abused? Asking me to 
explain why they should, seems counterproductive. It’s like asking me why I 
should stop a man from kicking a child in the head. Answer = it’s the right 
thing to do, even if I don’t have to.

“Why isn’t it for the domain registries/registrars”. They should all try to 
reduce the risk of malicious domains being registered, and/or react when 
someone complains about abuse.

When a domain is proven to be used for malicious activity it’s generally taken 
down - at least by companies that play fair. Some types of TLDs are even 
regulated to the point where you can’t buy a domain unless you have your 
identity verified.

By deflecting the conversation to other stakeholders you’re participating in 
“whataboutisim”. Let’s stick to why any company should not try to reduce the 
risk of abuse.

- Paul



Tobi
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Burton via dev-security-policy]

Please don't speculate on my opinion just because I won't answer the
question. That's unprofessional.

So act professional! You know it makes sense!

On Thu, Aug 13, 2020 at 8:04 PM Paul Walsh  wrote:

> Exactly what I thought - you’re either unable to answer the question
> honestly, or you simply do not care about the consequences that arise from
> abuse.
>
>
> On Aug 13, 2020, at 11:19 AM, Burton  wrote:
>
> I'm not going to answer the question because it's not relevant to
> discussion.
>
> On Thu, Aug 13, 2020 at 6:57 PM Paul Walsh  wrote:
>
>> Let me try this. Let’s say a report of child abuse is put forward to a
>> hosting provider, should they ignore it because they “are not the police”?
>> Should companies like Twitter and Facebook do nothing to reduce the risk of
>> bullying, misinformation and other bad things? It’s ok to say you think
>> they should do nothing - but is that in the best interest of internet
>> security and for society?
>>
>> Again, I’m talking about moral obligation, not the law or even standards
>> or best practices. Why would any company not want to reduce the risk of
>> abuse for illegal intent? Just because you don’t have to do something,
>> doesn’t mean you shouldn’t. You can walk past a child being kicked in the
>> head by a strange man if you want, but it’s probably not the right thing to
>> do. You can call the police but by then they could be dead.
>>
>> Where’s your sense of doing the right thing?
>>
>>
>>
>> On Aug 13, 2020, at 10:42 AM, Burton  wrote:
>>
>> I stand by the comments I made earlier and it's the correct terminology.
>> A domain should have a certificate regardless of intent by the user. CAs
>> are not the police and shouldn't act as one. CAs do have to follow policies
>> if the certificate is used in illegal activities, misissued, etc but no CA
>> shouldn't be refusing to issue a certificate for a domain unless for
>> certain reasons.
>>
>> We are talking about DV certificates because that is what Let's Encrypt
>> issues.
>>
>> On Thu, Aug 13, 2020 at 6:20 PM Paul Walsh  wrote:
>>
>>> "Every domain should be allowed to have a certificate ***regardless of
>>> intent***.”
>>>
>>> They are the most outrageously irresponsible words that I’ve heard in my
>>> career on the web since 1996 when I was at AOL, and sadly, I’ve heard them
>>> more than once. I just can’t get my head around it. To me, those words are
>>> akin to someone saying that masks, Bill Gates, 5G and vaccinations are all
>>> dangerous - totally stupid and not in the best interest of society.
>>>
>>> - Paul
>>>
>>>
>>>
>>> On Aug 13, 2020, at 1:37 AM, Burton  wrote:
>>>
>>> Let's Encrypt hasn't done anything wrong here.
>>> Let's Encrypt has issued the certificate according to the BR
>>> requirements and their own policies.
>>>
>>> Every domain should be allowed to have a certificate regardless of
>>> intent. CAs must not be allowed to act as judges.
>>>
>>> Remember, all server certificates have to go into CT log and therefore
>>> easily findable. That can be useful in many situations.
>>>
>>> On Thu, Aug 13, 2020 at 9:15 AM Matthew Hardeman via dev-security-policy
>>>  wrote:
>>>
 It’s actually really simple.

 You end up in a position of editorializing.  If you will not provide
 service for abuse, everyone with a gripe constantly tries to redefine
 abuse.


 Additionally, this is why positive security indicators are clearly on
 the
 way out.  In the not too distant future all sites will be https, so all
 will require certs.

 CAs are not meant to certify that the party you’re communicating with
 isn’t
 a monster.  Just that if you are visiting siterunbymonster.com that you
 really are speaking with siterunbymonster.com.

 On Wednesday, August 12, 2020, Paul Walsh via dev-security-policy <
 dev-security-policy@lists.mozilla.org> wrote:

 > [snip]
 >
 > >> So the question now is what the community intends to do to retain
 trust
 > >> in a certificate issuer with such an obvious malpractise enabling
 > >> phishing sites?
 > >
 > > TLS is the wrong layer to address phishing at, and this issue has
 > already been discussed extensively on this list. This domain is
 already
 > blocked by Google Safe Browsing, which is the correct layer (the User
 > Agent) to deal with phishing at. I'd suggest reading through these
 posts
 > before continuing so that we don't waste our time rehashing old
 arguments:
 >
 https://groups.google.com/g/mozilla.dev.security.policy/search?q=phishing
 >
 >
 > [PW]  I’m going to ignore technology and phishing here, it’s
 irrelevant.
 > What we’re talking about is a company’s anti-abuse policies and how
 they’re
 > implemented and enforced. It doesn’t matter if they’re selling
 certificates
 > or apples.
 >
 > Companies have a moral obligation (often legal) to **try** to reduce
 the
>>

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Paul Walsh via dev-security-policy]

Exactly what I thought - you’re either unable to answer the question honestly, 
or you simply do not care about the consequences that arise from abuse. 


> On Aug 13, 2020, at 11:19 AM, Burton  wrote:
> 
> I'm not going to answer the question because it's not relevant to discussion.
> 
> On Thu, Aug 13, 2020 at 6:57 PM Paul Walsh  > wrote:
> Let me try this. Let’s say a report of child abuse is put forward to a 
> hosting provider, should they ignore it because they “are not the police”? 
> Should companies like Twitter and Facebook do nothing to reduce the risk of 
> bullying, misinformation and other bad things? It’s ok to say you think they 
> should do nothing - but is that in the best interest of internet security and 
> for society? 
> 
> Again, I’m talking about moral obligation, not the law or even standards or 
> best practices. Why would any company not want to reduce the risk of abuse 
> for illegal intent? Just because you don’t have to do something, doesn’t mean 
> you shouldn’t. You can walk past a child being kicked in the head by a 
> strange man if you want, but it’s probably not the right thing to do. You can 
> call the police but by then they could be dead. 
> 
> Where’s your sense of doing the right thing?
> 
> 
> 
>> On Aug 13, 2020, at 10:42 AM, Burton mailto:j...@0.me.uk>> 
>> wrote:
>> 
>> I stand by the comments I made earlier and it's the correct terminology. A 
>> domain should have a certificate regardless of intent by the user. CAs are 
>> not the police and shouldn't act as one. CAs do have to follow policies if 
>> the certificate is used in illegal activities, misissued, etc but no CA 
>> shouldn't be refusing to issue a certificate for a domain unless for certain 
>> reasons.
>> 
>> We are talking about DV certificates because that is what Let's Encrypt 
>> issues. 
>> 
>> On Thu, Aug 13, 2020 at 6:20 PM Paul Walsh > > wrote:
>> "Every domain should be allowed to have a certificate ***regardless of 
>> intent***.”
>> 
>> They are the most outrageously irresponsible words that I’ve heard in my 
>> career on the web since 1996 when I was at AOL, and sadly, I’ve heard them 
>> more than once. I just can’t get my head around it. To me, those words are 
>> akin to someone saying that masks, Bill Gates, 5G and vaccinations are all 
>> dangerous - totally stupid and not in the best interest of society. 
>> 
>> - Paul
>> 
>> 
>> 
>>> On Aug 13, 2020, at 1:37 AM, Burton mailto:j...@0.me.uk>> 
>>> wrote:
>>> 
>>> Let's Encrypt hasn't done anything wrong here.
>>> Let's Encrypt has issued the certificate according to the BR requirements 
>>> and their own policies.
>>> 
>>> Every domain should be allowed to have a certificate regardless of intent. 
>>> CAs must not be allowed to act as judges.
>>> 
>>> Remember, all server certificates have to go into CT log and therefore 
>>> easily findable. That can be useful in many situations.  
>>> 
>>> On Thu, Aug 13, 2020 at 9:15 AM Matthew Hardeman via dev-security-policy 
>>> >> > wrote:
>>> It’s actually really simple.
>>> 
>>> You end up in a position of editorializing.  If you will not provide
>>> service for abuse, everyone with a gripe constantly tries to redefine abuse.
>>> 
>>> 
>>> Additionally, this is why positive security indicators are clearly on the
>>> way out.  In the not too distant future all sites will be https, so all
>>> will require certs.
>>> 
>>> CAs are not meant to certify that the party you’re communicating with isn’t
>>> a monster.  Just that if you are visiting siterunbymonster.com 
>>>  that you
>>> really are speaking with siterunbymonster.com 
>>> .
>>> 
>>> On Wednesday, August 12, 2020, Paul Walsh via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org 
>>> > wrote:
>>> 
>>> > [snip]
>>> >
>>> > >> So the question now is what the community intends to do to retain trust
>>> > >> in a certificate issuer with such an obvious malpractise enabling
>>> > >> phishing sites?
>>> > >
>>> > > TLS is the wrong layer to address phishing at, and this issue has
>>> > already been discussed extensively on this list. This domain is already
>>> > blocked by Google Safe Browsing, which is the correct layer (the User
>>> > Agent) to deal with phishing at. I'd suggest reading through these posts
>>> > before continuing so that we don't waste our time rehashing old arguments:
>>> > https://groups.google.com/g/mozilla.dev.security.policy/search?q=phishing 
>>> > 
>>> >
>>> >
>>> > [PW]  I’m going to ignore technology and phishing here, it’s irrelevant.
>>> > What we’re talking about is a company’s anti-abuse policies and how 
>>> > they’re
>>> > implemented and enforced. It doesn’t matter if they’re selling 
>>> > certificates
>>> > or apples.

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Paul Walsh via dev-security-policy]

> On Aug 13, 2020, at 11:04 AM, Tobias S. Josefowitz via dev-security-policy 
>  wrote:
> 
> On Thu, Aug 13, 2020 at 7:20 PM Paul Walsh via dev-security-policy
>  wrote:
>> 
>> "Every domain should be allowed to have a certificate ***regardless of 
>> intent***.”
>> 
>> They are the most outrageously irresponsible words that I’ve heard in my 
>> career on the web since 1996 when I was at AOL, and sadly, I’ve heard them 
>> more than once. I just can’t get my head around it. To me, those words are 
>> akin to someone saying that masks, Bill Gates, 5G and vaccinations are all 
>> dangerous - totally stupid and not in the best interest of society.
> 
> So in your opinion, what is wrong with every domain being allowed to
> have a certificate? What are your opinions on every domain being
> allowed TCP connections, IP addresses, its domain itself, and
> electricity? Is the certificate somehow standing out in your opinion?
> Why should it? If it was so easy for CAs to detect problematic
> domains, why isn't it for the domain registries/registrars? Why isn't
> the domain itself the problem but somehow the certificate is?

[PW] Good questions. Perhaps you could answer mine first? That is, why would a 
company not want to reduce the risk of their service being abused? Asking me to 
explain why they should, seems counterproductive. It’s like asking me why I 
should stop a man from kicking a child in the head. Answer = it’s the right 
thing to do, even if I don’t have to.

“Why isn’t it for the domain registries/registrars”. They should all try to 
reduce the risk of malicious domains being registered, and/or react when 
someone complains about abuse.

When a domain is proven to be used for malicious activity it’s generally taken 
down - at least by companies that play fair. Some types of TLDs are even 
regulated to the point where you can’t buy a domain unless you have your 
identity verified. 

By deflecting the conversation to other stakeholders you’re participating in 
“whataboutisim”. Let’s stick to why any company should not try to reduce the 
risk of abuse. 

- Paul


> 
> Tobi
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Burton via dev-security-policy]

I'm not going to answer the question because it's not relevant to
discussion.

On Thu, Aug 13, 2020 at 6:57 PM Paul Walsh  wrote:

> Let me try this. Let’s say a report of child abuse is put forward to a
> hosting provider, should they ignore it because they “are not the police”?
> Should companies like Twitter and Facebook do nothing to reduce the risk of
> bullying, misinformation and other bad things? It’s ok to say you think
> they should do nothing - but is that in the best interest of internet
> security and for society?
>
> Again, I’m talking about moral obligation, not the law or even standards
> or best practices. Why would any company not want to reduce the risk of
> abuse for illegal intent? Just because you don’t have to do something,
> doesn’t mean you shouldn’t. You can walk past a child being kicked in the
> head by a strange man if you want, but it’s probably not the right thing to
> do. You can call the police but by then they could be dead.
>
> Where’s your sense of doing the right thing?
>
>
>
> On Aug 13, 2020, at 10:42 AM, Burton  wrote:
>
> I stand by the comments I made earlier and it's the correct terminology. A
> domain should have a certificate regardless of intent by the user. CAs are
> not the police and shouldn't act as one. CAs do have to follow policies if
> the certificate is used in illegal activities, misissued, etc but no CA
> shouldn't be refusing to issue a certificate for a domain unless for
> certain reasons.
>
> We are talking about DV certificates because that is what Let's Encrypt
> issues.
>
> On Thu, Aug 13, 2020 at 6:20 PM Paul Walsh  wrote:
>
>> "Every domain should be allowed to have a certificate ***regardless of
>> intent***.”
>>
>> They are the most outrageously irresponsible words that I’ve heard in my
>> career on the web since 1996 when I was at AOL, and sadly, I’ve heard them
>> more than once. I just can’t get my head around it. To me, those words are
>> akin to someone saying that masks, Bill Gates, 5G and vaccinations are all
>> dangerous - totally stupid and not in the best interest of society.
>>
>> - Paul
>>
>>
>>
>> On Aug 13, 2020, at 1:37 AM, Burton  wrote:
>>
>> Let's Encrypt hasn't done anything wrong here.
>> Let's Encrypt has issued the certificate according to the BR requirements
>> and their own policies.
>>
>> Every domain should be allowed to have a certificate regardless of
>> intent. CAs must not be allowed to act as judges.
>>
>> Remember, all server certificates have to go into CT log and therefore
>> easily findable. That can be useful in many situations.
>>
>> On Thu, Aug 13, 2020 at 9:15 AM Matthew Hardeman via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>>> It’s actually really simple.
>>>
>>> You end up in a position of editorializing.  If you will not provide
>>> service for abuse, everyone with a gripe constantly tries to redefine
>>> abuse.
>>>
>>>
>>> Additionally, this is why positive security indicators are clearly on the
>>> way out.  In the not too distant future all sites will be https, so all
>>> will require certs.
>>>
>>> CAs are not meant to certify that the party you’re communicating with
>>> isn’t
>>> a monster.  Just that if you are visiting siterunbymonster.com that you
>>> really are speaking with siterunbymonster.com.
>>>
>>> On Wednesday, August 12, 2020, Paul Walsh via dev-security-policy <
>>> dev-security-policy@lists.mozilla.org> wrote:
>>>
>>> > [snip]
>>> >
>>> > >> So the question now is what the community intends to do to retain
>>> trust
>>> > >> in a certificate issuer with such an obvious malpractise enabling
>>> > >> phishing sites?
>>> > >
>>> > > TLS is the wrong layer to address phishing at, and this issue has
>>> > already been discussed extensively on this list. This domain is already
>>> > blocked by Google Safe Browsing, which is the correct layer (the User
>>> > Agent) to deal with phishing at. I'd suggest reading through these
>>> posts
>>> > before continuing so that we don't waste our time rehashing old
>>> arguments:
>>> >
>>> https://groups.google.com/g/mozilla.dev.security.policy/search?q=phishing
>>> >
>>> >
>>> > [PW]  I’m going to ignore technology and phishing here, it’s
>>> irrelevant.
>>> > What we’re talking about is a company’s anti-abuse policies and how
>>> they’re
>>> > implemented and enforced. It doesn’t matter if they’re selling
>>> certificates
>>> > or apples.
>>> >
>>> > Companies have a moral obligation (often legal) to **try** to reduce
>>> the
>>> > risk of their technology/service being abused by people with ill
>>> intent. If
>>> > they try and fail, that’s ok. I don’t think a reasonable person can
>>> > disagree with that.
>>> >
>>> > If Let’s Encrypt, Entrust Datacard, GoDaddy, or whoever, has been
>>> informed
>>> > that bad people are abusing their service, why wouldn’t they want to
>>> stop
>>> > that from happening? And why would anyone say that it’s ok for any
>>> service
>>> > to be abused? I don’t understand.
>>> >
>>> > -

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Tobias S. Josefowitz via dev-security-policy]

On Thu, Aug 13, 2020 at 7:20 PM Paul Walsh via dev-security-policy
 wrote:
>
> "Every domain should be allowed to have a certificate ***regardless of 
> intent***.”
>
> They are the most outrageously irresponsible words that I’ve heard in my 
> career on the web since 1996 when I was at AOL, and sadly, I’ve heard them 
> more than once. I just can’t get my head around it. To me, those words are 
> akin to someone saying that masks, Bill Gates, 5G and vaccinations are all 
> dangerous - totally stupid and not in the best interest of society.

So in your opinion, what is wrong with every domain being allowed to
have a certificate? What are your opinions on every domain being
allowed TCP connections, IP addresses, its domain itself, and
electricity? Is the certificate somehow standing out in your opinion?
Why should it? If it was so easy for CAs to detect problematic
domains, why isn't it for the domain registries/registrars? Why isn't
the domain itself the problem but somehow the certificate is?

Tobi
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Paul Walsh via dev-security-policy]

Let me try this. Let’s say a report of child abuse is put forward to a hosting 
provider, should they ignore it because they “are not the police”? Should 
companies like Twitter and Facebook do nothing to reduce the risk of bullying, 
misinformation and other bad things? It’s ok to say you think they should do 
nothing - but is that in the best interest of internet security and for 
society? 

Again, I’m talking about moral obligation, not the law or even standards or 
best practices. Why would any company not want to reduce the risk of abuse for 
illegal intent? Just because you don’t have to do something, doesn’t mean you 
shouldn’t. You can walk past a child being kicked in the head by a strange man 
if you want, but it’s probably not the right thing to do. You can call the 
police but by then they could be dead. 

Where’s your sense of doing the right thing?



> On Aug 13, 2020, at 10:42 AM, Burton  wrote:
> 
> I stand by the comments I made earlier and it's the correct terminology. A 
> domain should have a certificate regardless of intent by the user. CAs are 
> not the police and shouldn't act as one. CAs do have to follow policies if 
> the certificate is used in illegal activities, misissued, etc but no CA 
> shouldn't be refusing to issue a certificate for a domain unless for certain 
> reasons.
> 
> We are talking about DV certificates because that is what Let's Encrypt 
> issues. 
> 
> On Thu, Aug 13, 2020 at 6:20 PM Paul Walsh  > wrote:
> "Every domain should be allowed to have a certificate ***regardless of 
> intent***.”
> 
> They are the most outrageously irresponsible words that I’ve heard in my 
> career on the web since 1996 when I was at AOL, and sadly, I’ve heard them 
> more than once. I just can’t get my head around it. To me, those words are 
> akin to someone saying that masks, Bill Gates, 5G and vaccinations are all 
> dangerous - totally stupid and not in the best interest of society. 
> 
> - Paul
> 
> 
> 
>> On Aug 13, 2020, at 1:37 AM, Burton mailto:j...@0.me.uk>> 
>> wrote:
>> 
>> Let's Encrypt hasn't done anything wrong here.
>> Let's Encrypt has issued the certificate according to the BR requirements 
>> and their own policies.
>> 
>> Every domain should be allowed to have a certificate regardless of intent. 
>> CAs must not be allowed to act as judges.
>> 
>> Remember, all server certificates have to go into CT log and therefore 
>> easily findable. That can be useful in many situations.  
>> 
>> On Thu, Aug 13, 2020 at 9:15 AM Matthew Hardeman via dev-security-policy 
>> > > wrote:
>> It’s actually really simple.
>> 
>> You end up in a position of editorializing.  If you will not provide
>> service for abuse, everyone with a gripe constantly tries to redefine abuse.
>> 
>> 
>> Additionally, this is why positive security indicators are clearly on the
>> way out.  In the not too distant future all sites will be https, so all
>> will require certs.
>> 
>> CAs are not meant to certify that the party you’re communicating with isn’t
>> a monster.  Just that if you are visiting siterunbymonster.com 
>>  that you
>> really are speaking with siterunbymonster.com .
>> 
>> On Wednesday, August 12, 2020, Paul Walsh via dev-security-policy <
>> dev-security-policy@lists.mozilla.org 
>> > wrote:
>> 
>> > [snip]
>> >
>> > >> So the question now is what the community intends to do to retain trust
>> > >> in a certificate issuer with such an obvious malpractise enabling
>> > >> phishing sites?
>> > >
>> > > TLS is the wrong layer to address phishing at, and this issue has
>> > already been discussed extensively on this list. This domain is already
>> > blocked by Google Safe Browsing, which is the correct layer (the User
>> > Agent) to deal with phishing at. I'd suggest reading through these posts
>> > before continuing so that we don't waste our time rehashing old arguments:
>> > https://groups.google.com/g/mozilla.dev.security.policy/search?q=phishing 
>> > 
>> >
>> >
>> > [PW]  I’m going to ignore technology and phishing here, it’s irrelevant.
>> > What we’re talking about is a company’s anti-abuse policies and how they’re
>> > implemented and enforced. It doesn’t matter if they’re selling certificates
>> > or apples.
>> >
>> > Companies have a moral obligation (often legal) to **try** to reduce the
>> > risk of their technology/service being abused by people with ill intent. If
>> > they try and fail, that’s ok. I don’t think a reasonable person can
>> > disagree with that.
>> >
>> > If Let’s Encrypt, Entrust Datacard, GoDaddy, or whoever, has been informed
>> > that bad people are abusing their service, why wouldn’t they want to stop
>> > that from happening? And why would anyone say that it’s ok for any service
>> > to be abused? I do

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Burton via dev-security-policy]

I stand by the comments I made earlier and it's the correct terminology. A
domain should have a certificate regardless of intent by the user. CAs are
not the police and shouldn't act as one. CAs do have to follow policies if
the certificate is used in illegal activities, misissued, etc but no CA
shouldn't be refusing to issue a certificate for a domain unless for
certain reasons.

We are talking about DV certificates because that is what Let's Encrypt
issues.

On Thu, Aug 13, 2020 at 6:20 PM Paul Walsh  wrote:

> "Every domain should be allowed to have a certificate ***regardless of
> intent***.”
>
> They are the most outrageously irresponsible words that I’ve heard in my
> career on the web since 1996 when I was at AOL, and sadly, I’ve heard them
> more than once. I just can’t get my head around it. To me, those words are
> akin to someone saying that masks, Bill Gates, 5G and vaccinations are all
> dangerous - totally stupid and not in the best interest of society.
>
> - Paul
>
>
>
> On Aug 13, 2020, at 1:37 AM, Burton  wrote:
>
> Let's Encrypt hasn't done anything wrong here.
> Let's Encrypt has issued the certificate according to the BR requirements
> and their own policies.
>
> Every domain should be allowed to have a certificate regardless of intent.
> CAs must not be allowed to act as judges.
>
> Remember, all server certificates have to go into CT log and therefore
> easily findable. That can be useful in many situations.
>
> On Thu, Aug 13, 2020 at 9:15 AM Matthew Hardeman via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> It’s actually really simple.
>>
>> You end up in a position of editorializing.  If you will not provide
>> service for abuse, everyone with a gripe constantly tries to redefine
>> abuse.
>>
>>
>> Additionally, this is why positive security indicators are clearly on the
>> way out.  In the not too distant future all sites will be https, so all
>> will require certs.
>>
>> CAs are not meant to certify that the party you’re communicating with
>> isn’t
>> a monster.  Just that if you are visiting siterunbymonster.com that you
>> really are speaking with siterunbymonster.com.
>>
>> On Wednesday, August 12, 2020, Paul Walsh via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> wrote:
>>
>> > [snip]
>> >
>> > >> So the question now is what the community intends to do to retain
>> trust
>> > >> in a certificate issuer with such an obvious malpractise enabling
>> > >> phishing sites?
>> > >
>> > > TLS is the wrong layer to address phishing at, and this issue has
>> > already been discussed extensively on this list. This domain is already
>> > blocked by Google Safe Browsing, which is the correct layer (the User
>> > Agent) to deal with phishing at. I'd suggest reading through these posts
>> > before continuing so that we don't waste our time rehashing old
>> arguments:
>> >
>> https://groups.google.com/g/mozilla.dev.security.policy/search?q=phishing
>> >
>> >
>> > [PW]  I’m going to ignore technology and phishing here, it’s irrelevant.
>> > What we’re talking about is a company’s anti-abuse policies and how
>> they’re
>> > implemented and enforced. It doesn’t matter if they’re selling
>> certificates
>> > or apples.
>> >
>> > Companies have a moral obligation (often legal) to **try** to reduce the
>> > risk of their technology/service being abused by people with ill
>> intent. If
>> > they try and fail, that’s ok. I don’t think a reasonable person can
>> > disagree with that.
>> >
>> > If Let’s Encrypt, Entrust Datacard, GoDaddy, or whoever, has been
>> informed
>> > that bad people are abusing their service, why wouldn’t they want to
>> stop
>> > that from happening? And why would anyone say that it’s ok for any
>> service
>> > to be abused? I don’t understand.
>> >
>> > - Paul
>> >
>> >
>> >
>> > >
>> > > Jonathan
>> > > ___
>> > > dev-security-policy mailing list
>> > > dev-security-policy@lists.mozilla.org
>> > > https://lists.mozilla.org/listinfo/dev-security-policy
>> >
>> > ___
>> > dev-security-policy mailing list
>> > dev-security-policy@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-security-policy
>> >
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Paul Walsh via dev-security-policy]

You’re way off topic.. I purposely didn’t bring up indicators or phishing or 
certifying anything. Those things have absolutely nothing to do with my 
message. You’re joining dots that don’t exist in my conversation. Rather than 
do that, refer only to the words I write - not what I might be thinking or 
trying to say.

Saying that companies shouldn’t try to reduce abuse of any kind because some 
people will want to redefine what abuse isn’t logical in my opinion. 

Please answer this to help me understand your perspective - should CAs ignore 
all other instances of abuse? If your answer is no, it would help a great deal, 
if you can explain why some kinds of abuse are good and some kinds of abuse are 
ok and who gets to decide either way?

- Paul

> On Aug 13, 2020, at 1:15 AM, Matthew Hardeman  wrote:
> 
> It’s actually really simple.
> 
> You end up in a position of editorializing.  If you will not provide service 
> for abuse, everyone with a gripe constantly tries to redefine abuse.
> 
> 
> Additionally, this is why positive security indicators are clearly on the way 
> out.  In the not too distant future all sites will be https, so all will 
> require certs.
> 
> CAs are not meant to certify that the party you’re communicating with isn’t a 
> monster.  Just that if you are visiting siterunbymonster.com 
>  that you really are speaking with 
> siterunbymonster.com .
> 
> On Wednesday, August 12, 2020, Paul Walsh via dev-security-policy 
>  > wrote:
> [snip]
> 
> >> So the question now is what the community intends to do to retain trust 
> >> in a certificate issuer with such an obvious malpractise enabling 
> >> phishing sites?
> > 
> > TLS is the wrong layer to address phishing at, and this issue has already 
> > been discussed extensively on this list. This domain is already blocked by 
> > Google Safe Browsing, which is the correct layer (the User Agent) to deal 
> > with phishing at. I'd suggest reading through these posts before continuing 
> > so that we don't waste our time rehashing old arguments: 
> > https://groups.google.com/g/mozilla.dev.security.policy/search?q=phishing 
> > 
> 
> 
> [PW]  I’m going to ignore technology and phishing here, it’s irrelevant. What 
> we’re talking about is a company’s anti-abuse policies and how they’re 
> implemented and enforced. It doesn’t matter if they’re selling certificates 
> or apples.
> 
> Companies have a moral obligation (often legal) to **try** to reduce the risk 
> of their technology/service being abused by people with ill intent. If they 
> try and fail, that’s ok. I don’t think a reasonable person can disagree with 
> that. 
> 
> If Let’s Encrypt, Entrust Datacard, GoDaddy, or whoever, has been informed 
> that bad people are abusing their service, why wouldn’t they want to stop 
> that from happening? And why would anyone say that it’s ok for any service to 
> be abused? I don’t understand. 
> 
> - Paul
> 
> 
> 
> > 
> > Jonathan
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org 
> > 
> > https://lists.mozilla.org/listinfo/dev-security-policy 
> > 
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org 
> 
> https://lists.mozilla.org/listinfo/dev-security-policy 
> 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Paul Walsh via dev-security-policy]

"Every domain should be allowed to have a certificate ***regardless of 
intent***.”

They are the most outrageously irresponsible words that I’ve heard in my career 
on the web since 1996 when I was at AOL, and sadly, I’ve heard them more than 
once. I just can’t get my head around it. To me, those words are akin to 
someone saying that masks, Bill Gates, 5G and vaccinations are all dangerous - 
totally stupid and not in the best interest of society. 

- Paul



> On Aug 13, 2020, at 1:37 AM, Burton  wrote:
> 
> Let's Encrypt hasn't done anything wrong here.
> Let's Encrypt has issued the certificate according to the BR requirements and 
> their own policies.
> 
> Every domain should be allowed to have a certificate regardless of intent. 
> CAs must not be allowed to act as judges.
> 
> Remember, all server certificates have to go into CT log and therefore easily 
> findable. That can be useful in many situations.  
> 
> On Thu, Aug 13, 2020 at 9:15 AM Matthew Hardeman via dev-security-policy 
>  > wrote:
> It’s actually really simple.
> 
> You end up in a position of editorializing.  If you will not provide
> service for abuse, everyone with a gripe constantly tries to redefine abuse.
> 
> 
> Additionally, this is why positive security indicators are clearly on the
> way out.  In the not too distant future all sites will be https, so all
> will require certs.
> 
> CAs are not meant to certify that the party you’re communicating with isn’t
> a monster.  Just that if you are visiting siterunbymonster.com 
>  that you
> really are speaking with siterunbymonster.com .
> 
> On Wednesday, August 12, 2020, Paul Walsh via dev-security-policy <
> dev-security-policy@lists.mozilla.org 
> > wrote:
> 
> > [snip]
> >
> > >> So the question now is what the community intends to do to retain trust
> > >> in a certificate issuer with such an obvious malpractise enabling
> > >> phishing sites?
> > >
> > > TLS is the wrong layer to address phishing at, and this issue has
> > already been discussed extensively on this list. This domain is already
> > blocked by Google Safe Browsing, which is the correct layer (the User
> > Agent) to deal with phishing at. I'd suggest reading through these posts
> > before continuing so that we don't waste our time rehashing old arguments:
> > https://groups.google.com/g/mozilla.dev.security.policy/search?q=phishing 
> > 
> >
> >
> > [PW]  I’m going to ignore technology and phishing here, it’s irrelevant.
> > What we’re talking about is a company’s anti-abuse policies and how they’re
> > implemented and enforced. It doesn’t matter if they’re selling certificates
> > or apples.
> >
> > Companies have a moral obligation (often legal) to **try** to reduce the
> > risk of their technology/service being abused by people with ill intent. If
> > they try and fail, that’s ok. I don’t think a reasonable person can
> > disagree with that.
> >
> > If Let’s Encrypt, Entrust Datacard, GoDaddy, or whoever, has been informed
> > that bad people are abusing their service, why wouldn’t they want to stop
> > that from happening? And why would anyone say that it’s ok for any service
> > to be abused? I don’t understand.
> >
> > - Paul
> >
> >
> >
> > >
> > > Jonathan
> > > ___
> > > dev-security-policy mailing list
> > > dev-security-policy@lists.mozilla.org 
> > > 
> > > https://lists.mozilla.org/listinfo/dev-security-policy 
> > > 
> >
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org 
> > 
> > https://lists.mozilla.org/listinfo/dev-security-policy 
> > 
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org 
> 
> https://lists.mozilla.org/listinfo/dev-security-policy 
> 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Burton via dev-security-policy]

Let's Encrypt hasn't done anything wrong here.
Let's Encrypt has issued the certificate according to the BR requirements
and their own policies.

Every domain should be allowed to have a certificate regardless of intent.
CAs must not be allowed to act as judges.

Remember, all server certificates have to go into CT log and therefore
easily findable. That can be useful in many situations.

On Thu, Aug 13, 2020 at 9:15 AM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> It’s actually really simple.
>
> You end up in a position of editorializing.  If you will not provide
> service for abuse, everyone with a gripe constantly tries to redefine
> abuse.
>
>
> Additionally, this is why positive security indicators are clearly on the
> way out.  In the not too distant future all sites will be https, so all
> will require certs.
>
> CAs are not meant to certify that the party you’re communicating with isn’t
> a monster.  Just that if you are visiting siterunbymonster.com that you
> really are speaking with siterunbymonster.com.
>
> On Wednesday, August 12, 2020, Paul Walsh via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > [snip]
> >
> > >> So the question now is what the community intends to do to retain
> trust
> > >> in a certificate issuer with such an obvious malpractise enabling
> > >> phishing sites?
> > >
> > > TLS is the wrong layer to address phishing at, and this issue has
> > already been discussed extensively on this list. This domain is already
> > blocked by Google Safe Browsing, which is the correct layer (the User
> > Agent) to deal with phishing at. I'd suggest reading through these posts
> > before continuing so that we don't waste our time rehashing old
> arguments:
> >
> https://groups.google.com/g/mozilla.dev.security.policy/search?q=phishing
> >
> >
> > [PW]  I’m going to ignore technology and phishing here, it’s irrelevant.
> > What we’re talking about is a company’s anti-abuse policies and how
> they’re
> > implemented and enforced. It doesn’t matter if they’re selling
> certificates
> > or apples.
> >
> > Companies have a moral obligation (often legal) to **try** to reduce the
> > risk of their technology/service being abused by people with ill intent.
> If
> > they try and fail, that’s ok. I don’t think a reasonable person can
> > disagree with that.
> >
> > If Let’s Encrypt, Entrust Datacard, GoDaddy, or whoever, has been
> informed
> > that bad people are abusing their service, why wouldn’t they want to stop
> > that from happening? And why would anyone say that it’s ok for any
> service
> > to be abused? I don’t understand.
> >
> > - Paul
> >
> >
> >
> > >
> > > Jonathan
> > > ___
> > > dev-security-policy mailing list
> > > dev-security-policy@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

[Matthew Hardeman via dev-security-policy]

It’s actually really simple.

You end up in a position of editorializing.  If you will not provide
service for abuse, everyone with a gripe constantly tries to redefine abuse.


Additionally, this is why positive security indicators are clearly on the
way out.  In the not too distant future all sites will be https, so all
will require certs.

CAs are not meant to certify that the party you’re communicating with isn’t
a monster.  Just that if you are visiting siterunbymonster.com that you
really are speaking with siterunbymonster.com.

On Wednesday, August 12, 2020, Paul Walsh via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> [snip]
>
> >> So the question now is what the community intends to do to retain trust
> >> in a certificate issuer with such an obvious malpractise enabling
> >> phishing sites?
> >
> > TLS is the wrong layer to address phishing at, and this issue has
> already been discussed extensively on this list. This domain is already
> blocked by Google Safe Browsing, which is the correct layer (the User
> Agent) to deal with phishing at. I'd suggest reading through these posts
> before continuing so that we don't waste our time rehashing old arguments:
> https://groups.google.com/g/mozilla.dev.security.policy/search?q=phishing
>
>
> [PW]  I’m going to ignore technology and phishing here, it’s irrelevant.
> What we’re talking about is a company’s anti-abuse policies and how they’re
> implemented and enforced. It doesn’t matter if they’re selling certificates
> or apples.
>
> Companies have a moral obligation (often legal) to **try** to reduce the
> risk of their technology/service being abused by people with ill intent. If
> they try and fail, that’s ok. I don’t think a reasonable person can
> disagree with that.
>
> If Let’s Encrypt, Entrust Datacard, GoDaddy, or whoever, has been informed
> that bad people are abusing their service, why wouldn’t they want to stop
> that from happening? And why would anyone say that it’s ok for any service
> to be abused? I don’t understand.
>
> - Paul
>
>
>
> >
> > Jonathan
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy