IETF Last Call Review of draft-ietf-drip-registries-26
review-ietf-drip-registries-26-secdir-lc-huitema-2025-05-01-00

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 Ready, with nits.

The DRIP identifier is formatted as a Hierarchical Host Identity Tag (HHIT),
which is defined in RFC9374 as an IPv6 address with the reserved prefix
2001:30::/28, with hierarchical components describing Registered Assigning
Authorities (RAA) and HHIT domain authority. RFC9374 assumes that these
IPv6 addresses will be documented in the DNS under IP6.ARPA, just like regular
IPv6 addresses.

The current draft complements RFC9374 by defining procedures for managing the
registration of RAA, and by defining two RRTypes for HHIT and Broadcast RID
(BRID). The content of these resource records is encoded using CBOR.

The security section describes the usage of DNSSEC, which is "strongly
recommended", but whose implementation details should be defined
by the DRIP Identity Management Entities (DIME), i.e., the entities
in charge of the domain in which the unmanned aircraft is registered,
presumably under the guidance of the relevant Civil Aviation Authorities.
That maybe fine, but the following paragraph only explains in
very generic terms the consequences of providing spoofed values for
the HHIT or Broadcast RID records, or wrongly denying their existence.

The HHIT is tied to the public key of the Unmanned Aircraft System (UAS)
by means of a 64 bit Orchid hash, defined in RFC4843. 64 bit is short for a hash.
RFC4843 specifies this as the hash of a "context ID" concatenated with the
public key. The context ID is specified in RFC9374 as a constant, which
means it does not add much collision resistance. A well resourced adversary
could find colliding keys reasonably fast, and create fake RR records
for a target HHIT, or for a collection of HHIT. In the absence of DNSSEC, the
adversary could use attacks against DNS resolution to provide this fake record to an
observer, for example publishing a fake certificate in which the public
key hashes to the specified Orchid. Should we be worried? Should we warn
the CAAs about that, and tell them that DNSSEC really matters?

The HHIT RR contains a Canonical Registration Certificate. The
specification tells us it is encoded using X.509 DER. I suppose
that this is shortcut for a PKI Certificate as in RFC 5280. An
actual reference would be nice. In any case, the certificate
will contain the public key associated with the UAS. But then,
the security section is concerned about "public key exposure",
and recommends that "the public key for any DET not be exposed in DNS
(under any RRType) unless and until it is required for use in
verification by other parties." Does that mean some kind of
"just in time" publication of HHIT and BRID records? How can
DNS operator whether and when the records are "required for
use in verification"?

I am also a bit concerned about the use of CBOR encoding for the
RR Type. This is a mild concern for HHIT which only has three
fields, only two of which have variable length. But for BRID
the syntax description fills a full page, with many optional fields,
two variable length arrays and at least one variable length field.
I worry about attackers publishing "specially crafted" records
and causing a fault in an ill programmed or ill tested decoder.