Re: [Drip] [Internet]Re: 2nd WGLC of draft-ietf-drip-arch (Ends 30/12/2021)

[Daniel Migault <[e-mail]>]

Thank you all for the followup. We are probably close to being done, here
are my (minor) comments. As we did have some significant changes, please
reconfirm you are not aware of any IPR and let's ship the document.

Yours,
Daniel

On Wed, Jan 12, 2022 at 5:51 PM shuaiizhao(Shuai Zhao) <
[e-mail]> wrote:

> Hi Daniel and Stu,
>
> Please see my reply inline. Comments from Stu have answered some of
> Daniel's questions, so please double check if those have been cleared.
>
> I will share -19 with co-authors having the suggested changes below.
>
> Best,
> Shuai
>
> On 1/8/22, 07:23, "Tm-rid on behalf of Stuart W. Card" <
> [e-mail] on behalf of [e-mail]> wrote:
>
>     responses interleaved
>
>     On 12/22/2021 5:53 PM, Daniel Migault wrote:
>     > Hi,
>     >
>     > Thanks for posting this version, we are on track.
>     >
>     > The document is informational and I can see some normative language.
> I
>     > personally do not care and find it clearer but apparently it becomes
>     > something the IESG looks at, so maybe our AD can provide some
> guidance
>     > there.
>     >
>     > Before submitting -19, please ensure that you run the nits check on
> the
>     > datatracker.
>     > Please find below the current nits reported by the datatracker for
> this
>     > version.
>     >
> https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-drip-arch-18.txt
>     > <
> https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-drip-arch-18.txt
> >
>     >
>     > You can run it at the submission time.
>     >
>     > To complete the shepherd write up I would need the following
> information:
>     > 1. Please let me know which known implementations
>     > 2. For each author confirmed that any and all appropriate IPR
>     > disclosures required for full conformance with the provisions of BCP
> 78
>     > and BCP 79 have already been filed.
>     >
>     > Please see my comments for this version.
>     >
>     > Yours,
>     > Daniel
>     >
>     > abstract
>     > '''
>     > This document describes an architecture for protocols and services to
>     >     support Unmanned Aircraft System Remote Identification and
> tracking
>     >     (UAS RID), plus RID-related communications.
>     > '''
>     > I am wondering if 'and tracking' has not been added mistakenly. In
> fact
>     > it seems strange to have (UAS RID) after as opposed to before 'and
>     > tracking' and I could see tracking as one of the services associated
> to
>     > UAS RID.
>     >
>     > The same text is copied in the introduction.
>
>     This was intentional. UAS RID indeed is the acronym for not just
> remote
>     identification but also tracking. The FAA ARC name and the ASTM F3411
>     standard title both include "and tracking".
>
>     > section 1.2.2
>     >
>     > """
>     > [F3411  <
> https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch-18#ref-F3411>],
> using the same data dictionary that is the basis of
>     >     Broadcast RID messages, defines a Network Remote Identification
> (Net-
>     >     RID) data flow as follows.
>     > """
>     >
>     > Unless I am missing it, I do not think the data dictionary has been
>     > defined for the broadcast ID. I have the impression ''using the same
>     > data dictionary that is the basis of Broadcast RID messages,"
> couldbe
>     > removed.
>
>     Addressed in my previous email.
>
>     > I do not see GCS being shown in its expanded form. I propose it is
>     > expanded in section 1.2.2.
>
>     I agree that all acronyms should be expanded on first use in the prose
>     body of each document, even if also expanded in the terminology of
> that
>     document or another document cited as the terminology reference (such
> as
>     -reqs for DRIP).
>
> Shuai/ Expanded GCS at first use
>
>     > Figure 2
>     > I am wondering if USS can be placed on the figure.
>
>     The Net-RID SP will usually be a function of a USS.
>     The Net-RID DP will often be a function of that same or another USS.
>     This is explicit in the FAA rule but not specified in ASTM F3411.
>
>     > I have the impression DSS is a subpart of the Net-RID SP and more
>     > especially the interface between the Net-RID SP and the Net-RID DP.
> I am
>     > wondering if that is correct, and in any case if DSS may be
> represented
>     > on the figure.
>
>     DSS is used to support Network RID and also for other UTM functions.
>     It is an overlay network on the Internet, provided by one or more
>     servers, used for discovery and synchronization, per its name, but not
>     use for main data transfer between USS (which communicate more or less
>     directly, typically via TCP connections from one USS to another).
>     I suspect the figure would become more confusing if we tried to show
> it.
>
>     > I am also wondering if there are any reasons to represent links
> without
>     > orientation as opposed to directed links. I see that arrows might
> help
>     > understand the description easier, while links are never totally
>     > uni-directional.
>
>     These links are generally bidirectional.
>     Arrows here could show the typical main data flow direction.
>
>     > It is a bit unclear to what the link (+) - (+) represents.
>
>     That was a logical 'or' connection:
>
>     UA could talk via the Internet to a Net-RID SP;
>
>     GCS could talk via the Internet to a Net-Rid SP;
>
>     UA could talk via the Internet to the GCS and thence via the Internet
> to
>     a Net-RID SP;
>
>     UA could talk via a direct wireless link to the GCS and thence via the
>     Internet to a Net-RID SP.
>
>     If that is not clear, I guess we need more text to make it clear.
>
>     > The figure uses NET-RID SP while the text uses Net-RID SP.
>
>     CamelCase in text is correct, all caps in figure is wrong.
>
> Shuai/ I saw req-18 uses a different style, "NET-Rid SP" in the figure,
> "Net-RID SP" in text. Arch-19 follows Req-18's format, Let me know if that
> works for everyone
>
>     > """
>     > Command and Control (C2) must flow from the GCS to the UA via some
>     >     path, currently (in the year of 2021) typically a direct RF
> link, but
>     >     with increasing beyond Visual Line of Sight (BVLOS) operations
>     >     expected often to be wireless links at either end with the
> Internet
>     >     between.
>     > """
>     > I suspect there is nits and it could be "... operations, it is
> expected
>     > " -- but I guess co-authors are more qualified to check the language.
>
>     I have no objection to such an edit.
>
> Shuai/ Implemented as suggested, Looks good to me.
>
>     > The text also mentions "via some path" in the paragraph above and
> the
>     > following one. I have the impression that is unnecessary information
>     > that can be removed -- as if no path would exist the communication
> would
>     > not be possible.
>
>     The point was that _some_ path is needed for C2, so can be assumed to
> be
>     present during operations and potentially re-usable for other (not C2
>     but related) purposes, however exactly _what_ path is unspecified.
>
>     > """
>     >   [F3411] prescribes the protocols between the Net-RID SP, Net-RID
> DP,
>     >     and the Discovery and Synchronization Service (DSS).  It also
>     >     prescribes data elements (in JSON) between Observer and Net-RID
> DP.
>     >     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.
>     > """
>     >
>     > From the figure I can see the link between SP and DP, but I am
> missing
>     > where the DSS is and if there is another link.
>
>     The servers that comprise the DSS can be anywhere on the Internet.
>     They are not part of the main data flow of Network RID.
>     They are used _inter alia_ to enable one USS to find another,
>     e.g. a Net-RID DP to find a Net-RID SP with operations in a 4-D volume
>     intersecting a volume of interest to a client of the Net-RID DP.
>
>     > The display of the informative note is strange. I do not see any
> reason
>     > for having something different than a standard paragraph. This is
> just a
>     > comment that can be fixed by the rfc editor.
>
>     It was suggested, I can't remember by whom but thought it was one of
> the
>     chairs or the AD, that we highlight this point.
>
> Shuai/ At that time, half of year ago, authors were asked to put such note
> to make things clear. I suggest we leave it there.
>
>     > section 1.3
>     >
>     > DSS is expanded multiple times. I suggest expanding it once.
>
>     I agree, just the 1st use.
>
> Shuai/ updated
>
>     > Figure 3: maybe for coherence, DSS may be mentioned together with SP
> in
>     > a similar way as figure 2 -- with the additional DSS.
>
>     Additional DSS? I don't understand the comment.
>
>     > section 1.4
>     >
>     > I am not sure the two bullet style is intentional.
>
>     Neither am I.
> Shuai/ Updated
>
>     > Figure 4
>     >
>     > I have the impression NetRID goes through SP/DP to some observers in
>     > this case GP/PS OD or the other UAS. The figure may suggest that
> NetRID
>     > are directly communicated by one UAS to the other. I am wondering if
>     > orienting lightly the flows towards the observers might clarify the
>     > figure. Keep this as a suggestion as I believed you went already
> through
>     > such suggestions.
>
>     It was intended only to show that each UAS must use the Internet for
>     Network RID, but that either UAS subsystem (UA or GCS) may make the
>     proximate connection.
>
>     UAS indeed may in some cases communicate directly with each other, but
>     that is not currently envisioned as a primary use case for RID.
>
>     We tried to use arrows only where a connection was strictly
>     unidirectional, as in Figure 1. We could change the convention to use
>     them to indicate the typical main data flow direction, but the only
>     place where that would be likely to improve rather than degrade
> clarity
>     would be in Figure 2.
>
>     > I am also wondering if the registration link could be oriented
> toward
>     > the registries.
>
>     There is no registration link; the annotation "Registration (and UTM)"
>     was only to indicate that GCS - Internet connectivity is required at
>     least to support registration, and is also required to support UTM if
>     the UAS is participating in UTM, but is not restricted to those uses.
>
>     > section 3
>     >
>     > """
>     > Self-asserting in this usage is given the Host Identity (HI), the
>     >     HHIT ORCHID construction and a signature of the HHIT by the HI
> can
>     >     both be validated.
>     > """
>     > I suspect there is a english nits in "is given the" -- maybe "is
> given
>     > by the ''.
>     > I am wondering if any references should be added to  HI, HHIT
> ORCHID...
>     > I have the impression that as we remain at a high level description
> and
>     > the rid document is close to being ready that we can reference it
> for
>     > HHIT ORCHID if needed.
>
>     I admit this construction is somewhat inelegant, even if grammatically
>     allowed. Perhaps "in this usage means that, if given only the HI, then
>     the HHIT..."?
>
> Shuai/  I think "is given by" is probably better.
>
>     > section 3.1
>     >
>     > I believe that mentioning cryptographic identifiers is sufficient.
>     >
>     > """
>     > This
>     >     means that given a sufficient collection of RID messages, an
> Observer
>     >     can establish that the cryptographic identifier claimed therein
>     >     uniquely belongs to the claimant
>     > """
>
>     The point was that due to the short maximum payload of a single RID
>     message (due to the short Bluetooth 4 advertisement frames), UAS ID
>     ownership cannot be established on the basis of a single message, but
>     rather requires a collection of messages.
>
>     > I see the following text as necessary and can be removed:
>     >
>     > """
>     >   that the only way for any other entity to prove
>     >     ownership of that identifier would be to obtain information that
>     >     ought to be available only to the legitimate owner of the
> identifier
>     >     (e.g., a cryptographic private key).
>     > """
>
>     Fine, if the assumption is that any reader not only already
> understands
>     this basic principle of asymmetric crypto based authentication but
> also
>     finds it obvious that we propose here a correct application thereof.
>
> Shuai/ I think that is a good piece information. But remove it now as
> suggested by Chair
>
>     > I suggest to split the following sentence for clarity.
>     >
>     > """
>     >   Likewise, the
>     >     maximum ASTM RID [F3411  <
> https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch-18#ref-F3411>]
> Authentication Message payload is 201 bytes
>     >     for most authentication types, but for type 5, also added in this
>     >     revision, for IETF and other SDOs to develop Specific
> Authentication
>     >     Methods as extensions to ASTM RID, one byte is consumed to index
> the
>     >     sub-type, leaving only 200 for DRIP authentication payloads,
>     >     including one or more DRIP entity identifiers and associated
>     >     authentication data.
>     > """
>
>     I agree.
>
> Shuai/ Updated.
>
>     > """
>     > Rather than using a key
>     >     signing operation to claim ownership of an ID that does not
> guarantee
>     >     name uniqueness, in this method the ID is cryptographically
> derived
>     >     directly from the public key.
>     > """
>     >
>     > I believe the problem is more related to the way an ID is bound to
> the
>     > key. It is also hard to guarantee no collision happens. I believe
> that
>     > saying what we do is clearer than suggesting in a very unclear way
> what
>     > we do not do. I would suggest to replace the following sentence by:
>     >
>     > """
>     > In this method the ID is cryptographically derived
>     >     directly from the public key.
>     > """
>
>     As long as we retain, in some form, the justification for _why_ we do
> this.
>
> Shuai/ Updated
>
>     > As I understand, this sentence repeats the one of the
>     > following paragraph and can be removed. On the other hand we do not
>     > mention the ID as being the HIT, so I would suggest to replace
>     > """
>     > OLD:
>     > It is statistically hard for
>     >     another entity to create a public key that would generate
> (spoof) the
>     >     ID.
>     >
>     > NEW:
>     > The public key is designated as the HI while the ID is designated as
> the
>     > HIT.
>     > """
>     >
> Shuai/ This suggestion looks fine to me, implemented as suggested.
>
>     > """
>     > The basic HIT is designed statistically unique through the
>     >     cryptographic hash feature of second-preimage resistance.
>     > """
>     >
>     > The basic HIT seems to be the HIT, as it follows the description
> above I
>     > would consider saying:
>     > By construction, the HIT is statistically unique...
>
>     I don't have any objection to rewording for clarity and to remove any
>     redundancy. Bob is not the right writer to do the rewording, but he
>     needs to vet any proposed rewording, _inter alia_ to maintain
>     consistency of usage, e.g. identity vs identifier.
>
> Shuai/ Suggestion is fine to me.
>
>     > """
>     > The
>     >     cryptographically-bound addition of the Hierarchy and an HHIT
>     >     registration process (e.g. based on Extensible Provisioning
> Protocol,
>     >     [RFC5730]) provide complete, global HHIT uniqueness.
>     > """
>     >
>     > EPP is transparent to the registration process as far as I
> understand. I
>     > do see this information more confusing and would recommend removing
> it.
>     > The text does not explicitly mention why the registration results in
> a
>     > unique HHIT. In my opinion the registration is for little as opposed
> to
>     > the integration of that HIT into a centralized naming scheme that
>     > guarantees by construction the uniqueness.
>
>     I agree that EPP does not need to be mentioned here, as it distracts
>     from the main point addressed here; but it should be mentioned
>     somewhere, as we are trying very hard to leverage existing Internet
>     standards, protocols, infrastructure and business models to achieve
>     trustworthy UAS RID, and EPP is currently the way registration is done
>     in the Internet.
>
> Shuai/ I recall Bob added this a while back. And I don’t think EPP is
> totally transparent to registration process unless I am wrong. I suggest
> keep it for now and will ask Bob for clarification.


