On Mon, Dec 18, 2017 at 4:09 PM, Wayne Thayer <[email protected]> wrote:
> Thank you Ryan for raising this question, and to everyone who has been > contributing in a constructive manner to the discussion. A number of > excellent points have been raised on the effectiveness of EV in general and > on the practicality of solving the problems that exist with EV. > > While we have concerns about the value of EV as well as the potential for > EV to actually harm users, Mozilla currently has no definite plans to > remove the EV UI from Firefox. At the very least, we want to see > Certificate Transparency required for all certificates before making any > change that is likely to reduce the use of EV certificates. > > Is Google planning to remove the EV UI from desktop Chrome? If so, how > does that relate to the plan to mark HTTP sites as ‘Not secure’ [1]? Does > this imply the complete removal of HTTPS UI? > > While we agree that improvements to EV validation won’t remove many of the > underlying issues that have been raised here, we hope that CAs will move > quickly to make the EV Subject information displayed in the address bar > more reliable and less confusing. > > - Wayne > > [1] https://security.googleblog.com/2016/09/moving-towards- > more-secure-web.html > Our plans regarding the overall status of HTTP are kept at [1] , which explains the rationale as well as linking to other research. Notably, this is framed as states of "secure" and "not secure", aligning with the bare minimum of transport security, and with an end state of showing negative indicators for not-secure connections. As shared in past CA/Browser Forum meetings [2][3][4][5], it should come as no surprise that we continue to explore with the EV UI treatment in a way that best reflects the guarantees it provides. We intentionally removed the EV UI indicator from our mobile products, and continue to include significant UI experiments [6][7][8] to help users better understand the information presented. In a similar vein, when unintentional bugs have resulted in EV status being denied for some sites, whether by CA or by other conditions, or when CAs themselves find their certificates have never been granted EV, we've been surprised at the delays in which these changes are landed versus when users or CAs notice and report them. As there are a number of changes, both announced and in-development, related to SSL/TLS improvements, we're being mindful of the ecosystem and the potential for change. Certainly, seeing Certificate Transparency required for all is an important and shared goal in our efforts to improve security. However, research such as James' shows the danger in granting arbitrary control over security UI [9], and we've removed other situations where arbitrary data was presented to the user as trustworthy [10]. Ian's work is consistent with our own experiences, and mitigating that introduces significant complexity for questionable security - which is somewhat at odds with our Core Principles [11]. It's unclear if Mozilla's remarks are one of principles or priorities - that is, whether EV is perceived to provide a value useful to users and the ecosystem, or whether it is one of prioritization, as Mozillans, like Googlers, continue to work through a long backlog of CA incidents, audit reports and issues, and high-value security improvements, such as Certificate Transparency, the successful deprecation of SHA-1, and work on TLS 1.3. If the former, it helps understand what considerations should be afforded the research. If the latter, it may present collaborative opportunities to explore changes to the UI that better reflect the guarantees users are afforded. [1] https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure [2] https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Google [3] https://cabforum.org/2016/02/17/2016-02-17-minutes-of-f2f-meeting-37/#Google [4] https://cabforum.org/2014/09/16/2014-09-16-18-f2f-meeting-33/#Google [5] https://cabforum.org/2015/10/07/2015-10-07-face-to-face-meeting-minutes-meeting-36-istanbul/#Google [6] http://www.allenpike.com/2014/burying-the-url/ [7] https://research.google.com/pubs/pub45366.html [8] https://research.google.com/pubs/pub41927.html [9] https://textslashplain.com/2017/01/14/the-line-of-death/ [10] https://bugs.chromium.org/p/chromium/issues/detail?id=544244 [11] https://www.chromium.org/developers/core-principles _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
