- From: Zack Weinberg <zackw@cmu.edu>
- Date: Tue, 10 Jun 2014 14:47:53 -0400
- To: Katharine Berry <katharine@getpebble.com>
- Cc: Mike West <mkwst@google.com>, Brian Smith <brian@briansmith.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Jun 10, 2014 at 2:05 AM, Katharine Berry <katharine@getpebble.com> wrote: > On 9 Jun 2014, at 21:21, Mike West <mkwst@google.com> wrote: >> Did you give consideration to the suggestion above that developers >> could simply be asked to accept a self-signed certificate presented by >> the device upon connection? ... > Also problematically, the user would > probably be unable to distinguish an actual validation failure on > the site itself from its “standard” behaviour of throwing the same > warning in their face and not working if they don’t accept it. I see this as *the* objection to the "suggestion above". This is exactly the sort of choice that users should not be saddled with. (Read <https://www.cs.auckland.ac.nz/~pgut001/pubs/psychology.pdf>. Then read it again. Then let it sink in for a while and read it again.) I'm not the person to speak about implementation difficulty in any of the browsers, but - strictly from a usable-security standpoint - I think that if we're going to go here at all [and there is a demonstrated need] we have to find some way to automate the handshake. Which means turning that self-signed certificate into a certificate tied to some kind of trust anchor, even if it's not a normal TLS-PKI trust anchor. Note also that, because of the pharming attack, we really need mutual authorization here. zw
Received on Tuesday, 10 June 2014 18:48:19 UTC