Re: [Iotops] comments on draft-sweet-iot-acme-00.txt

[Michael Sweet <[e-mail]>]

Michael,

> On Apr 13, 2022, at 1:03 PM, Michael Richardson <[e-mail]> wrote:
> 
> Signed PGP part
> 
> Michael Sweet <msweet=[e-mail]> wrote:
>> A proposed solution for locally-managed (and trusted) X.509
>> certificates, to solve the "this web site will eat your child" errors.
>> I'm working on coding up a sample implementation...
> 
>> Comments/feedback is appreciated!
> 
> As I understand it,
> 
> 1) I need to teach all the browsers which I will use at my home include this new
>   trust anchor, and ideally, to trust it only for .local.
>   If I don't do a path restriction for .local, then the new anchor could
>   impersonate any web property.   That comes with significant liability,
>   since they could intercept my bank cookies, steal the end users' money, etc.

Correct.  Ideally this would be done at the OS level (Windows and macOS both have what is needed to support this, and I think there has been some recent work for Linux desktops as well) so that the browsers can just ask the OS whether to trust a certificate for an mDNS hostname, but it would be easy enough to implement in the browsers as well.

>   And, even when I do that path restriction, if there are multiple places
>   that do this, then I might need to trust multiple anchors to speak for .local.
>   (The one at my home, my parents' home, the small nursury school, the
>   church office, ....)

Right, that is why you need to tie the trust anchor to the router's MAC address (or some other unique identifier).  Switch networks/routers and you need to update the current local trust anchor.

>   I'm unaware of protocols to discover local trust anchors on a
>   per-provisioning domain basis.  But actually, it's something we probably
>   need.
>   Perhaps that's something you'd be interested in working on?

Yes, specifically because I've been dealing with this issue basically since CUPS got TLS support (20 years ago or so...)

> 2) The innovation here is using RFC8555 to enroll rather than, say, RFC7030,
>   or CSA/MATTER, or OPC UA, or...
> 
>   * We still need to setup a local certification authority someplace.

I'm hoping to end up with an implementation that can be embedded in wireless routers.

>   * We need to teach IoT devices to do RFC8555.

... and have code that IoT devices can use to do so. :)

> So for this proposal to fly, three things need to happen:
> 
> a) updates to browser.

and/or OS, which would make supporting local trust anchors easier/more reliable.

> b) updates to IoT devices
> c) updates to local network to have ACME server

... which should be pretty straight-forward on existing enterprise networks which often have CA servers for company subdomains.  For home networks we need to get the server running on the router.

> Please see our SUIB talks at IETF112 and IETF113.

I've seen both presentations; sadly, I spent most of my 13 years at Apple lobbying the security and browser folks to support self-signed certificates for .local and link-local/private IP addresses, and every year the warning/error messages got worse.  So my confidence that we can get browsers to support self-signed certificates with a TOFU policy is 0.

Client-driven PKI solutions still need a valid trust anchor, which in general means a locally-distributed self-signed root (for .local) and/or a CA-signed root (for example.com) that a (local/public) CA uses to generate the device certificate.  In my experience, managing per-device (not to mention web server) certificates by hand doesn't scale, thus ACME...

My ACME draft is basically a "Gateway Issued Certificate" solution, just without vendor lock-in/global oversight.  If you can trust your DHCP server/router to connect you to the Internet, you can trust it to manage the X.509 certificates for your network or tell you which server is doing the job...  If you can't (e.g., public Wi-Fi) then you *don't* use IoT-ACME and you *don't* use the local trust anchor.

> I can't see how this is different than the requirements to deploy RFC8995 in
> he home.  It also seems to include no authorized transfer of ownership, nor
> does it seem to deal with how to get (unique, per-device, because RCM) WiFI
> credentials to the device.

One problem with RFC8995 is the notion that a manufacturer should have any control over provisioning/transfer of ownership.  Too many manufacturers have either gone out of business, stopped supporting "legacy" products, and/or added lock-in restrictions to their products (ink/toner cartridges with chips, etc.), leaving the customer with a paperweight in the end.

Another problem is that you need Internet access to use your device, and there are enough situations where you don't have access (intentionally or not).  We shouldn't create more reasons why you need to be online 100% of the time just for your device to work *locally*.

Finally, you need to get manufacturers on board to provide an always-available cloud service with the corresponding liability of being a CA, (necessarily) tracking every user's device, and protecting that data from disclosure forever (on penalty of serious fines from the EU, etc.) If there is a data breach, that likely will mean revoking ALL of the device certificates that have been issued and somehow getting them to re-register once the service is back up.

WRT getting an IoT device on a network, there are already standards for that for Ethernet and Wi-Fi, plus plenty of vendor solutions that offer different levels of security/confidentiality.  Adding more standards is always an interesting exercise [1] but it would be nice if everyone implemented the existing stuff first. :)

[1] https://xkcd.com/927/

________________________
Michael Sweet