[cabfpub] DV/OV UI

[Dean Coclin]

Gerv wrote:
"Can an attacker get an OV certificate with a bogus O field? However hard
you think that is, it's certainly easier to do that for OV than for EV."

And it's much, much easier for an attacker to get a DV certificate.

Here are some statistics:

1. Roughly 1/3 of e-commerce websites use DV certificates
2. DV certificates are more likely to be used by cybercriminals for
e-commerce fraud (see #4)
3. 25,000 suspected phishing sites were using SSL in the year leading up to
March 2014
4. I asked Netcraft to provide me with some data related to this and
although I'm not allowed to release the report (due to contractual
agreements with Netcraft), I was able to get this statement released: "A
recent Netcraft study showed that 78% of SSL certificates found on servers
hosting fraudulent websites were Domain Validated. While the majority were
not obtained exclusively for phishing, those with misleading domains were
subject only to domain validation."

As Eddy noted, there are many appropriate uses for DV certificates and in no
way do I want to diminish or degrade that experience for those use cases. 
E-Commerce however is another story and given the fraud stats above, the
risks presented by DV certs in e-commerce are significant. I applaud Eddy
for refusing to provide DV for e-commerce websites.

Since people are throwing around studies claiming that users don't look at
security warnings, I'll counter with this one:
http://people.scs.carleton.ca/~paulv/papers/ccsw09.pdf 
It's an interesting but very technical read. The summary, which is talking
about an alternative cert UI, says: 
"The alternative (UI) design demonstrated significant improvements over IE
in the following areas:
 easier to find web site ownership information
 easier to find and understand data safety information
 increased confidence in data safety (when encryption
is present)
 accuracy of security decisions"

>From my interpretation, users can understand (if properly presented) and
will take appropriate action. The mockups in the paper all show that privacy
is protected (encryption) but provides 3 levels of identity: Low
(corresponding to DV), Medium (corresponding to OV) and High (corresponding
to EV) as indicated by words and pictures. 

Why do cybercriminals bother to get certificates at all? It's because users
are more informed and are becoming trained to look for the lock or https. To
"legitimize" their hack, cybercriminals are increasingly bothering to obtain
certs for these sites. And DV certs make it easy for them.

But, it's been made clear that browsers don't support additional UI features
for DV/OV/EV. OK, fine, let's move on from that.  What about disallowing DV
for e-commerce sites? I recall this being discussed about 5 or so years ago
and from what I remember, it didn't pass because of a debate around what
constitutes an e-commerce site. It could be as simple as: (1) it collects
payment info (i.e. credit card, Paypal, etc) and (2) runs a checkout module.

Dean Coclin

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Gervase Markham
Sent: Friday, November 07, 2014 4:49 AM
To: Eddy Nigg; CABFPub
Subject: Re: [cabfpub] downgrade DV UI RE: OIDs for DV and OV

On 07/11/14 09:44, Eddy Nigg wrote:
> Does it reduce risk of intentional abuse? Yes

You need to be more specific on how you think it reduces the risk.

> Does it provide a trace to a real (legal) entity? Yes

But this is not a binary thing. Can an attacker get an OV certificate with a
bogus O field? However hard you think that is, it's certainly easier to do
that for OV than for EV.

> Or the other way around, why don't we just issue code signing 
> certificates to anyone able to validate an email address? Ask Tom.

Code signing certificates are an entirely different use case, and I don't
think the comparison is useful.

Gerv
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6130 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141110/45707684/attachment.p7s>