On the value of EV

[Ryan Sleevi]

Recently, researchers have been looking into the value proposition of EV certificates, and more importantly, how easy it is to obtain certificates that may confuse or mislead users - a purpose that EV is supposedly intended to avoid.

James Burton was able to obtain a certificate for "Identity Verified", as described in https://0.me.uk/ev-phishing/ , which is a fully valid and legal EV certificate, but which can otherwise confuse users.

Today, Ian Carroll disclosed how easy he was able to get a certificate for "Stripe, Inc", registered within the US, and being granted the full EV treatment as the 'legitimate' stripe.com. He's written up the explanation at https://stripe.ian.sh/

I suppose this is both a question for policy and for Mozilla - given the ability to provide accurate-but-misleading information in EV certificates, and the effect it has on the URL bar (the lone trusted space for security information), has any consideration been given to removing or deprecating EV certificates?

[Tim Hollebeek]

It turns out that the CA/Browser Validation working group is currently
looking into how to address these issues, in order to tighten up validation
in these cases. We discussed it a bit last Thursday, and will be continuing
the discussion on the 21st.

If anyone has any good ideas, we'd be more than happy to hear them.

-Tim

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+tim.hollebeek=digice...@lists.mozilla
.org] On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, December 11, 2017 12:01 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: On the value of EV

Recently, researchers have been looking into the value proposition of EV
certificates, and more importantly, how easy it is to obtain certificates
that may confuse or mislead users - a purpose that EV is supposedly intended
to avoid.

James Burton was able to obtain a certificate for "Identity Verified", as
described in

https://clicktime.symantec.com/a/1/UMvfjhjcKci8WaOicVRiVWm_NzyoAX0Pc2qXQBXjH
nE=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02
VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11B
ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7
DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%3D%3D&u=htt
ps%3A%2F%2F0.me.uk%2Fev-phishing%2F , which is a fully valid and legal EV

certificate, but which can otherwise confuse users.

Today, Ian Carroll disclosed how easy he was able to get a certificate for
"Stripe, Inc", registered within the US, and being granted the full EV
treatment as the 'legitimate' stripe.com. He's written up the explanation at

https://clicktime.symantec.com/a/1/Fahzn1Xee7EnTLqF7kqdnVFVklYxzLF8hiDkGN7kU
UM=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02
VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11B
ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7
DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%3D%3D&u=htt
ps%3A%2F%2Fstripe.ian.sh%2F

I suppose this is both a question for policy and for Mozilla - given the
ability to provide accurate-but-misleading information in EV certificates,
and the effect it has on the URL bar (the lone trusted space for security
information), has any consideration been given to removing or deprecating EV
certificates?

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://clicktime.symantec.com/a/1/kDDKlZK0leEPqVUm7AaittNvNX0qYVu4pVG8QnvM6
8E=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02
VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11B
ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7
DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%3D%3D&u=htt
ps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

[Paul Wouters]

On Mon, 11 Dec 2017, Ryan Sleevi via dev-security-policy wrote:

> I suppose this is both a question for policy and for Mozilla - given the ability to provide accurate-but-misleading information in EV certificates, and the effect it has on the URL bar (the lone trusted space for security information), has any consideration been given to removing or deprecating EV certificates?

Fix the EV GUI not to hide the hostname part of the URL, and retain the
display of the company name.

Unless you are going to invent a new namespace, there isn't anything to
gain by removing EV. It's still better than not having EV, even if it
is a second race to the bottom after the DV race.

Paul

[Alex Gaynor]

Can you share what the working group has been brainstorming on?

Near as I can tell, this is a validly issued EV cert, for a valid KY
company. If "Stripe, Inc of Kentucky" were in a distinct industry from this
Stripe there wouldn't even be a trademark claim (I'm not a lawyer, etc.).

Lest anyone think "well, they should be able to tell if this was being used
maliciously", there's no reason a clever attacker couldn't make a fake
landing page for their fake Stripe, Inc, while sending phishing emails that
point to various other URLs, which show unrelated phishing contents.

Alex

> I suppose this is both a question for policy and for Mozilla - given the
> ability to provide accurate-but-misleading information in EV certificates,
> and the effect it has on the URL bar (the lone trusted space for security
> information), has any consideration been given to removing or deprecating
> EV
> certificates?

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://clicktime.symantec.com/a/1/kDDKlZK0leEPqVUm7AaittNvNX0qYV
> u4pVG8QnvM6
> 8E=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_
> QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
> FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-
> 3508LqFwnMSFygeNRYQQYxQ02
> VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUV
> KrPl_t11B
> ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7N
> ZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
> yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlv
> ecDTXHAOGDfgwKo7
> DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%
> 3D%3D&u=htt
> ps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>
>

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 2:14 PM, Tim Hollebeek <tim.ho...@digicert.com>

wrote:

>
> It turns out that the CA/Browser Validation working group is currently
> looking into how to address these issues, in order to tighten up validation
> in these cases. We discussed it a bit last Thursday, and will be
> continuing
> the discussion on the 21st.
>
> If anyone has any good ideas, we'd be more than happy to hear them.
>
> -Tim
>

Hi Tim,

The proposal to 'tighten up validation' seems to presume that those
certificates should not have been issued in the first place, and/or rules
should exist to prohibit such issuance. I'm not sure that would
appropriately reflect the "Intent" of EV (to provide legally identifying
information about the certificate holder). Further, I think the questions
Ian raised in his post are rather fundamental to the value proposition of
granting EV any particular UI, and so I'm curious to hear from Mozilla
whether they are comfortable granting external control over their critical
security surface (the URL bar)

As you know, Chrome is still evaluating the value of EV having special UI,
as discussed in past CA/Browser Forum meetings [1][2]. This doesn't opine
on the value of EV to the ecosystem overall, but rather, the value in
browsers distinguishing such certificates or affording specialized UI.

[1]
https://cabforum.org/2016/02/17/2016-02-17-minutes-of-f2f-meeting-37/#Google
[2]
https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Google

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 2:23 PM, Paul Wouters via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Mon, 11 Dec 2017, Ryan Sleevi via dev-security-policy wrote:
>

> I suppose this is both a question for policy and for Mozilla - given the
>> ability to provide accurate-but-misleading information in EV certificates,
>> and the effect it has on the URL bar (the lone trusted space for security
>> information), has any consideration been given to removing or deprecating
>> EV certificates?
>>
>

> Fix the EV GUI not to hide the hostname part of the URL, and retain the
> display of the company name.
>

This is already the behaviour of Firefox. Perhaps you were thinking of
Safari?

> Unless you are going to invent a new namespace, there isn't anything to
> gain by removing EV. It's still better than not having EV, even if it
> is a second race to the bottom after the DV race.
>

I'm not sure I understand this remark. EV is an attempt to invent a new
namespace (through corporate jurisdiction of incorporation). As presently
implemented in Firefox (and other browsers), this namespace granularity is
limited to the country, although the example from Ian highlights the
long-known issue that the namespace for corporate jurisdiction can be much
finer grained - down to city/municipality, in some cases. Unless all of
that information is presented to the user at the same precedence of the URL
bar, and with the same understanding about what the 'expected' values
should be, then there is no additional value derived from that presentation
at all.

[Matthew Hardeman]

That's not clear at all.

Someone other than the famous Stripe, Inc. has -- without violating BR
rules or requirements -- a proper EV certificate showing (correctly) entity
name Stripe, Inc.

That this exists suggests that EV is harmful if the target is normal
everyday people. Making the abstract normal person more confident that the
website behind that entity name is that other particular famous Stripe is
harmful.

Just my thoughts...

Matt Hardeman

On Mon, Dec 11, 2017 at 1:23 PM, Paul Wouters via dev-security-policy <

dev-secur...@lists.mozilla.org> wrote:

> On Mon, 11 Dec 2017, Ryan Sleevi via dev-security-policy wrote:
>
> I suppose this is both a question for policy and for Mozilla - given the
>> ability to provide accurate-but-misleading information in EV certificates,
>> and the effect it has on the URL bar (the lone trusted space for security
>> information), has any consideration been given to removing or deprecating
>> EV certificates?
>>
>
> Fix the EV GUI not to hide the hostname part of the URL, and retain the
> display of the company name.
>

> Unless you are going to invent a new namespace, there isn't anything to
> gain by removing EV. It's still better than not having EV, even if it
> is a second race to the bottom after the DV race.
>

> Paul

[Matthew Hardeman]

(Reposting as I accidentally replied directly to OP ).

Part of this discussion will necessarily have to include who the intended
and potential beneficiaries of EV certificate status are:

1. Is it the common web end user? If so, EV either needs to go or be
massively changed.
2. Is it for the kind of person who could properly investigate corporate
documents and structure AND would have some benefit in knowing that a given
website is asserted by cryptographic signature to be affiliated to a given
real world entity? If so, few changes are needed but several could be
helpful.

The short version of the Stripe, Inc. case above is that the certificate is
totally valid. Someone created a Stripe, Inc. in Kentucky and got the
certificate, properly, for that. It's totally valid and normal for two
different entities, totally unrelated, to be able to have the same business
name in the United States. It happens all the time.

The scope of name exclusivity in the US, and, indeed, in many jurisdictions
is really quite complicated. The EV green bar display goes so far as to
name the Country of the legal entity but goes no further. Even the
certificate details only specify the registered address and name of a given
entity. The format and its elements make no attempt to identify the
official scope of the name or the authority. That would be something to
address. Who is the registry? What's the scope of that registry's name
exclusivity? Who is the REGISTRAR who interceded to create that
registration. These are often different and often revealing.

There are different directions to take solutions which address some of the
concerns for EV status, but if there's a definitive position that EV
handling -- if handling is to be special -- should only be granted in cases
which benefit the broad-sweeping general public WebPKI end user, then all
of these solutions (if effective) will involve some form of:

1. Requirement in objective/mostly objective terms of notoriety of
client. High note-worthiness of EV applicant would be required.
Validation procedures would modify to ensure that the commonly held "note
worthy" entity is actually the one applying.

2. Stability of entity records. The corporate structure is known and has
been unchanged, perhaps for a year or more. Effectively, no EV for
startups or any new or restructured entity that can't show lengthly and
broad claim to the name.

3. Pragmatically, to limit scope, probably would need to modify EV
applicant process and qualifications to require that the applicant hold a
national level registered trademark / servicemark and that the name
included in the certificate be strongly associated with this/these.

I could run down to an Alabama court house and establish in minutes the
necessary documentation to get just about any EV certificate name I want.
That's a problem, if the above doesn't happen and you still want EV to be
useful to regular end users.

If EV status is intended for business, asset management, and legal
professionals, then it's easier. Add mandatory validated parameters for
official registry from which the data was referenced (ex: Alabama Secretary
of State, Corporations Division) as well as originally filed for
registration (ex: State of AL, County of Jefferson Probate Court). Give
the docket or document numbers or entity registration number as appropriate
for each of these. Attempt to construe a scope of exclusivity and indicate
that in lieu of just Country in the green bar.

Thanks,

Matt Hardeman

[Tim Hollebeek]

Happy to share the details.



We only had about 10 minutes on the agenda, so the discussion hasn’t been too detailed so far (there is still a lot of fallout from CAA that is dominating many validation discussions). There was a general consensus that companies with intentionally misleading names, and companies that are recently created shell companies solely for the purpose of obtaining a certificate should not be able to get an EV certificate.



Exactly what additional validation or rules might help with that problem, while not unnecessarily burdening legitimate businesses will require more time and discussion, which is why if anyone has good ideas, I’d love to hear them.



-Tim

From: Alex Gaynor [mailto:aga...@mozilla.com]
Sent: Monday, December 11, 2017 12:26 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Ryan Sleevi <ry...@sleevi.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: On the value of EV



Can you share what the working group has been brainstorming on?



Near as I can tell, this is a validly issued EV cert, for a valid KY company. If "Stripe, Inc of Kentucky" were in a distinct industry from this Stripe there wouldn't even be a trademark claim (I'm not a lawyer, etc.).



Lest anyone think "well, they should be able to tell if this was being used maliciously", there's no reason a clever attacker couldn't make a fake landing page for their fake Stripe, Inc, while sending phishing emails that point to various other URLs, which show unrelated phishing contents.



Alex

On Mon, Dec 11, 2017 at 2:14 PM, Tim Hollebeek via dev-security-policy <dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org> > wrote:


It turns out that the CA/Browser Validation working group is currently
looking into how to address these issues, in order to tighten up validation
in these cases. We discussed it a bit last Thursday, and will be continuing
the discussion on the 21st.

If anyone has any good ideas, we'd be more than happy to hear them.

-Tim

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+tim.hollebeek <mailto:dev-security-policy-bounces%2Btim.hollebeek> =digice...@lists.mozilla
.org] On Behalf Of Ryan Sleevi via dev-security-policy
Sent: Monday, December 11, 2017 12:01 PM
To: mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: On the value of EV

Recently, researchers have been looking into the value proposition of EV
certificates, and more importantly, how easy it is to obtain certificates
that may confuse or mislead users - a purpose that EV is supposedly intended
to avoid.

James Burton was able to obtain a certificate for "Identity Verified", as
described in

https://clicktime.symantec.com/a/1/UMvfjhjcKci8WaOicVRiVWm_NzyoAX0Pc2qXQBXjH <https://clicktime.symantec.com/a/1/UMvfjhjcKci8WaOicVRiVWm_NzyoAX0Pc2qXQBXjHnE=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtLFaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11BctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9VtyCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7>

nE=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02
VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11B
ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7
DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%3D%3D&u=htt

ps%3A%2F%2F0.me.uk <http://2F0.me.uk> %2Fev-phishing%2F , which is a fully valid and legal EV

certificate, but which can otherwise confuse users.

Today, Ian Carroll disclosed how easy he was able to get a certificate for
"Stripe, Inc", registered within the US, and being granted the full EV

treatment as the 'legitimate' stripe.com <http://stripe.com> . He's written up the explanation at
https://clicktime.symantec.com/a/1/Fahzn1Xee7EnTLqF7kqdnVFVklYxzLF8hiDkGN7kU <https://clicktime.symantec.com/a/1/Fahzn1Xee7EnTLqF7kqdnVFVklYxzLF8hiDkGN7kUUM=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtLFaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11BctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9VtyCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7>

UM=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02
VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11B
ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7
DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%3D%3D&u=htt

ps%3A%2F%2Fstripe.ian.sh <http://2Fstripe.ian.sh> %2F

I suppose this is both a question for policy and for Mozilla - given the
ability to provide accurate-but-misleading information in EV certificates,
and the effect it has on the URL bar (the lone trusted space for security
information), has any consideration been given to removing or deprecating EV
certificates?

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://clicktime.symantec.com/a/1/kDDKlZK0leEPqVUm7AaittNvNX0qYVu4pVG8QnvM6 <https://clicktime.symantec.com/a/1/kDDKlZK0leEPqVUm7AaittNvNX0qYVu4pVG8QnvM68E=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtLFaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11BctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9VtyCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7>

8E=?d=4GxSxTMvs_XrCwnblzpDidRZeFwt4_CpS4UexlQ_QRYfMXTACGlU9KcLjcIV2AmJ-zJBtL
FaDv8U-F04Ie90QpnF8tK-ybyXlpLa2rqOTh9r7oBUmc1owCqd-3508LqFwnMSFygeNRYQQYxQ02
VE4dkt0wPLETCFlfrS7_BHqaxO5w6BikwFhE-nrVLpigRJAQlM14eULh56NL69CQWUVKrPl_t11B
ctsMNiFHBfSsJIZQ-82hU2y9cXYXVjjBcvic6aPKW8LtO7NZsXhDeVSSC6deBqC3QcR-K_Rip9Vt
yCDvYUoxnv9khLm24jo5M6xium8o1FiYEr5jvgfuRegHNRO1YAs1qwAmURlvecDTXHAOGDfgwKo7
DsjmEeyhtB5pylwlXn6YvgPEnUzvJZqqgb-lNj1M94f08yucGQETp7UZXA19h3qg%3D%3D&u=htt

ps%3A%2F%2Flists.mozilla.org <http://2Flists.mozilla.org> %2Flistinfo%2Fdev-security-policy

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Jonathan Rudenberg]

> On Dec 11, 2017, at 14:14, Tim Hollebeek via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
>
> It turns out that the CA/Browser Validation working group is currently
> looking into how to address these issues, in order to tighten up validation
> in these cases.

This isn’t a validation issue. Both certificates were properly validated and have correct (but very misleading information) in them. Business entity names are not unique, so it’s not clear how validation changes could address this.

I think it makes a lot of sense to get rid of the EV UI, as it can be trivially used to present misleading information to users in the most security-critical browser UI area. My understanding is that the research done to date shows that EV does not help users defend against phishing attacks, it does not influence decision making, and users don’t understand or are confused by EV.

Jonathan

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 2:31 PM, Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> (Reposting as I accidentally replied directly to OP ).
>
> Part of this discussion will necessarily have to include who the intended
> and potential beneficiaries of EV certificate status are:
>
> 1. Is it the common web end user? If so, EV either needs to go or be
> massively changed.
> 2. Is it for the kind of person who could properly investigate corporate
> documents and structure AND would have some benefit in knowing that a given
> website is asserted by cryptographic signature to be affiliated to a given
> real world entity? If so, few changes are needed but several could be
> helpful.
>

Agreed that these are potential goals, which is why I tried to provide a
specific and narrow set of questions, so that we can avoid ratholing on
those.

Specifically, I was asking about 1, as that is what comes from the UI
treatment. A conclusion of 2 implies the UI should go.

> 1. Requirement in objective/mostly objective terms of notoriety of
> client. High note-worthiness of EV applicant would be required.
> Validation procedures would modify to ensure that the commonly held "note
> worthy" entity is actually the one applying.
>

Naturally, this falls apart at "Internet scale"

> 2. Stability of entity records. The corporate structure is known and has
> been unchanged, perhaps for a year or more. Effectively, no EV for
> startups or any new or restructured entity that can't show lengthly and
> broad claim to the name.
>

This seems to create a bifurcated Internet which is not "open and
accessible" (per Item 2 on the Mozilla Manifesto). Namely, if it favors or
empowers incumbents, and the only ability to be trusted by users is to 'sit
around' so you have a stable corporate identity, then we're not creating a
neutral, open platform.

> If EV status is intended for business, asset management, and legal
> professionals, then it's easier. Add mandatory validated parameters for
> official registry from which the data was referenced (ex: Alabama Secretary
> of State, Corporations Division) as well as originally filed for
> registration (ex: State of AL, County of Jefferson Probate Court). Give
> the docket or document numbers or entity registration number as appropriate
> for each of these. Attempt to construe a scope of exclusivity and indicate
> that in lieu of just Country in the green bar.
>

The EV guidelines already encompass this information - the jurisdiction
fields, combined with the serialNumber, which is the unique identifying
number for that entity within the jurisdictional registry, which is unique
per jurisdictional boundary.

[Tim Hollebeek]

Nobody is disputing the fact that these certificates were legitimate given the rules that exist today.

However, I don't believe "technically correct, but intentionally misleading" information should be included in certificates. The question is how best to accomplish that.

-Tim

-----Original Message-----
From: Jonathan Rudenberg [mailto:jona...@titanous.com]
Sent: Monday, December 11, 2017 12:34 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Ryan Sleevi <ry...@sleevi.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: On the value of EV

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 2:39 PM, Tim Hollebeek <tim.ho...@digicert.com>
wrote:

> Nobody is disputing the fact that these certificates were legitimate given
> the rules that exist today.
>
> However, I don't believe "technically correct, but intentionally
> misleading" information should be included in certificates. The question
> is how best to accomplish that.
>
> -Tim
>

