Re: [Acme] Fwd: New Version Notification for draft-sweet-iot-acme-04.txt

[Michael Sweet <[e-mail]>]

Sebastian,

> On Aug 2, 2023, at 1:17 PM, Sebastian Nielsen <sebastian=[e-mail]> wrote:
> 
> 7) Validity of certificates: https://www.ietf.org/archive/id/draft-sweet-iot-acme-04.html#name-iot-device-certificates
>  >> I disagree with short validity.
> If the certificate is restricted to local domain names only, I suggest allowing validity up to 10 years.

My concern is that mDNS hostnames are not that stable, so long-lived certs will need to be revoked whenever the hostname changes, and that revocation record needs to be kept at least until the original cert expired...

> HOWEVER, if local certificates should be accepted by browsers as root, THEN there must be a mechanism, similar to DNS Rebinding protection, that prohibits an external site (that are not an RFC1918-IP or local resources) or a resource received externally (for example an email) from hyperlinking or redirecting to a .local resource, an private, loopback or local IP, or a mDNS resource.

This would prevent OAuth redirections from working, for example, so I'm not sure we can issue a blanket ban on redirections from an external site to an internal one.  The concern with DNS Rebinding attacks is that an external FQDN points at a local address in order to work around browser "same site" security mechanisms, not that a redirection/link goes to a local hostname or address.

>  In the same thing, I see that reuse of key material, mentioned in 4.11 is no problem, as long as key material is NEVER reused along multiple devices (eDellSupport and such).
> If key material is reused among the same user only (same local network), I see no risks.

The concern with key re-use (say when renewing a cert) is that if the private key is ever compromised then all of the certs using that key are compromised.  Given that EC key pairs are relatively cheap to produce (compared to large RSA key pairs), why not always create a fresh pair?

>  4.9 and 3.3 solves any issues that may exist with attacks, since each root certificate will only recongnize whatever exist on the very same local network.
>  Since the device SHOULD regenerate certificate (4.5) when a “factory reset” is done, a device which changes owner (through selling on marketplace as used product) will not pose a security risk.
>  There could be good to impose a rule, that a IoT device, should, on each power up:
> Set a flag “NeverConnected = true”
> Do power up connection.
> If a connection to a network for which it owns a certificate is found, then:
> “NeverConnected” should be set to false.
>  IF a pairing of a new user is done to the device, AND the pairing is not done through a existing user (Pairing done with a button or similar) – AND “NeverConnected” is set to true, then it should do an automatic factory reset, or require a factory reset.

It would be useful to talk more about this in a future draft; an IoT device *could* keep track of multiple networks (for "roaming" between different networks) but it would be important for it to treat a new network as such...

That said, this mechanism is meant to be automatic so no user pairing is happening specifically, just the IoT device "pairing" with the local ACME server.

________________________
Michael Sweet