I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Almost ready. Is there any protection against old signed Zero Touch Information? I see that Ownership Vouchers and Owner Certificates both have mechanisms for expiration (and for certs, revocation), but I don't see anything comparable for redirect or onboarding information. If an owner creates a valid redirect or onboarding object and discovers a bug in it, is there any way for the owner to make that object no-longer-valid without getting an entirely new owner certificate and revoking the old cert? Is that intentional? It seems like this protocol places more trust in device manufacturers than was previously required, but I don't see any discussion of that in the security considerations. If necessary, is there any way to disable zero touch, and configure a device manually? E.g., if the supply chain is presumed-secure, but the manufacturer's well-known bootstrap server is compromised, is there any way to securely provision a new device? Section 3.4 mentions a device identify certificate. I assume the public keys in those certificates are unique per-device? If not, I want to think a bit more about possible attacks where the attacker correlates encrypted artifacts without being able to decrypt them. Section 5.4 says what to do "if the revocation status is not attainable". What does that mean precisely? E.g., I assume failure to download a CRL, absence of a CRL in the CMS data, and failure to contact an OCSP server all count. But what if the device acquires a valid CRL that is stale (nextUpdate < now)? If I'm understanding correctly, the intent of well-known bootstrap servers is that the manufacturer can redirect devices to customer bootstrap servers that have the actual onboarding information. But I also don't see any reason that a (potentially compromised) trusted manufacturer's bootstrap server couldn't provide the onboarding information directly. It's probably easier to secure the (potentially offline) private keys used to sign ownership vouchers than it is to secure the (presumably highly available, online) well-known bootstrap servers. So it seems like the system as a whole could be more secure if well-known bootstrap servers could only provide untrusted redirects. I don't understand the error cases around the "flag to enable zerotouch bootstrapping" in section 5.1. How exactly is that flag set to false? Is it by the initial configuration step in section 5.6? If that's where the flag is set to false, won't some owners forget to include that in their config? Also, how atomic is the application of initial configuration? Is there any possible case in which some of the initial configuration can be applied without touching the flag, so that the device appears to be correctly configured, but will try to bootstrap again on the next reboot? Conversely, can the flag be set to false without the device being fully configured? (I don't think that's a security issue, just potentially a management headache.) Section 9.4 says to assume owner certificates "are not revokable" if there's no accurate clock. Is there no value in checking for a CRL or OCSP response, even without the ability to determine if it's recent? It seems to me that checking with an active server (CRL Distribution Point or OCSP server, as opposed to a stapled CRL or OCSP response) would make it significantly harder (not infeasible, just harder) for an attacker to use a revoked cert against a device with no clock. -- Freelance cyber security consultant, software developer, and more https://david.mandelberg.org/