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

[nathali...--- via dev-security-policy]

Apologies for triggering such a controversial discussion. Just to be clear, my 
original post was not directed at discrediting any practice of a CA, but rather 
to trigger discussion about what is/should be/will be the best option to solve 
the issue.

> >> Why not just do the right thing? 
> > The domain you send your emails from is, as far as I can tell, at 
> > least as much in breach of Germany's "Telemediengesetz" ("Tele media 
> > law") as a CA is of identity theft.
> That would raise a very involved question of international jurisdiction 
> that was not raised by the original question of a U.S. CA under the law 
> of a U.S. state. 
> > ...Why even think about whether the CA is legally bound by a German
> > court-order when it could ***just do the right thing***?
> Please tell us, counseller, what "the right thing" is? I think there's a 
> big difference between 
> 
> (1) a CA refusing to take action following a report that one of its 
> certs is being used to perpetrate fraud (my hypo); and 
> 
> (2) a CA taking no pre-emptive action regarding a supposed technical 
> violation of a labelling requirement for which no specific section of 
> law has been cited, and which "violation" makes no real difference to 
> how anyone interacts with the "violating" site or in the services (if 
> any) that it provides to people who visit it (your hypo). 

For post-issuing, this may be a solution in my opinion for damage containment. 
But, and that is what bothers me more, it is a reactive measure. Shouldn't we 
think and aim at  a preventive measure by solving the root cause?
Trust into such a phishing site is given by the DV certificate issued. The 
basis for issuing is that the ownership of the domain is confirmed. So, any 
user on the Internet is suggested to trust that the domain really has been 
verified as being the domain it is. And here, I guess the discrepancy happens. 
Domain validation means only it is controlled by whoever registered it. No 
statement on validation of any other attributes is given, although it is 
suggested that if it has "credit-suisse" in the name, it should belong to this 
financial institution. So, the root cuase in my opinion is that the validation 
method suggests more than it is. So as a solution we either make that clear to 
the user (what she/he gets trustwise with this certificate; certainly not easy 
to do) or we think about improving the validation so that the user gets 
validation for whats she/he expects to get which probably means that only OV or 
EV or QWAC will be needed, or we work on how we revoke such certificates in a
 n efficient manner (probably by an according change in the BRGs).

- Nathalie
___
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/14/2020 2:14 PM, Tobias S. Josefowitz via dev-security-policy wrote:

On Fri, Aug 14, 2020 at 10:32 PM Ronald Crane via dev-security-policy
 wrote:


Why not just do the right thing?

The domain you send your emails from is, as far as I can tell, at
least as much in breach of Germany's "Telemediengesetz" ("Tele media
law") as a CA is of identity theft.
That would raise a very involved question of international jurisdiction 
that was not raised by the original question of a U.S. CA under the law 
of a U.S. state.

...Why even think about whether the CA is legally bound by a German
court-order when it could ***just do the right thing***?


Please tell us, counseller, what "the right thing" is? I think there's a 
big difference between


(1) a CA refusing to take action following a report that one of its 
certs is being used to perpetrate fraud (my hypo); and


(2) a CA taking no pre-emptive action regarding a supposed technical 
violation of a labelling requirement for which no specific section of 
law has been cited, and which "violation" makes no real difference to 
how anyone interacts with the "violating" site or in the services (if 
any) that it provides to people who visit it (your hypo).


Certain acts (such as fraud) are malum in se -- intrinsically injurious 
to the operation of an ordered society. That (at least at common law -- 
I don't know what continental law says on this topic) is a critical 
distinction between the two hypos.


-R

P.S. Again, not legal advice...consult your favorite lawyer for that.


___
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/14/2020 2:38 PM, Matthias van de Meent via dev-security-policy wrote:

On Fri, 14 Aug 2020, 21:52 Ronald Crane via dev-security-policy, <
dev-security-policy@lists.mozilla.org> wrote:


It could raise legal issues for a CA to refuse to revoke an obvious
phishing domain after notice that it is fraudulent, or at least after
notice that it's actually being used to defraud.

For example, Calif. Penal Code s.530.5 says:

 (d)(2) Every person who, with _actual knowledge_ that the personal
 identifying information, as defined in subdivision (b) of Section
 530.55, of a specific person will be used to commit a violation of
 subsection (a), sells, transfers, _or conveys_ that same personal
 identifying information is guilty of a public offense

(emphasis added). Does a CA "convey[]" "personal identifying
information" if it leaves unrevoked, after notice, a certificate for a
domain that is being used to phish bank credentials?

Subdivision (a), in turn, makes it an public offense to "willfully
obtain[] personal identifying information,  as defined in subdivision
(b) of Section 530.55, of another person, and use[] that information for
any unlawful purpose...".  (This would seem to cover actual phishing of
bank credentials).


IANAL, but please note that you quote "personal identifying information [...]
of another person".
AIUI, to trigger clause (d)(2) for the CA, the phishing party would _at the
very least_ need to have obtained a valid certificate (and keypair, to use
this certificate) for a domain that they do not own / are authorized to
control (= PII of another person). ...