Note: Jonathan did not mention "intentionally" misleading (instead

"properly validated and have correct (but very misleading information) in

them". Similarly, I noted that it was providing "accurate-but-misleading".

Unless the CA/Browser Forum has determined a way to discern intent (which
would be a profound breakthrough in and of itself), we cannot and should
not consider intent, and must merely evaluate based on result. As such, the
only way to remedy this information is to deny one or more parties the
ability to obtain certificates that correctly and accurately reflect their
organizational information, which is nominally the value proposition of EV
certificates. Unless we're willing to redefine EV certificates as being
something other tied to the legal identifier, I don't believe it's fair or
beneficial to suggest we can resolve this through validation means.

To that end, given the inherent confusion that results from legal
identities - and, again, this is a fully valid legal identity being used -
I raised the question as to whether or not it should be given the same UI
treatment as the unambiguous, fully qualified URL.

One option, as noted, is to fully qualify the organization information, if
users are to be expected to recognize the nuances of legal identities (and
why so many sites seem to be in Delaware and Nevada). However, that seems
exceptionally user-hostile and to ignore countless research studies, so
another option would be to consider removing the (unqualified) legal
identity from the address bar.

[Tim Hollebeek]

Certainly, as you noted, one option is to improve EV beyond simply being an assertion of legal existence.



-Tim

From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Monday, December 11, 2017 12:46 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Jonathan Rudenberg <jona...@titanous.com>; Ryan Sleevi <ry...@sleevi.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: On the value of EV







On Mon, Dec 11, 2017 at 2:39 PM, Tim Hollebeek <tim.ho...@digicert.com <mailto:tim.ho...@digicert.com> > wrote:

Nobody is disputing the fact that these certificates were legitimate given the rules that exist today.

However, I don't believe "technically correct, but intentionally misleading" information should be included in certificates. The question is how best to accomplish that.

-Tim



Note: Jonathan did not mention "intentionally" misleading (instead "properly validated and have correct (but very misleading information) in them". Similarly, I noted that it was providing "accurate-but-misleading".



Unless the CA/Browser Forum has determined a way to discern intent (which would be a profound breakthrough in and of itself), we cannot and should not consider intent, and must merely evaluate based on result. As such, the only way to remedy this information is to deny one or more parties the ability to obtain certificates that correctly and accurately reflect their organizational information, which is nominally the value proposition of EV certificates. Unless we're willing to redefine EV certificates as being something other tied to the legal identifier, I don't believe it's fair or beneficial to suggest we can resolve this through validation means.



To that end, given the inherent confusion that results from legal identities - and, again, this is a fully valid legal identity being used - I raised the question as to whether or not it should be given the same UI treatment as the unambiguous, fully qualified URL.



One option, as noted, is to fully qualify the organization information, if users are to be expected to recognize the nuances of legal identities (and why so many sites seem to be in Delaware and Nevada). However, that seems exceptionally user-hostile and to ignore countless research studies, so another option would be to consider removing the (unqualified) legal identity from the address bar.




-----Original Message-----
From: Jonathan Rudenberg [mailto:jona...@titanous.com <mailto:jona...@titanous.com> ]
Sent: Monday, December 11, 2017 12:34 PM
To: Tim Hollebeek <tim.ho...@digicert.com <mailto:tim.ho...@digicert.com> >
Cc: Ryan Sleevi <ry...@sleevi.com <mailto:ry...@sleevi.com> >; mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org>

Subject: Re: On the value of EV

[Adam Caudill]

> However, I don't believe "technically correct, but intentionally
misleading" information should be included in certificates. The question
is how best to accomplish that.

How would you determine what's misleading, and what isn't? As mentioned,
the Stripe, Inc of Kentucky could present an image of a legitimate company
in a completely different field as the better known Stripe, Inc of Delaware
(which, most people would associate with California based on where their
offices are). There's no way to know what the intended future use of the
company is, or just how legitimate the intentions of those behind it are.

In a larger sense, and to the question that Ryan raises, what value has the
EV UI treatment added? In the case of Safari, it's clear that it's actually
quite harmful to a normal user. In the case of Firefox, it's likely that
the UI treatment would add confusion as a result of the legitimately issued
certificate to Stripe, Inc of Kentucky. Instead of adding value, adding
some type of assurance, all that the UI treatment has done is make it more
likely that the user will make an unfortunate mistake - a mistake they
likely wouldn't have made if they were focused on the URL instead of the
business name displayed.

Adding the state would likely add no value, as most users would have no
idea where a business is incorporated - and this is often different from
where their offices are known to be, adding an additional level of
confusion. There is also the unrelated DBA issue, where the certificate is
issued to a company name that isn't familiar to the user, which is yet
another way the UI treatment adds confusion.

While EV validation rules could be changed to make the rules more strict,
locking new businesses out, all it does is slow the process down - it
doesn't actually prevent name collisions which could be harmful.

I have long felt that the EV UI treatment is unwarranted, and I still do
today. Removing the treatment from EV certificates, as it doesn't actually
add enough value to be justified, still seems to be the correct decision to
me.

[Matthew Hardeman]

On Mon, Dec 11, 2017 at 1:37 PM, Ryan Sleevi <ry...@sleevi.com> wrote:

>
>
> On Mon, Dec 11, 2017 at 2:31 PM, Matthew Hardeman via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
>> (Reposting as I accidentally replied directly to OP ).
>>
>> Part of this discussion will necessarily have to include who the intended
>> and potential beneficiaries of EV certificate status are:
>>
>> 1. Is it the common web end user? If so, EV either needs to go or be
>> massively changed.
>> 2. Is it for the kind of person who could properly investigate corporate
>> documents and structure AND would have some benefit in knowing that a
>> given
>> website is asserted by cryptographic signature to be affiliated to a given
>> real world entity? If so, few changes are needed but several could be
>> helpful.
>>
>
> Agreed that these are potential goals, which is why I tried to provide a
> specific and narrow set of questions, so that we can avoid ratholing on
> those.
>
> Specifically, I was asking about 1, as that is what comes from the UI
> treatment. A conclusion of 2 implies the UI should go.
>

In general I would concur that if #2, the UI should go. I think it's
appropriate to raise a question of whether EV can be fixed rather than
dropped. I concur that as it sits, it's broken and can be exploited to
achieve an outcome perverse to EV's stated goals.

>
>
>> 1. Requirement in objective/mostly objective terms of notoriety of
>> client. High note-worthiness of EV applicant would be required.
>> Validation procedures would modify to ensure that the commonly held "note
>> worthy" entity is actually the one applying.
>>
>
> Naturally, this falls apart at "Internet scale"
>

EV issuance is by requirement and definition a manual process. To the
extent that all manual processes fail at internet scale, sure. To the
extent that the outcome of a manual process can still provide useful
information to end users, I do not agree with your conclusion that this
falls apart.

>
>
>> 2. Stability of entity records. The corporate structure is known and has
>> been unchanged, perhaps for a year or more. Effectively, no EV for
>> startups or any new or restructured entity that can't show lengthly and
>> broad claim to the name.
>>
>
> This seems to create a bifurcated Internet which is not "open and
> accessible" (per Item 2 on the Mozilla Manifesto). Namely, if it favors or
> empowers incumbents, and the only ability to be trusted by users is to 'sit
> around' so you have a stable corporate identity, then we're not creating a
> neutral, open platform.
>

Let's be honest, here, though. EV status was intended to discriminate
against scammers, phishers, and resourceful MITMs. That's not "open and
accessible" either, strictly speaking. Yet, we've tolerated it.

>
>
>> If EV status is intended for business, asset management, and legal
>> professionals, then it's easier. Add mandatory validated parameters for
>> official registry from which the data was referenced (ex: Alabama
>> Secretary
>> of State, Corporations Division) as well as originally filed for
>> registration (ex: State of AL, County of Jefferson Probate Court). Give
>> the docket or document numbers or entity registration number as
>> appropriate
>> for each of these. Attempt to construe a scope of exclusivity and
>> indicate
>> that in lieu of just Country in the green bar.
>>
>
> The EV guidelines already encompass this information - the jurisdiction
> fields, combined with the serialNumber, which is the unique identifying
> number for that entity within the jurisdictional registry, which is unique
> per jurisdictional boundary.
>

Sadly, the current parameters do not fully encompass the legal
possibilities. At a minimum, it is deficient that the purportedly
authoritative registry, as according to the CA, is not explicitly named.

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 2:50 PM, Tim Hollebeek <tim.ho...@digicert.com>
wrote:

>
>

> Certainly, as you noted, one option is to improve EV beyond simply being
> an assertion of legal existence.
>

Does this mean we're in agreement that EV doesn't provide value to justify
the UI then? ;-)

I say it loaded and facetiously, but I think we'd need to be honest and
open that if we're saying something needs to be 'more' than EV, in order to
be useful and meaningful to users - which is what justifies the UI surface,
versus being useful to others, as Matt highlighted - then either EV meets
the bar of UI utility or it doesn't. And if it doesn't, then orthogonal to
and separate from efforts to add "Validation ++" (whether they be QWACS in
eIDAS terms or something else), then there's no value in the UI surface
today, and whether there's any value in UI surface in that Validation++
should be evaluated on the merits of Validation++'s proposals, and not by
invoking EV or grandfathering it in.

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 3:06 PM, Matthew Hardeman <mhar...@gmail.com>
wrote:

>
> The EV guidelines already encompass this information - the jurisdiction
>> fields, combined with the serialNumber, which is the unique identifying
>> number for that entity within the jurisdictional registry, which is unique
>> per jurisdictional boundary.
>>
>
> Sadly, the current parameters do not fully encompass the legal
> possibilities. At a minimum, it is deficient that the purportedly
> authoritative registry, as according to the CA, is not explicitly named.
>

Are you aware of any jurisdictions where, if scoped as required by the
EVGs, they would not serve as a full disambiguator as to the registry used?

[Tim Hollebeek]

On the contrary, everything needs to be improved with time. Just because it could be made better doesn’t make it useless or bad.

-Tim



From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Monday, December 11, 2017 1:09 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: ry...@sleevi.com; Jonathan Rudenberg <jona...@titanous.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: On the value of EV

[Matthew Hardeman]

The question that I have is whether the community might consider it
in-scope to discuss enhancements (even fixes) to EV to arrive at assurance
commensurate to its handling.

Matt Hardeman

On Mon, Dec 11, 2017 at 2:09 PM, Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Mon, Dec 11, 2017 at 2:50 PM, Tim Hollebeek <tim.ho...@digicert.com
> >

> wrote:
>
> >
> >
> > Certainly, as you noted, one option is to improve EV beyond simply being
> > an assertion of legal existence.
> >
>
> Does this mean we're in agreement that EV doesn't provide value to justify
> the UI then? ;-)
>
> I say it loaded and facetiously, but I think we'd need to be honest and
> open that if we're saying something needs to be 'more' than EV, in order to
> be useful and meaningful to users - which is what justifies the UI surface,
> versus being useful to others, as Matt highlighted - then either EV meets
> the bar of UI utility or it doesn't. And if it doesn't, then orthogonal to
> and separate from efforts to add "Validation ++" (whether they be QWACS in
> eIDAS terms or something else), then there's no value in the UI surface
> today, and whether there's any value in UI surface in that Validation++
> should be evaluated on the merits of Validation++'s proposals, and not by
> invoking EV or grandfathering it in.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[James Burton]

EV is on borrowed time and deprecating EV is the most logical viable
solution right now and brings us one step forward in vanishing the old
broken web security frameworks of the past. Now that both me and Ian
have demonstrated the fundamental issues with EV and the way its displayed
in the UI, it's only time until the REAL phishing starts with EV.

James

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 3:12 PM, Tim Hollebeek <tim.ho...@digicert.com>
wrote:

>
>

> On the contrary, everything needs to be improved with time. Just because
> it could be made better doesn’t make it useless or bad.
>
>
>
> -Tim
>

I didn't say that its ability to be improved made it bad - merely, its
present state is bad, particularly for users. Let's not focus on
generalities when we have a very specific case in front of us.

- We're in agreement that the certificates were legitimate.
- We're (seemingly) in agreement that we cannot discern intent (whether
they were used for good or bad), and certainly not on the browser side.
- We're in agreement that, as a result of the certificates being
legitimate, they are potentially confusing for users. I say potentially,
because the fact that "Stripe, Inc" is a company in Kentucky versus
Delaware may not be an issue - there are other companies with the name
"Stripe" in their name that may or may not be confusing, depending on the
user's context. [1]

As such, it's a fair and legitimate question to ask whether EV
certificates, as presently specified, deserve the UI treatment afforded to
them.
- If the fundamental certificate does not deserve it, then the UI should be
removed. This is orthogonal to any proposals to introduce some new type of
certificate that affords special UI.
- Suggestions to "change the UI" are not equal or equivalent to "remove
the UI" - adding user interface complexity is not equivalent to simplifying
the user interface
- If the fundamental certificate does deserve the UI treatment, then
demonstrate why it does. You seem to be in agreement that the present form
of legal identity is insufficient for the presumed use case, so I'm hoping
you can close the gap in my understanding on why something is
simultaneously insufficient yet suitable.

[1] https://crt.sh/?O=Stripe%25

[Ryan Hurst]

Stripe, Inc could very well be a road striping company.

This may have situationally been the equivalent of a misleading certificate but the scenario of name collisions is real.

Ryan Hurst

[Paul Wouters]

On Mon, 11 Dec 2017, James Burton via dev-security-policy wrote:

> EV is on borrowed time

You don't explain why?

I mean domain names can be confusing or malicious too. Are domain names
on borrowed time?

If you remove EV, how will the users react when paypal or their bank is
suddenly no longer "green" ? Are we going to teach them again that
padlocks and green security come and go and to ignore it?

Why is your cure (remove EV) better than fixing the UI parts of EV?

Paul

[Matthew Hardeman]

I don't denigrate the recent work done. Not at all.

This "exploit" is long known to those in the know.

My key objection is that there needs to be a way to validate that the brick
and mortar bank you've done business with for years _is_ the same group as
currenrtly has web domain xyz.

Something significant is lost if that capability disappears.

Some would argue that any diminished capability there qualifies the
treatment to be removed.

Some would argue that we should fix the holes in the scheme, even if those
fixes are draconian and exclude startups.

Can we accept that there is value in being sure that website XYZ actually
is the bank down the road?

On Mon, Dec 11, 2017 at 2:32 PM, James Burton <j...@0.me.uk> wrote:

> EV is on borrowed time and deprecating EV is the most logical viable
> solution right now and brings us one step forward in vanishing the old
> broken web security frameworks of the past. Now that both me and Ian
> have demonstrated the fundamental issues with EV and the way its displayed
> in the UI, it's only time until the REAL phishing starts with EV.
>
> James
>
> On Mon, Dec 11, 2017 at 8:29 PM, Matthew Hardeman via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
>
>> The question that I have is whether the community might consider it
>> in-scope to discuss enhancements (even fixes) to EV to arrive at assurance
>> commensurate to its handling.
>>
>> Matt Hardeman
>>
>> On Mon, Dec 11, 2017 at 2:09 PM, Ryan Sleevi via dev-security-policy <
>> dev-secur...@lists.mozilla.org> wrote:
>>

>> > On Mon, Dec 11, 2017 at 2:50 PM, Tim Hollebeek <
>> tim.ho...@digicert.com

[Ryan Hurst]

The issues with EV are much larger than UI. It needs to be revisited and a honest and achievable set of goals need to be established and the processes and procedures used pre-issuance and post-issuance need to be defined in support those goals. Until thats been done I can not imagine any browser would invest in new UI and education of users for this capability.

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 3:43 PM, Matthew Hardeman <mhar...@gmail.com>
wrote:

> I don't denigrate the recent work done. Not at all.
>
> This "exploit" is long known to those in the know.
>
> My key objection is that there needs to be a way to validate that the
> brick and mortar bank you've done business with for years _is_ the same
> group as currenrtly has web domain xyz.
>

I understand this objection, but I don't think it's supported - by the
technology, by the research, or by the implementation.

That is, I don't think we should conflate the need with the solution - and
I don't think we should ignore that the 'solution' at present isn't.

Something significant is lost if that capability disappears.
>

I'm not sure that the capability was there to begin with.

> Some would argue that any diminished capability there qualifies the
> treatment to be removed.
>
> Some would argue that we should fix the holes in the scheme, even if those
> fixes are draconian and exclude startups.
>
> Can we accept that there is value in being sure that website XYZ actually
> is the bank down the road?
>

I don't disagree there is value in the abstract, but it's fair to ask
whether EV the certificate technology and EV the UI achieve that. I think
it's reasonable to point out that the latter certainly does not, and to
call into question the former. We should also recognize that there is
active harm caused by suggesting it does achieve those goals, or should
achieve those goals, and that's reasonable to question the foundational
premise.

It feels like, to some extent, this is a question about whether we should
point out the Emperor has no clothes if we don't have clothes to offer him.
It'd be great if they was wearing some, I agree - the Emperor does need
clothes. But that doesn't mean we should pretend they are wearing clothes
simply because we don't have any to offer them.

[Paul Wouters]

On Mon, 11 Dec 2017, Ryan Hurst via dev-security-policy wrote:

> The issues with EV are much larger than UI. It needs to be revisited and a honest and achievable set of goals need to be established and the processes and procedures used pre-issuance and post-issuance need to be defined in support those goals. Until thats been done I can not imagine any browser would invest in new UI and education of users for this capability.

While I agree that EV does not solve world peace, can you tell me what
is wrong with the firefox approach of showing EV? That is, browsers
hiding the real hostname with EV seems to behave wrong, and should be
fixed. This seems unrelated to other noble goals of giving users improved
security. It seems you are conflating many things, then say it is too
much work and lets just scrap it.

Thus, so far I see reason for some browsers to fix their UI. I can see
reasons for EV to improve. I see no reason to further confuse users
by removing EV without a successor.

Paul

[Matthew Hardeman]

- If the fundamental certificate does deserve the UI treatment, then
> demonstrate why it does. You seem to be in agreement that the present form
> of legal identity is insufficient for the presumed use case, so I'm hoping
> you can close the gap in my understanding on why something is
> simultaneously insufficient yet suitable.
>
>

One argument, for example, is that the mechanism provides significant value
to the advanced user who is skilled in business structure / business entity
exploration. I did not say it was a strong or broad argument, but there is
a reasonably unambiguous value to a non-zero population.

I think it will be a difficult sell to remove EV certificate UI handling,
as nothing is proposed to replace it.

It seems fairly simple to redefine the EV qualifications and validation
standards to achieve strong value, though admittedly it would do so at the
cost of some inclusiveness.

That seems far more likely to achieve short term results than removing the
UI handling, having CAs lobby to re-add the UI for a whole new program, etc.

An objective study of the advisability of the removal of EV handling would
incorporate an analysis of the risks EV -- as it sits today -- is
successfully mitigating as well as the risks it enhances or presents.

That Kentucky registration for Stripe, Inc. -- Is it completely fraudulent
as to registered agent, business address, etc? If it's not, then the
certificate and underlying entity serve as an archived investigative entry
point for law enforcement or potential civil action.

Even if it is, someone filed the paperwork. Court houses have clerks,
guards, video cameras, etc... It still may present a real physical point
from which to bootstrap an investigation.

[Matthew Hardeman]

On Mon, Dec 11, 2017 at 2:53 PM, Ryan Sleevi <ry...@sleevi.com> wrote:
>
>
> It feels like, to some extent, this is a question about whether we should
> point out the Emperor has no clothes if we don't have clothes to offer him.
> It'd be great if they was wearing some, I agree - the Emperor does need
> clothes. But that doesn't mean we should pretend they are wearing clothes
> simply because we don't have any to offer them.
>

Joke mode on. But.... What if the Emperor is just unspeakably sexy? So
sexy that everyone wants to see the Emperor sans attire? Like so sexy the
guys in the room are like "You know, I'm not gay, but I'm gay for the
Emperor." What would that mean?

[Matthew Hardeman]

While I understand that it may formally be beyond the scope formally to
consider this in discussion with EV UI handling, I think some consideration
to ecosystem harm is appropriate here.

If we eliminate EV UI, we have reduced the scope of WebPKI to domain
validated certificates (in any pragmatic sense, anyway).

At that point, we can look to the question of best source of validation.

Conveniently. if the domain validation is all important, there is, for any
given domain, a single entity authoritatively enshrined to answer at any
given moment to whom and when a certificate may issue: the currently
attached domain registrar.

Taken ad absurdum, that's where an exclusively domain validation landscape
leads.

Any layer or validation mechanism above that merely adds potential for
imperfections. And if there's only one assertion of identity left in the
certificate, and there's a perfect data source, doesn't it follow that
we'll just enshrine as WebPKI CAs the various fully approved domain
registrars? Or perhaps even the registry, via interfaces exposed by the
then-attached registrar?

Every change in an ecosystem has effects intended and not. I'm concerned
that the "not" on this should give more pause.

On Mon, Dec 11, 2017 at 2:05 PM, Adam Caudill via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> > However, I don't believe "technically correct, but intentionally
> misleading" information should be included in certificates. The question
> is how best to accomplish that.
>

[Ryan Sleevi]

