Roman Danyliw - Githubissues

Discussion points:

** Definition of a HHIT.

Various security claims are made about the HHIT down to specifying cryptographic algorithms and resistance to attacks. However, this document provides inconsistent and vague definitions for a HHIT. Surprisingly, it doesn’t cite draft-ietf-drip-rid. It is difficult to assess these claims given the lack of information on a HHIT. I would have expected this architecture document to make high-level claims and leave the details to a standards-track document. A few places to source the HHTI definitions:

-- Section 3 says ‘… explains the use of Hierarchical Host Identity Tags (HHITs) [RFC7401] …”, RFC7401 defines HIT but not HHIT.

-- Section 3 also says ‘Self-asserting in this usage means that, given the Host Identity (HI), the HHIT ORCHID construction and a signature of the registry on the HHIT …”, but as doesn’t explain that connection

-- A few places in the text suggest that HHIT, as the name suggest are hierarchical, and this hierarchy is key to ensuring security properties (e.g., Section 3.2. “The cryptographically-bound addition of the Hierarchy …”; Section 3.4 says “To provide this, each HHIT embeds plaintext information designating the hierarchy within which it is registered and a cryptographic hash of that information concatenated with the entity's public key, etc. provides examples of computing a HHIT by encoding a HHIT”; and Section 4.2.1. “The HHIT hierarchy can provide the needed scalability and management structure”). Where is that hierarchy explained in this document?

This is up to the WG, but IMO, the discussion about cryptographic properties would be better suited in the document providing the specifics (draft-ietf-drip-rid) and the top-level security properties cited by reference here.

** Verification process of claims/assertions. -- Section 3.2. Each Observer device SHOULD be provisioned either with public keys of the DRIP identifier root registries or certificates for subordinate registries.

-- Section 3.2 ... prepopulating small caches on Observer devices with Registry public keys and a chain of Attestations or Certificates (tracing a path through the Registry tree).

Where is the behavior ensuring a trust relationship between registries described? These are no chains certificates in the X.509 sense.

Where is the link between the “DRIP identifier root registries” and the verification of UA traffic? Is that draft-ietf-drip-auth?

-- Section 5. Optimization of different DRIP Authentication Messages allows an Observer, without Internet connection (offline) or with (online), to be able to validate a UAS DRIP ID in real-time. First is the sending of Broadcast Attestations (over DRIP Link Authentication Messages)

[I-D.ietf-drip-auth] containing the relevant registration of the UA's DRIP ID in the claimed Registry. Next is sending DRIP Wrapper Authentication Messages that sign over both static (e.g., above registration) and dynamically changing data (such as UA location data). Combining these two sets of information, an Observer can piece together a chain of trust and real-time evidence to make their determination of the UA's claims.

How does the use of specific message work if the Observer is offline?

As noted above, this is up to the WG, but IMO there is a level of detail here that distracts from the discussion of the architecture. It would be best covered by reference.

** Section 9 Broadcast RID messages can contain Personally Identifiable Information (PII). A viable architecture for PII protection would be symmetric encryption of the PII using a session key known to the UAS and its USS ...

Per “A viable architecture ...”, I’m not sure how to read all the text after the first sentence given this phrasing. Is the rest of the text the official “DRIP architecture” or an example? I’m assuming the former and believe it would benefit from its own set of security considerations. A few initial questions:

-- Are there channel security requirements between the decryption oracle/key escrow or distribution server/USS and the Observer?

-- Is there a strong authentication/authorization model to gain services from the USS?

-- How does this oracle or key server approach work in the case an offline observer?

comments: ** Section 1.2.1. This section discusses a “range up to approximately 1 km”, notes “smartphones” as endpoints, and cites Bluetooth and WiFi as the wireless technologies. Even with line of sight, these seem like very long ranges without specialized antennas (i.e., not on a smartphone).

** Section 2.1

DRIP could address standardization of secure protocols between the UA and GCS (over direct wireless and Internet connection), between the UAS and the Net-RID SP, and/or between the Net-RID DP and Observer devices.

Can this text be clarified? Does this hypothetical make sense in an archival document?

** Figure 4. This diagram introduces a lot of complexity, but then doesn’t reference architectural elements later by these names – GPOD and PSOD; and these use cases too -- V2I, VV. Are those additional labels needed?

** Section 3.1

… a revision to [F3411], currently in balloting (as of Oct 2021) , adds type 4, Specific Session ID, to be standardized by IETF and other standards development organizations (SDOs) as extensions to ASTM UAS RID, consumes one of those bytes to index the sub-type, leaving only 19 for the identifier (see DRIP Requirement ID-1).

Has anything of note happened in the last 9 months per the type 4 balloting activities in [F3411]? Section 3.2. Consider:

OLD By construction, the HIT is statistically unique through the cryptographic hash feature of second-preimage resistance

NEW By construction, the HIT is statistically unique through the mandatory use of cryptographic hash functions with second-preimage resistance.

** 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

It would be clearer to explain how to compute these 84 bytes (64-bytes for the Ed25519 signature + 16-bytes for the HHIT + 4 byte for the timestamp = 84 bytes).

** Section 3.2 Ed25519 [RFC8032] is used as the HHIT signing algorithm as [RFC9153] GEN-1 and ID-5 can best be met by restricting the HI to 32 bytes. A larger public key would rule out the offline attestation feature that fits within the 200-byte Authentication Message maximum length. Other algorithms that meet this 32 byte constraint can be added as deemed needed.

-- The requirement for using Ed25519 doesn’t come from [RFC9153]

-- If Ed25519 is MTI, it should be stated here or instead cite the standards track document from which it comes. It feels a bit odd to me to have an informational document specifying the required crypto algorithm when there are more detailed proposed standard document with the required interoperability details.

** Section 3.3

Given the size constraints imposed by the Bluetooth 4 broadcast media, the UAS ID itself needs to be a non-spoofable inquiry input into the lookup.

Shouldn’t the UAS ID be non-spoofable regardless of the Bluetooth size constraints.

** Section 3.4. Although hash collisions may occur, the registrar can detect them and reject registration requests rather than issue credentials ...

This is the first reference to Registrar issuing credentials. What are those?

** Section 4. DRIP registries [I-D.ietf-drip-registries] hold both public and private UAS information (See PRIV-1 in [RFC9153]) resulting from the DRIP identifier registration process.

What is the link to PRIV-1?

** Section 4.1.1. What role does the HDA and RAA play relative to the reference architecture in Figure 4.

** Section 4.1.2. What is a “standardized HHIT FQDN” vs. a “HHIT”?

** Section 4.1.2.

A DRIP identifier SHOULD be registered as an Internet domain name (at an arbitrary level in the hierarchy, e.g., in .ip6.arpa).
(Since this is a “SHOULD” level requirement without citation) What is does it mean to register at an arbitrary level in the hierarchy beyond just registering?

** Section 4.2. What information is being put into the Private Information Registry?

** Section 4.2.2 and 4.2.3. I don’t understand the contrast being proposed here. In Section 4.2.2, there is a feature rich protocol like EPP being suggested which handles not only query capabilities but a add/delete/update support. Section 4.2.3 seems to be suggested query only capabilities. If one uses, WebFinger, is there an alternative mechanism expected to register this information? Could I use EPP + WebFinger?

** Section 5.

For that it MUST be registered (under DRIP Registries)

In both the public and private registry?

** Section 5.

Only sending the DET and a signature on frequently changing data that can be sanity-checked by the Observer (such as a Location/Vector message) proves that the observed UA possesses the claimed UAS ID.

-- Editorial. In the spirit of inclusive language consider an alternative to “sanity-checked”.

-- What additional validation is the Observer doing?

-- Does it “prove” or increase the likelihood of the UAS does in fact have the identity? The current text suggests that it is circumstantial.

** Section 5. From received Broadcast RID messages and information that can be looked up using the received UAS ID in online registries or local caches, it is possible to establish levels of trust in the asserted information and the Operator.

What are these levels of trust? As in the previous comment, is this a increased confidence in the information?

* Section 6.. The CS-RID doesn’t appear to land on the reference architecture in Figure 4.

** Section 7.

-- What does it mean to “initiate a cryptographic handshake … assuming mutual authentication … IPsec tunnel” vs. just initiating a IPsec tunnel?

-- What is the planned approach for provision the key materials for this communication?

-- Is it being suggested that the public/private key pair be used for IPsec too?

-- There is no suggestion of reusing the HIT public/private key for IPsec?

** Section 8.

Compromise of a registry private key could do widespread harm.

Understood. Thanks for saying so. Could you please add more text to explain why there would be widespread harm. There is almost no detail in this document about what is in that registry.

** Section 8.

Key revocation procedures are as yet to be determined.

-- Revocation of what keys? The key-pair used for the HI and to generate the HHIT?

-- What’s the plan for static HI/HHITs set by the manufacture as described in Section 3.2

** Section 8.1

Leakage of the private key either from the UA or GCS to the component manufacturer is a valid concern and steps need to be in place to ensure safe keeping of the private key.

-- Section 3.2 seems to allow for the possibility that the manufacture is in the key security boundary. What is the implication of that design?

-- In what way is it anticipated that a UA would leak a key back to the manufacturer?

** Section 8.1 Since it is possible for the UAS RID sender of a small harmless UA (or the entire UA) to be carried by a larger dangerous UA as a "false flag", it is out of scope to deal wtih secure store for the private key.

I don’t follow why a piggy-backing done precludes the need for dealing with the secure storage of private keys. I would understand that DRIP is making it out of scope as it is an end-point security issue. However, declaring secure storage of keys as out of scope is inconsistent with draft-ietf-drip-rid-29 which says in Section 4.1, that “The private key for the HI SHOULD be held in a cryptographically secure component.”

** Section 8.2 UAs and Broadcast Remote ID communications are so constrained that current post quantum computing cryptography is not applicable.

Plus since a UA may use a unique HHIT for each operation, the attack window could be limited to the duration of the operation.

Since we are talking about a non-existent quantum computer, I’m not sure why this time bounding excludes consideration for this reason. There would be no confusion or complication in the RID ecosystem if an attacker could reuse HHIT in a volume of airspace?

Editorial -- Section 1.1. Editorial. s/The rule clearly states/The rule states/

-- Section 1.2 Editorial. s/two types UAS Remote ID/two types of UAS Remote ID/

-- Figure 2. Editorial. Consider number the steps described in the previous paragraph and then providing these corresponding numeric labels in the diagram.

-- Section 5. Typo.

OLD A sender's identity can not be approved NEW A sender's identity can not be proved

ietf-wg-drip / draft-ietf-drip-arch

Roman Danyliw #51