On 5/7/2025 1:40 PM, Robert Moskowitz wrote:
Greetings Christian!
Hello Bob! Nice to have a technical exchange with you!
On 5/1/25 9:08 PM, Christian Huitema via Datatracker wrote:
Document: draft-ietf-drip-registries
Title: DRIP Entity Tags (DET) in the Domain Name System (DNS)
Reviewer: Christian Huitema
Review result: Has Nits
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?
Roman and I went around this quite a bit during review for 9374. And a
thread I started in CFRG (see ref CFRG-COMMENT in 9374) looked at this
attack.
Yes, an adversary CAN duplicate a DET with another Public Key.
Particularly if attacking a delivery service with thousands of DETs;
only need to duplicate one.
But this Public Key will not be signed by the HDA and that level of
the DNS SHOULD be DNSSEC signed. All the Endorsements (9575 DRIP
Endorsement and X.509 certs) contain the public key, signed by the
next node up the tree.
The attacker CAN duplicate a DET, but the Endorsement they stuff into
the DNS record (with their Public Key) will not pass validation.
My problem is that DNSSEC is "recommended" in drip-reg, but is not
mandatory. If it is not mandatory, then there will be a code path to
deal with unsigned HDA subtrees. We can imagine DNS shenanigans to
deliver a HHIT record that is not signed. At that point, the solution
has to be to either reject it because of the lack of DNSSEC, or to
verify it through some other means. I could see the entity reading the
record because it "knows" that this subtree must be signed (maybe
because signature is mandatory for this RAA). Or I could see some
PKI/DANE style verification of the certificate in the HHIT. We do not
have text in the draft explaining that. Is it because it is obvious to
everybody but me? (Old age could do that.)
Also in use, the full DET tree is sent (see rfc 9575).
So careful consideration was applied to the whole DET tree.
Also draft-ietf-drip-dki goes into this. And the profiles in this
draft will be in ICAO's Certificate Policy, Sec 10.3.4 (in final draft
review to come out end of May, Doc 10169).
Sure. But the DRIP certificates are not part of the HHIT record.
The root of my issue is that DNSSEC is not mandatory, and thus the
entities will sometimes retrieve HHIT or BRID records that are not
signed. I would like to see some text explaining how the various DRIP
users can deal with that.
-- Christian Huitema
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