EV adds unnecessary information to the UI that can easily mislead users into believing a site is not as it stands, and condition users away from the only meaningful mitigation - checking the URL (and that itself is not perfect, but it's not helped by EV either)

That is, showing EV is wrong.

[Ryan Sleevi]

On Monday, December 11, 2017 at 4:03:41 PM UTC-5, Matthew Hardeman wrote:
> I think it will be a difficult sell to remove EV certificate UI handling,
> as nothing is proposed to replace it.

I think this is flawed. If EV doesn't provide value, and adds confusion, it absolutely should go, and doesn't need something to replace it to be the correct and right choice.

> It seems fairly simple to redefine the EV qualifications and validation
> standards to achieve strong value, though admittedly it would do so at the
> cost of some inclusiveness.

It isn't.

> That seems far more likely to achieve short term results than removing the
> UI handling, having CAs lobby to re-add the UI for a whole new program, etc.

Note: I don't think adding new UI should be the goal either.

> An objective study of the advisability of the removal of EV handling would
> incorporate an analysis of the risks EV -- as it sits today -- is
> successfully mitigating as well as the risks it enhances or presents.

I think that is both unrealistic and actively harmful. We know something is the cause of user confusion. We know something actively does not provide the value it achieves to. Yet we're insisting that the folks pointing out the harm and insufficiency must replace it? I hardly agree with that being in line with what's good for users.

An objective study of EV handling would determine what, if any, value it provides. If it does not - and I think work like James' and Ian's rightfully demonstrates, along with the research in to user understanding of the UI surface - then it's absolutely ripe for removal. The proponents of maintaining the UI treatment bear the responsibility to demonstrate that UI treatment is meaningful and valuable, in the concrete case.

If the question is just "power users" want it, then it can be moved to secondary UI surface, like it already is - the certificate viewer - or even removed entirely, since power users can access that information.

> That Kentucky registration for Stripe, Inc. -- Is it completely fraudulent
> as to registered agent, business address, etc? If it's not, then the
> certificate and underlying entity serve as an archived investigative entry
> point for law enforcement or potential civil action.

Fundamentally, I think this is misleading. It presumes that, upon something bad happening, someone can link it back to that certificate to link it back to that identity. If I was phished, and entered my credentials, there's no reason to believe I've maintained the record details including the phishing link to know I was phished. Are users supposed to spleunk their HTTP cache or maintain complete archives of every link they visited, such that they can get the cert back from it to aid an investigation?

The problem with this comparison (and indeed, CAs' like to bring it up), is there's no model of how it gets to the civil action or criminal investigation to begin with, in a way that is equivalent with the supposed risks it prevents.

> Even if it is, someone filed the paperwork. Court houses have clerks,
> guards, video cameras, etc... It still may present a real physical point
> from which to bootstrap an investigation.

Court houses also have online systems. I think if you read both Ian and James' work, you'll see the issues they're raising address this hypothetical.

[Ryan Sleevi]

On Monday, December 11, 2017 at 5:47:50 PM UTC-5, Matthew Hardeman wrote:
> While I understand that it may formally be beyond the scope formally to
> consider this in discussion with EV UI handling, I think some consideration
> to ecosystem harm is appropriate here.
>
> If we eliminate EV UI, we have reduced the scope of WebPKI to domain
> validated certificates (in any pragmatic sense, anyway).

That already is all the Web PKI is. Full stop.

The origin is the scheme, host, port. It's not the validation method. The validation method does not constitute a security boundary on the Web or in the Web PKI, so all there is is domain validation.

Everything else is a quasi-boundary that is full of more holes than the most exquisite of cheeses. Every attempt to somehow redefine that as a different boundary has been unable to do so. Even the introduction of EV called for the separation of scheme, because without that, EV provided no direct security value.

So why are we promoting EV as a boundary or with UI surface? Under the mistaken assumption that the user is always inspecting the URL at every key stroke and interaction and sub-resource load. That's actively user hostile, and damaging to any credible discussion of security.

> Conveniently. if the domain validation is all important, there is, for any
> given domain, a single entity authoritatively enshrined to answer at any
> given moment to whom and when a certificate may issue: the currently
> attached domain registrar.
>
> Taken ad absurdum, that's where an exclusively domain validation landscape
> leads.

ad aburdum isn't necessary - that's exactly how it should work! And it's absolutely true that third-party CAs act as an indirection between this registrar and the issuance of a certificate - an independent attestation of this relationship.

[Hanno Böck]

Hi,

On Mon, 11 Dec 2017 11:01:10 -0800 (PST)

Ryan Sleevi via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> I suppose this is both a question for policy and for Mozilla - given
> the ability to provide accurate-but-misleading information in EV
> certificates, and the effect it has on the URL bar (the lone trusted
> space for security information), has any consideration been given to
> removing or deprecating EV certificates?

I support the removal of special treatments and UI for EV
certificates.

Rationale: I believe plenty of security research shows that it is
incredibly hard to communicate security indicators to users. If you ask
average users about the meaning of green locks, green URL bars or
anything else they will usually not know what it means.

This lets only one sensible conclusion: Security indicators should be
removed. The goal should be to have one security level that is the
default (HTTPS+DV) and make that as secure as possible. The community
should therefore try to strengthen the CA ecosystem as a whole and not
try to make any "special" certificates.

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Matthew Hardeman]

On Mon, Dec 11, 2017 at 5:03 PM, Ryan Sleevi via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Monday, December 11, 2017 at 5:47:50 PM UTC-5, Matthew Hardeman wrote:

> > While I understand that it may formally be beyond the scope formally to
> > consider this in discussion with EV UI handling, I think some
> consideration
> > to ecosystem harm is appropriate here.
> >
> > If we eliminate EV UI, we have reduced the scope of WebPKI to domain
> > validated certificates (in any pragmatic sense, anyway).
>

> That already is all the Web PKI is. Full stop.
>
> The origin is the scheme, host, port. It's not the validation method. The
> validation method does not constitute a security boundary on the Web or in
> the Web PKI, so all there is is domain validation.
>

This argument has been presented before, and was not previously
sufficiently compelling to effect change.

>
> Everything else is a quasi-boundary that is full of more holes than the
> most exquisite of cheeses. Every attempt to somehow redefine that as a
> different boundary has been unable to do so. Even the introduction of EV
> called for the separation of scheme, because without that, EV provided no
> direct security value.
>
> So why are we promoting EV as a boundary or with UI surface? Under the
> mistaken assumption that the user is always inspecting the URL at every key
> stroke and interaction and sub-resource load. That's actively user hostile,
> and damaging to any credible discussion of security.
>

The goal, I should think, would be for the user to be able to identify that
the principal resource at the URI in the browser window is pulling in
resources under the direction and responsibility of "EV Cert Holder", who
hopefully work to minimize third party resources.

>
> > Conveniently. if the domain validation is all important, there is, for
> any
> > given domain, a single entity authoritatively enshrined to answer at any
> > given moment to whom and when a certificate may issue: the currently
> > attached domain registrar.
> >
> > Taken ad absurdum, that's where an exclusively domain validation
> landscape
> > leads.
>

> ad aburdum isn't necessary - that's exactly how it should work! And it's
> absolutely true that third-party CAs act as an indirection between this
> registrar and the issuance of a certificate - an independent attestation of
> this relationship.
>

Let me be sure I understand: the third party CAs add value or not? In this
picture you've painted, I think not. That indirection has less value as
"an independent attestation" than it has cost or potential cost in points
of exploit. There is little security if any over the communications
between the DNS infrastructure, the registry, and the CAs. Generally, it's
over insecure and MITMable DNS queries. And there's no independent
attestation to trust the CAs word on here: let's face it - the registry is
still the authoritative answer, even if they blatantly engaged in
revisionist history. So, if we're headed to objectively best security,
should we not just be working toward the registry as a CA? Conveniently,
we can even name-constrain each registry to their own TLDs.

[Matthew Hardeman]

What I dislike about this particular rationale is that I presupposes we
should architect web security such as to avoid enhancements which have
value to anyone the least common denominator.

Is the average user (actually, the bottom rung of the concentration of
values around the average, I suppose) the only user our interfaces should
target?

On Mon, Dec 11, 2017 at 5:21 PM, Hanno Böck via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
>
> I support the removal of special treatments and UI for EV
> certificates.
>
> Rationale: I believe plenty of security research shows that it is
> incredibly hard to communicate security indicators to users. If you ask
> average users about the meaning of green locks, green URL bars or
> anything else they will usually not know what it means.
>
>

What I dislike about this particular rationale is that it presupposes that
we should architect web security such as to avoid enhancements which have
value to anyone beyond the least common denominator.

Is the average user (actually, the bottom rung of the concentration of
values around the average, I suppose) the only user our interfaces should
target?

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 6:31 PM Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> What I dislike about this particular rationale is that I presupposes we
> should architect web security such as to avoid enhancements which have
> value to anyone the least common denominator.
>
> Is the average user (actually, the bottom rung of the concentration of
> values around the average, I suppose) the only user our interfaces should
> target?

Yes.

If something is not valuable for billions of users, if it is not
trustworthy for billions of users, it should not occupy the cognitive or
visual model billions of users rely on.

>
> On Mon, Dec 11, 2017 at 5:21 PM, Hanno Böck via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
> >
> >
> > I support the removal of special treatments and UI for EV
> > certificates.
> >
> > Rationale: I believe plenty of security research shows that it is
> > incredibly hard to communicate security indicators to users. If you ask
> > average users about the meaning of green locks, green URL bars or
> > anything else they will usually not know what it means.
> >
> >
> What I dislike about this particular rationale is that it presupposes that
> we should architect web security such as to avoid enhancements which have
> value to anyone beyond the least common denominator.
>
> Is the average user (actually, the bottom rung of the concentration of
> values around the average, I suppose) the only user our interfaces should
> target?

[Matthew Hardeman]

On Monday, December 11, 2017 at 5:00:14 PM UTC-6, Ryan Sleevi wrote:
> > That Kentucky registration for Stripe, Inc. -- Is it completely fraudulent
> > as to registered agent, business address, etc? If it's not, then the
> > certificate and underlying entity serve as an archived investigative entry
> > point for law enforcement or potential civil action.
>
> Fundamentally, I think this is misleading. It presumes that, upon something bad happening, someone can link it back to that certificate to link it back to that identity. If I was phished, and entered my credentials, there's no reason to believe I've maintained the record details including the phishing link to know I was phished. Are users supposed to spleunk their HTTP cache or maintain complete archives of every link they visited, such that they can get the cert back from it to aid an investigation?

Not really - what matters is that the user insists they got had via a phishing link or other process - that can certainly be verified after the fact - did someone steal their money in a sketchy way, but with apparent user authorization? Further, the user swears back and forth that the green bar was there and they looked to see that it matched the site's name - their bank, PayPal, etc. All EV certs are CT logged, find the cert or homograph from there, track to issuer and validation details, chase the entity document path, etc.

>
> The problem with this comparison (and indeed, CAs' like to bring it up), is there's no model of how it gets to the civil action or criminal investigation to begin with, in a way that is equivalent with the supposed risks it prevents.

It begins with a sufficient loss, an aggressive attorney, or an aggressive complaining witness before law enforcement.

>
> > Even if it is, someone filed the paperwork. Court houses have clerks,
> > guards, video cameras, etc... It still may present a real physical point
> > from which to bootstrap an investigation.
>
> Court houses also have online systems. I think if you read both Ian and James' work, you'll see the issues they're raising address this hypothetical.

I shall certainly read their work closely on that matter. In my experience, these generally don't allow filings for new businesses from those not previously known to the court/registrar in real life.

[Ryan Sleevi]

On Mon, Dec 11, 2017 at 6:46 PM Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Monday, December 11, 2017 at 5:00:14 PM UTC-6, Ryan Sleevi wrote:

> > > That Kentucky registration for Stripe, Inc. -- Is it completely
> fraudulent
> > > as to registered agent, business address, etc? If it's not, then the
> > > certificate and underlying entity serve as an archived investigative
> entry
> > > point for law enforcement or potential civil action.
> >
> > Fundamentally, I think this is misleading. It presumes that, upon
> something bad happening, someone can link it back to that certificate to
> link it back to that identity. If I was phished, and entered my
> credentials, there's no reason to believe I've maintained the record
> details including the phishing link to know I was phished. Are users
> supposed to spleunk their HTTP cache or maintain complete archives of every
> link they visited, such that they can get the cert back from it to aid an
> investigation?
>

> Not really - what matters is that the user insists they got had via a
> phishing link or other process - that can certainly be verified after the
> fact

No.

- did someone steal their money in a sketchy way, but with apparent user
> authorization? Further, the user swears back and forth that the green bar
> was there and they looked to see that it matched the site's name - their
> bank, PayPal, etc.

All users will swear this if it avoids liability. And let’s be honest, it’s
actively hostile to users to say they bear liability if they don’t do this
- for every click of the page.

All EV certs are CT logged, find the cert or homograph from there, track
> to issuer and validation details, chase the entity document path, etc.

As both James and Ian have shown, there are ample ways of you assume an
adversary that such a process can be circumvented.

And of course ignoring all the innocent bystanders along the way - such as
Ian, who has not phished Stripe users.

>
> > The problem with this comparison (and indeed, CAs' like to bring it up),
> is there's no model of how it gets to the civil action or criminal
> investigation to begin with, in a way that is equivalent with the supposed
> risks it prevents.
>

> It begins with a sufficient loss, an aggressive attorney, or an aggressive
> complaining witness before law enforcement.

I do not feel we are engaging in productive dialog anymore. Not for ill
intent, but we are clearly talking past each other. Nor do I feel your
examples hold up to the simplest of practical concerns, let alone ample
research into human computer interaction or warning interaction. Which is
the point. Just look at the studies of TSA effectiveness to see this
demonstrated in the real world - where 99.9% positive can easily detract
from the negative.
There is no evidence to support, let alone threat model, that showing the
EV UI today deters threats or provides value in an adversarial model
against the average user. And that is the minimal necessary threshold to
justify that UI, I would assert.

[Adam Caudill]

> > > Even if it is, someone filed the paperwork. Court houses have clerks,
> > > guards, video cameras, etc... It still may present a real physical
point
> > > from which to bootstrap an investigation.
> >
> > Court houses also have online systems. I think if you read both Ian and
James' work, you'll see the issues they're raising address this
hypothetical.
>

> I shall certainly read their work closely on that matter. In my
experience, these generally don't allow filings for new businesses from
those not previously known to the court/registrar in real life.

I can say from my own experience, in some states in the US, it's a trivial
matter to create a company online, with no validation of identity or other
information. It takes about 10 minutes, and you'll have all the paperwork
the next day. When I did this (in a state I had never done business in
before), there was absolutely no identity checks, no identity documents,
nothing at all that would tie the business to me if I had lied. Creating a
business with no connection to the people behind it is a very, very simple
thing to do.

[Matthew Hardeman]

On Monday, December 11, 2017 at 5:37:34 PM UTC-6, Ryan Sleevi wrote:

> Yes.
>
> If something is not valuable for billions of users, if it is not
> trustworthy for billions of users, it should not occupy the cognitive or
> visual model billions of users rely on.
>

Perish the thought that a UI element might spark, in even a tiny percentage, a question in a mind that leads to an exploration that leads to an individual human being's growth. Design that conforms only to the least common denominator is sure to play into a downward spiraling feedback loop.

I concur -- as you elsewhere suggested -- we are talking past each other. Prior to this comment, I looked on that with hope, as an opportunity for ME to learn and improve.

[scott...@gmail.com]

I recently talked about [1] some of the many problems I see with EV certificates on my blog but looking at the tangible security benefits of EV they can already be matched, or will soon be matched, by DV certificates.

Certificate Transparency will be required [2] for all certificates and not just EV certificates. This means a mis-issued DV certificate will be exposed just as quickly as a mis-issued EV certificate.

The requirement to revocation check an EV certificate can be matched by a DV certificate using the OCSP Must-Staple [3] flag set by the CA.

Those are both technical measures that don't rely on any user perception, knowledge or action for them to work, thus making them effective in all supporting UAs.

The remaining value of an EV certificate is then based solely on the user observing, understanding and responding to the presence or lack of an EV indicator. The same EV indicator that is stripped by Antivirus programs, proxies and corporate network inspection, which all happen often enough to be negatively impacting the roll out of TLSv1.3 at present.

Finally, looking at section 2.1.3 Excluded Purposes of the EV SSL Guidelines [4] we're essentially saying to the user, look, here's a company name, some name, *any* name, but we can't tell you anything about it other than this is the name. If the user doesn't already have prior knowledge of the name of the company they wish to do dealings with to validate against the EV UI, what value is telling them the name of the company?


[1] https://scotthelme.co.uk/are-ev-certificates-worth-the-paper-theyre-written-on/
[2] https://scotthelme.co.uk/certificate-transparency-an-introduction/
[3] https://scotthelme.co.uk/ocsp-must-staple/
[4] https://cabforum.org/wp-content/uploads/EV-V1_6_6.pdf

[Jakob Bohm]

A lot of people have posed suggestions for countermeasures so extreme
they should not be taken seriously. This includes discontinuing EV,
requiring that companies cannot get EV certs during their first year of
existence, or suggesting that only "famous" companies can get EV
certificates.

Here is a more reasonable suggestion:

1. In the Fx UI, display the actual jurisdictionOfIncorporation instead
of just the country, especially where those differ (For example
Kentucky versus all-of-US).

2. Add a rule that if there is a big national or international company
with a name, other companies cannot get certificates for the same
name in related jurisdictions. For example if there is a company
listed on NYSE or NASDAQ, no similarly named US company can get an
EV or OV certificate for that name. Ditto for a reasonable list of
national registries in each country. CAs should be required to
publicly state which "big-status" lists beat local
company/organization registrations in each country, and similar for
any special lists of major global organizations, such as Google or
The Red Cross.

3. Minimum (not maximum) standards for such things need to be published
by the CAB/F.

4. Note that stock exchanges should not be the only list of "nationally
significant companies", as that would exclude a lot of companies with
different ownership structures, such as Mozilla Inc. or the pre-IPO
Google. However the list criteria should be clear and not rely
too heavily on the subjective experience of vetting agents etc.

5. It is worth noting that some countries do use a national company
registry which ensures uniqueness directly. Denmark is one such
country (though the uniqueness checking is probably limited to exact
matches).

6. It should still be possible for local branches and franchise holders
to get EV certificates, if the bigger company approves as part of the
vetting process. For example Google Canada should be able to get a
3rd party EV certificate if the international headquarters of Alphabet
approves it.

Formulating this into formal rules, and selecting appropriate
per-country and global lists of name-dominating organizations will both
take some time and should be done in parallel.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Tim Hollebeek]

This is useful feedback. Thanks.

-Tim

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of Jakob Bohm via dev-security-policy
Sent: Tuesday, December 12, 2017 6:36 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: On the value of EV

On 12/12/2017 01:08, Adam Caudill wrote:

Jakob Bohm, CIO, Partner, WiseMo A/S. https://clicktime.symantec.com/a/1/ysoeSRBosKMv2y51HEgmye3dC3w01KcfPIlE7uDFUrg=?d=Mj2xApkajNC6NUPymFNEfV5jUyRoXYatn3xbe_lByhtvBUca3QjCjyhaIGmwyP7KNNQYWgpsKuZ5UOpqhOXzkWfEx5Q49kKdvaVDsMmrCXF1qDZ308yVoUNOuj54O3Hcywy1MV6DDNORzSB1HLrHF6H4QPXWkHwn7zC1NE61drhv701Lv9vqhPlAgM3UqEBFdvuv8SQ3rAqKRLMZUCKH8HfwOw28xg6GQL8K2m34lqKD3AUGpC1hiH0XNtxgaOpoPrF7Tu2pv69E3yNM79rVTdB_ikacGGQ4RVtUCJlxLfFvstZDs2dP2RsXHlH9ZMtvch7bZjuDDWCQPuDdT4VSw0VZEr_7jNECLrlf7haoNdtxbcv7-SfpfFBGmpS5unFU92yRHdgylNVBg3B8Dlui4NX4P3j2WjucbZw23st8fxV8vw%3D%3D&u=https%3A%2F%2Fwww.wisemo.com

Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors.

WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://clicktime.symantec.com/a/1/FhPk-7MdjrPtV9JspPoItqTDwr9vvNbq9QibW0Sl0co=?d=Mj2xApkajNC6NUPymFNEfV5jUyRoXYatn3xbe_lByhtvBUca3QjCjyhaIGmwyP7KNNQYWgpsKuZ5UOpqhOXzkWfEx5Q49kKdvaVDsMmrCXF1qDZ308yVoUNOuj54O3Hcywy1MV6DDNORzSB1HLrHF6H4QPXWkHwn7zC1NE61drhv701Lv9vqhPlAgM3UqEBFdvuv8SQ3rAqKRLMZUCKH8HfwOw28xg6GQL8K2m34lqKD3AUGpC1hiH0XNtxgaOpoPrF7Tu2pv69E3yNM79rVTdB_ikacGGQ4RVtUCJlxLfFvstZDs2dP2RsXHlH9ZMtvch7bZjuDDWCQPuDdT4VSw0VZEr_7jNECLrlf7haoNdtxbcv7-SfpfFBGmpS5unFU92yRHdgylNVBg3B8Dlui4NX4P3j2WjucbZw23st8fxV8vw%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

[Peter Bachman]

I think this is fundamentally an issue of the history of the DNS and X.500 architecture. Combined with social factors since 1996 when the original NSF Directory and DNS grant money ran out, and domains (which had been free) became this wild west name space, which has reached some predictable level of insecurity. Inevitably the classic solutions are brought out and rejected. I think the rapid growth of the Internet has been achieved in terms of IP over everything, but security is always going to be a work in progress.

People who understand X.509 versions understand that the original version was highly integrated with the Directory, which provides its own level of assurance. It was also stifling. However we are seeing a renewed interest in directory variants around the issue of lowering US healthcare processing overhead. Using the Internet has been on the agenda since 2004.


There’s a long thread here dating back to the 1980’s regarding naming, resulting in the fields that are eventually defined in RFC 5280.

The ANSI registration component is permanent and perpetual.

Like most elements of the Internet that remain insecure, it’s a matter of ubiquitous access (domains are cheap, it costs more money to validate a business or organization, so the less secure solution is adopted) or other solutions like pinning are tried.

I would be open to partnering with Mozilla and doing this using X.500, but the ANSI name and OID fee is high. Which is the case also with NIST LOA 3 certificates. I’m certainly open to any ideas to make this work. Right now there is a governance gap of a organization equivalent to ICANN that is addressed by various industry organizations that do well known certificate cross certification at the Federal Bridge and European trust anchors.

[Nick Lamb]

On Mon, 11 Dec 2017 19:08:43 -0500

Adam Caudill via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> I can say from my own experience, in some states in the US, it's a
> trivial matter to create a company online, with no validation of
> identity or other information. It takes about 10 minutes, and you'll
> have all the paperwork the next day. When I did this (in a state I
> had never done business in before), there was absolutely no identity
> checks, no identity documents, nothing at all that would tie the
> business to me if I had lied. Creating a business with no connection
> to the people behind it is a very, very simple thing to do.

It may be valuable to understand here that although we often think of
countries like the United States and United Kingdom as places with
great respect for the Rule of Law, they have also both quietly
functioned as places where the rich may hide their wealth with no
questions asked. Even "Who are you?" is too many questions.

The ability to create companies in these countries without anyone
really knowing who controls them or ultimately benefits from any
financial income is a _feature_ not a bug as far as their governments
are concerned.

[Jakob Bohm]

On 12/12/2017 16:57, Peter Bachman wrote:
> I think this is fundamentally an issue of the history of the DNS and X.500 architecture. Combined with social factors since 1996 when the original NSF Directory and DNS grant money ran out, and domains (which had been free) became this wild west name space, which has reached some predictable level of insecurity. Inevitably the classic solutions are brought out and rejected. I think the rapid growth of the Internet has been achieved in terms of IP over everything, but security is always going to be a work in progress.
>
> People who understand X.509 versions understand that the original version was highly integrated with the Directory, which provides its own level of assurance. It was also stifling. However we are seeing a renewed interest in directory variants around the issue of lowering US healthcare processing overhead. Using the Internet has been on the agenda since 2004.
>
>
> There’s a long thread here dating back to the 1980’s regarding naming, resulting in the fields that are eventually defined in RFC 5280.
>
> The ANSI registration component is permanent and perpetual.
>

If you are referring to the OID namespace (as opposed to the
"distinguished name" namespace), then both the IETF, Mozilla
and most other relevant organizations have their own branches
in that tree. Many of those are subtrees under the "enterprise
ID" suballocation from IANA.

Of cause, the OID tree is rooted at ISO and ITU, not the US-specific
ANSI. Also, it is generally used to identify technical elements (such
as fields and data types) rather than organizations and businesses.

If you are referring to the "distinguished name" namespace to which
X.509 certificates are actually issued, 3 competing and overlapping
branches exist:

1. The traditional (telephone) directory namespace organized by
geographical/postal address and generally unpopulated due to not
being set up by most national telephone companies.

2. An ad-hoc equivalent of the traditional directory namespace, not
explicitly stored anywhere but instead filled out based on available
traditional information sources such as the postal addresses found in
various public records. This is what most public X.509 certificates
are currently issued to, with a slight misuse of the "common name" as
a "DNS address" field due to early deployments by Netscape (now
Mozilla). The EV program under discussion here is a set of minimum
requirements for certificate issuers to verify the applicants
directory name details before signing certificates containing those.

3. An X.500-style restatement of the DNS namespace, using distinguished
name component of the form "DC=label". This is used in the internal
company X.500 directories in companies that use Microsoft's directory
management software, but appears to be older, an early variant can be
found in RFC1274 though I am not sure if the DC (DomainComponent)
definition is still the same and if it still uses the OID
ITU(?)-data(9)-pss(2342)-ucl(19200300)-pilot(100)-
pilotAttributeType(1)-domainComponent(25)
(Not sure if this syntax is entirely correct)

4. A "dummy" branch where members contain only DNS names in commonName
and non-X.500 extensions, country name (where known or wrong) and some
metadata about certificate issuance. This branch of the X.500
namespace is used for so called DV certificates, where only a
mechanical check of DNS name ownership is done. The CAB/F "Basic
requirements" and Mozilla policy provides minimum standards for this
mechanical checking.

> Like most elements of the Internet that remain insecure, it’s a matter of ubiquitous access (domains are cheap, it costs more money to validate a business or organization, so the less secure solution is adopted) or other solutions like pinning are tried.
>
> I would be open to partnering with Mozilla and doing this using X.500, but the ANSI name and OID fee is high. Which is the case also with NIST LOA 3 certificates. I’m certainly open to any ideas to make this work. Right now there is a governance gap of a organization equivalent to ICANN that is addressed by various industry organizations that do well known certificate cross certification at the Federal Bridge and European trust anchors.
>

The overall problem addressed by WebPKI certificates is verifying that
the server end of a network connection is:

- The actual user-requested DNS name.

AND (optional):

- A specific real-world entity such as a business, government entity,
NGO, inter-governmental organizations etc., whose identity can be
presented to the human user to let them know who they are communicating
with.

The problem that started this thread was that the current WebPKI system
provides no workaround for the real-world problem that many of the
worlds jurisdictions allows the creation of actual legal businesses etc.
with misleading names, and the fact that once a government entity has
allowed such a misleadingly named business to officially exist in the
real world, it might obtain WebPKI certificates bearing that confusing
but legally authorized name. If the relevant government operated an
X.500 directory of legally existing businesses, the confusing entries
would exist in that X.500 directory.





Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com

[Ryan Sleevi]

On Tue, Dec 12, 2017 at 8:36 AM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 12/12/2017 01:08, Adam Caudill wrote:
>

> A lot of people have posed suggestions for countermeasures so extreme
> they should not be taken seriously. This includes discontinuing EV,
> requiring that companies cannot get EV certs during their first year of
> existence, or suggesting that only "famous" companies can get EV
> certificates.
>
> Here is a more reasonable suggestion:
>
> 1. In the Fx UI, display the actual jurisdictionOfIncorporation instead
> of just the country, especially where those differ (For example
> Kentucky versus all-of-US).
>

I will note that suggestions of this nature are not particularly productive
or in line with usability research. Beyond the simple fact that "UI is not
a democracy" - it's a product decision - let's look at what we're saying:

Users are expected to know and understand these distinguishing factors.
Either they're expected to understand that the "Stripe, Inc" they want to
use is not in Kentucky (an external piece of knowledge few have) or that
the "Stripe, Inc" they normally deal with is something they have to
memorize (in addition to the URL and other distinguishing factors)

As such, this does not stand the basic "Is this a reasonable thing to ask
all users" test.

> 2. Add a rule that if there is a big national or international company
> with a name, other companies cannot get certificates for the same
> name in related jurisdictions. For example if there is a company
> listed on NYSE or NASDAQ, no similarly named US company can get an
> EV or OV certificate for that name. Ditto for a reasonable list of
> national registries in each country. CAs should be required to
> publicly state which "big-status" lists beat local
> company/organization registrations in each country, and similar for
> any special lists of major global organizations, such as Google or
> The Red Cross.
>

I realize your intent is well, but this is a huge and tremendous challenge.
If you don't believe me, understand why
http://www.wipo.int/portal/en/index.html exists.

There is not a 'reasonable list' here nor is there a good definition of
'big national or international company'. Or look at
http://www.wipo.int/amc/en/domains/decisions/html/2000/d2000-1015.html

5. It is worth noting that some countries do use a national company
> registry which ensures uniqueness directly. Denmark is one such
> country (though the uniqueness checking is probably limited to exact
> matches).
>

There are a number of such countries.

I think it's great you're engaging, but it's not for lack of consideration
of your proposals that the result is to remove EV. Rather, it's because the
impracticality of them - as already demonstrated - that they shouldn't be
on the table.

[Jonathan Rudenberg]

> On Dec 12, 2017, at 08:36, Jakob Bohm via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> A lot of people have posed suggestions for countermeasures so extreme
> they should not be taken seriously. This includes discontinuing EV,

I don’t think that removing the EV UI is extreme, and it should definitely be taken seriously. The default Android browsers do not have EV at all, and many mobile browsers on iOS and Android including Chrome, Firefox, and Brave do not either. Those browsers combined have a huge number of pageviews that do not have any EV UI right now.

Additionally, all of the research I’ve seen shows that most users have no idea what is going on with EV and that it doesn’t help protect users.

> Here is a more reasonable suggestion:
>
> 1. In the Fx UI, display the actual jurisdictionOfIncorporation instead
> of just the country, especially where those differ (For example
> Kentucky versus all-of-US).

It’s not clear how this will help. The jurisdiction that a business entity is incorporated in is unrelated to the physical location that the user associates with a website (if any) is based on factors related to corporate law and taxation. Even if all users were able to use the EV UI constructively somehow (they aren’t), adding a piece of information that is effectively arbitrary is not useful.

> 2. Add a rule that if there is a big national or international company
> with a name, other companies cannot get certificates for the same
> name in related jurisdictions. For example if there is a company
> listed on NYSE or NASDAQ, no similarly named US company can get an
> EV or OV certificate for that name. Ditto for a reasonable list of
> national registries in each country. CAs should be required to
> publicly state which "big-status" lists beat local
> company/organization registrations in each country, and similar for
> any special lists of major global organizations, such as Google or
> The Red Cross.

How similar is similar? What if Bancorpsouth Inc, The Bancorp Inc., and U.S. Bancorp all want your EV++ certificates? What about Apple Inc. and Apple Corps Ltd? Business entity names are not unique. Trying to enforce a unique constraint against them, especially with an additional “similarity” fuzzy layer is just asking for trouble. Trying to have users also make that determination (which is the current state of EV) is similarly troublesome.

Jonathan

[Jakob Bohm]

The overall thing is that the current thread seems to be a major case of
throwing the baby out with the bathwater.

The entire problem boils down to this:

Some jurisdictions (such as Kentucky) allow people to set up
businesses with official legal names that are significantly
misleading. This failure by those governments naturally allows such
misleading names to appear in documents (such as X.509 certificates)
that are visible far outside those jurisdictions.

Insisting that no businesses at all get to show proof of their legal
names to Internet users just because some businesses have been allowed
by their governments to hold misleading names, is doing significantly
more damage to the overall community of Internet users than the
current risk of such government-authorized situations being used to
deceive users.

The simple solution, seemingly rejected by some here, is to state "This
is a vulnerability in the relevant government entity (such as whatever
Kentucky institution allowed the name), it is not misissuance to put
such official legal names in EV certificates". If this would be
accepted, no changes are needed in the EV rules, case closed.

As an alternative to this simple solution, I have therefore been
suggesting *minimal* restrictions on EV certificates that could mitigate
the problem while still allowing most businesses to get EV certificates
for their non-misleading names.

And since these would be restrictions only for EV certificates, rather
than restrictions on having those names at all, the community can
reasonably afford to impose rules more strict than what governments,
trademark authorities etc. can practically impose.

My "lists of big companies" would be much more ad-hoc and much less
formal than what is used for e.g. trademark enforcement. The intention
being that there will be a small proportion of businesses (less than
0.5%) that will be unable to get EV certificates for their trademarked
and government registered names due to conflicts with other businesses
by the same name. Sometimes this will be mutual (two similarly named
companies can't get EV certificates because of each other), at other
times one entity gets the opportunity semi-arbitrarily (based on lists
that are not arbitrary CA or Browser decisions, but were arbitrarily
chosen without directly targeting those businesses).

The "Spring Inc" not-of-Kentucky versus "Spring Inc" (Kentucky) case is
the one that would be imperfectly captured by the lists of US-wide and
world-wide companies. There is no certainty that "Spring Inc" will
be on those lists at all relevant times, though it should be predictable
based on things at least partially in the companies control (such as if
they are on the "Fortune 500 list" and if they are publicly traded on
their big national stock exchange(s)).

The "display the jurisdictionOfIncorporation" rule captures the more
common case of "First National Bank" (Kentucky) vs. "First National
Bank" (Arizona), where neither has any reason to be considered the only
"First National Bank" on a wider scale, but the user has a reasonable
expectation to connect to the one in a specific location.

Making it attractive for such locally operating businesses to register
in their actual location rather than in a "haven" such as Delaware or
Luxemburg is good on a society level. It is similar to how passengers
on Caribean cruise-liners may have a slight preference for ships that
are labeled "M/S Example, Fort Lauderdale" (with a US flag) rather than
"M/S Example, Freetown" (with a Liberian flag).

[Jakob Bohm]

On 12/12/2017 18:31, Jonathan Rudenberg wrote:
>
>> On Dec 12, 2017, at 08:36, Jakob Bohm via dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>>
>> A lot of people have posed suggestions for countermeasures so extreme
>> they should not be taken seriously. This includes discontinuing EV,
>
> I don’t think that removing the EV UI is extreme, and it should definitely be taken seriously. The default Android browsers do not have EV at all, and many mobile browsers on iOS and Android including Chrome, Firefox, and Brave do not either. Those browsers combined have a huge number of pageviews that do not have any EV UI right now.
>

Using intentionally non-functional mini-browsers as examples of what
functionality can be removed from serious desktop browsers is a really
bad idea. Just look at how the market has widely rejected attempts to
put a mobile device user interface on PCs.

> Additionally, all of the research I’ve seen shows that most users have no idea what is going on with EV and that it doesn’t help protect users.

While the EV interface is confusing to users (with such misleading
elements as "The website does not supply identity information" displayed
for OV certificates), the difference between having their name and
address displayed in the browser is very effectively marketed to
business owners, and arguably adds to the user's sense of being on an
official site.

This is the same situation for many of the other marks and decals that
can be displayed by a business, online or offline. Most users don't
understand the full meaning and implications, but still semi-consciously
use them to tell reputable businesses from dodgy ones.

>
>> Here is a more reasonable suggestion:
>>
>> 1. In the Fx UI, display the actual jurisdictionOfIncorporation instead
>> of just the country, especially where those differ (For example
>> Kentucky versus all-of-US).
>
> It’s not clear how this will help. The jurisdiction that a business entity is incorporated in is unrelated to the physical location that the user associates with a website (if any) is based on factors related to corporate law and taxation. Even if all users were able to use the EV UI constructively somehow (they aren’t), adding a piece of information that is effectively arbitrary is not useful.

This is only the case for tax-dodging company structures. It is rarely
the case for local businesses, which is the case where distinguishing
between equally-genuine companies in different places matter to users.

>
>> 2. Add a rule that if there is a big national or international company
>> with a name, other companies cannot get certificates for the same
>> name in related jurisdictions. For example if there is a company
>> listed on NYSE or NASDAQ, no similarly named US company can get an
>> EV or OV certificate for that name. Ditto for a reasonable list of
>> national registries in each country. CAs should be required to
>> publicly state which "big-status" lists beat local
>> company/organization registrations in each country, and similar for
>> any special lists of major global organizations, such as Google or
>> The Red Cross.
>
> How similar is similar? What if Bancorpsouth Inc, The Bancorp Inc., and U.S. Bancorp all want your EV++ certificates? What about Apple Inc. and Apple Corps Ltd? Business entity names are not unique. Trying to enforce a unique constraint against them, especially with an additional “similarity” fuzzy layer is just asking for trouble. Trying to have users also make that determination (which is the current state of EV) is similarly troublesome.
>

The similarity factor would be very limited. Something like "strip away
words that just mean company or organization, replace punctuation by
spaces, then compare case-insensitively".

Anyway, the similarity thing is not the point, the point would be about
essentially identical company names, such as "Apple" (Beatles music
rights company) vs. "Apple" (California Computer and music company named
after the Beatles one). While Beatles are themselves famous, their
company entity has a very small international presence compared to the
computer company.

And there is also the option of just letting governments (including
courts) deal with the risk of companies holding misleading names, and
simply declaring that this is not our problem. If the government says
this company is allowed to call itself Spring Inc, it can get an EV
certificate for Spring Inc. (Domain names in EV certs should still be
subject to domain verification).

[Ryan Sleevi]

On Tue, Dec 12, 2017 at 1:11 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> The overall thing is that the current thread seems to be a major case of
> throwing the baby out with the bathwater.
>

That is overly reductive and may demonstrate a lack of understanding of the
points of criticism.

> The entire problem boils down to this:
>

No, it doesn't.

This is yet another practical demonstration of an overall set of flaws with
EV, for which those bolsters (which it would be fair to say include you, at
this point) do not acknowledge the holistic set of issues - or their
fundamental failure.

For those involved in the regular, day to day involvement with PKI, these
sets of concerns are well at the forefront of our minds, but in the event
you may not be familiar:

The EV Guidelines establish what CAs (rightly or wrongly) believe as the
purpose of EV, as noted in Section 2.1 of
https://cabforum.org/wp-content/uploads/EV-V1_6_6.pdf
- 2.1.1 (1) does not require special UI treatment
- 2.1.1 (2) is not necessary - DV already achieves that
- 2.1.2 (1) is demonstrably false
- While Ian's example is yet another part of this, there's nothing
fundamental within EV certificates that achieves 2.1.2 (1), because that
goal is itself so ill-defined that it fundamentally is unachievable.
- CAs who believe that biased marketing surveys are equivalent to
peer-reviewed research would have you believe that "Out of 100 phishing
sites we saw, none used EV, therefore, EV is more secure", therefore this
goal is achieved. This is so scientifically unsound and methodogically
flawed that it should be laughed out of serious discussion, yet they
continue to peddle such abject logically unsound rubbish. They might as
well shout "fake news" for all the credibility should be afforded to them.
- Sticklers for this point will typically suggest this can be achieved
through one of three means - "temporal risk", "financial cost", or "legal
risk" - namely:
- because an EV cert takes longer (temporal), it reduces risk because
people don't want to wait (ignoring the fact that some CAs will turn out an
EV cert in hours)
- because an EV cert has, on average, a substantially higher cost
(financial) than a DV cert, it serves as a bar to entry for attackers who
would otherwise not want to use money (ignoring that attackers,
particularly phishers, already have a network of credentials and resources
to charge against)
- because an EV cert requires some sort of legal identity, they're
exposing themselves to risk of identification (ignoring work like James' or
Ian's, because, well, that's convenient)
- 2.1.2 (3) does not require any UI - that's purely on the backend

So the whole premise for why there should be *any* UI treatment is
predicated on 2.1.2 (2), which clearly spells out that EV is a marketing
tool, wrapped in the guise of a security tool. I do not feel you can offer
a more charitable read of that section.

And what do we get for that browsers selling, rent-free, their critical UI
space of billions of users?

Well,
2.1.3 (1) - No assurances that they're doing business
2.1.3 (2) - No assurances that they comply with applicable laws
2.1.3 (3) - No assurances that they're trustworthy, honest, or reputable


Literally the entire value proposition of EV reduces to "CAs want to sell
billboards in the browser's security UI". And the fundamental point is that
such UI is security critical - it's the line of death between trustworthy
and untrustworthy content (
https://textslashplain.com/2017/01/14/the-line-of-death/ ).

The goal is to ensure this URL bar requires as little cognitive thought
possible - you should be able to quickly determine if you're at where you
expect, where "where you expect" is the URL. And the URLs you use should
use systems that do not rely on users checking that - e.g., they should be
using origin bound credentials (WebAuthN/U2F), they should be using
browser/password manager mediated identities (Credentials API), etc.

This isn't throwing the baby out with the bathwater. This is recognizing
that having a billboard of things users are also supposed to know or else
we get to blame them when things go wrong is bad policy, bad security, and
actively hostile to users. Let's not let idealism get in the way of the
pragmatic reality that the most important job a browser has is keeping
users safe and secure, the most effective way to do that is to keep things
as simple as possible (so that all people, of all skillsets, can enjoy the
Web), and the simplest way to security is to get users to the point of not
having to think about it, because the systems Just Work. EV is predicated
on the idea of training users to be cognitively aware of all of the legal
nuance of the organization, and ever vigilent, as a way of absolving site
operators and CAs of their responsibility to make the system better. That's
just bad policy.

[Jakob Bohm]

On 12/12/2017 20:04, Ryan Sleevi wrote:
> On Tue, Dec 12, 2017 at 1:11 PM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>>
>> The overall thing is that the current thread seems to be a major case of
>> throwing the baby out with the bathwater.
>>
>
> That is overly reductive and may demonstrate a lack of understanding of the
> points of criticism.
>
>
>> The entire problem boils down to this:
>>
>
> No, it doesn't.
>
> This is yet another practical demonstration of an overall set of flaws with
> EV, for which those bolsters (which it would be fair to say include you, at
> this point) do not acknowledge the holistic set of issues - or their
> fundamental failure.
>
> For those involved in the regular, day to day involvement with PKI, these
> sets of concerns are well at the forefront of our minds, but in the event
> you may not be familiar:
>

What you are writing below, with far too many words is that you think
that URLs are the only identities that matter in this world, and
therefore DV certificates are enough security for everyone.

> The EV Guidelines establish what CAs (rightly or wrongly) believe as the
> purpose of EV, as noted in Section 2.1 of
> https://cabforum.org/wp-content/uploads/EV-V1_6_6.pdf
> - 2.1.1 (1) does not require special UI treatment

2.1.1(1) most certainly requires an UI that displays that legal entity
identity. It does not require suppressing legal entity identities
verified at a lower confidence level (OV certs). I have myself filed
bug comments to this effect.

> - 2.1.1 (2) is not necessary - DV already achieves that

But DV doesn't tie the encrypted connection to 2.1.1(1).

> - 2.1.2 (1) is demonstrably false

2.1.2 (1) is a lofty and difficult goal. But 2.1.2 (2) helps in this
regard.

If the vetting is as strong as it should be for EV, the evidence of
tying to a real legal entity will also be strong enough to facilitate
2.1.2 (3).

> - While Ian's example is yet another part of this, there's nothing
> fundamental within EV certificates that achieves 2.1.2 (1), because that
> goal is itself so ill-defined that it fundamentally is unachievable.

The "Spring Inc." (Kentucky) contributes towards achieving 2.1.2 (1) by
actually requiring the phisher to pass whatever requirements are imposed
by a government entity within the victim country (because the EV UI
shows the country directly). This reduces the attack surface from all
global domain name registrars to the national set of government company
registration authorities, and whatever anti-fraud security precautions
are imposed on them by the same governments that actually have courts
and police forces applicable to fighting online phishing scams.

Registering a company in Kentucky will not get you an EV certificate
that pretends to be in Canada, Mexico or France. Registering a company
in Italy will not get you an EV certificate that pretends to be in the
US.

Displaying the actual jurisdictionOfIncorporation (not just the country)
would further reduce the attack surface to the actual operating location
(such as California) and any common generic locations in that country
(Delaware, New York, etc.).

> - CAs who believe that biased marketing surveys are equivalent to
> peer-reviewed research would have you believe that "Out of 100 phishing
> sites we saw, none used EV, therefore, EV is more secure", therefore this
> goal is achieved. This is so scientifically unsound and methodogically
> flawed that it should be laughed out of serious discussion, yet they
> continue to peddle such abject logically unsound rubbish. They might as
> well shout "fake news" for all the credibility should be afforded to them.

I have not used any such nonsense in my argumentation.

> - Sticklers for this point will typically suggest this can be achieved
> through one of three means - "temporal risk", "financial cost", or "legal
> risk" - namely:

> - because an EV cert takes longer (temporal), it reduces risk because
> people don't want to wait (ignoring the fact that some CAs will turn out an
> EV cert in hours)

That might be a missing requirement in the EV guidelines. i.e. "If not
renewing a certificate or otherwise dealing with a long established CA
subscriber relationship, EV vetting should not be considered complete
until at least 1 week has passed since the vetting began. During such a
delay, the CA must monitor any relevant places where identity frauds are
likely or required to be reported to ensure that any quickly reported
fraud cannot result in issuance to someone other than the true
identity".

However none of my arguments for keeping EV require this.

> - because an EV cert has, on average, a substantially higher cost
> (financial) than a DV cert, it serves as a bar to entry for attackers who
> would otherwise not want to use money (ignoring that attackers,
> particularly phishers, already have a network of credentials and resources
> to charge against)

There could be requirements that the payment means (credit card, PO
etc.) is legally tied to the vetted entity. This would limit the use of
stolen payment resources to impersonating the legit holders of same (or
getting a bank to issue payment means for the wrong identity).

However none of my arguments for keeping EV require this.

> - because an EV cert requires some sort of legal identity, they're
> exposing themselves to risk of identification (ignoring work like James' or
> Ian's, because, well, that's convenient)

Is there any report that James or Ian did not have to use their real
identities to set up the companies? If they didn't, there's something
wrong with the administration of that company jurisdiction.

> - 2.1.2 (3) does not require any UI - that's purely on the backend
>

Of cause.

> So the whole premise for why there should be *any* UI treatment is
> predicated on 2.1.2 (2), which clearly spells out that EV is a marketing
> tool, wrapped in the guise of a security tool. I do not feel you can offer
> a more charitable read of that section.
>

That is not what it says. At all. It says that it should be a way
for genuine businesses to show they are "not a dog", but someone who
exist in a very real sense, at least to the extend that laws enforce
such requirements in the offline world.

For major phishing targets such as banks they can (and do!) include
notifications in their brochures etc. telling customers to only type
their identity in if there is a green bar with the banks name next to
the URL.

This is to ensure that the only ways to bypass EV is to compromise the
Banks' genuine systems (directly or indirectly), or to compromise a
government office dedicated to establishing company identities (which
may be easy in Kentucky).

> And what do we get for that browsers selling, rent-free, their critical UI
> space of billions of users?
>
> Well,
> 2.1.3 (1) - No assurances that they're doing business
> 2.1.3 (2) - No assurances that they comply with applicable laws
> 2.1.3 (3) - No assurances that they're trustworthy, honest, or reputable
>

That just spells out the very real and good principle that the issuance
of *identity* documents does not vouch for the *quality* of the
individual or company.

>
> Literally the entire value proposition of EV reduces to "CAs want to sell
> billboards in the browser's security UI". And the fundamental point is that
> such UI is security critical - it's the line of death between trustworthy
> and untrustworthy content (
> https://textslashplain.com/2017/01/14/the-line-of-death/ ).
>

> The goal is to ensure this URL bar requires as little cognitive thought
> possible - you should be able to quickly determine if you're at where you
> expect, where "where you expect" is the URL. And the URLs you use should
> use systems that do not rely on users checking that - e.g., they should be
> using origin bound credentials (WebAuthN/U2F), they should be using
> browser/password manager mediated identities (Credentials API), etc.
>

"Where you expect" is NOT the URL. It is the real world entity you want
to talk to. EV and OV tie the URL to someone real, such as the bank
around the corner or the well known company you want to do business
with.

> This isn't throwing the baby out with the bathwater. This is recognizing
> that having a billboard of things users are also supposed to know or else
> we get to blame them when things go wrong is bad policy, bad security, and
> actively hostile to users. Let's not let idealism get in the way of the
> pragmatic reality that the most important job a browser has is keeping
> users safe and secure, the most effective way to do that is to keep things
> as simple as possible (so that all people, of all skillsets, can enjoy the
> Web), and the simplest way to security is to get users to the point of not
> having to think about it, because the systems Just Work. EV is predicated
> on the idea of training users to be cognitively aware of all of the legal
> nuance of the organization, and ever vigilent, as a way of absolving site
> operators and CAs of their responsibility to make the system better. That's
> just bad policy.
>

Having a billboard of things to blame the user for not knowing is
certainly the wrong way to use this. Having something easy to check
like a policeman wearing an official badge helps users reject obvious
fakes, thus making it harder for any random fraudster to just tell
people they are cops / banks / shops.

Victims should not be blamed for being defrauded, but they should still
be helped not to be.

[Michael Pietsch]

Would it be reasonable to have some sort of global database where the company
names and other identifiers that can be displayed in UI will be stored including
some sort of contact data?
In the validation process for EV the CA could then be required to contact the
companies with similar names (define use of levenshtein distance or other algorithms to find them) and give them time to respond to a new EV certificate request.

With that the companies could at least take some sort of legal actions to prevent malicious use of the EV cert mentioning their company name.

[Ryan Sleevi]

On Tue, Dec 12, 2017 at 3:44 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> What you are writing below, with far too many words is that you think
> that URLs are the only identities that matter in this world, and
> therefore DV certificates are enough security for everyone.

Yes. This is the foundation and limit of Web Security.

https://en.wikipedia.org/wiki/Same-origin_policy

This is what is programatically enforced. Anything else either requires new
technology to technically enforce it (such as a new scheme), or is
offloading the liability to the user.

Respectfully, I would encourage you to re-read both Ian's and James'
research. For example, you will find that the organization being discussed
is "Stripe, Inc", not "Spring, Inc" - a mistake made frequent enough to not
be charitably attributabed as a typo. The question about the level of
stringency on the validation requirements has also been responded to, as
well as the deficiencies of "Well, they'd have to lie to do so" as a
response.

The remainder of your argument basically boils down to "But Banks already
are offloading the liability to users when they say check for the green
bar" (and that is bad, user hostile, and unsustainable), and the "Look for
the corporate identity" has been shown repeatedly to be insufficient and
incomplete that if that is the response you'd offer, then it's not
introducing new information into the conversation.

I agree that we should be concerned about potential fraud, and there are
far more user-friendly technologies that can help mitigate that - as I
mentioned. That doesn't mean that getting rid of EV UI is throwing the
proverbial baby out - it means having the maturity to accept that some
technological experiments don't pan out, and as good engineers and
socially-responsible developers, we should recognize when certain features
are causing systemic harm to users overall security. I realize the innate
appeal to "Let users decide" by giving them an option, but a trivial survey
of human-computer interaction literature should reveal the flaw in that. If
that is too much to ask, reading about "Analysis Paralysis", "Decision
Fatigue", and "Information Overload" on Wikipedia should all provide
sufficient background context.

So we have to circle back to the core question:
- Is the display of the UI, as implemented today, meaningful and useful for
the problems it tries to solve and the cognitive overhead it introduces to
billions of users. If not, are there plans to remove it?

"Showing more information" is not a viable answer - it results in a worse
outcome for users.
"Improve the validation" presumes that the information is viable and
useful, which goes against the SOP. (Read [1] if you're not sure why that's
bad)

[1] http://www.adambarth.com/papers/2008/jackson-barth-b.pdf

[Kristian Fiskerstrand]

On 12/12/2017 12:21 AM, Hanno Böck via dev-security-policy wrote:
> Hi,
>
> On Mon, 11 Dec 2017 11:01:10 -0800 (PST)

> Ryan Sleevi via dev-security-policy

> <dev-secur...@lists.mozilla.org> wrote:
>
>> I suppose this is both a question for policy and for Mozilla - given
>> the ability to provide accurate-but-misleading information in EV
>> certificates, and the effect it has on the URL bar (the lone trusted
>> space for security information), has any consideration been given to
>> removing or deprecating EV certificates?

> I support the removal of special treatments and UI for EV
> certificates.
>
> Rationale: I believe plenty of security research shows that it is
> incredibly hard to communicate security indicators to users. If you ask
> average users about the meaning of green locks, green URL bars or
> anything else they will usually not know what it means.
>

> This lets only one sensible conclusion: Security indicators should be
> removed. The goal should be to have one security level that is the
> default (HTTPS+DV) and make that as secure as possible. The community
> should therefore try to strengthen the CA ecosystem as a whole and not
> try to make any "special" certificates.

For what it is worth, I'm also supporting removal of special UI elements
for EV certificates. Users tends to be easily swayed one way or the
other, and if it is to have any value the checks necessary exceeds what
is natural for a CA in the ecosystem.

--
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3

[Jakob Bohm]

On 12/12/2017 22:51, Ryan Sleevi wrote:
> On Tue, Dec 12, 2017 at 3:44 PM, Jakob Bohm via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> What you are writing below, with far too many words is that you think
>> that URLs are the only identities that matter in this world, and
>> therefore DV certificates are enough security for everyone.
>
>
> Yes. This is the foundation and limit of Web Security.
>
> https://en.wikipedia.org/wiki/Same-origin_policy
>
> This is what is programatically enforced. Anything else either requires new
> technology to technically enforce it (such as a new scheme), or is
> offloading the liability to the user.
>

What is *programmatically* enforced is too little for human safety.
believing that computers can replace human judgement is a big mistake.
Most of the world knows this.

That is why there is such a thing as identity documents in the real
world. Because humans often need to know who they are talking to, not
just that they have a vanity plate and a company logo on their white
van.

Humans have opinions about and relationships with other humans and
human-operated companies. The prominent display of CA vetted identity
information in addition to the self-selected network address (URLs)
provides this information to human users as part of their decision
process. The way the information is presented is very similar to how
such information is presented in real world trust scenarios: Id cards
pinned to the clothes or hanging around the neck. Official business
license framed on the wall behind the counter. Official health and
safety inspection report posted at the door. People glance to see it is
there, occasionally reads just enough to see if it looks right, taking
comfort in the other party not knowing if today is the day you will do
actually read and not just glance.

You need to understand that not every trust begins and ends with a
Google search for a URL. The more real the stakes are, the more real
the basis of trust needs to be. Sometimes people are just commenting on
a blog and don't care much of the blogger is even a real person.
Sometimes people buy cheaper items online and just need to know that
their credit card transaction is not visible to a random company (hence
the common practice of outsourcing the entry of card details to a
reputable clearing service that promises not to hand the credit card
number back to the seller). Sometimes people make bigger purchases and
need the assurance that there is a real company at the other end, which
can (if necessary) be sued for non-delivery. Sometimes people make
really big transactions and need to know that they are dealing with a
real world entity that they have a real world trust relationship with.

> Respectfully, I would encourage you to re-read both Ian's and James'
> research. For example, you will find that the organization being discussed
> is "Stripe, Inc", not "Spring, Inc" - a mistake made frequent enough to not
> be charitably attributabed as a typo. The question about the level of
> stringency on the validation requirements has also been responded to, as
> well as the deficiencies of "Well, they'd have to lie to do so" as a
> response.
>

I have been copying the example name from message to message, with noone
objecting. Saving up this mistake for use as ammunition when you run
out of arguments is not a nice way to argue.

> The remainder of your argument basically boils down to "But Banks already
> are offloading the liability to users when they say check for the green
> bar" (and that is bad, user hostile, and unsustainable), and the "Look for
> the corporate identity" has been shown repeatedly to be insufficient and
> incomplete that if that is the response you'd offer, then it's not
> introducing new information into the conversation.
>

No, I was using the awareness campaigns by banks as an example of how
users can be, and have been, trained to use the EV UI even if they don't
fully understand it. It was a counterexample to your use of misleading
statistics about how few users understand the nuances of EV
certificates.

> I agree that we should be concerned about potential fraud, and there are
> far more user-friendly technologies that can help mitigate that - as I
> mentioned. That doesn't mean that getting rid of EV UI is throwing the
> proverbial baby out - it means having the maturity to accept that some
> technological experiments don't pan out, and as good engineers and
> socially-responsible developers, we should recognize when certain features
> are causing systemic harm to users overall security. I realize the innate
> appeal to "Let users decide" by giving them an option, but a trivial survey
> of human-computer interaction literature should reveal the flaw in that. If
> that is too much to ask, reading about "Analysis Paralysis", "Decision
> Fatigue", and "Information Overload" on Wikipedia should all provide
> sufficient background context.

I am saying that your view of what the EV system achieves and has
already achieved is completely biased and flawed.

>
> So we have to circle back to the core question:
> - Is the display of the UI, as implemented today, meaningful and useful for
> the problems it tries to solve and the cognitive overhead it introduces to
> billions of users. If not, are there plans to remove it?
>

I am saying it *does* achieve its goal of helping to protect users
against misleading domain names, but not perfectly. It also achieved
the goal of getting CAs to provide a more thorough vetting of OV
certificates by providing a way to sell thoroughly vetted EV
certificates despite the higher real cost (in man hours etc.) above more
sloppy OV practices.

> "Showing more information" is not a viable answer - it results in a worse
> outcome for users.

Only if you believe that hiding essential information from users is an
honest thing to do.

> "Improve the validation" presumes that the information is viable and
> useful, which goes against the SOP. (Read [1] if you're not sure why that's
> bad)
>
> [1] http://www.adambarth.com/papers/2008/jackson-barth-b.pdf
>

EV requirements are supposed to ensure that the information is viable,
useful and correct, it is specifically supposed to ban any problematic
operating procedures of 10 years ago. If there are CA practices that
undercut that, the requirements need to be strengthened. If there are
government practices undercutting that (e.g. by allowing companies to
register misleading names or to be created with no firm link to a
prosecutable person), then that is a general society problem not limited
to the Internet context.

[Ryan Sleevi]

On Wed, Dec 13, 2017 at 6:29 AM Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

>
> > Yes. This is the foundation and limit of Web Security.
> >
> > https://en.wikipedia.org/wiki/Same-origin_policy
> >
> > This is what is programatically enforced. Anything else either requires
> new
> > technology to technically enforce it (such as a new scheme), or is
> > offloading the liability to the user.
> >
>

> What is *programmatically* enforced is too little for human safety.
> believing that computers can replace human judgement is a big mistake.
> Most of the world knows this.

That is a misguided and inaccurate rephrasing.

However, it still shows that you are fundamentally taking the view point
that:
1) Users should be responsible and bear the liability (straight up user
hostile)
2) This information is as critical as the one piece of truly guarantees
information, the URL (it isn’t)
3) It is a usable solution to require the visual determination as to
whether a given piece of information is present - that is, a positive
indicator (where both general studies AND browser specific studies show
this doesn’t work)

