Subject: [Iotops] Fwd: New Version Notification for draft-sweet-iot-acme-00.txt

From: Michael Sweet <[email-masked]>
Date: Wed, 6 Apr 2022 12:25:26 -0400

All,

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!

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-sweet-iot-acme-00.txt
> Date: April 6, 2022 at 12:12:43 PM EDT
> To: "Michael Sweet" <[email-masked]>
> 
> 
> A new version of I-D, draft-sweet-iot-acme-00.txt
> has been successfully submitted by Michael Sweet and posted to the
> IETF repository.
> 
> Name:		draft-sweet-iot-acme
> Revision:	00
> Title:		ACME-Based Provisioning of IoT Devices
> Document date:	2022-04-06
> Group:		Individual Submission
> Pages:		10
> URL:            https://www.ietf.org/archive/id/draft-sweet-iot-acme-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-sweet-iot-acme/
> Html:           https://www.ietf.org/archive/id/draft-sweet-iot-acme-00.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-sweet-iot-acme
> 
> 
> Abstract:
>   This document extends the Automatic Certificate Management
>   Environment (ACME) [RFC8555] to provision X.509 certificates for
>   local Internet of Things (IoT) devices that are accepted by existing
>   web browsers and other software running on End User client devices.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 

________________________
Michael Sweet

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Apr 2022 13:03:09 -0400

Michael Sweet <msweet=[email-masked]> 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.

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

   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?

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.
   * We need to teach IoT devices to do RFC8555.

So for this proposal to fly, three things need to happen:

a) updates to browser.
b) updates to IoT devices
c) updates to local network to have ACME server

Please see our SUIB talks at IETF112 and IETF113.

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.

    >> Begin forwarded message:
    >>
    >> From: [email-masked] Subject: New Version Notification for
    >> draft-sweet-iot-acme-00.txt Date: April 6, 2022 at 12:12:43 PM EDT To:
    >> "Michael Sweet" <[email-masked]>
    >>
    >>
    >> A new version of I-D, draft-sweet-iot-acme-00.txt has been
    >> successfully submitted by Michael Sweet and posted to the IETF
    >> repository.
    >>
    >> Name: draft-sweet-iot-acme Revision: 00 Title: ACME-Based Provisioning
    >> of IoT Devices Document date: 2022-04-06 Group: Individual Submission
    >> Pages: 10 URL:
    >> https://www.ietf.org/archive/id/draft-sweet-iot-acme-00.txt Status:
    >> https://datatracker.ietf.org/doc/draft-sweet-iot-acme/ Html:
    >> https://www.ietf.org/archive/id/draft-sweet-iot-acme-00.html Htmlized:
    >> https://datatracker.ietf.org/doc/html/draft-sweet-iot-acme
    >>
    >>
    >> Abstract: This document extends the Automatic Certificate Management
    >> Environment (ACME) [RFC8555] to provision X.509 certificates for local
    >> Internet of Things (IoT) devices that are accepted by existing web
    >> browsers and other software running on End User client devices.
    >>
    >>
    >>
    >>
    >> The IETF Secretariat
    >>
    >>

    > ________________________ Michael Sweet

    > ----------------------------------------------------
    > Alternatives:

    > ----------------------------------------------------
    > --
    > Iotops mailing list [email-masked]
    > https://www.ietf.org/mailman/listinfo/iotops

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Sweet <[email-masked]>
Date: Wed, 13 Apr 2022 16:00:44 -0400

Michael,

> On Apr 13, 2022, at 1:03 PM, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

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.

>   (The one at my home, my parents' home, the small nursury school, the

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.

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

>   * 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:

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

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

> 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