On 5/8/25 12:06 PM, Adam Wiethuechter
wrote:
Christian,
A new version, with changes related to your comments, has been posted as -27.You may also look in our GitHub [1] for specific commits related to your issues starting with "fix(secdir)".
Hopefully our changes address your comments accordingly.The only comment not in the document is around "test vectors" for our CBOR items as they probably should live in the GitHub.
--------
73,Adam T. WiethuechterSoftware Engineer; AX Enterprize, LLC
From: Christian Huitema <huitema@xxxxxxxxxxx>
Sent: Wednesday, May 7, 2025 11:55 PM
To: Adam Wiethuechter <adam.wiethuechter@xxxxxxxxxxxxxxxx>; 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>; tjw.ietf@xxxxxxxxx <tjw.ietf@xxxxxxxxx>
Subject: Re: [Last-Call] Re: draft-ietf-drip-registries-26 ietf last call Secdir reviewOn 5/7/2025 2:17 PM, Adam Wiethuechter wrote:
> 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.
Hello Adam,
I will only comment here on the parts that Bob is not handling -- see
inline.
-- Christian Huitema
>
> --------
> 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>
<ch>
Thanks for adding the reference to RFC5280.
Do you propose to write your revised text in the security section to
replace the current "As such it is RECOMMENDED that the public key for
any DET not be exposed in DNS..."? That would be cool, but you have to
acknowledge the tension between the desire to keep the public key under
wraps and management, which is simpler when DNS records are published
and DNSSEC signed in batches. Between the two, I would recommend that
DNSSEC wins! The hiding of the public key is a nice defense in depth
mechanism, but you cannot really rely on that for security: the
certificate will have to be shown sometimes, you cannot predict where it
will land after that, and the public key has better be strong enough to
resist offline attacks. DNSSEC, in contrast, is the best defense against
spoofs of the Orchid code, which are much simpler than breaking a public
key.
I am sure that combining "just in time" DNSSEC is possible, but that
will introduce some complexity. Tim Wicinski in his DNSDIR review says
that he would like to see "something working in a zone file". I think
that if you want to recommend "just in time" registration coupled with
DNSSEC, it would be nice to have an existing proof of concept. Not
really my specialty, so I will defer to Tim Wicinski on that.
</ch>
>
> 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/
> <https://mailarchive.ietf.org/arch/msg/cbor/x9o8goNc3vgmPXFFVSDo1oks-i4/>
> </atw>
<ch>
I read the email thread and the review. They ensured that the RR content
specifications conforms with CBOR/CDDL rules and practices, which is
great. As I told you, my concern is not there. I am worried of the
potential for coding errors in handwritten message parsers. We have a
long history there. It would be nice if we had a set of test samples
deliberately exercising the quirks of CBOR, such as the variable length
encoding of integers and lengths. Maybe adding a series of deliberately
erroneous test samples, e.g., with mismatch between the RR length field
and the encoding. Opinion of whether such test vectors belong in an RFC
vary, but it would be nice if they were available somewhere!
</ch>
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