You aren’t adding to this, you’re simply phrasing your view that this
information is valuable. You haven’t responded to these points as to the
user experience, or the research, but instead theorize about how it should
be, or power users, or user education, all while ignoring the substance of
these realities.

>
> You need to understand that not every trust begins and ends with a
> Google search for a URL.

You need to understand that EV specifically states it is not for this
purpose. As already provided to you from the EVGs.

>
> Sometimes people buy cheaper items online and just need to know that
> their credit card transaction is not visible to a random company (hence
> the common practice of outsourcing the entry of card details to a
> reputable clearing service that promises not to hand the credit card
> number back to the seller).

EV does not provide this. This is just a basic understand of the technology.

Sometimes people make bigger purchases and
> need the assurance that there is a real company at the other end, which
> can (if necessary) be sued for non-delivery.

EV EXPLICITLY does not provide this. Read the EVGs.

Sometimes people make
> really big transactions and need to know that they are dealing with a
> real world entity that they have a real world trust relationship with.

EV EXPLICITLY does not provide this. Read the EVGs.

I have been copying the example name from message to message, with noone
> objecting. Saving up this mistake for use as ammunition when you run
> out of arguments is not a nice way to argue.

Getting upset doesn’t undermine the fact that you’ve continued to make
mistakes that have already been addressed in both the original research and
past replies to you. The discussion has not been moved forward by the
points you’ve raised, because they’ve already been shown to be logically or
factually flawed and unsupported. I do hope that you will revisit these and
see how the points you’ve raised - even in this very message - are already
disputed by the research, design, and technology.

