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

Thu Nov 30 15:47:53 MST 2017

I've requested statistics from the UK government in regards to the issues
highlighted on here.

On Wed, Nov 29, 2017 at 7:52 PM, Eric Mill via Public <public at cabforum.org>
wrote:

> 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>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20171130/a9ca8581/attachment.html>