Unless you believe that mentioning EPP adds some value. I would remove the
text.

>
>
>     > The following text does in my opinion add any information and should
> be
>     > remove din my opinion.
>     >
>     > """
>     > This
>     >     registration forces the attacker to generate the same public key
>     >     rather than a public key that generates the same HHIT.  This is
> in
>     >     contrast to general IDs (e.g. a UUID or device serial number) as
> the
>     >     subject in an X.509 certificate.
>     > """
>
>     I think it is an important distinction that HHIT collisions are
>     insufficient and only HI collisions are sufficient to create this
>     vulnerability, and that registration is part of enforcing this.
>
>     > """
>     >   Such a static HHIT SHOULD
>     >     only be used to bind one-time use DRIP identifiers to the unique
> UA.
>     > """
>     >
>     > This sentence is unclear to me - I suspect a nits.
>     > While the current text is defining how an HHIT is defined, this
> sentence
>     > - as I understand it - suggest a mechanism where an initial HHIT can
>     > assert the another HHIT. If my understanding is correct it seems a
> bit
>     > out of scope of that section and I would suggest to remove this
> comment.
>
>     The main use for which we are proposing HHITs as DETs is single use
>     Session IDs, which preserve privacy. However, in the US, the FAA has
>     required that Broadcast Modules send their manufacturer assigned
>     hardware serial numbers, so we have also developed a procedure for
>     deriving such serial numbers and corresponding DETs from the same HI
> and
>     other information. However, we do not want to encourage their use
> where
>     single use Sessions IDs are allowed, i.e. for standard RID UA. So we
>     clarify that, if used where Session IDs are allowed, they should be
> used
>     only as the initial anchor of a trust chain, not broadcast or
> otherwise
>     used in operations other than registration. I hav.e no objection to
>     moving this caveat elsewhere in the document, if a more appropriate
>     place for it can be found
>
>
> I see. I am then wondering if the text provides sufficient context. Try to
make sure you catch it properly and ship it as you think it is clear to the
reader.