> The remainder of your argument basically boils down to "But Banks already
> > are offloading the liability to users when they say check for the green
> > bar" (and that is bad, user hostile, and unsustainable), and the "Look
> for
> > the corporate identity" has been shown repeatedly to be insufficient and
> > incomplete that if that is the response you'd offer, then it's not
> > introducing new information into the conversation.
> >
>

> No, I was using the awareness campaigns by banks as an example of how
> users can be, and have been, trained to use the EV UI even if they don't
> fully understand it. It was a counterexample to your use of misleading
> statistics about how few users understand the nuances of EV
> certificates.

It is hardly a counter-example. It continues to be unsupported by data, by
the extant user studies contradicting your conclusions and belief - that
they are effective and users understand - and themselves still rely on the
fundamentally flawed approach of shifting the liability to the user to make
sense of the legal identity.

You have yet to respond to the substance of this basic model about users -
continuing to insist that somehow it’s reasonable to expect billions of
users to be aware of an interface that shows the jurisdictional nuance in a
critical UI point. It’s hnclear whether or not you even acknowledge the
current flaws - I would hope, given your earlier proposal to display the
full jurisdictional information, that you can at least acknowledge that EV
as it presently exists is insufficient UI and insufficient validation for
the status afforded it. At best, your view seems to be to double down on
promoting a user-hostile, unrealistic workflow, by adding even more
information (ignoring the research and basic cognitive challenges I pointed
out to you), restricting the access even further (ignoring the inherent
limitations of that, as demonstrated by WIPO), and then expecting users to
understand this even more nuanced approach of limitations.

None of this has changed from when we first started discussing, and you
haven’t meaningfully engaged on these basics, other than providing your
opinion - which, while valuable, doesn’t dispute or disprove those issues
above.

> I am saying that your view of what the EV system achieves and has
> already achieved is completely biased and flawed.
>

Cool. Well, since you won’t engage in the substance - where I provided the
supporting facts and basic positions for the conclusions, and walked you
through how they are arrived at - and are willing to hold the line on this
opinion despite it being unsubstantiated by the facts, then we’re done.
You’re not engaging with anything more than opinions and stories about how
it ought to be, so I haven’t learned anything new from you that wasn’t
already discounted or disproved. You’re either not willing to read the
research - or even the original issues - or not convinced by the years of
academic research showing your conclusions aren’t supported, so theres no
point trying to convince you of these facts.

The lack of engagement on, or discussion of, origins perhaps best
illustrates how fundamentally ineffective this conversation has been -
because that is the starting point, in any conversation, yet it is
continually deflected or ignored.

[Nick Lamb]

On Wed, 13 Dec 2017 12:29:40 +0100

Jakob Bohm via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> What is *programmatically* enforced is too little for human safety.
> believing that computers can replace human judgement is a big mistake.
> Most of the world knows this.

That's a massive and probably insurmountable problem then since the
design of HTTPS in particular and the way web browsers are normally
used is _only_ compatible with programmatic enforcement.

Allow me to illustrate:


Suppose you visit your bank's web site. There is a lovely "Green
Bar" EV certificate, and you, as a vocal enthusiast for the value of
Extended Validation, examine this certificate in considerable detail,
verifying that the business identified by the certificate is indeed
your bank. You are doubtless proud that this capability was available
to you.


You fill in your username and password and press "Submit". What happens?


Maybe your web browser finds that the connection it had before to
the bank's web site has gone, maybe it timed out, or there was a
transient network problem or a million other things. But no worry, you
don't run a web browser in order to be bothered with technical minutiae
- the browser will just make a new connection. This sort of thing
happens all the time without any trouble.

This new connection involves a fresh TLS setup, the server and browser
must begin again, the server will present its certificate to establish
identity. The web browser examines this certificate programmatically to
decide that it's OK, and if it is, the HTTPS form POST operation for
the log in form is completed by sending your username and password over
the new TLS connection.


You did NOT get to examine this certificate. Maybe it's the same one as
before, maybe it's slightly different, maybe completely different, the
hardware (let alone software) answering needn't be the same as last
time and the certificate needn't have any EV data in it. Your web
browser was happy with it, so that's where your bank username and
password were sent.

Even IF you decide now, with the new connection, that you don't trust
this certificate, it's too late. Your credentials were already
delivered to whoever had that certificate.



Software makes these trust decisions constantly, they take only the
blink of an eye, and require no human attention, so we can safely build
a world that requires millions of them. The moment you demand human
attention, you not only introduce lots of failure modes, you also use
up a very limited resource.

Perhaps you feel that when browsing the web you make a conscious
decision about trust for each site you visit. Maybe, if you are
extraordinarily cautious, you make the decision for individual web
pages. Alas, to be of any use the decisions must be taken for every
single HTTP operation, and most pages will use dozens (some hundreds)
of such operations.

[Jakob Bohm]

I have been trying very hard to engage at the substance, but you keep
misunderstanding my statements and then answering that strawman.

So lets reiterate:

- I do not suggest assigning *liability* to the user.

- I do suggest *helping the user* make informed decisions of the kind
that humans traditionally make in the offline world. Decisions such as
"does this look like a safe place to eat?". "Does something look wrong
about this?".

- I suggest that users *want to know* who the *real world entity* behind
a website is before doing certain things in relationship to that real
world entity (possibly through the website, possibly not).

- I suggest that the EV UI provides *useful information* to human users
deciding if they want to interact with a real world entity.

- I suggest that EV certificates *do provide the warranties* listed in
section 7.1 of the EV guidelines.

- I suggest that the exclusions in section 2.1.3 of the EV guidelines
simply mean the CA does not judge or police companies, *only check
their identities*. This does not contradict the section 7.1 warranties.

- I suggest that statistics about how little users understand the EV
user interface and ecosystem do not provide any information about the
practical usefulness of what little they do understand. I do not claim
to have statistics about that usefulness, which can only be measured
from comparing real world events that are sufficiently similar, or by
very carefully conducted behavioral experiments (not to be confused
with A/B experiments on unwilling participants).

[Tim Shirley]

So many of the arguments made here, such as this one, as well as the recent demonstrations that helped start this thread, focus on edge cases. And while those are certainly valuable to consider, they obscure the fact that “Green Bar” adds value in the mainstream use cases. If we were talking about how to improve EV, then by all means focus on the edge cases. The thing I don’t see in all this is a compelling argument to take away something that’s useful most of the time.

As an employee of a CA, I’m sure many here will dismiss my point of view as self-serving. But when I am making trust decisions on the internet, I absolutely rely on both the URL and the organization information in the “green bar”. I relied on it before I worked for a CA, and I’m pretty sure I’ll still rely on it after I no longer work in this industry (if such a thing is even possible, as some in the industry have assured me it’s not).

Sure, I don’t pay attention if I’m just reading the news or something. But before I enter credentials or credit card info into a web page, I absolutely look at both the URL and the organization name to see if they match my expectations. If the company name shown is not what I expected or if it’s absent altogether, that’s a red flag to me to either do a little more research before proceeding, or abandon it altogether. I agree, James & Ian’s demonstrations show cases where the information presented was not effective for the end user. But it seems an incredible leap to me to go from a couple of demonstrated shortcomings to suggesting outright removal of something that is useful most of the time. It also seems that if you follow that line of thinking, you have to also advocate for removing the URL from display. If “Identity Verified” as a company name is going to confuse some people into trusting the site, then couldn’t I also confuse many of the same people by registering “identity-verified.com” or some variant?

I don’t claim to speak for anyone but myself as a web user here. I probably view a web site with more suspicion than most of the general public, as a result of the nature of my work. The majority of users are probably going to make their trust decisions purely based on whether or not the browser jumps in with an interstitial warning them that it’s a known malicious site. Absent that, they’re going to trust that if the page has Megabank’s logo on it, then it’s really Megabank. While I appreciate the value the malicious site filters are providing me, they can’t know about every bad site, and I’m not willing to fully outsource my trust decisions to them. Safari’s decision to hide the URL and only display the organization name on a site with an EV cert is a deal-killer to me using it, because it’s taking away information I rely on. Similarly, if Firefox were to remove the EV indicator, that would be more than enough reason for me to switch to another browser that still had it. Of course a scenario like Nick describes could happen to subvert my decision. Of course I might make a human mistake in interpreting the displayed organization name in a particular instance. But what I am confident of is, in the totality of my web usage, my credentials / credit card / whatever will be sent to wrong people less times if you give me that information than if you hide it from me.

On 12/13/17, 12:38 PM, "dev-security-policy on behalf of Nick Lamb via dev-security-policy" <dev-security-policy-bounces+tshirley=trustw...@lists.mozilla.org on behalf of dev-secur...@lists.mozilla.org> wrote:

On Wed, 13 Dec 2017 12:29:40 +0100

Jakob Bohm via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:

> What is *programmatically* enforced is too little for human safety.
> believing that computers can replace human judgement is a big mistake.
> Most of the world knows this.

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org

https://scanmail.trustwave.com/?c=4062&d=p-Wx2sFhk_SN5yb-p3zLmDnjwtEJBCCLSXdwG-cNGw&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy

[Ryan Sleevi]

On Wed, Dec 13, 2017 at 12:58 PM, Tim Shirley via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> As an employee of a CA, I’m sure many here will dismiss my point of view
> as self-serving. But when I am making trust decisions on the internet, I
> absolutely rely on both the URL and the organization information in the
> “green bar”. I relied on it before I worked for a CA, and I’m pretty sure
> I’ll still rely on it after I no longer work in this industry (if such a
> thing is even possible, as some in the industry have assured me it’s not).
>

I think the focus on the edge cases has been because even the case you
raise here (and below), can be demonstrated as technically flawed.

You believe you're approaching a sense of security, but under an
adversarial model, it falls apart.

The historic focus has been on the technical adversary - see Nick Lamb's
recently reply a few minutes before yours - and that's been thoroughly
shown that EV is insufficient under an attacker model that is 'on the
wire'. However, EV proponents have still argued for EV, by suggesting that
even if its insufficient for network adversaries, it's sufficient for
organizational adversaries. Ian's and James' research shows that's also
misguided.

So you're not wrong that, as a technically skilled user, and as an employee
of a CA, you've come to a conclusion that EV has value, and conditioned
yourself to look for that value being expressed. But under both adversarial
models relative to the value EV provides, EV does not address them. So what
does the UI provide, then, if it cannot provide either technical
enforcement or "mental-model" safety.

Are you wrong for wanting those things? No, absolutely not. They're
perfectly reasonable to want. But both the technical means of expressing
that (the certificate) and the way to display that to the user (the UI
bar), neither of these hold up to rigor. They serve as placebo rather than
panacea, as tiger repelling rocks rather than real protections.

Since improving it as a technical means is an effective non-starter (e.g.
introducing a new origin for only EV certs), the only fallback is to the
cognitive means - and while users such as yourself may know the
jurisdictional details for all the sites they interact with, and may have a
compelling desire for such information, that doesn't necessarily mean it
should be exposed to millions of users. Firefox has about:config, for
example - as well as extensions - and both of those could provide
alternative avenues with much greater simplicity for the common user.

[Jakob Bohm]

I would be sorely disappointed and consider it a security bug if a
browser shows one validated certificate then submits a posted form to a
connection with a substantially different certificate. There may be a
(very short) list of permitted variations for cases such as server farms
with separate private keys per server. But any real change of
certificate mid-transaction should be blocked the same way cross-domain
posting is usually blocked.

Checking for certificate equality is an easy programmatic task, deciding
if a real world entity is trustworthy is not.

> Even IF you decide now, with the new connection, that you don't trust
> this certificate, it's too late. Your credentials were already
> delivered to whoever had that certificate.
>
>
>
> Software makes these trust decisions constantly, they take only the
> blink of an eye, and require no human attention, so we can safely build
> a world that requires millions of them. The moment you demand human
> attention, you not only introduce lots of failure modes, you also use
> up a very limited resource.
>
> Perhaps you feel that when browsing the web you make a conscious
> decision about trust for each site you visit. Maybe, if you are
> extraordinarily cautious, you make the decision for individual web
> pages. Alas, to be of any use the decisions must be taken for every
> single HTTP operation, and most pages will use dozens (some hundreds)
> of such operations.
>

[Ryan Sleevi]

On Wed, Dec 13, 2017 at 1:19 PM, Jakob Bohm via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> I would be sorely disappointed

Prepare to be sorely disappointed

> and consider it a security bug

It is not a bug. It is not part of the security boundary of the Web, thus
WontFix/WorkingAsIntended. Feature Requests to change this behaviour will
be closed, with reference to "Beware Finer Grained Origins", which explains
the flaws in that.

> if a
> browser shows one validated certificate then submits a posted form to a
> connection with a substantially different certificate.

This is what browsers do. As referenced earlier in the discussion about
Same Origin Policy, and more generally, the security notion of origins - as
these two certificates do not constitute distinct origins, they are the
same in privilege, capability, and trust. That is how the Web works. This
has been mentioned several times, but I'm greatly appreciative for Nick
spelling it out, as it does seem some degree of progress has been made in
arriving at common talking points.

> There may be a
> (very short) list of permitted variations for cases such as server farms
> with separate private keys per server. But any real change of
> certificate mid-transaction should be blocked the same way cross-domain
> posting is usually blocked.
>

They are not blocked. This is also covered in the SOP and how the web works.

> Checking for certificate equality is an easy programmatic task, deciding
> if a real world entity is trustworthy is not.

Unquestionably. Yet using certificates to do so is both technically and
procedurally deficient.

[Tim Shirley]

I don’t dispute your claims if the attacker is ‘on the wire’; what I dispute is that that is actually the case most of the time. I’d think a far more common case is one in which I receive an email, purportedly from my bank, but containing a URL that isn’t the one I recognize as my bank’s. Usually that’s a scam, but sometimes it’s a legit separate domain they have for the credit card rewards program or something like that. Or a case where I am typing a known URL and I fat-finger something and stumble onto a scammer’s site. The immediate absence of the EV organization name is going to help me detect that I’m not where I want to be.

BTW, I looked at these things long before I was in the CA business, so if I was “conditioned” it must have been by the outside world. ☺

