[cabfpub] [EXTERNAL]Re: Obtaining an EV cert for phishing

[Eric Mill]

There's a big logical gap here. Saying that "OV and EV websites are much
less likely to be used for phishing than DV sites" does not make it so that
OV and EV certs "are much safer for users". That most phishing sites use DV
doesn't mean much on its own, since most sites in general use DV.

DV certs are easy and cheap, just like domain names are. Which are
appropriate for the role they play in providing DNS and authenticated TLS
as fundamental pieces of infrastructure. That's not likely to change, nor
is it desirable to introduce heavy identity checks as a requirement for
basic protocols, or to try and separate "sensitive" services from "less
sensitive" services in a subjective manner.

If DV certs became less easy or less cheap, or had friction added to them
in user agents, then phishing sites would use DV less often -- because all
sites would use DV less often. But it's not necessarily the case that
phishing would become less common or less effective.

Another reason EV is a poor tool for policing phishing is that phishing
isn't reliably associated with a domain name. Phishing forms can be
present, quite often, on sub-paths of existing and otherwise-fine domains,
through compromise or because the domain is used deliberately for
user-hosted content. For example, if someone put up a phishing form at
https://s3.amazonaws.com/paypal.com/login.html, the certificate would be a
meaningless lever to deal with it, and revocation of the certificate would
be catastrophic and affect many other customers.

Finally, the EV process seems to presume that identity verification is
meaningful in tracking phishing attempts, and that the resulting identity
displays are useful to users and they can make good decisions based on
them. That, as far as I can tell, has no basis in reality in user behavior,
and I regularly come across baffling EV name displays that bear no
user-recognizable resemblance to the service they are using.

For all these reasons, in my work I consistently and strongly recommend
that federal government services employ DV certificates, even/especially
for their most sensitive services. Within my organization, I help oversee a
number of such services. We don't use OV or EV, and I personally view the
use of EV certificates as harmful to user security -- EV leads ordinary
people to rely on unreliable information that they should never have to
think about anyway, has yet to demonstrate any meaningful technical
protections, and inevitably impedes automation and security agility.

It would be much healthier for users if the enterprise security community
redirected its energy away from policing the nature and strength of TLS
deployment, and towards furthering the use of modern of modern protocols
that provide direct and specific phishing resistance without the need for
users to learn or think about anything (such as U2F and DMARC) by the
organizations people depend on.

-- Eric

On Wed, Nov 29, 2017 at 1:58 PM, Ryan Sleevi via Public <public at cabforum.org
> wrote:

> You are correct that 11.2.2(4)(A) does not require that, because 11.2.2(4)
> is limited to a specific type of subject, rather than corporate or
> government identities (11.2.2(1) and (3), and 11.2.2.(4), respectively).
> This is not surprising, as corporate legal persons do not themselves
> constitute natural persons that you can meet F2F with.
>
> I think if that's something of value - and again, I question that premise
> itself - then I think it's worth noting that the F2F method you describe
> allows for a Registration Agency (a QGIS...) to do that. If the Validation
> WG were to do that, then it seems like it would also be necessary to
> maintain an open, community database of Registration Agencies that one or
> more CAs have deemed to fulfill or not fulfill the F2F validation
> requirements, as otherwise, the level of assurance in insufficient when
> considering a holistic system that allows two CAs to reach different
> conclusions about the same Registration Agency's process.
>
> And much like the questioning of the utility of QGIS's and their use as a
> single source of information, we'd have simply moved the weak link from
> being the QGIS to the means or method of which the CA attests to the
> independence of the Third-Party Validator (which 11.2.2(4)(B) allows the CA
> to do at its discretion) if we are to make a meaningful statement about the
> holistic value of EV.
>
> On Wed, Nov 29, 2017 at 1:33 PM, Kirk Hall via Public <public at cabforum.org
> > wrote:
>
>> Interesting idea, Wayne – we already have a process in the EV Guidelines
>> for doing Face-to-Face Validation for individuals at EVGL 11.2.2(4)(A), but
>> it’s not required in all cases.  Maybe this is as simple as adding that as
>> a requirement in all cases for EV certs.
>>
>>
>>
>> *From:* Wayne Thayer [mailto:wthayer at mozilla.com]
>> *Sent:* Wednesday, November 29, 2017 9:44 AM
>> *To:* Ryan Sleevi <sleevi at google.com>; CA/Browser Forum Public
>> Discussion List <public at cabforum.org>
>> *Cc:* Kirk Hall <Kirk.Hall at entrustdatacard.com>
>> *Subject:* Re: [cabfpub] [EXTERNAL]Re: Obtaining an EV cert for phishing
>>
>>
>>
>> The EV process is intended to gather a robust body of information about
>> the Subject that, when viewed collectively, "provides users with a
>> trustworthy confirmation of the identity of the entity". James and later
>> Ryan have pointed out a weakness in the standard where incorrect data from
>> a single data source (QGIS) could be used to obtain a "properly validated"
>> EV certificate containing that incorrect data.
>>
>>
>>
>> A positive outcome from this discussion would be for the Validation WG to
>> review this information and propose changes to the EVGLs (such as a
>> requirement for face-to-face validation mentioned by Jeremy) that mitigate
>> this weakness.
>>
>>
>>
>> Wayne
>>
>> _______________________________________________
>> Public mailing list
>> Public at cabforum.org
>> https://cabforum.org/mailman/listinfo/public
>>
>>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>


-- 
Eric Mill
Senior Advisor, Technology Transformation Services, GSA
eric.mill at gsa.gov, +1-617-314-0966 <(617)%20314-0966>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171129/1505a216/attachment-0002.html>