W3C home > Mailing lists > Public > public-webappsec@w3.org > June 2014

Re: [MIX]: Expand scope beyond TLS/non-TLS (Re: "Mixed Content" draft up for review.)

From: Zack Weinberg <zackw@cmu.edu>
Date: Tue, 10 Jun 2014 14:47:53 -0400
Message-ID: <CAKCAbMgUp65KH2VueKkAicvai4Bs8zHdNhE8oA6CFOoDx7fbjg@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:05 UTC