From: Ryan Sleevi <ry...@sleevi.com>
Reply-To: "ry...@sleevi.com" <ry...@sleevi.com>
Date: Wednesday, December 13, 2017 at 1:18 PM
To: Tim Shirley <TShi...@trustwave.com>
Cc: Nick Lamb <n...@tlrmx.org>, "dev-secur...@lists.mozilla.org" <dev-secur...@lists.mozilla.org>, Jakob Bohm <jb-mo...@wisemo.com>
Subject: Re: On the value of EV

[Ryan Sleevi]

Right, but both Ian and James' research show that it's an unreliable
guarantee for those attacks - you may be relying on it, but it's not safe
for it.

Further, the costs to support your use case - well-intentioned but perhaps
not aligning with the pragmatic reality - affect users who don't do so or
aren't conditioned, by adding further confusion into the nuances of
jurisdictional incorporation.

So if it doesn't meet your intended use case / you're relying on a placebo,
and it harms others, perhaps the UI treatment should go away :)

Note, my focus in all of this discussion has been about the expression of
UI surface in the security-critical section of a browser, and specifically,
asked for Mozillans to comment on their plans (which, of course, had
everyone but them commenting). There may still be value in
EV-as-a-validation, but EV as a phishing mitigation - your scam emails or
such - are not solved by EV. Technically or via validation.

On Wed, Dec 13, 2017 at 1:52 PM, Tim Shirley <TShi...@trustwave.com> wrote:

> I don’t dispute your claims if the attacker is ‘on the wire’; what I
> dispute is that that is actually the case most of the time. I’d think a
> far more common case is one in which I receive an email, purportedly from
> my bank, but containing a URL that isn’t the one I recognize as my bank’s.
> Usually that’s a scam, but sometimes it’s a legit separate domain they have
> for the credit card rewards program or something like that. Or a case
> where I am typing a known URL and I fat-finger something and stumble onto a
> scammer’s site. The immediate absence of the EV organization name is going
> to help me detect that I’m not where I want to be.
>
>
>
> BTW, I looked at these things long before I was in the CA business, so if
> I was “conditioned” it must have been by the outside world. ☺
>
>
>

> *From: *Ryan Sleevi <ry...@sleevi.com>
> *Reply-To: *"ry...@sleevi.com" <ry...@sleevi.com>
> *Date: *Wednesday, December 13, 2017 at 1:18 PM
> *To: *Tim Shirley <TShi...@trustwave.com>
> *Cc: *Nick Lamb <n...@tlrmx.org>, "dev-secur...@lists.mozilla.org" <

> dev-secur...@lists.mozilla.org>, Jakob Bohm <jb-mo...@wisemo.com>

> *Subject: *Re: On the value of EV

>
>
>
>
>
>
>
> On Wed, Dec 13, 2017 at 12:58 PM, Tim Shirley via dev-security-policy <

[Gervase Markham]

On 11/12/17 17:00, Ryan Sleevi wrote:
> Fundamentally, I think this is misleading. It presumes that, upon
> something bad happening, someone can link it back to that certificate
> to link it back to that identity. If I was phished, and entered my
> credentials, there's no reason to believe I've maintained the record
> details including the phishing link to know I was phished. Are users
> supposed to spleunk their HTTP cache or maintain complete archives of
> every link they visited, such that they can get the cert back from it
> to aid an investigation?

This is something that has always worried me about the EV value
proposition. Even if it worked perfectly, once one has realised one has
been scammed, one would want to find the cert again to know where to
serve the lawsuit papers or send the police. Unless your browser caches
all EV certs for sites you've ever visited in the past month, and
provides some UI for querying that cache, then that's not necessarily
going to be possible. So having the info about the site owner in the
cert isn't actually useful.

CT does address this to a degree, but only to a degree.

Gerv

[Gervase Markham]

On 13/12/17 11:58, Tim Shirley wrote:
> So many of the arguments made here, such as this one, as well as the recent demonstrations that helped start this thread, focus on edge cases. And while those are certainly valuable to consider, they obscure the fact that “Green Bar” adds value in the mainstream use cases. If we were talking about how to improve EV, then by all means focus on the edge cases. The thing I don’t see in all this is a compelling argument to take away something that’s useful most of the time.

My concern with this argument is that it's susceptible to the criticism
that Adam Langley made of revocation checking:
https://www.imperialviolet.org/2012/02/05/crlsets.html

"So [EV identity is] like a seat-belt that snaps when you crash. Even
though it works 99% of the time, it's worthless because it only works
when you don't need it."

Gerv

[Tim Shirley]

I’m not looking for a guarantee. Nothing is ever going to meet that standard. What I’m looking for is something that’s going to improve my odds. What I see in Ian’s and James’s research is some ways that it’s possible to create confusion, accidentally or deliberately. But I haven’t heard of any real world cases where such deception was used deliberately to date. And I’d expect, since Certificate Transparency has been required for a couple years now for EV treatment in Chrome, that if such attacks were actually happening in the real world today with EV certificates, we’d know about them and they would be getting trumpeted in this thread.

Why do police wear bulletproof vests when they know they’re entering a dangerous situation? A vest only covers part of the body, so they’re still in danger. I wouldn’t call a bulletproof vest a placebo. It’s a layer of defense, just like EV. I’m not claiming EV “solves” phishing but I am claiming that it mitigates it.

I guess I’m also having a hard time appreciating how the presence of this information is a “cost” to users who don’t care about it. For one thing, it’s been there for years in all major browsers, so everyone has at least been conditioned to its presence already. But how is someone who isn’t interested in the information in the first place being confused by it? And if the mere presence of an organization name is creating confusion, then surely a URL with lots of words and funny characters in it would be confusing people too, and we should remove that too, right?

From: Ryan Sleevi <ry...@sleevi.com>
Reply-To: "ry...@sleevi.com" <ry...@sleevi.com>
Date: Wednesday, December 13, 2017 at 2:01 PM
To: Tim Shirley <TShi...@trustwave.com>

Cc: "ry...@sleevi.com" <ry...@sleevi.com>, Nick Lamb <n...@tlrmx.org>, "dev-secur...@lists.mozilla.org" <dev-secur...@lists.mozilla.org>, Jakob Bohm <jb-mo...@wisemo.com>
Subject: Re: On the value of EV

Right, but both Ian and James' research show that it's an unreliable guarantee for those attacks - you may be relying on it, but it's not safe for it.

Further, the costs to support your use case - well-intentioned but perhaps not aligning with the pragmatic reality - affect users who don't do so or aren't conditioned, by adding further confusion into the nuances of jurisdictional incorporation.

So if it doesn't meet your intended use case / you're relying on a placebo, and it harms others, perhaps the UI treatment should go away :)

Note, my focus in all of this discussion has been about the expression of UI surface in the security-critical section of a browser, and specifically, asked for Mozillans to comment on their plans (which, of course, had everyone but them commenting). There may still be value in EV-as-a-validation, but EV as a phishing mitigation - your scam emails or such - are not solved by EV. Technically or via validation.

On Wed, Dec 13, 2017 at 1:52 PM, Tim Shirley <TShi...@trustwave.com<mailto:TShi...@trustwave.com>> wrote:
I don’t dispute your claims if the attacker is ‘on the wire’; what I dispute is that that is actually the case most of the time. I’d think a far more common case is one in which I receive an email, purportedly from my bank, but containing a URL that isn’t the one I recognize as my bank’s. Usually that’s a scam, but sometimes it’s a legit separate domain they have for the credit card rewards program or something like that. Or a case where I am typing a known URL and I fat-finger something and stumble onto a scammer’s site. The immediate absence of the EV organization name is going to help me detect that I’m not where I want to be.

BTW, I looked at these things long before I was in the CA business, so if I was “conditioned” it must have been by the outside world. ☺

From: Ryan Sleevi <ry...@sleevi.com<mailto:ry...@sleevi.com>>
Reply-To: "ry...@sleevi.com<mailto:ry...@sleevi.com>" <ry...@sleevi.com<mailto:ry...@sleevi.com>>
Date: Wednesday, December 13, 2017 at 1:18 PM
To: Tim Shirley <TShi...@trustwave.com<mailto:TShi...@trustwave.com>>
Cc: Nick Lamb <n...@tlrmx.org<mailto:n...@tlrmx.org>>, "dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>" <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>>, Jakob Bohm <jb-mo...@wisemo.com<mailto:jb-mo...@wisemo.com>>
Subject: Re: On the value of EV

[Matthew Hardeman]

On Monday, December 11, 2017 at 6:01:25 PM UTC-6, Ryan Sleevi wrote:

> > Not really - what matters is that the user insists they got had via a
> > phishing link or other process - that can certainly be verified after the
> > fact
>
>
> No.

Why's that? This is how investigations begin.

>
> - did someone steal their money in a sketchy way, but with apparent user
> > authorization? Further, the user swears back and forth that the green bar
> > was there and they looked to see that it matched the site's name - their
> > bank, PayPal, etc.
>
>
> All users will swear this if it avoids liability. And let’s be honest, it’s
> actively hostile to users to say they bear liability if they don’t do this
> - for every click of the page.

I'm confused. I never suggested that the user's assertion that they saw this would cause any change in liability. In fact, anyone responsible would explain that to the user even as the user tries to report it. The value would be that if the certificate that managed to sway the user can be found and tracked down (which should be possible via CT), the possibility exists that the person(s) responsible for the deception may ultimately be caused to suffer for their deception.

Real world contracts, business relationships, and statutes define who is responsible for what frauds and torts arise in engaging in commerce whether online or not. EV status is not about shifting liability.

A significant value that EV does provide (or at least have strong potential to provide) is the ability of a user to assess the EV certificate and its most essential contents as one additional factor to rely upon in the calculus of whether or not to assume the risk of entering certain confidential data into the website they are visiting.

>
> All EV certs are CT logged, find the cert or homograph from there, track
> > to issuer and validation details, chase the entity document path, etc.

One should presume that if the EV presented certificate confused the user who relied upon it into thinking they were dealing with a particular party, that the contents should contain sequences or homograph sequences that closely mirror what the real site would indicate.

>
> And of course ignoring all the innocent bystanders along the way - such as
> Ian, who has not phished Stripe users.

Security research is legitimate. The people who created these entities and got these certificates are innocent of any crime. What they are not is immune from reasonable investigation to show this. If someone suggested tomorrow that an EV certificate caused that person to believe that they were at the Stripe site, it would be entirely reasonable for any law enforcement agency or investigator to track down these researchers and ask them to explain why they sought certificates and entity creation that seem engineered to deceive. The matter should resolve when they show legitimate cause. This doesn't mean that they should be given a free pass and ignored, if subsequently, someone phishes a Stripe customer by way of a look-alike entity and cert.

[Ryan Sleevi]

On Wed, Dec 13, 2017 at 3:50 PM, Tim Shirley <TShi...@trustwave.com> wrote:

> I’m not looking for a guarantee. Nothing is ever going to meet that
> standard. What I’m looking for is something that’s going to improve my
> odds. What I see in Ian’s and James’s research is some ways that it’s
> possible to create confusion, accidentally or deliberately. But I haven’t
> heard of any real world cases where such deception was used deliberately to
> date.
>

Nor did CAs hear about real-world cases about MD5 or SHA-1 until, well, it
was too late. Look at the fact that the CA/Browser Forum was actively
debating extending SHA-1's lifetime (indefinitely, as proposed by some
CAs), up to the very morning that it was publicly shown as broken - despite
years of warning.

> And I’d expect, since Certificate Transparency has been required for a
> couple years now for EV treatment in Chrome, that if such attacks were
> actually happening in the real world today with EV certificates, we’d know
> about them and they would be getting trumpeted in this thread.
>

Sure, but the CT-derived value doesn't require UI. Or, conversely, are you
saying that EV is only safe with CT, and if (and only if) sites are looking
for confusion?

> Why do police wear bulletproof vests when they know they’re entering a
> dangerous situation? A vest only covers part of the body, so they’re still
> in danger. I wouldn’t call a bulletproof vest a placebo. It’s a layer of
> defense, just like EV. I’m not claiming EV “solves” phishing but I am
> claiming that it mitigates it.
>

