On Sun, Dec 17, 2017 at 4:45 PM, Peter Kurrasch via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> Second, the actual value in EV as far as I can see is in having that human > readable name in addition to the domain name. A successful plan of attack > will need convincing names for both, which does raise the bar on an > attacker. If EV and the UI treatments were to go away, it would simplify > the task for some attackers and that seems undesirable. > I've tried to highlight the significant logical fallacy of this argument, but I'll try to break it down in more concrete terms. What is the "bar" an attacker has to achieve, and why are they incentivized to do so? We can't start with the bar of "enhanced validation" - there's no value in and of itself of that (c.f. OV). The value derived is on whether or not there is a measurable impact on user experience. As EV is not a technical method, it does not grant any additional technical protection. Thus, EV's protection is limited to whether or not the user notices and the effectiveness of that notice. The premise of Ian's "attack" is to suggest that even an informed user can be make an incorrect decision based on the available information. The premise of James' "attack" is to suggest that uninformed users can be mislead about the 'trustworthiness' of the UI. The premise of Adam Barth's "attack" is to show that the technical details can be circumvented in a way that is undetectable. Further, we know that such effectiveness is limited - consider https://www.proto-pic.co.uk/ (as an example). Or consider https://crt.sh/?id=22342824 , which used to be my favorite example, until they went through and changed their company name ( https://beta.companieshouse.gov.uk/company/04205228/filing-history ) due to confusion about their domain. So the premise of a bar rests on the idea that some users, some of the time, get lucky enough that the information is meaningful enough to alter behaviour. For those users, the "Extended" validation is nominally seen to serve as a barrier for entry for attack. This does not extend to all users - if it did, the bar is sufficiently low enough that it doesn't actually represent a challenge - but setting aside the value of that bar, it fundamentally rests on the belief that any value is derived from users knowing and actively checking the UI. Such decisions are not zero-cost. They have the concerns raised with James' "attack" - giving trusted UI surface to attackers (and CAs). They add complexity and nuance to the code, let alone the cost of managing and overseeing an EV program. They do not work with limited screen real estate (c.f. Safari). The counter-argument generally (incorrectly) suggests "Defense in Depth" as somehow a mitigation from these concerns - that the prevention (and its effectiveness) is somehow greater than its cost. I firmly assert that is false. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