That is certainly a valid point, though I am arguing that the "personal 
identifying information...of another person" here is the substance of 
the domain name (usually the SLD). In my hypo, the phisher chooses the 
SLD precisely because it's identical to the SLD that "the other person" 
uses to conduct business, for the purpose of defrauding that person's 
customers. As in the SLD of "bankofamerica.com" vs 
"bankofamerica.someridiculousTLD".


It strikes me that there is also a cybersquatting issue here, but it's 
been ages since I've looked at that.


-R
___
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

[Matthias van de Meent via dev-security-policy]

On Fri, 14 Aug 2020, 21:52 Ronald Crane via dev-security-policy, <
dev-security-policy@lists.mozilla.org> wrote:

> It could raise legal issues for a CA to refuse to revoke an obvious
> phishing domain after notice that it is fraudulent, or at least after
> notice that it's actually being used to defraud.
>
> For example, Calif. Penal Code s.530.5 says:
>
> (d)(2) Every person who, with _actual knowledge_ that the personal
> identifying information, as defined in subdivision (b) of Section
> 530.55, of a specific person will be used to commit a violation of
> subsection (a), sells, transfers, _or conveys_ that same personal
> identifying information is guilty of a public offense
>
> (emphasis added). Does a CA "convey[]" "personal identifying
> information" if it leaves unrevoked, after notice, a certificate for a
> domain that is being used to phish bank credentials?
>
> Subdivision (a), in turn, makes it an public offense to "willfully
> obtain[] personal identifying information,  as defined in subdivision
> (b) of Section 530.55, of another person, and use[] that information for
> any unlawful purpose...".  (This would seem to cover actual phishing of
> bank credentials).
>

IANAL, but please note that you quote "personal identifying information [...]
of another person".
AIUI, to trigger clause (d)(2) for the CA, the phishing party would _at the
very least_ need to have obtained a valid certificate (and keypair, to use
this certificate) for a domain that they do not own / are authorized to
control (= PII of another person). The revocation of such certificates is
already covered by the first listing in BR section 4.9.1.1.


This is not legal advice. Consult your favorite lawyer for that.
>
> -R
>

Same here,


-Matthias
___
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 Fri, Aug 14, 2020 at 10:32 PM Ronald Crane via dev-security-policy
 wrote:

> If a CA "conveys" (or "transfers") by not revoking after notice (which
> gives "actual knowledge" that the "specific person" (that is, the legit
> site) is being impersonated), then there seems to be a problem. If a CA
> does not revoke after notice of actual fraudulent use, they have a bad
> fact pattern to defend. "Your honor! The BRs don't require it!" is
> pretty weak tea in this context.

Neither a domain name nor a public key seems to be Section 530.55
style personal identifying information of a specific person. Also your
interpretation of "conveys" and "transfers" really seems contrived to
me.

> Why not just do the right thing?

The domain you send your emails from is, as far as I can tell, at
least as much in breach of Germany's "Telemediengesetz" ("Tele media
law") as a CA is of identity theft. [It doesn't really matter here,
but the Telemediengesetz requires an imprint to be published on the
homepage identifying the person or legal entity responsible)]. German
law also has a somewhat wide-ranging concept in who might be an
accessory to a breach of law. Such accessories can easily be
court-ordered to end their participation in the breach of law, or sued
for damages if they don't upon becoming aware of them. Complicated
stuff, but then the details are not important.

Now what if someone actually got a court-order against a CA used by
the domain you send your mails from? It would be a German court-order,
presumably, so would it really bind the CA used, assuming it's not in
Germany? Are there treaties in place between Germany and the
jurisdiction a CA used by the domain you send mails from where local
courts would help enforce the German court-order in this matter? Why
even think about whether the CA is legally bound by a German
court-order when it could ***just do the right thing***?

As I said before, I am not a lawyer. This is just to serve as an
illustration of what may lurk down the direction you are exploring
here, and how it is maybe simply not as clear as you think it is what
"the right thing" is and how to "do" it.

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/14/2020 1:17 PM, Tobias S. Josefowitz via dev-security-policy wrote:

On Fri, Aug 14, 2020 at 9:52 PM Ronald Crane via dev-security-policy
 wrote:

It could raise legal issues for a CA to refuse to revoke an obvious
phishing domain after notice that it is fraudulent, or at least after
notice that it's actually being used to defraud.

For example, Calif. Penal Code s.530.5 says:

 (d)(2) Every person who, with _actual knowledge_ that the personal
 identifying information, as defined in subdivision (b) of Section
 530.55, of a specific person will be used to commit a violation of
 subsection (a), sells, transfers, _or conveys_ that same personal
 identifying information is guilty of a public offense

(emphasis added). Does a CA "convey[]" "personal identifying
information" if it leaves unrevoked, after notice, a certificate for a
domain that is being used to phish bank credentials?

IANAL. Yet, that sounds at best very far-fetched regarding the
conveying, and then even if, the "actual knowledge" regarding the
"specific person" would not have been the case at the time of the very
constructed "conveying".