But it's an outsourced mitigation - the site operator is being convinced to
buy an EV cert by a CA, but the protection is only effective if the
technical controls work (they don't) or the user's are trained on the
business realities (which I would assert _no one_ is, given the
jurisdictional nuance)

It's not an apples to apples comparison - this isn't defense in depth.

> I guess I’m also having a hard time appreciating how the presence of this
> information is a “cost” to users who don’t care about it. For one thing,
> it’s been there for years in all major browsers, so everyone has at least
> been conditioned to its presence already. But how is someone who isn’t
> interested in the information in the first place being confused by it? And
> if the mere presence of an organization name is creating confusion, then
> surely a URL with lots of words and funny characters in it would be
> confusing people too, and we should remove that too, right?
>

That has been proposed, yes. To some extent, that's what Safari's UI tries
to do, for what we can extrapolate as similar reasonings.

But yes, the complex state of indicators has ample (general) HCI research
supporting it, and even specific to the browser case (e.g.
https://research.google.com/pubs/pub45366.html in more modern times, or
http://www.usablesecurity.org/papers/jackson.pdf going further back). As
far as I'm aware, there has been zero peer-reviewed, academically sound
research demonstrating the value proposition of EV, just anecdata, while
there is a rather extant body showing the harm that complexity causes, both
individually (as earlier referenced) and as applied to connection security
indicators - particularly, positive indicators such as EV (where you must
note the absence of, rather than the presence)

[Matthew Hardeman]

On Wednesday, December 13, 2017 at 2:46:10 PM UTC-6, Gervase Markham wrote:

> My concern with this argument is that it's susceptible to the criticism
> that Adam Langley made of revocation checking:
> https://www.imperialviolet.org/2012/02/05/crlsets.html
>
> "So [EV identity is] like a seat-belt that snaps when you crash. Even
> though it works 99% of the time, it's worthless because it only works
> when you don't need it."

This aspect considers only the potential downsides of improper trust and confidence in the users' mind given improper use of a look-alike certificate leading to a phishing exploit or similar.

There is a benefit of EV certificates that deserves consideration:

There are events, many per day, in which the additional confidence to engage in commerce with a given website is properly enhanced by the user's examination and assessment of the EV presentation. Any such instance is a tangible benefit, deserving -- I believe -- some weight in the discussion even if there were the rare negative outcome.

This is even more the case if there are mitigations to the EV definition, qualifications, validation process, issuance process, etc, which could help.

Just spitballing, one enhancement to the EV issuance might be to require that upon validation, the proposed EV entity name and jurisdiction name proposed to be included in the certificate have a 30 days publish-for-opposition embargo. It would arise each time a new EV validation is performed, including for EV validation renewals. Further certificates could issue or re-issue within the validation life time. A natural service that would arise from this would be that CAs would presumably police this publish-for-opposition database for their own customers' EV names and name-a-likes, working with their existing customer to object to and stop issuance of the (presumed) phishing certificate request.

Another thing that should not be problematic for legitimate businesses -- even gigantic ones -- is to require that EV certificate qualification and validation process identify a strongly identified individual (government photo ID, etc) be explicitly authorized by the applying entity as authorized to request EV certificates for the entity -- and furthermore -- document within the certificate the name, jurisdiction, and nature of documents verifying that person's identification.

Would Ian have requested a certificate for Stripe, Inc. if his full name were also in that certificate? Maybe, maybe not. But anyone investigating that certificate would need do no extra work to know what individual they should start communicating with to further discern the history and use of that certificate and the associated entity.

[Ryan Sleevi]

On Wed, Dec 13, 2017 at 4:14 PM, Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Monday, December 11, 2017 at 6:01:25 PM UTC-6, Ryan Sleevi wrote:
>
> > > Not really - what matters is that the user insists they got had via a
> > > phishing link or other process - that can certainly be verified after
> the
> > > fact
> >
> >
> > No.
>
> Why's that? This is how investigations begin.
>

I think you're operating on a somewhat reductionist view that doesn't align
with the real world experiences of users. That's not to say it doesn't make
a good narrative, and one that concievably could happen, but it doesn't
align with the common cause.

An example that I admit is contrived, but no more than I think your
original case was, is a user on an ephemeral messaging app receiving a
link. No 'investigation' can happen because that message is no longer
available. You can replace this with "I deleted the email after I got
hacked" or "I think I clicked on something, I'm not sure" (such as a banner
ad).

Further, fraud itself is based on cost. The investigatory cost of finding
'what' hacked the user and 'when' is a profoundly expensive case, and thus
the cost of doing that (routinely) versus the cost of eating the fraud
and/or shifting the liability quickly is the attractive cost. This is no
different then the real-world where storefronts build in models for 'loss'
(that is, shoplifting), because the cost to the brand and the store to
aggressively police such quickly outweighs the potential losses.

>
> I'm confused. I never suggested that the user's assertion that they saw
> this would cause any change in liability. In fact, anyone responsible
> would explain that to the user even as the user tries to report it. The
> value would be that if the certificate that managed to sway the user can be
> found and tracked down (which should be possible via CT), the possibility
> exists that the person(s) responsible for the deception may ultimately be
> caused to suffer for their deception.
>

The problem is that you are shifting the liability to the user, but may not
be realizing it. Your presumed model is that the information that swayed
the user was correct and accurate to the extent the user was fooled. Yet
there's no reason to believe the user checked for "Stripe, Inc [US]", they
could have just looked for "Striping, Inc [US]" and not realized the
confusion.

I also think you're unrealistically relying on CT to detect what you
believe may be modeled as fraud (expecting, I presume, something similar to
Ian's level of attack), whereas I'm saying even at the most bare minimum,
this doesn't functionally mitigate, because it's still assuming the user
has checked the URL bar to ensure there's enough similarity such that you
would be able to, with some model (ML? what) detect other certs that
'maybe' were involved - but you can't be sure, since Ian's "Stripe, Inc" is
a fully legitimate certificate, so you don't *know* he was involved.

> One should presume that if the EV presented certificate confused the user
> who relied upon it into thinking they were dealing with a particular party,
> that the contents should contain sequences or homograph sequences that
> closely mirror what the real site would indicate.
>

But there's the rub - for EV to be valuable, you're saying the
responsibility *is* on the user to do *at minimum* that level of checking.
If they haven't, then you can't link - because you can't expect that it
will contain sequences or homoglyphs or homographs that are similar. It
could just be "J Random EV" cert.

That's what I mean by shifting the liability - in order for there to be any
investigation, the user must have been perfect, 100% of the time, *and* the
attacker must not have exploited any of the technical means mentioned.

> Security research is legitimate. The people who created these entities
> and got these certificates are innocent of any crime. What they are not is
> immune from reasonable investigation to show this.

Yes. They are.

If someone suggested tomorrow that an EV certificate caused that person to
> believe that they were at the Stripe site, it would be entirely reasonable
> for any law enforcement agency or investigator to track down these
> researchers and ask them to explain why they sought certificates and entity
> creation that seem engineered to deceive.

No. It wouldn't. Innocence until proven guilty is a virtue, and at least in
the context of EV certificates, there is zero legitimate reason to be
suspicious. Under that model, it becomes quite easy to harass competitors,
for example. This is why complex processes exist (e.g. the WIPO process).

> The matter should resolve when they show legitimate cause. This doesn't
> mean that they should be given a free pass and ignored, if subsequently,
> someone phishes a Stripe customer by way of a look-alike entity and cert.
>

No, this is an entirely unreasonable burden, and rather antithetical to
good governance. That said, I understand it may be a position you hold, but
I find it imminently disagreeable, and so if the value of EV is predicated
on 'the strong can bully the weak', then it's deeply unsavory.

[Matthew Hardeman]

On Tuesday, December 12, 2017 at 3:52:40 PM UTC-6, Ryan Sleevi wrote:

> Yes. This is the foundation and limit of Web Security.
>
> https://en.wikipedia.org/wiki/Same-origin_policy
>
> This is what is programatically enforced. Anything else either requires new
> technology to technically enforce it (such as a new scheme), or is
> offloading the liability to the user.
>

The notion that a sub-resource load of a non-EV sort should downgrade the EV display status of the page is very questionable.

I'm not sure we need namespace separation for EV versus non-EV subresouces.

The cause for this is simple:

It is the main page resource at the root of the document which causes each sub-resource to be loaded.

There is a "curatorship", if you will, engaged by the site author. If there are sub-resources loaded in, whether they are EV or not, it is the root page author's place to "take responsibility" for the contents of the DV or EV validated sub-resources that they cause to be loaded.

Frankly, I reduce third party origin resources to zero on web applications on systems I design where those systems have strong security implications.

Of course, that strategy is probably not likely to be popular at Google, which is, in a quite high percentage of instances, the target origin of all kinds of sub-resources loaded in pages across the web.

If anyone takes the following comment seriously, this probably spawns an entirely separate conversation: I regard an EV certificate as more of a code-signing of a given webpage / website and of the sub-resources whether or not same origin, as they descend from the root page load.

[Ryan Sleevi]

On Wed, Dec 13, 2017 at 4:28 PM, Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Wednesday, December 13, 2017 at 2:46:10 PM UTC-6, Gervase Markham wrote:
>

> > My concern with this argument is that it's susceptible to the criticism
> > that Adam Langley made of revocation checking:
> > https://www.imperialviolet.org/2012/02/05/crlsets.html
> >
> > "So [EV identity is] like a seat-belt that snaps when you crash. Even
> > though it works 99% of the time, it's worthless because it only works
> > when you don't need it."
>

> This aspect considers only the potential downsides of improper trust and
> confidence in the users' mind given improper use of a look-alike
> certificate leading to a phishing exploit or similar.
>
> There is a benefit of EV certificates that deserves consideration:
>
> There are events, many per day, in which the additional confidence to
> engage in commerce with a given website is properly enhanced by the user's
> examination and assessment of the EV presentation. Any such instance is a
> tangible benefit, deserving -- I believe -- some weight in the discussion
> even if there were the rare negative outcome.
>

I think the flaw in this argument is that 'properly enhanced' has not been
demonstrated. It's quite literally the "works 99% of the time" case being
referred to here. Whether or not it's reasonable for the user to rely on
that information is rather the key.

> Just spitballing, one enhancement to the EV issuance might be to require
> that upon validation, the proposed EV entity name and jurisdiction name
> proposed to be included in the certificate have a 30 days
> publish-for-opposition embargo. It would arise each time a new EV
> validation is performed, including for EV validation renewals. Further
> certificates could issue or re-issue within the validation life time. A
> natural service that would arise from this would be that CAs would
> presumably police this publish-for-opposition database for their own
> customers' EV names and name-a-likes, working with their existing customer
> to object to and stop issuance of the (presumed) phishing certificate
> request.
>
> Another thing that should not be problematic for legitimate businesses --
> even gigantic ones -- is to require that EV certificate qualification and
> validation process identify a strongly identified individual (government
> photo ID, etc) be explicitly authorized by the applying entity as
> authorized to request EV certificates for the entity -- and furthermore --
> document within the certificate the name, jurisdiction, and nature of
> documents verifying that person's identification.
>
> Would Ian have requested a certificate for Stripe, Inc. if his full name
> were also in that certificate? Maybe, maybe not. But anyone investigating
> that certificate would need do no extra work to know what individual they
> should start communicating with to further discern the history and use of
> that certificate and the associated entity.

There are a number of problems with this, although I appreciate the
suggestion.

Governance is not something easily spitballed. I've tried to highlight the
WIPO process as one example of showing how complex such deliberations can
be, especially in an international/transnational situation. I think, for
this specific proposal, you might look at resources such as
https://www.eff.org/issues/icann to see that many of these proposals you're
discussing have profound policy impact on Internet governance.
Alternatively, you may find
https://www.techdirt.com/articles/20150623/17321931439/icanns-war-whois-privacy.shtml
useful discussion

I realize I'm doing a poor job at articulating the profound risks, perhaps
because they're best not for e-mail discussions, but these problems are not
unique to EV, and the solutions are unquestionably worse (for freedom and
privacy). It is in this holistic understanding - including regulatory risks
of mandatory EV and the like - that it's clear that EV isn't "just"
something a site opts into - it has a non-trivial, detrimental affect on
users day to day browsing, on the way in which the Internet is maintained,
in efforts to secure it, and to the underlying privacy and security. This
isn't hyperbole - this is something I think most browsers are profoundly
aware of.

[Tim Shirley]

As I understand it, Adam’s argument there was that to get value out of a revoked certificate, you need to be between the user and the web server so you can direct the traffic to your web server, so you’re already in position to also block revocation checks. I don’t think that maps here because a lot of the scenarios EV assists with don’t involve an attacker being in that position.

I know the question has been raised before as to why most phishing sites use DV. Some argue it’s because OV/EV are harder for people with bad intent to obtain. Some argue it’s because DV is more ubiquitous across the web and thus more ubiquitous on phishing sites. But regardless of which (or neither) is true, the very fact that EV certs are rarely (never?) used on phishing sites is in and of itself providing protection today to those of us who pay attention to it. I’d argue that alone means the seat belt isn’t worthless, and we should focus on building better seat belts rather than cutting them out and relying on the air bag alone.

On 12/13/17, 3:46 PM, "Gervase Markham via dev-security-policy" <dev-secur...@lists.mozilla.org> wrote:

On 13/12/17 11:58, Tim Shirley wrote:

> So many of the arguments made here, such as this one, as well as the recent demonstrations that helped start this thread, focus on edge cases. And while those are certainly valuable to consider, they obscure the fact that “Green Bar” adds value in the mainstream use cases. If we were talking about how to improve EV, then by all means focus on the edge cases. The thing I don’t see in all this is a compelling argument to take away something that’s useful most of the time.

My concern with this argument is that it's susceptible to the criticism
that Adam Langley made of revocation checking:

https://scanmail.trustwave.com/?c=4062&d=kJGx2vx-xMRho_TXqyD3e8mI4fM_V-yKUKn2tKZHNQ&s=5&u=https%3a%2f%2fwww%2eimperialviolet%2eorg%2f2012%2f02%2f05%2fcrlsets%2ehtml

"So [EV identity is] like a seat-belt that snaps when you crash. Even
though it works 99% of the time, it's worthless because it only works
when you don't need it."

Gerv

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org

https://scanmail.trustwave.com/?c=4062&d=kJGx2vx-xMRho_TXqyD3e8mI4fM_V-yKUK2gu_0caA&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy

[Gijs Kruitbosch]

On 13/12/2017 14:50, Tim Shirley wrote:
> I guess I’m also having a hard time appreciating how the presence of this information is a “cost” to users who don’t care about it. For one thing, it’s been there for years in all major browsers, so everyone has at least been conditioned to its presence already. But how is someone who isn’t interested in the information in the first place being confused by it? And if the mere presence of an organization name is creating confusion,

In addition to what Ryan said, speaking as an engineer who's worked on
the Firefox URL bar, the EV indicator also has a non-trivial cost in
terms of implementation/UI-design complexity.

On a purely practical level, displaying a longer EV entity string
implies less of the actual URL string is visible to the user, which in
itself is a risk for phishing.

> then surely a URL with lots of words and funny characters in it would be confusing people too, and we should remove that too, right?

I know you're speaking in jest, but yes. This is exactly why Safari
doesn't show the URL path/querystring etc. in the URL bar when the URL
isn't being edited (only the domain and/or EV name). We may or may not
end up doing something similar (ie lose path/querystring/hash) in
Firefox, but either way there are definitely reasonable arguments for
doing something along those lines.

Going further off-topic, as people have already implied, perhaps we want
other trust UI that provides more meaningful information to users about
the trust status of a page, that is easier to understand than a URL or
scheme/hostname/port combination. But we don't need to block removing EV
UI on that if there's consensus that EV UI doesn't add (sufficient)
value to remain in browsers.

~ Gijs

[Ryan Sleevi]

On Wed, Dec 13, 2017 at 4:40 PM, Matthew Hardeman via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On Tuesday, December 12, 2017 at 3:52:40 PM UTC-6, Ryan Sleevi wrote:
>

> > Yes. This is the foundation and limit of Web Security.
> >
> > https://en.wikipedia.org/wiki/Same-origin_policy
> >
> > This is what is programatically enforced. Anything else either requires
> new
> > technology to technically enforce it (such as a new scheme), or is
> > offloading the liability to the user.
> >
>

> The notion that a sub-resource load of a non-EV sort should downgrade the
> EV display status of the page is very questionable.
>

This is what Opera did until recently, and which early versions of Chrome
have done, and what some Safari engineers have proposed. I agree, it's very
questionable - that's part of why I was happy to see it removed - but it's
not uncontroversial.

> I'm not sure we need namespace separation for EV versus non-EV subresouces.
>

Without that separation, then you cannot be safe against EV downgrade
attacks (even if ever-vigilant as an end-user, there are ways to subvert
the state while maintaining the UI). Similarly, you cannot be safe against
"EV confusibles".

Under both attacks, the normal rejoinder is "The user should look" - but
what they're looking at, they can't trust. The rejoinder from this thread
is "Yes, but if most of the time they can trust, it's not so bad" - to
which I reply, yes, it is bad, if they're trusting something they can't
trust and just getting lucky that a stopped clock is right twice a day.

> Frankly, I reduce third party origin resources to zero on web applications
> on systems I design where those systems have strong security implications.
>
> Of course, that strategy is probably not likely to be popular at Google,
> which is, in a quite high percentage of instances, the target origin of all
> kinds of sub-resources loaded in pages across the web.
>

Nope. This is incredibly popular, both in Google at others. However, rather
than needing to reduce those resources to zero, you can use things like
Subresource Integrity to provide assurances.

But you're correct in that it's missing the point of the discussion - those
resources don't affect state, and the users assurances - even of the UI
shown - has technical limits that prevent it from meeting user expectations.

[Ryan Sleevi]

On Wed, Dec 13, 2017 at 4:46 PM, Tim Shirley via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> As I understand it, Adam’s argument there was that to get value out of a
> revoked certificate, you need to be between the user and the web server so
> you can direct the traffic to your web server, so you’re already in
> position to also block revocation checks. I don’t think that maps here
> because a lot of the scenarios EV assists with don’t involve an attacker
> being in that position.
>

Well, no, that's misunderstanding the point. The revocation checks
themselves are the placebo - because they are not hard fail, you don't get
benefit from doing them, precisely because they can be blocked. However,
they cannot be hard fail, because the failures are expected under
non-adversarial models. So because hard fail is not viable (and Rob's
recent sharing of OCSP status of CAs truly captures that better than a
thousand words on the topic), nor even if CAs had sound infrastructure is
it viable on the "internet at large" (that is, CAs are definitely the
worst, but even if they were perfect, it'd still be unacceptably bad), then
revocation doesn't provide value.

The same argument being applied to EV here is that the presumptive value of
EV is that it either provides technical mitigations OR the display to the
user provides sufficient value to allow for an informed decision. However,
the technical mitigations are non-existant, and the value of the display is
not sufficient enough on an adversarial model. In both cases, much like
hardfail, the structural deficiencies mean that the system is unreliable,
and because the system is unreliable, it should not be relied upon during
critical times. It is the weak link.

I know for non-security folks, this seems like throwing the baby out with
the bathwater, because it's "mostly good". But much like broken messaging
encryption is still broken, even if it's encrypted, the flaws of EV are
systemic, and mean you cannot and should not rely upon it (and of course
the EVGs disclaim reliance for a number of cases), and so the whole notion
of it is flawed. If you cannot rely on it, why rely on it?

>
> I know the question has been raised before as to why most phishing sites
> use DV. Some argue it’s because OV/EV are harder for people with bad
> intent to obtain. Some argue it’s because DV is more ubiquitous across the
> web and thus more ubiquitous on phishing sites. But regardless of which
> (or neither) is true, the very fact that EV certs are rarely (never?) used
> on phishing sites is in and of itself providing protection today to those
> of us who pay attention to it. I’d argue that alone means the seat belt
> isn’t worthless, and we should focus on building better seat belts rather
> than cutting them out and relying on the air bag alone.
>

"The very fact that EV certs are rarely (never?) used" is, of course,
unsubstantiated with data. It's a logically flawed argument - you're
presuming that non-existence is proof of non-existence. The irony is this
is the same argument made 10 years ago with certificates in general
(flashback proof -
http://voices.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html
) - that certificates prevented phishing, because you never saw phishing on
HTTPS.

Such arguments are both logically unsound and do not reflect on what
phishing/fraud are used for, or in general, how security works. It also
underscores the continued user-hostile message - which is to say, the user
is responsible for inspecting this UI, 100% of the time, if they want to be
safe from phishing. It doesn't align with the HCI research on positive
indicators, nor is it a fair or reasonable thing to ask of the average
user.

[Tim Hollebeek]

There are also the really cool hash-based revocation ideas that actually do help
even against active attackers on the same network. I really wish those ideas got
more serious attention.

-Tim

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of Tim
> Shirley via dev-security-policy
> Sent: Wednesday, December 13, 2017 2:47 PM
> To: Gervase Markham <ge...@mozilla.org>; mozilla-dev-security-
> pol...@lists.mozilla.org
> Subject: Re: On the value of EV
>

> As I understand it, Adam’s argument there was that to get value out of a
> revoked certificate, you need to be between the user and the web server so
> you can direct the traffic to your web server, so you’re already in position to
> also block revocation checks. I don’t think that maps here because a lot of the
> scenarios EV assists with don’t involve an attacker being in that position.
>

> I know the question has been raised before as to why most phishing sites use
> DV. Some argue it’s because OV/EV are harder for people with bad intent to
> obtain. Some argue it’s because DV is more ubiquitous across the web and
> thus more ubiquitous on phishing sites. But regardless of which (or neither) is
> true, the very fact that EV certs are rarely (never?) used on phishing sites is in
> and of itself providing protection today to those of us who pay attention to it.
> I’d argue that alone means the seat belt isn’t worthless, and we should focus
> on building better seat belts rather than cutting them out and relying on the
> air bag alone.
>
>
>

> On 12/13/17, 3:46 PM, "Gervase Markham via dev-security-policy" <dev-

> securit...@lists.mozilla.org> wrote:
>
> On 13/12/17 11:58, Tim Shirley wrote:

> > So many of the arguments made here, such as this one, as well as the
> recent demonstrations that helped start this thread, focus on edge cases. And
> while those are certainly valuable to consider, they obscure the fact that
> “Green Bar” adds value in the mainstream use cases. If we were talking about
> how to improve EV, then by all means focus on the edge cases. The thing I
> don’t see in all this is a compelling argument to take away something that’s
> useful most of the time.
>

> My concern with this argument is that it's susceptible to the criticism
> that Adam Langley made of revocation checking:

> https://clicktime.symantec.com/a/1/oIyM4YfpaH03Is-
> zFRH8AJzVNaqfkUt09K3WEgNPHOw=?d=uXDB34hHU71idZadw5ip3nRlsyu-
> Farb4fe8P50v8eGeFFyo2uKWwJ4Owcn1ya1sP6zsnOxx541A3GOFiGV3Cf5xeA
> C4qommBEsD51KyHnN1oECe8T_yt8LZ6ZCjx8lUkHA5M71KtHURAAzZWV7FY
> W2u82WBSW6GLHWpUZAjFGUha5-
> UmlfcwC2w_ObguO5luns9CJP7vlg2dgz6CGb-
> qAUfdN84H9LFGImuQWG9kuOWmMJcPEtw37KtxFYHCUMUhYVoEv863RTwkj
> agPy1iVmYeDYR3xVul3nPvwyGqiZxJFxeziNE-
> gCzFthw99KCm3R75bz2c8DaSqvfSupR5AeE0exbXmWyQsLe7rCIHgOOKttvpaa
> uSMp0gMzX-
> AKZKGFpnyyt0VDxm9VA1jGMekaZ0QJfVj_l_rAFBGuauBVoWFBg_LOH5tQ%3D
> %3D&u=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D4062%26d%
> 3DkJGx2vx-xMRho_TXqyD3e8mI4fM_V-
> yKUKn2tKZHNQ%26s%3D5%26u%3Dhttps%3A%2F%2Fwww.imperialviolet.or
> g%2F2012%2F02%2F05%2Fcrlsets.html

>
> "So [EV identity is] like a seat-belt that snaps when you crash. Even
> though it works 99% of the time, it's worthless because it only works
> when you don't need it."
>
> Gerv

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
>

> https://clicktime.symantec.com/a/1/x_xKxQuisdeMQ99vEcSB8fYv9i3RYV6ppz
> _my_vxbgs=?d=uXDB34hHU71idZadw5ip3nRlsyu-
> Farb4fe8P50v8eGeFFyo2uKWwJ4Owcn1ya1sP6zsnOxx541A3GOFiGV3Cf5xeA
> C4qommBEsD51KyHnN1oECe8T_yt8LZ6ZCjx8lUkHA5M71KtHURAAzZWV7FY
> W2u82WBSW6GLHWpUZAjFGUha5-
> UmlfcwC2w_ObguO5luns9CJP7vlg2dgz6CGb-
> qAUfdN84H9LFGImuQWG9kuOWmMJcPEtw37KtxFYHCUMUhYVoEv863RTwkj
> agPy1iVmYeDYR3xVul3nPvwyGqiZxJFxeziNE-
> gCzFthw99KCm3R75bz2c8DaSqvfSupR5AeE0exbXmWyQsLe7rCIHgOOKttvpaa
> uSMp0gMzX-
> AKZKGFpnyyt0VDxm9VA1jGMekaZ0QJfVj_l_rAFBGuauBVoWFBg_LOH5tQ%3D
> %3D&u=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D4062%26d%
> 3DkJGx2vx-xMRho_TXqyD3e8mI4fM_V-
> yKUK2gu_0caA%26s%3D5%26u%3Dhttps%3A%2F%2Flists.mozilla.org%2Flisti
> nfo%2Fdev-security-policy

>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://clicktime.symantec.com/a/1/kC1oRrCZP6m7Z3MS1qjK8ooXeqYR94Ar
> rjso4ZlYIqk=?d=uXDB34hHU71idZadw5ip3nRlsyu-
> Farb4fe8P50v8eGeFFyo2uKWwJ4Owcn1ya1sP6zsnOxx541A3GOFiGV3Cf5xeA
> C4qommBEsD51KyHnN1oECe8T_yt8LZ6ZCjx8lUkHA5M71KtHURAAzZWV7FY
> W2u82WBSW6GLHWpUZAjFGUha5-
> UmlfcwC2w_ObguO5luns9CJP7vlg2dgz6CGb-
> qAUfdN84H9LFGImuQWG9kuOWmMJcPEtw37KtxFYHCUMUhYVoEv863RTwkj
> agPy1iVmYeDYR3xVul3nPvwyGqiZxJFxeziNE-
> gCzFthw99KCm3R75bz2c8DaSqvfSupR5AeE0exbXmWyQsLe7rCIHgOOKttvpaa
> uSMp0gMzX-
> AKZKGFpnyyt0VDxm9VA1jGMekaZ0QJfVj_l_rAFBGuauBVoWFBg_LOH5tQ%3D
> %3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

[Ryan Sleevi]

On Wed, Dec 13, 2017 at 5:19 PM, Tim Hollebeek via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> There are also the really cool hash-based revocation ideas that actually
> do help
> even against active attackers on the same network. I really wish those
> ideas got
> more serious attention.
>
> -Tim
>

I'm not sure it's fair to conclude that the lack of implementation is
equivalent to lack of serious attention :)

But there's also a host of systemic policy issues with revocation that
would need to be tackled. Which is not to say we shouldn't explore them -
but that they may not be the long pole or the tricky part, so we may want
to make sure we're holistically prioritizing the right stuff :)

[Tim Shirley]

No, I’m not presuming that; that’s why I put the ? after never. I’ve never heard of any, so it’s possible it really is never. But I’m pretty confident in at least the “rare” part because I’m sure if you knew of any you’d be sharing examples. ;)

From: Ryan Sleevi <ry...@sleevi.com>
Reply-To: "ry...@sleevi.com" <ry...@sleevi.com>
Date: Wednesday, December 13, 2017 at 5:03 PM
To: Tim Shirley <TShi...@trustwave.com>

Cc: Gervase Markham <ge...@mozilla.org>, "mozilla-dev-s...@lists.mozilla.org" <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: On the value of EV

[Matt Palmer]

On Wed, Dec 13, 2017 at 05:58:38PM +0000, Tim Shirley via dev-security-policy wrote:
> So many of the arguments made here, such as this one, as well as the
> recent demonstrations that helped start this thread, focus on edge cases.
> And while those are certainly valuable to consider, they obscure the fact
> that “Green Bar” adds value in the mainstream use cases. If we were
> talking about how to improve EV, then by all means focus on the edge
> cases. The thing I don’t see in all this is a compelling argument to take
> away something that’s useful most of the time.

That assumes it's useful most of the time. I don't believe there's evidence
that the EV UI is -- all the rigorous research I'm aware of shows that the
EV UI is rarely "useful" to users.

Even in the rare case of a user that knows to look for the EV indication,
the information that the EV UI presents is demonstrably insufficient for the
purposes you wish to use it for. Anyone who wants to use the information
present in an EV certificate to make trust decisions needs to dig into the
cert info screen to determine *which* "FooBar Holdings Inc." they're talking
to when they visit https://example.com.

So, the current situation is that the EV UI is useless for *everyone*.
There's two options to "fix" it:

* Insert even more information into the EV "green bar", for the benefit of
the tiny fraction of users who know and care what that information
actually is; or

* Remove it as being insufficiently valuable to users-in-aggregate.

I have my doubts that there has ever been a situation in which adding more
information to a UI element that users already ignore and don't understand
has improved user experience, so I'm not expecting stuffing
jurisdictionOfIncorporation, registration numbers, and all manner of other
stuff into the green bar is going to improve matters. So I'm in favour of
removing the UI element entirely.

As others have mentioned, there's no reason why, if browsers were to remove
the "green bar", EV certificates need to necessarily go away[1]. The tiny
subset of users who wish to examine the identity of the organisation behind
the site that sent them a form (not necessarily the same organisation as the
one they'll be sending the form data to, as Nick Lamb has explained), they
can open the cert viewer and dig in. It's simply that there's no compelling
evidence that putting an organisation name and country in a green bar is
sufficiently valuable for users-in-aggregate to be worth keeping it.

- Matt

[1] CAs are fine to keep selling EV certificates, and marketing them in
whatever way they see fit, if they like. OV certs are still a thing
despite conveying no UI advantage, so there's no more reason to believe
EV will cease to be a thing just because browsers remove the green bar,
than there is evidence that the EV UI is useful.

[Ryan Sleevi]

I'm saying that even 'rarely' is presumptive - that is, that the lack of
public evidence is equivalent to a lack of occurrence.

As to sharing examples, it presumes that the point of discussion is whether
EV is an effective mitigator of phishing, which is a logically flawed
viewpoint assuming correlation, if any, is equivalent to causation, or that
the correlation is meaningfully significant for the discussion of security.

If the concern is phishing, we know more effective mitigators exist - both
in terms of technology and user experience - so the continued focus on
certificates, particularly EV, whether as a primary or a 'boots and
suspenders' approach to mitigation is misguided.

If the concern is fraud, then we already have the existence proof to show
the fundamental flaw in assuming a fraud mitigation. An exploit doesn't
have to be used in the wild for it to be an exploit. Although that is
itself its own topic of discussion - how vendors approach exploits.

Regardless, it can be categorically stated that it does not prevent fraud

On Wed, Dec 13, 2017 at 5:35 PM, Tim Shirley <TShi...@trustwave.com> wrote:

> No, I’m not presuming that; that’s why I put the ? after never. I’ve
> never heard of any, so it’s possible it really is never. But I’m pretty
> confident in at least the “rare” part because I’m sure if you knew of any
> you’d be sharing examples. ;)
>
>
>
>
>

> *From: *Ryan Sleevi <ry...@sleevi.com>
> *Reply-To: *"ry...@sleevi.com" <ry...@sleevi.com>

> *Date: *Wednesday, December 13, 2017 at 5:03 PM
> *To: *Tim Shirley <TShi...@trustwave.com>
> *Cc: *Gervase Markham <ge...@mozilla.org>, "mozilla-dev-security-policy@
> lists.mozilla.org" <mozilla-dev-s...@lists.mozilla.org>
> *Subject: *Re: On the value of EV

[Matt Palmer]

On Wed, Dec 13, 2017 at 01:40:35PM -0800, Matthew Hardeman via dev-security-policy wrote:
> I'm not sure we need namespace separation for EV versus non-EV subresouces.
>

> The cause for this is simple:
>
> It is the main page resource at the root of the document which causes each
> sub-resource to be loaded.
>
> There is a "curatorship", if you will, engaged by the site author. If
> there are sub-resources loaded in, whether they are EV or not, it is the
> root page author's place to "take responsibility" for the contents of the
> DV or EV validated sub-resources that they cause to be loaded.

Oh, if only that were true -- then every site that embedded a third-party ad
network that served up malware could be done under the CFAA, and the world
would be a much, much better place.

But it isn't, and your "curatorship" model of the web, whilst a lovely idea,
is completely unsupported by reality.

- Matt

[Matthew Hardeman]

I think you've done an excellent job of specifically pointing to other risks and concerns. In this last paragraph, however, it seems you've alluded to non-specific others of even graver consequence and followed up neatly with what feels like a "just trust me on this one." Well, maybe we should, but... it's just inconsistent.

I'm at a bit of a loss on this particular matter. I don't see how a privacy implication arises. Or intellectual property for that matter. I certainly don't see even the proximal nexus to internet governance.

I propose no change to how an authorized individual for engagement on behalf of the entity requesting EV issuance is identified with respect to the relationship and delegation between the business and the individual. I do propose that the individual have to be strongly identified individually and that the individually directly become contractually obliged to the CA.

Speaking of Internet governance, by funny coincidence, gives an example of such policies. For certain matters, ARIN requires a notarized affidavit of identity and assertions as to relationship with a certain business, etc, etc. This concept is not novel.

EV certificates are exclusively a business or organization matter. The validation process for EV already identifies an authorized party for directing issuance. Update the standards to require that said individual be willing to be identified in the certificate as well as identified as to the jurisdiction in which his identity validation occurred. Require that the CA engage into a contractual relationship with that individual with specifies unpalatable consequences for the individual if misrepresentations are made. This creates a liability that has a cash value that can interest "ambulance chasers" as well as law enforcement -- who generally need to have a dollar figure value of harm in order to pursue a case which hinges on the financial.

No one's privacy is being improperly compromised. We all give up some of our individual privacy in day to day corporate activities attendant to our jobs. If part of our role involves interfacing with external entities like CAs, and making representations on behalf of the business, we are already exposed.

No one is twisting the business or individual to comply. There's this benefit of getting an EV certificate available to them if and only if they comply with the requirements.

Those entities who don't have even one face willing to stand behind the request publicly should not have EV certificates available to them. One would want such an organization to achieve less trust than one with a face.

Ensuring that the CA can supply appropriate authorities with documentation pointing to the individual who requested this certificate and the contact points at which they previously validated that person makes the leap from certificate to a person with direct nexus to the certificate's request and subsequent issuance easy. That would greatly dissuade people with bad intent from acquiring EV certificates. For those who proceed regardless, it makes it far more likely that the individual(s) responsible for subsequent bad actions can be found [and tortured] appropriately.

[Peter Gutmann]

Tim Shirley via dev-security-policy <dev-secur...@lists.mozilla.org> writes:

>But regardless of which (or neither) is true, the very fact that EV certs are
>rarely (never?) used on phishing sites

There's no need:

https://info.phishlabs.com/blog/quarter-phishing-attacks-hosted-https-domains

In particular, "the rate at which phishing sites are hosted on HTTPS pages is
rising significantly faster than overall HTTPS adoption".

It's like SPF and site security seals, adoption by spammers and crooks was
ahead of adoption by legit users because the bad guys have more need of a
signalling mechanism like that than anyone else.

Peter.

[Matthew Hardeman]

On Wednesday, December 13, 2017 at 5:08:05 PM UTC-6, Matt Palmer wrote:

> > There is a "curatorship", if you will, engaged by the site author. If
> > there are sub-resources loaded in, whether they are EV or not, it is the
> > root page author's place to "take responsibility" for the contents of the
> > DV or EV validated sub-resources that they cause to be loaded.
>
> Oh, if only that were true -- then every site that embedded a third-party ad
> network that served up malware could be done under the CFAA, and the world
> would be a much, much better place.
>
> But it isn't, and your "curatorship" model of the web, whilst a lovely idea,
> is completely unsupported by reality.

I concur that today far fewer than should have acted in accordance with such a model.

But that could change any time. As the web platform's general capabilities expand, more and further abuses driven by site authors are going to reshape that paradigm.

It seems inevitable. We've got frameworks for burning browsers' CPU and energy to mine alt-coints in the background while you're served up cat memes.

It has been a presumption, up to this point, that a person visiting a website has agreed within non-destructive limits to have their browser/computer perform whatever tasks the website says to.

The kinds of abuses evolving won't permit such an assumption moving forward.

A modern website is software like any other. While it lives in a sandbox, it's still software driving a computer.

People have and do go to prison, even for terms approximating their life spans, for the creation and distribution of malware.

There's no real technological or logical reason that a sufficiently complex website is any different.

[Ryan Sleevi]

> I think you've done an excellent job of specifically pointing to other
> risks and concerns. In this last paragraph, however, it seems you've
> alluded to non-specific others of even graver consequence and followed up
> neatly with what feels like a "just trust me on this one." Well, maybe we
> should, but... it's just inconsistent.
>

That's certainly not my intent. Rather, I'm trying to highlight that your
'simple' solution is really not quite simple, and the nuances and political
implications of that are non-trivial. Further, trying to capture all of
that nuanced conversation in an email thread, particularly when some
parties actively profit from exploiting misinterpretations, is not an ideal
medium. I tried to provide related links so that you can read and
understand how, in other contexts of governance and security, such
arguments have been captured, and some of the non-obvious, significant
implications of them. I think most browsers are aware of that nuance
because it's an existential awareness about the role they play in the
security of users, and trying to capture all of the carefully considered
philosophy and security in an email thread is, well, not exactly productive
either.

> EV certificates are exclusively a business or organization matter.

No, they aren't. That's the thing - for a number of reasons, they aren't.
Or more aptly, "business or organization" themselves are not neat and
compact things, nor is it safe to presume that what is true today is true
tomorrow.

> The validation process for EV already identifies an authorized party for
> directing issuance. Update the standards to require that said individual
> be willing to be identified in the certificate as well as identified as to
> the jurisdiction in which his identity validation occurred. Require that
> the CA engage into a contractual relationship with that individual with
> specifies unpalatable consequences for the individual if misrepresentations
> are made. This creates a liability that has a cash value that can interest
> "ambulance chasers" as well as law enforcement -- who generally need to
> have a dollar figure value of harm in order to pursue a case which hinges
> on the financial.
>

I'm trying to be respectful, but I think this regard of law enforcement
does not hold up with how the Internet works, nor how the real world works,
nor how financial risk works. I realize this again sounds like "trust me",
because it's hard to point out the experiences day to day of people dealing
with this, or to highlight the many flaws and abuses. And even then, I
don't think it's necessarily a reasonable goal to expect you to be
convinced - those who understand recognize it as such.

> No one's privacy is being improperly compromised. We all give up some of
> our individual privacy in day to day corporate activities attendant to our
> jobs. If part of our role involves interfacing with external entities like
> CAs, and making representations on behalf of the business, we are already
> exposed.


> No one is twisting the business or individual to comply. There's this
> benefit of getting an EV certificate available to them if and only if they
> comply with the requirements.
>

This is not true. CAs tried to get PCI-DSS to require this for accepting
credit cards online. And naively, we might say, "That sounds good, I'm sure
that would prevent fraud" - but it also promotes and enables abuse. Or we
can look at several governments trying to require - whether at a government
level, at a 'doing business with government', or a 'doing any business with
our citizens' level, attempts to mandate EV - which precludes a number of
participants from engaging in online secure transactions or communications.
There's even been attempts to require "If you're within our jurisdiction,
you MUST use an EV cert" - which is balderdash!

I encourage you to revisit the resources I linked you to, spend an
afternoon reading them. The discussions around ICANN, RDAP, and WHOIS
privacy are very insightful in understanding the tradeoffs to privacy.
Legislation such as eIDAS, particularly if you can find counsel to walk you
through and explain the nuance that non-legally-trained professionals may
miss, is also illustrative. Looking at WIPO policies and precedent are
similarly beneficial.

But we must also, ultimately, circle back on the fact that none of that
discussion above *matters* for this discussion. It's redirecting the
conversation topic to something different, something that *is* a simpler
question - which is understanding what value, if any, the UI provides.

I don't think its' worth continuing to discuss your proposals without
recognizing agreement on that basic discussion. Nor do I think it's
valuable to discuss the validation changes without understanding and
appreciating the fundamental technical flaws with EV. If that validation
information is to be useful, if it's valuable, it's not because it's for a
billion users. It's because you want it available to law enforcement or
investigation - and there are far better ways to do that. Let's stop trying
to fit a square block in a round hole.

[Tim Hollebeek]

If you look at the phishing data feeds and correlate them with EV certificates,
you'll find out that Tim's "speculation" is right.

In my experience, it's generally a bad idea to disagree with Tim Shirley.

-Tim

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of Tim
> Shirley via dev-security-policy

> Sent: Wednesday, December 13, 2017 3:35 PM
> To: ry...@sleevi.com
> Cc: mozilla-dev-s...@lists.mozilla.org; Gervase Markham
> <ge...@mozilla.org>
> Subject: Re: On the value of EV
>
> No, I’m not presuming that; that’s why I put the ? after never. I’ve never heard
> of any, so it’s possible it really is never. But I’m pretty confident in at least the
> “rare” part because I’m sure if you knew of any you’d be sharing examples. ;)
>
>