>     > The section is focused on describing the HHIT of the UA, so I
> suggest
>     > the section finished with such description -- that is the UA and
> differ
>     > comments concerning Observers, USS, providers.... to the end of the
>     > section or at least after the paragraph "A self attesting ...."
>     >
>     > """
>     > Each Observer
>     >     device SHOULD be provisioned either with public keys of the DRIP
>     >     identifier root registries or certificates for subordinate
>     >     registries.
>     >
>     >     HHITs can also be used throughout the USS/UTM system.  The
> Operators,
>     >     Private Information Registries, as well as other UTM entities,
> can
>     >     use HHITs for their IDs.  Such HHITs can facilitate DRIP security
>     >     functions such as used with HIP to strongly mutually
> authenticate and
>     >     encrypt communications.
>     > """
>
>     I have no objection to re-ordering the text for better flow.
>
> Shua/ So my understanding is to move "A DRIP identifier can be assigned to
> a UAS as a static HHIT by its manufacturer,.........." after " A
> self-attestation of a HHIT used as a UAS ID can be done in as little as 84
> byte.......", right. I am fine with that. Just need to clarify.
>
>     > """
>     > A self-attestation of a HHIT used as a UAS ID can be done in as
>     >     little as 84 bytes
>     > """
>     >
>     > This is only valid with Ed25519, and not valid with any signature
>     > algorithm. I think that needs to be specified.
>
>     Agreed that we should cite Ed25519 as one way to achieve this, making
>     clear that it is only one way, which we propose using initially, not
>     precluding other ways that may be developed in the future.
>
> Shuai/   updated as "   A self-attestation of a HHIT used as a UAS ID can
> be done in as
>    little as 84 bytes when use Ed25519 [RFC8032]". Let me know if there is
> objections.
>
>     > section 3.3.
>     >
>     > I have the impression we have been using RID, if so I would suggest
> to
>     > change Remote ID to RID.
>
>     I have no objection to using RID everywhere after spelling it out on
>     first use. However, in some cases we may want to use only "RID" and in
>     other cases "UAS RID", as we propose using DETs not only for UA but
> also
>     for other entities.
>
> Shuai/ I don’t see why we have to use RID in this case, using "Remote ID"
> might be better since it is a new section and easier for reader to digest.
> But I implemented as suggest.
>
>     > HHIT proof should mention the proof of what. It is probably proof of
>     > ownership.
>
>     Again, someone other than Bob should propose specific language, then
> Bob
>     should vet it.
>
> Shuai/ Can Adam help here?
>
> From memory I think just adding "of ownership" would be sufficient.

