Last Call Review of draft-ietf-drip-arch-22
review-ietf-drip-arch-22-secdir-lc-smyslov-2022-03-30-00

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.