If a CA "conveys" (or "transfers") by not revoking after notice (which 
gives "actual knowledge" that the "specific person" (that is, the legit 
site) is being impersonated), then there seems to be a problem. If a CA 
does not revoke after notice of actual fraudulent use, they have a bad 
fact pattern to defend. "Your honor! The BRs don't require it!" is 
pretty weak tea in this context.


Why not just do the right thing?

-R
___
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 Fri, Aug 14, 2020 at 9:52 PM Ronald Crane via dev-security-policy
 wrote:
>
> It could raise legal issues for a CA to refuse to revoke an obvious
> phishing domain after notice that it is fraudulent, or at least after
> notice that it's actually being used to defraud.
>
> For example, Calif. Penal Code s.530.5 says:
>
> (d)(2) Every person who, with _actual knowledge_ that the personal
> identifying information, as defined in subdivision (b) of Section
> 530.55, of a specific person will be used to commit a violation of
> subsection (a), sells, transfers, _or conveys_ that same personal
> identifying information is guilty of a public offense
>
> (emphasis added). Does a CA "convey[]" "personal identifying
> information" if it leaves unrevoked, after notice, a certificate for a
> domain that is being used to phish bank credentials?

IANAL. Yet, that sounds at best very far-fetched regarding the
conveying, and then even if, the "actual knowledge" regarding the
"specific person" would not have been the case at the time of the very
constructed "conveying".

> This seems like iffy territory.

That however is very true, just take a few minutes to sit back, relax,
and appreciate how many things are perfectly legal maybe in most
jurisdictions of the world, but not in all of them. Maybe we should
not pry open Pandora's box here.

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]

It could raise legal issues for a CA to refuse to revoke an obvious 
phishing domain after notice that it is fraudulent, or at least after 
notice that it's actually being used to defraud.


For example, Calif. Penal Code s.530.5 says:

   (d)(2) Every person who, with _actual knowledge_ that the personal
   identifying information, as defined in subdivision (b) of Section
   530.55, of a specific person will be used to commit a violation of
   subsection (a), sells, transfers, _or conveys_ that same personal
   identifying information is guilty of a public offense

(emphasis added). Does a CA "convey[]" "personal identifying 
information" if it leaves unrevoked, after notice, a certificate for a 
domain that is being used to phish bank credentials?


Subdivision (a), in turn, makes it an public offense to "willfully 
obtain[] personal identifying information,  as defined in subdivision 
(b) of Section 530.55, of another person, and use[] that information for 
any unlawful purpose...".  (This would seem to cover actual phishing of 
bank credentials).


And section 530.55 says:

   (a) For purposes of this chapter, "person" means a natural
   person,...organization...company, corporation

   (b) For purposes of this chapter, "personal identifying information"
   means any _name_, ..._unique electronic data including information
   identification number assigned to that person, address or routing
   code, telecommunications identifying information...or an equivalent
   form of identification._

(emphasis added). In this context "telecommunications identifying 
information...or an equivalent form of identification" would seem to 
include a phishy domain.


This seems like iffy territory.

This is not legal advice. Consult your favorite lawyer for that.

-R

___
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 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

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
> > > > ___
> > > > 

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 

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 

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

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

[Paul Walsh via dev-security-policy]

[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

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

[Jonathan Rudenberg via dev-security-policy]

On Tue, Aug 11, 2020, at 15:20, nathali...--- via dev-security-policy wrote:

> The problem report was answered by Let's Encrpyt with an answer 
> indicating that they will continue to issue and hence are not following 
> BRG 4.2.1. requiring them to have procedures in place for such High 
> Risk Certificate Requests.

Not revoking this certificate and continuing issuance does not indicate that 
they are not complying with the Baseline Requirements.

> The CA SHALL develop, maintain, and implement documented procedures that 
> identify and require additional verification activity for High Risk 
> Certificate Requests prior to the Certificate’s approval, as reasonably 
> necessary to ensure that such requests are properly verified under these 
> Requirements.

The issuance of a specific certificate doesn't indicate that they don't have 
the required "documented procedures" in place. There is no language in the 
Baseline Requirements or Mozilla Requirements that require specific criteria or 
procedures for High Risk Certificate Requests. However, since their CA software 
is open source, we can confirm that they do in fact have procedures implemented 
for High Risk Certificate Requests: 
https://github.com/letsencrypt/boulder/blob/e2c8f6743a3c3539a75ee59b8e3c152e069a7a1e/policy/pa.go#L53-L73

The Baseline Requirements and Mozilla Requirements also do not have any 
requirements to revoke or block future issuance in cases like this, so I don't 
see any "malpractise" or policy violations here.

> 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

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

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

[nathali...--- via dev-security-policy]

In the last days Let's Encrypt continued to issue certificates to a fraudulent 
website. The certificates of concern can be seen here:  
https://crt.sh/?Identity=entry.credit-suisse.services 

The problem report was answered by Let's Encrpyt with an answer indicating that 
they will continue to issue and hence are not following BRG 4.2.1. requiring 
them to have procedures in place for such High Risk Certificate Requests. 
 
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?


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