Reviewer: Valery Smyslov Review result: Has Issues The topic of the draft is complex and involves many fields which I'm not expert of. The overall architecture looks secure, however it's difficult for me to analyse all the details. Nevertheless, it seems to me that there are some security issues with the draft. 1. Section 3.2 A UA equipped for Broadcast RID SHOULD be provisioned not only with its HHIT but also with the HI public key from which the HHIT was derived and the corresponding private key, to enable message signature. A UAS equipped for Network RID SHOULD be provisioned likewise; the private key resides only in the ultimate source of Network RID messages (i.e., on the UA itself if the GCS is merely relaying rather than sourcing Network RID messages). Each Observer device SHOULD be provisioned either with public keys of the DRIP identifier root registries or certificates for subordinate registries. I wonder why SHOULDs are used here and not MUSTs. In which cases it's OK not to equip e.g. UAs with private keys and how they will perform digital signatures in this case? Am I missing something? 2. It is not clear for me how revocation is done in case the private key of UA is compromised. While the Security considerations section states that revocation procedures are yet to be determined, I think that some text about the directions in which they are planned to be determined should be present. 3. Section 9. The size of the public key hash in the HHIT is also of concern. It is well within current server array technology to compute another key pair that hashes to the same HHIT. If I understand the draft correctly, the size of public key hash is 20 or 19 octets (Section 3.1). Finding another key pair that hashes to the same hash requires second preimage attack, which must take in this case 2^160 or 2^152. In my understanding of the state-of-art, it's still beyond possibilities of current computers. Am I missing something? 4. The Security Considerations section is silent about possible impact of Cryptographically Relevant Quantum Computers. While it's not clear whether such computers will be ever build, the proposed architecture looks fragile with respect to them. First, from my understanding the architecture, private/public key pairs in UA are relatively long-lived and difficult to update. This gives an attacker plenty of time to break them and once they are broken, enough time to exploit. Second, the impact of breaking can be substantial due to the nature of UA (a potentially dangerous object). Third, while many protocols involved in this architecture can be upgraded with quantum safe cryptographic primitives, it seems to me that for some pieces it will be really challenging (e.g. the draft discusses limitations on payload size for Bluetooth, which will be more severe with PQ cryptography with much larger keys and signatures). I think this issue must be addressed somehow, at least mentioned. 5. While an example when one UA physically steals UAS RID sender of another UA is clever, I think that such scenarios (physical security) are not in scope of IETF work. I believe that many others similar schemes can be invented, so I suggest to discuss physical security in a separate subsection of Section 9. Not related to security: Section 3.2: A self-attestation of a HHIT used as a UAS ID can be done in as little as 84 bytes when Ed25519 [RFC8032] is used, by avoiding an explicit encoding technology like ASN.1 or Concise Binary Object Representation (CBOR [RFC8949]). This attestation consists of only the HHIT, a timestamp, and the EdDSA signature on them. If no encoding is used then how extensibility is achieved? I also wonder how algorithm agility property is achieved for broadcast RID messages. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
