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

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:02:03 UTC