This is an early review of this document by the Security Directorate, as requested by the WG.

The document is well written, but in my opinion the security section needs a bit of work.

The document proposes to have devices publish a software bills of material (SBOM) describing which software they run, what version, what dependencies. Network managers could retrieve that information and then obtain from the manufacturers the list of vulnerabilities in that version of the software. They could use the information to isolate devices or force device software updates quickly after a vulnerability is disclosed. This seems like a nice feature for improving IoT security. But then, I am concerned that if not deployed correctly, the same mechanisms could be used by attackers to degrade the security of the IoT devices. I am also concerned that adding a service to publish SBOM increases the attack surface on the device.

The security section is extensive but in my opinion would benefit from some organization, such as clearly delineated subsections for specific attacks. It addresses a number of issues, which is good. But I my mind, the first security issue is the possibility by attackers to use SBOM and find vulnerable devices "at scale". The text in the security section starting with "SBOMs provide an inventory of software" does address the issue, butnot with enough force and persuasion. 

Let's suppose an attacker that have access to the IoT, either because ports were left open in a firewall or because the attacker has somehow breached the perimeter. The attacker will obtain from the device the SBOM with software, version and dependencies. Knowing the version, the attacker determine immediately which vulnerabilities have been patched and which have not, and thus which exploits might work. Of course, attackers today could just throw exploits at devices in the hope that one will work, but reading the SBOM makes the attacks more efficient and stealthy. In short, without precautions, defense at scale enables attack at scale.

The obvious defense is for devices to only provide such information if the client is explicitly authorized. The text says that, but use MAY after providing excuses such as "the attacker could derive the information by other means." Yes the attacker could use some form of fingerprinting, but that takes time and effort -- finding vulnerabilities at scale is much more convenient. I would be much more forceful, such as having devices configured to not provide any information unless access control and authorization methods have been properly configured.

One specific concern would be naive deployments in which users plug devices but do not change the default configuration -- the classic user=admin/password=admin issue. The lack of configuration itself is bad enough, but combining it with vulnerability detection at scale seems foolhardy. The security section says that "to further mitigate attacks against a device, manufacturers SHOULD recommend access controls." I would go further. Again, I wish we recommended a default posture in which no such information is provided until access control has been configured on the device.

In order to publish the SBOM, the devices must have a web server available or some equivalent, ready to accept queries from network manager. That means an open port, which in most cases will increase the attack surface on the device. That's another reason for requiring configuration of access controls before enabling publication of SBOM.

The reminder of the security section, addresses other threats, such as an attacker with control of the devices providing false information in the SBOM, or an attacker hijacking the manufacturer publishing site providing false information about vulnerabilities, or directing devices to update their software with attacker provided software. This is well written, but I am concerned with weasel-words like "These data nodes may be considered sensitive or vulnerable in some network environments." Which data nodes? What are the environments in which the information becomes "not vulnerable" or "not sensitive"? Is that a hidden reference to some kind of perimeter security? Do WG members still trust perimeter security? Even if perimeter defense was effective, we must be concerned lateral exploration after an initial break, or usage of IoT devices as persistent beach-heads for further exploitation. Let's be more direct, please.