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

["shuaiizhao(Shuai Zhao)" <[e-mail]>]

Hi Daniel,


  1.  All updated based on suggestion -19. Will sync with co-authors for latest changes.
  2.  I reconfirm I am not aware of any IPRs.

Best,
Shuai

From: Daniel Migault <[e-mail]>
Date: Wednesday, January 12, 2022 at 19:40
To: "shuaiizhao(Shuai Zhao)" <[e-mail]>
Cc: "Stuart W. Card" <[e-mail]>, Mohamed Boucadair <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: [Internet]Re: Re: [Drip] 2nd WGLC of draft-ietf-drip-arch (Ends 30/12/2021)

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]<mailto:[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]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[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.
Shuai/ removed


    > 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.
Shuai/ Updated.
    > 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.
Shuai/ I think we can get ready for that 😊

    > 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.
Shuai/ Updated.
    > " 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.
Shuai/ referenced drip-auth as normative , the same as we did for drip-req in drip-auth.


    Thanks Daniel!

    --
    -----------------------------------------
    Stuart W. Card, PhD, Principal Engineer
    AX Enterprize, LLC  www.axenterprize.com<http://www.axenterprize.com>
    4947 Commercial Drive, Yorkville NY 13495

    --
    Tm-rid mailing list
    [e-mail]<mailto:[e-mail]>
    https://www.ietf.org/mailman/listinfo/tm-rid


--
Daniel Migault
Ericsson