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

Does it make sense for this to begin as spec work and then get pushed to
browsers, or should we encourage each browser vendor to start working on
the problem? Then once there are reasonable ideas out there, we can start
working on specs and moving forwards an agreed-upon standard.

On Mon, Oct 20, 2014 at 11:08 AM, Brad Hill <hillbrad@gmail.com> wrote:

> 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.
>