Hi Richard,
I like the concept of promoting better security practices through an
indicator or other means. I especially like the idea of providing a
coordinated effort between multiple members of the security community to
ensure everyone is informed, working towards a common goal, and
promoting the idea. However, I dislike mixing the indicator with EV.
EV means something already - that the identity of the subject was
verified in accordance with the EV Guidelines. Tacking on other
requirements confuses this meaning just as we are seeing an increase in
recognition and understanding. Using the EV indicator will cause the
public to assume there is something wrong with their digital
certificate, attributing the error to the CA instead of the server
operator.
I've expressed similar concerns over deploying CT first as an EV
requirement. Fortunately, CT is an area where CAs can readily assume
responsibility, ensuring that certificate users are compliant without
them necessarily understanding how they are compliant - something that
is vital for operations with small IT departments. Still, the potential
confusion between EV and CT (in addition to my support for CT as a
concept) makes me especially hopeful that CT will rapidly expand to
cover all certificates.
Instead of taking away the EV indicator, perhaps a super-indicator for
technical security? That way there is still an indicator for the
identity of the website operator which can be combined with an indicator
about the technical controls deployed by the server operator.
Jeremy
On 9/17/2014 9:20 AM, Richard Barnes wrote:
Hey all,
Anne suggested an idea to me that I thought would be interesting for this
group. Consider this email a rough sketch of an idea, not any sort of plan.
There are a bunch of security features right now that I think we all agree
improve security over and above just using HTTPS:
-- HTTP Strict Transport Security
-- HTTP Public Key Pinning
-- TLS 1.2+
-- Certificate Transparency
-- Use of ciphersuites with forward secrecy
-- No mixed content
-- Content Security Policy (?)
-- Sub-resource integrity (?)
It would be good if we could create incentives for sites to turn on these features. EFF has
already seen some sites trying to turn things green on their "Encrypt the Web Report"
[1]. Should we consider creating a suite of features that comprise a "high-security" web
site, and create some UI to express that to the user?
We could invent new UI for this (e.g., a green lock icon), or we could overlay these
requirements on the EV criteria. Chrome already does this to some extent, downgrading
the EV indicator to DV if the site attempts to POST to an "http://"; URI or
(soon) if the site doesn't do CT.
What would people think about creating a list of security features that must be
enabled in order to get special UI (EV or otherwise)? We would obviously want
to coordinate this with the other browser vendors, and to some degree with site
operators (though the whole point here is to lean on them to do better!)
Thoughts? Suggestions?
Thanks,
--Richard
[1] https://www.eff.org/encrypt-the-web-report
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
