Re: [Drip] Roman Danyliw's Discuss on draft-ietf-drip-arch-24: (with DISCUSS and COMMENT)

[Robert Moskowitz <[e-mail]>]

On 6/28/22 15:09, Roman Danyliw via Datatracker wrote:
> Roman Danyliw has entered the following ballot position for
> draft-ietf-drip-arch-24: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-drip-arch/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I applaud the deliberate consideration being provided for security matters.  My
> concern is about the symmetry between the security claims being made and the
> level of detail being provided in the mechanisms.
>
> ** 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.

I am going to take a shot, here, at adding in references to dirp-rid 
that has evolved to avoided, to needed..


1. Introduction

    The architecture adheres to the requirements listed in the DRIP
    Requirements document [RFC9153].  The requirements document provides
    an extended introduction to the problem space and use cases. Further,
    it frames the DRIP Entity Tag (DET) [ietf-drip-rid] within the 
architecture.

..........

3.  HHIT as the DRIP Entity Identifier

    This section describes the DRIP architectural approach to meeting the
    basic requirements of a DRIP entity identifier within external
    technical standard ASTM [F3411] and regulatory constraints.  It
    justifies and explains the use of Hierarchical Host Identity Tags
    (HHITs) [ietf-drip-rid] as self-asserting IPv6 addresses suitable as 
a UAS
    ID type and, more generally, as trustworthy multipurpose remote
    identifiers.

    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 and HI, the HHIT can be verified by the receiver as a 
trusted UAS ID.
    The explicit registration hierarchy within the HHIT provides 
registry discovery
    (managed by a Registrar) to either yield the HI for a 3rd-party
    (seeking UAS ID attestation) validation or prove that the HHIT and HI
    have been registered uniquely.

3.3.  HHIT for DRIP Identifier Registration and Lookup

...  Note:  1st para reworded further down on question about 3.3....

    A DRIP registration process based on the explicit hierarchy within a
    HHIT provides manageable uniqueness of the HI for the HHIT.  The
    hierarchy is defined in [ietf-drip-rid] and consists of 2-levels, a
    Registered Assigning Authority (RAA) and then a Hierarchical HIT
    Domain Authority (HDA).  The registration within this hierarchy is
    the defense against a cryptographic hash second pre-image attack on
    the HHIT (e.g., multiple HIs yielding the same HHIT, see Requirement
    ID-3).  A lookup of the HHIT into the registration data provides the
    registered HI for HHIT proof of ownership.  A first-come-first-served
    registration for a HHIT provides deterministic access to any other
    needed actionable information based on inquiry access authority (more
    details in Section 4.2).

Do these changes, adding reference to ietf-drip-rid clear up your questions?


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


    In general, Internet access may be needed to validate Attestations or
    Certificates [I-D.ietf-drip-registries] transmitted ASTM Authentication
    Messages [I-D.ietf-drip-auth].  This may be obviated in the most 
common cases (e.g.,
    attestation of the UAS ID), even in disconnected environments, by
    prepopulating small caches on Observer devices with Registry public
    keys and a chain of Attestations or Certificates (tracing a path
    through the Registry tree) defined in [I-D.ietf-drip-registries].  This
    is assuming all parties on the trust path also use HHITs for their 
identities.


and I see text I need to add to drip-auth.  thank you.

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

Covered in drip-auth that there is an attestation of the UA DET by the 
registrar (HDA) and that signed by the UA.  Thus only a cache with HDA 
keys is needed.

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

One proposal for this is

https://datatracker.ietf.org/doc/draft-moskowitz-drip-operator-privacy/

It also deals with policy of use, like MUST NOT be used when there is no 
Internet for Authorized Observers to get keys.

This one gets into a bit of airspace politics.

I think the text is as specific it can be without pointing to 
drip-operator-privacy.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you to Valery Smyslov for the SECDIR review.
>
> ** 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).

Actual field work has shown these distances achieved and there is a 
general push from many sources to use these numbers.


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

draft-moskowitz-drip-secure-nrid-c2

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

Other authors will need to address this.

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


Looks like it is FINALLY available:

https://www.astm.org/f3411-22.html

I downloaded my members copy that I could not get last month, and also 
last month the public version was only the redline copy.

Looks like it is finally available so we can update all references.

Whew.

We will update the draft to reflect the finally published F3411-22.


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


Thanks will make this change.

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


    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 only including
    the 16-byte HHIT, a 4-byte timestamp, and the 64-byte EdDSA25519
    signature.

Does this work better?  To leave out any comparison to using some TLV 
method?


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

    Ed25519 [RFC8032] is used as the HHIT Manditory to Implement
    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.

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

    UAS RID needs a deterministic lookup mechanism that rapidly provides
    actionable information about the identified UA.  Given the size
    constraints imposed by the Bluetooth 4 broadcast media, the UAS ID
    itself, with no associated transmitted data, needs to be a non-spoofable
    inquiry input into the lookup.

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


In drip-registries.  And we are still adjusting content in that draft, 
though it is 90% ? right?

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

PRIV-1 says:  Confidential Handling:

I think sec 4 includes Confidential Handling within the registration 
process.

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

