[cabfpub] DV/OV UI

[Richard Wang]

This discussion passed one week that the browsers are very tough. 

I suggest to stop the war of words since this can’t solve anything.

 

Chinese has an idiom “求人不如求己”( Better to rely on yourself than ask help from others), I think this is why Comodo is doing its own browser.

 

 

Best Regards,

 

Richard

 

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi
Sent: Tuesday, November 11, 2014 9:25 AM
To: Dean Coclin
Cc: CABFPub
Subject: Re: [cabfpub] DV/OV UI

 

 

 

On Mon, Nov 10, 2014 at 2:19 PM, Dean Coclin <Dean_Coclin at symantec.com <mailto:Dean_Coclin at symantec.com> > wrote:

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

 

As noted in the past, I don't think we really agree with your conclusions, nor are terribly interested in this proposal. Nor is it really implementable.

 

Cheers,

Ryan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141111/092b5fd2/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5075 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20141111/092b5fd2/attachment-0001.bin