>     > section 3.4
>     >
>     > Maybe
>     > s/within which is registered/within which it is registered
>
>     Good catch.
>
>     > section 4.1.1
>     >
>     > """
>     >   (e.g., for HDA and RAA
>     >     HHIT|HI used in attestation signing operations)
>     > """
>     >
>     > I am unsure if I understand it correctly. Is the
>     > intention to say that HDA and RAA are identified by
>     > HHIT or HI ?
>
>     More than that: the HHIT of any entity identifies the HDA in which and
>     the RAA under which the entity is registered; the HDA and RAA should
>     also have HHITs of their own, to enable compact attestations of the
>     identifiers and identities of all the entities involved.
>
>     > 4.1.2
>     >
>     > (e.g.  DNS   over TLS) currently most DNS over TLS
>     > have been defined for resolvers. I do not necessarily
>     > see an issue of carrying a DNS packet in TLS, but DNSSEC actually
> does what you are mentioning.
>     > I suggest adding DNSSEC and be prepared to receive some comments
> regarding the DNS over TLS.
>
>     Sorry, I don't understand the comment.
>
> In our case TLS applies between a DNS client and a DNS authoritative
server. Currently DoH DoT is only defined between a DNS client and a DNS
resolver - this is a bit different. I expect some comments to be raised.
To ensure the integrity protection between the client and the authoritative
server DNSSEC can be used.


