Re: "Secure Introduction of Internet-Connected Things" (was Re: [webappsec] Agenda for MONDAY Teleconference 2014-10-20, 12:00 PDT)

Sure, but I think that if we want to produce something that actually
works, it will be of great help to have a specified, agreed-upon
standard so as to motivate device manufacturers to do something which
they can know will work in any browser on every platform.  It can be a
very small spec with no pictures, I think.

On Mon, Oct 20, 2014 at 11:01 AM, Chris Palmer <palmer@google.com> wrote:
> On Mon, Oct 20, 2014 at 10:24 AM, Mike West <mkwst@google.com> wrote:
>
>>> I think it is a bad idea to have users go through the ordinary
>>> "untrusted certificate" or "unknown authority" flows in the browser to
>>> use these devices, because it trains users to ignore these warnings
>>> and puts back pressure on UA authors who want to make these
>>> experiences increasingly strict.
>
> I call that the Dual-Mode Client solution in my post. I agree that we
> can't, even for 1 more minute, torture users with the Public Internet
> Mode for private networks. It's awful, and Adrienne and I end up
> closing comments on the bug reports due to the swearing: :|
>
> Although I say so only obliquely, I am really against the
> custom-client solution. Not because I am a web platform evangelist,
> but because:
>
> * Vendors already face incredible cost pressure, and quality is
> abysmal as noted in the post. Multiplying client platforms multiplies
> that problem.
>
> * Vendors are likely to reduce the multiplier by abandoning certain
> client platforms. "Oh, yeah, you'll need an iOS device to manage your
> refrigerator." No.
>
> * We know these devices get abandoned anyway. An open REST API, or
> even just a scrapable set of pages, allows the open community to pick
> up development when the vendor leaves town. It's much easier to
> reverse-engineer with Fiddler than with a custom Wireshark module.
>
> * I'm really bitter about that kernel module I had to install for the
> file server appliance. :) Kernel modules should be absolutely beyond
> the pale, for anything. But custom clients make it seem more
> acceptable, to weird vendors...
>
>>> The idea I was tossing around would be to have some different kind of
>>> secure introduction ceremony to replace the untrusted certificate
>>> dialog *for hosts on the local network only*.  Perhaps something like
>>> Bluetooth / WPS pairing, where the user could get a page that tells
>>> them this is a locally connected device and they have to enter a
>>> pairing code to trust it, with other-than-standard HTTPS UX treatment
>>> following, but less strict rules about mixed content blocking, etc.
>>> than an untrusted or HTTP connection would receive.
>
> Yes.
>
>>> There are a number of moving parts involved to get this right:
>>>   - definitely UI, which the W3C doesn't have a great history in, but
>>> perhaps which we can describe the requirements for without
>>> prescriptively specifying
>>>   - thinking about what constitutes a "locally attached network
>>> device", how to detect and verify that, and how to manage subsequent
>>> accesses over a WAN
>>>   - some Fetch rules similar to Mixed Content
>>>   - perhaps a certificate extension to identify these devices
>
> I'd really, really like to keep any spec work minimal. The sketch of
> when to go into IoT Mode I give in the post is likely sufficient, at
> least for a start. And I definitely don't think tht secure UX design
> by committee is going to work.

Received on Monday, 20 October 2014 18:09:11 UTC