|
Hello Christian,
Thanks for your review. Replies in line.
Bob beat me to the punch on one of your comments so will let him handle the discussion around it.
--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC
From: Christian Huitema via Datatracker <noreply@xxxxxxxx>
Sent: Thursday, May 1, 2025 9:08 PM To: secdir@xxxxxxxx <secdir@xxxxxxxx> Cc: draft-ietf-drip-registries.all@xxxxxxxx <draft-ietf-drip-registries.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; tm-rid@xxxxxxxx <tm-rid@xxxxxxxx> Subject: draft-ietf-drip-registries-26 ietf last call Secdir review Document: draft-ietf-drip-registries
Title: DRIP Entity Tags (DET) in the Domain Name System (DNS) Reviewer: Christian Huitema Review result: Has Nits 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"? <atw>
I will add the reference to RFC5280, thanks.
This does mean some "just in time publication" as the best-case scenario.
The only time this would really apply (and be useful) is when a UAS Service Supplier (USS) has a registry component (including the DNS portion). As such an Operational Intent (i.e. the 4D [3D area + time])
being "activated" could signal to processes of the USS that the DNS RRTypes for the given Operational Intents Session ID are "published".
You could have a system where the USS and DNS providers be different and tightly integrated in some way to achieve the same result. How this is done is out of scope of the document.
Perhaps something along the lines of "When practical, it is RECOMMENDED" instead of the current wording?
</atw>
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. <atw>
A review of the CBOR was carried out:
https://mailarchive.ietf.org/arch/msg/cbor/x9o8goNc3vgmPXFFVSDo1oks-i4/
</atw>
|
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