> From: Ryan Sleevi <ry...@sleevi.com>
> Reply-To: "ry...@sleevi.com" <ry...@sleevi.com>
> Date: Wednesday, December 13, 2017 at 5:03 PM
> To: Tim Shirley <TShi...@trustwave.com>

> Cc: Gervase Markham <ge...@mozilla.org>, "mozilla-dev-security-
> pol...@lists.mozilla.org" <mozilla-dev-s...@lists.mozilla.org>
> Subject: Re: On the value of EV
>
> "The very fact that EV certs are rarely (never?) used" is, of course,
> unsubstantiated with data. It's a logically flawed argument - you're presuming
> that non-existence is proof of non-existence.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://clicktime.symantec.com/a/1/1mqhGL6xJbzNGRpvF0vTa3WSnEAQZQF
> 5K8VgNSFvl4s=?d=gqGQYeASiQy2N3lU7K-
> sEhOlQFbmNC2fxAOHBYelo4XflHuD2J9CzlFlH1A4n9gPmfRm7PO65FrdOoGfE
> G4_NkKF6-
> 8MK2zsOPqWmmn1vGp6Vnisxb3aI7shACwoWBG13n7WdXQU7nSrm_tFvcoN
> 9O0NKUrlWvavx4iSGiiXzsDv01k8TE8-Yo_fPj-
> 3jovLn9wEG58glLeHrORIeDZBuxW2AhHJoW4MJTAlfEcVHypFeL1oqs8zKB9LvE
> VIUjqp3uKWLp2zpjq2Kig_eG7zbANgxreRmS4W7SCFZQXf6wwvzxDRQsu0mq-
> AEES6RX6E2oLIYUPGOm92xX7muZtDJiATEc4W4zkWK-OgxI-llU1e4nM-gBlD-
> MdN6MEdFgK31iyhAmp9nahN24LYmBIOZcmZtNEVVi8xWXSKfZ4HRQ94ZCQx
> mxlJBA%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-
> security-policy

[Tim Hollebeek]

If you look at where the HTTPS phishing certificates come from, they come
almost
entirely from Let's Encrypt and Comodo.

This is perhaps the best argument in favor of distinguishing between CAs
that care
about phishing and those that don't.

-Tim

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-

> bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of Peter
> Gutmann via dev-security-policy
> Sent: Wednesday, December 13, 2017 4:23 PM
> To: Gervase Markham <ge...@mozilla.org>; mozilla-dev-security-

> pol...@lists.mozilla.org; Tim Shirley <TShi...@trustwave.com>
> Subject: Re: On the value of EV
>

> Tim Shirley via dev-security-policy
<dev-secur...@lists.mozilla.org>
> writes:
>

> >But regardless of which (or neither) is true, the very fact that EV
> >certs are rarely (never?) used on phishing sites

>
> There's no need:
>
> https://info.phishlabs.com/blog/quarter-phishing-attacks-hosted-https-
> domains
>
> In particular, "the rate at which phishing sites are hosted on HTTPS pages
is
> rising significantly faster than overall HTTPS adoption".
>
> It's like SPF and site security seals, adoption by spammers and crooks was
> ahead of adoption by legit users because the bad guys have more need of a
> signalling mechanism like that than anyone else.
>
> Peter.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy

[Tim Hollebeek]

I don't want to spend too much time digressing into a discussion of the same
origin policy as a basis for a reasonable security model for the web, but I
hope we could all agree on one thing that was abundantly obvious twenty
years ago, and has only become more obvious:

Anything originally introduced by Netscape is horribly broken and needs to
be replaced.

-Tim

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of
> Matthew Hardeman via dev-security-policy
> Sent: Wednesday, December 13, 2017 2:41 PM
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: On the value of EV
>

> On Tuesday, December 12, 2017 at 3:52:40 PM UTC-6, Ryan Sleevi wrote:
>
> > Yes. This is the foundation and limit of Web Security.
> >
> >

> https://clicktime.symantec.com/a/1/GrbZLkNqUS91rgzMay4M15oOr3bYABO
> Whq1
> > K3U87RIo=?d=pHiUFZpus7xBKMLSCUAfZRndcniHFdqZrXgc-
> _r0FxYSwiMHScu8QgSvJy
> > E8LSHlko0v84eVoyDMoTZTqKVUvrQ_LxFgoZAq1f-
> Iw1ESfQHF0h4v_K1IjkBwaIhjNiNX
> > coOSGp7NnMokKR3ug1bd6esHHwnMamBgCwow-ecE3suQ9uS4-
> zfp_NLR0LWp-kXGqFhQqR
> > AfcAImdNz09yApHBItSOYOep3BWfyNMoDnHxlSQJaFx3zhDxV3a-
> AkndjySZN86maZVN5c
> > DBfq3b_73V2qS22vAabmGLFF5uZN8g8Lxstv8tiVTx9_BPzKFZVzWHsrnnheL-
> W3D22riT
> > AFkvNYWYFwJ1fHe0NpVNxMU3y4vi7I9_zIoxa24Fox-
> VmvQlMPLAbZZwHNAumWKMqIhjrt
> >
> k76Lk7EkqLehoiC9__j0qne7lDkDd47_&u=https%3A%2F%2Fen.wikipedia.org%
> 2Fwi
> > ki%2FSame-origin_policy

> >
> > This is what is programatically enforced. Anything else either
> > requires new technology to technically enforce it (such as a new
> > scheme), or is offloading the liability to the user.
> >
>
> The notion that a sub-resource load of a non-EV sort should downgrade the
EV
> display status of the page is very questionable.
>

> I'm not sure we need namespace separation for EV versus non-EV
> subresouces.
>
> The cause for this is simple:
>
> It is the main page resource at the root of the document which causes each
> sub-resource to be loaded.
>

> There is a "curatorship", if you will, engaged by the site author. If
there are
> sub-resources loaded in, whether they are EV or not, it is the root page
> author's place to "take responsibility" for the contents of the DV or EV
> validated sub-resources that they cause to be loaded.
>

> Frankly, I reduce third party origin resources to zero on web applications
on
> systems I design where those systems have strong security implications.
>
> Of course, that strategy is probably not likely to be popular at Google,
which
> is, in a quite high percentage of instances, the target origin of all
kinds of sub-
> resources loaded in pages across the web.
>

> If anyone takes the following comment seriously, this probably spawns an
> entirely separate conversation: I regard an EV certificate as more of a
code-
> signing of a given webpage / website and of the sub-resources whether or
not
> same origin, as they descend from the root page load.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://clicktime.symantec.com/a/1/oq_SYtg88dEoDRxJA115VhfXkFgyjy6paw
> HDkVPMqrM=?d=pHiUFZpus7xBKMLSCUAfZRndcniHFdqZrXgc-
> _r0FxYSwiMHScu8QgSvJyE8LSHlko0v84eVoyDMoTZTqKVUvrQ_LxFgoZAq1f-
> Iw1ESfQHF0h4v_K1IjkBwaIhjNiNXcoOSGp7NnMokKR3ug1bd6esHHwnMamBg
> Cwow-ecE3suQ9uS4-zfp_NLR0LWp-
> kXGqFhQqRAfcAImdNz09yApHBItSOYOep3BWfyNMoDnHxlSQJaFx3zhDxV3a-
> AkndjySZN86maZVN5cDBfq3b_73V2qS22vAabmGLFF5uZN8g8Lxstv8tiVTx9_B
> PzKFZVzWHsrnnheL-
> W3D22riTAFkvNYWYFwJ1fHe0NpVNxMU3y4vi7I9_zIoxa24Fox-
> VmvQlMPLAbZZwHNAumWKMqIhjrtk76Lk7EkqLehoiC9__j0qne7lDkDd47_&u
> =https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

[Ryan Sleevi]

Perhaps, but Mozilla has stated their position on that, so it’s not germane
to this thread and discussion.

You’re still making a logically flawed argument to say “Because (some)
feeds of known phishing sources (with undefined definitions or resolution
mechanisms) don’t contain an EV, EV is a defense against phishing”. That
hasn’t changed.

If I wanted to make logically flawed arguments, I could point out that many
of these phishing sources are derived from users reporting them as such. If
EV was a mitigation for phishing, phishers could be using EV certs like
Ian’s or James’ (or potentially any EV cert, since we don’t know or have
evidence that the organization matters to users) to phish users who don’t
self report these sites, thus don’t end in the phishing feeds. Thus, EV
enables undetectable phishing, therefor harms users. Is it plausible? Yes.
Does it sound good? Hopefully. Is it a valid logical deduction? No - it’s
speculation.

What isn’t speculative is the complexity it brings. What is speculative is
that the complexity is beneficial to users, not just a specially
conditioned subset. Which we do know what that subset size was, and we
don’t have evidence that it has grown.

On Wed, Dec 13, 2017 at 7:25 PM Tim Hollebeek via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> If you look at where the HTTPS phishing certificates come from, they come
> almost
> entirely from Let's Encrypt and Comodo.
>
> This is perhaps the best argument in favor of distinguishing between CAs
> that care
> about phishing and those that don't.
>

> -Tim
>
> > -----Original Message-----
> > From: dev-security-policy [mailto:dev-security-policy-

> > bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of Peter
> > Gutmann via dev-security-policy
> > Sent: Wednesday, December 13, 2017 4:23 PM
> > To: Gervase Markham <ge...@mozilla.org>; mozilla-dev-security-
> > pol...@lists.mozilla.org; Tim Shirley <TShi...@trustwave.com>

> > Subject: Re: On the value of EV
> >

> > Tim Shirley via dev-security-policy
> <dev-secur...@lists.mozilla.org>
> > writes:
> >
> > >But regardless of which (or neither) is true, the very fact that EV
> > >certs are rarely (never?) used on phishing sites
> >
> > There's no need:
> >
> > https://info.phishlabs.com/blog/quarter-phishing-attacks-hosted-https-
> > domains
> >
> > In particular, "the rate at which phishing sites are hosted on HTTPS
> pages
> is
> > rising significantly faster than overall HTTPS adoption".
> >
> > It's like SPF and site security seals, adoption by spammers and crooks
> was
> > ahead of adoption by legit users because the bad guys have more need of a
> > signalling mechanism like that than anyone else.
> >
> > Peter.

> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org

> > https://lists.mozilla.org/listinfo/dev-security-policy

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Ryan Sleevi]

Of course not - facetious or not, it’s similarly logically and empirically
flawed.

On Wed, Dec 13, 2017 at 7:29 PM Tim Hollebeek via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I don't want to spend too much time digressing into a discussion of the
> same
> origin policy as a basis for a reasonable security model for the web, but I
> hope we could all agree on one thing that was abundantly obvious twenty
> years ago, and has only become more obvious:
>
> Anything originally introduced by Netscape is horribly broken and needs to
> be replaced.
>

> -Tim
>
> > -----Original Message-----
> > From: dev-security-policy [mailto:dev-security-policy-
> > bounces+tim.hollebeek=digice...@lists.mozilla.org] On Behalf Of

> > Matthew Hardeman via dev-security-policy
> > Sent: Wednesday, December 13, 2017 2:41 PM
> > To: mozilla-dev-s...@lists.mozilla.org

> > Subject: Re: On the value of EV
> >

> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org

> > https://clicktime.symantec.com/a/1/oq_SYtg88dEoDRxJA115VhfXkFgyjy6paw
> > HDkVPMqrM=?d=pHiUFZpus7xBKMLSCUAfZRndcniHFdqZrXgc-
> > _r0FxYSwiMHScu8QgSvJyE8LSHlko0v84eVoyDMoTZTqKVUvrQ_LxFgoZAq1f-
> > Iw1ESfQHF0h4v_K1IjkBwaIhjNiNXcoOSGp7NnMokKR3ug1bd6esHHwnMamBg
> > Cwow-ecE3suQ9uS4-zfp_NLR0LWp-
> > kXGqFhQqRAfcAImdNz09yApHBItSOYOep3BWfyNMoDnHxlSQJaFx3zhDxV3a-
> > AkndjySZN86maZVN5cDBfq3b_73V2qS22vAabmGLFF5uZN8g8Lxstv8tiVTx9_B
> > PzKFZVzWHsrnnheL-
> > W3D22riTAFkvNYWYFwJ1fHe0NpVNxMU3y4vi7I9_zIoxa24Fox-
> > VmvQlMPLAbZZwHNAumWKMqIhjrtk76Lk7EkqLehoiC9__j0qne7lDkDd47_&u
> > =https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

[Matt Palmer]

On Thu, Dec 14, 2017 at 12:21:12AM +0000, Tim Hollebeek via dev-security-policy wrote:
> If you look at the phishing data feeds and correlate them with EV certificates,
> you'll find out that Tim's "speculation" is right.

Ladies and gentlemen, this evening, for your viewing pleasure, the musical
number will be performed by The "Correlation is not Causation" Choir.

Before that, though, a quick word from our sponsor, Elephant-Be-Gone Amulets
of America, Inc. No elephants in America, you say? See, they're 100%
effective! Get yours today!

- Matt

[Matthew Hardeman]

On Wednesday, December 13, 2017 at 11:09:44 PM UTC-6, Matt Palmer wrote:

>
> Before that, though, a quick word from our sponsor, Elephant-Be-Gone Amulets
> of America, Inc. No elephants in America, you say? See, they're 100%
> effective! Get yours today!

Of relevance on this point, I'm quite sure there are several elephants a few miles away at the Birmingham Zoo. I'll grant you, it was a close thing, but after yesterday's election results, I believe the rest of the country has decided to let Alabama remain in America. For now. It would appear that the Amulets' influence is limited.

[Rob Stradling]

On 14/12/17 00:25, Tim Hollebeek via dev-security-policy wrote:
> If you look at where the HTTPS phishing certificates come from, they come
> almost entirely from Let's Encrypt and Comodo.
>
> This is perhaps the best argument in favor of distinguishing between CAs
> that care about phishing and those that don't.

Tim,

We reject certificate requests for sites that are already known to
engage in phishing, and we revoke (for all the good that does)
certificates for sites that are subsequently discovered to have engaged
in phishing.

IIUC, you're saying that "CAs that care about phishing" are ~100%
successful at avoiding issuing certs to phishing sites. If so, that's
great! Perhaps you could help us to become one of the "CAs that care
about phishing" by sharing your crystal ball technology with us, so that
we too can avoid issuing certs to sites that subsequently engage in
phishing?

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Tim Hollebeek]

Of course, the main reason Comodo gets sucked into this swamp is the
price point. That isn't necessarily their fault.

As I've pointed out elsewhere, Comodo has some great ideas about fixing
revocation that would go a long way towards solving the "misbehave only
after issuance" problem that you correctly pointed out.

-Tim

> -----Original Message-----
> From: Rob Stradling [mailto:rob.st...@comodo.com]
> Sent: Thursday, December 14, 2017 6:01 AM
> To: Tim Hollebeek <tim.ho...@digicert.com>
> Cc: Peter Gutmann <pgu...@cs.auckland.ac.nz>; Gervase Markham
> <ge...@mozilla.org>; mozilla-dev-s...@lists.mozilla.org; Tim
> Shirley <TShi...@trustwave.com>
> Subject: Re: On the value of EV
>

[Ryan Sleevi]

As much as I hate to thread-police, I do want to re-iterate that the
discussion about whether CAs should or should not issue certificates to
legitimate domain holders, and/or whether they should revoke such
certificates for domain holders, is itself an entirely separate issue, and
one has been discussed heavily in the past, with positions being expressed.
Similarly, the discussion of other ways to express revocation data, while
interesting and itself rife with its own set of policy implications
(consider the recent cessationOfOperation vs keyCompromise discussion),
it's also not germane to a discussion about the value of EV UI :)