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

[Jeffrey Walton]

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.

Thanks in advance.

Jeff

On Thu, Dec 18, 2014 at 2:33 PM, Chris Palmer <pal...@google.com> wrote:
> On Thu, Dec 18, 2014 at 9:52 AM, jstriegel via blink-dev
> <blin...@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...
>

[Adam Langley]

On Sun, Feb 22, 2015 at 10:35 AM, Jeffrey Walton <nolo...@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.


Cheers

AGL

[Jeffrey Walton]

On Mon, Feb 23, 2015 at 1:32 PM, Adam Langley <a...@chromium.org> wrote:
> On Sun, Feb 22, 2015 at 10:35 AM, Jeffrey Walton <nolo...@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.