>     > section 5
>     >
>     > """and be actively used by the party (in most cases the UA)."""
>     >
>     > I believe we need to understand why it needs to be actively used and
> what actively used means.
>
>     Yes, this should be made explicit, perhaps as follows:
>
>     "A sender simply possessing a DET (HHIT based UAS ID) and broadcasting
> a
>     claim that it belongs to that sender proves nothing about that
> sender's
>     identity. Even the sender using that HI's private key to sign static
>     data proves nothing, as it is subject to trivial replay attacks. 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."
>
> Shuai/  Do you need to add the example explanation here? Or it is clear now
>
> Let's say yes.

>     > " without Internet connection (offline) or with (online)," sounds to
> me like A or non A which is always true. I would suggest to remove this
> text.
>
>     You are correct from the perspective of Logic, but I disagree from the
>     perspective of Rhetoric. :-) This highlights the AFAIK unique ability
> of
>     a DET (HHIT based UAS ID) to support both on- and off-line
> verification
>     that the UAS is registered in a specific registry (from which can be
>     inferred a trust classification). We may need to make that more
> explicit.
>
>     > The text introduces a lot of new terminology that needs some
> explanation.
>     >
>     >   """
>     > First is the sending
>     >     of Broadcast Attestations (over DRIP Link Authentication
> Messages)
>     >     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).
>     > """
>     I agree, this is using terms defined in -auth, not -arch or -reqs, so
> it
>     is a "forward reference", which we should avoid.
>
> Shuai/ I don’t know what should I do here. It might not be wise to repeat
> the content from -auth. Need some advice.

just make sure auth is referenced, we can probably live with that.

>
>
>     Thanks Daniel!
>
>     --
>     -----------------------------------------
>     Stuart W. Card, PhD, Principal Engineer
>     AX Enterprize, LLC  www.axenterprize.com
>     4947 Commercial Drive, Yorkville NY 13495
>
>     --
>     Tm-rid mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/tm-rid
>
>

-- 
Daniel Migault
Ericsson