The HDAs run the Public and Private Registries under the authorization 
of their RAA.

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

One standardized in the DRIP documents for DRIP participants to use for 
DNS lookups.

Drip-registries will be where this is defined.

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

    A DRIP identifier SHOULD be registered as an Internet domain name (at
    an arbitrary level in the hierarchy, e.g., in .ip6.arpa) 
[I-D.ietf-drip-registries] .  Thus DNS


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

Policy of RAA and HDA. Covered in [I-D.ietf-drip-registries] , but 
generally out of scope as it will be up to each to decided what to 
require and then make available to authorized users.  You don't like
what one RAA|HDA is asking of you, try another.

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

drip-registries develops the EPP/RDAP approach for RAAs and HDAs. But 
some RAA/HDA might want to take another approach, thus 4.2.3.

> ** Section 5.
>
>    For that it MUST be
>     registered (under DRIP Registries)
>
> In both the public and private registry?

Public, as this is what public observers will rely on.

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

Oops 'approved"?  I think that was suppose to be "proved".

I don't which one of us take the hit on "sanity-checked", but:

    While the DRIP entity identifier is self-asserting, it alone does not
    provide the trustworthiness (non-repudiability, protection vs.
    spoofing, message integrity protection, scalability, etc.) essential
    to UAS RID, as justified in [RFC9153].  For that it MUST be
    registered (under DRIP Registries) and be actively used by the party
    (in most cases the UA).  A sender's identity can not be proved by
    only possessing a DRIP Entity Tag (DET) and broadcasting it as a claim
    that it belongs to that sender.  Even the
    sender using that HI's private key to sign static data proves nothing
    as well, as it is subject to trivial replay attacks.  Only sending
    the DET and a signature on frequently changing data that can be
    externally validated by the Observer (such as a Location/Vector message
    matching actually seeing the UA at that location)
    proves that the observed UA possesses the claimed UAS ID.


> -- What additional validation is the Observer doing?

Just because the Observer receives a signed Location/Vector message and 
all the pieces in drip-auth, is that to be trusted and proof of the UA.  
"Seeing is believing", so actually Observing the UA about around the 
claimed location and speed.  Note about 'claimed'; the UA have traveled 
further or there might be GPS issues where the UA is resulting in errors 
in the GPS data.  But "The it is!" and it kind of matches these messages 
my smartphone is displaying on the map...


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

We have spent a lot of time discussing what really establishes identity 
proofs and where fault lines exist.  Spoofable Identities with 
sight-provable location messages only establishes that a UA is there 
making a non-provable identity.  We have concluded you need provable 
digital data and physical existence data  (I see it).


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

each piece notches up the confidence.

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

For author of Figure 4...

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

    A suitably equipped Observer could initiate a secure communication
    channel, using the DET HI, to a similarly equipped and identified 
entity: the UA itself, if
    operating autonomously; the GCS, if the UA is remotely piloted and
    the necessary records have been populated in DNS; the USS, etc.
    Assuming secure communication setup (e.g. via IPsec or HIP),
    arbitrary standard higher layer protocols can then be used
    for Observer to Pilot (O2P)communications (e.g., SIP [RFC3261] et
    seq), V2X communications (e.g., [MAVLink]), etc.  Certain
    preconditions are necessary: each party needs a currently usable
    means (typically DNS) of resolving the other party's DRIP entity
    identifier to a currently usable locator (IP address); and there must
    be currently usable bidirectional IP (not necessarily Internet)
    connectivity between the parties.  One method directly supported by
    the use of HHITs as DRIP entity identifiers is initiation of a HIP
    Base Exchange (BEX) and Bound End-to-End Tunnel (BEET).


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

I believe the above text clears this up that it is the HIs.

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

IPsec or HIP.

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

Using, say MOBIKE and SubjectPublicKeyInfo encoding of HIs?

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

    Compromise of a registry private key could do widespread harm
    [I-D.ietf-drip-registries].  In particular, it would allow bad actors to
    impersonate trusted members of said 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?

Yes, thus revocation of a DET.  Will be added into 
[I-D.ietf-drip-registries]

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

[I-D.ietf-drip-registries]  covers this.

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

Unfortunately we have seen this in part in the Ukraine.  Russia has been 
getting information on Ukrainian drones used from their Chinese 
manufacturers.  The young men that were hobbyists have found that this 
need to be very careful on what they do, or they get personally targeted.


So do you trust your manufacturer?  DoD is not allowed to use DJI 
systems.  Well, I have heard they use the physical platform and put in 
their own controller systems.  DJI makes some of the best UAs...


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

It means make reasonable efforts, but know that your best efforts can be 
circumvented all too easily.  No excuse for basic protection, but 
tamper-proof, like some at FAA call for, is pretty much a waste.  
Tamper-evident, though....  (this is an ongoing discussion)

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

If the HHIT is time-bound for its use to a hour flight, say, then the 
attacker has to do that during that time.  These are Session IDs, but 
the length of the Session is up to the UAS owner (and maybe HDA policy).

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

Thank you.


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

thank you for all your comments.

I hope that these changes help address your concerns and I am open to 
further discussions.

Bob