Re: Private Devices and IoT (was Proposal: Marking HTTP As Non-Secure)

On Mon, Feb 23, 2015 at 1:32 PM, Adam Langley <agl@chromium.org> wrote:
> On Sun, Feb 22, 2015 at 10:35 AM, Jeffrey Walton <noloader@gmail.com> wrote:
>> Hi Chris,
>>
>> Sorry to dig up an old thread.
>>
>>> Yes, I agree this is a problem. I am hoping to publish a proposal for
>>> how UAs can authenticate private devices soon (in January probably).
>>
>> Were you able to publish something? I wanted to read more about what
>> directions the solutions are moving towards.
>>
>> This just made my radar:
>> http://blog.kaspersky.com/internet-of-crappy-things/, and I was
>> wondering how much has been addressed and how much is hyperbole.
>
> Chris has disappeared off to write a book for a few months and
> promises to mostly not check email. I still have this idea in my head
> but haven't written anything. In my formulation, it would be a PAKE
> scheme based mutual authentication done above the TLS layer, but used
> to confirm the certificate. Chris was thinking more along the lines of
> a public-key hash in the URL, but wanted it to be useably short and
> thus worryingly weak.
>
I think the public key hash could have merit, too. It sounds a lot
like self authenticating URLs (if I am parsing it correctly). Gutmann
discusses them in his book on Engineering Security
(https://www.cs.auckland.ac.nz/~pgut001/pubs/book.pdf).

So those two seem like ways to verify a device, like a fridge or
thermostat, is authenticated and authorized to do something on the
home network. How do you provision them? That seems like the pain
point.

I wonder if some of those devices will be able to do the public key
stuff. How powerful does the processor need to be in a fridge or
thermostat? The price point on a fridge may make it viable to
manufacture one with the processing horsepower needed. But how about
thermostats? The thermostat use case seems like it begs a PSK (or
other PAKE).

Going back to Jason's comment:

>>> A key goal is not having to ask the user "Is this a device you
>>> recognize?"

I think that may need to be refined to "repeatedly ask the user". Or
provisioning needs to be solved (which I believe is a restatement of
the key distribution problem).

One thing I know: I definitely want to read more about it.

Jeff

>> On Thu, Dec 18, 2014 at 2:33 PM, Chris Palmer <palmer@google.com> wrote:
>>> On Thu, Dec 18, 2014 at 9:52 AM, jstriegel via blink-dev
>>> <blink-dev@chromium.org> wrote:
>>>
>>>> I'd like to propose consideration of a fourth category:
>>>> Personal Devices (home routers, printers, IoT, raspberry pis in classrooms, refrigerators):
>>>>  - cannot, by nature, participate in DNS and CA systems
>>>>  - likely on private network block
>>>>  - user is the owner of the service, hence can trust self rather than CA
>>>>
>>>> Suggested use:
>>>>  - IoT devices generate unique, self-signed cert
>>>>  - Friendlier interstitial (Ie. "Is this a device you recognize?") for self-signed connections on *.local, 192.168.*, 10.*, or on same local network as browser.
>>>>  - user approves use on first https connection
>>>>  - browser remembers (device is promoted to "secure" status)
>>>>
>>>> A lot of IoT use cases could benefit from direct connection (not requiring a cloud service as secure data proxy), but this currently gives the scariest of Chrome warnings. This is probably why the average home router or firewall is administered over http.
>>>
>>> Yes, I agree this is a problem. I am hoping to publish a proposal for
>>> how UAs can authenticate private devices soon (in January probably).
>>>
>>> A key goal is not having to ask the user "Is this a device you
>>> recognize?" — I think we can get the UX flow even simpler, and still
>>> be strong. Watch this space...

Received on Monday, 23 February 2015 18:55:04 UTC