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

From: Daniel Migault <[email-masked]>
Date: Fri, 7 Jan 2022 10:58:01 -0500

Hi everyone,

Please try not to delay the update too much, so we can ship the
document ideally next week.

Yours,
Daniel

On Wed, Dec 22, 2021 at 5:53 PM Daniel Migault <[email-masked]> 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
>
> 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.
>
> 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," could be
> removed.
>
> I do not see GCS being shown in its expanded form. I propose it is
> expanded in section 1.2.2.
>
>  Figure 2
> I am wondering if USS can be placed on the figure.
> 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.
> 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.
> It is a bit unclear to what the link (+) - (+) represents.
> The figure uses NET-RID SP while the text uses Net-RID SP.
>
> """
> 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.
>
> 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.
>
> """
>
>  [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 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.
>
> section 1.3
>
> DSS is expanded multiple times. I suggest expanding it once.
>
> Figure 3: maybe for coherence, DSS may be mentioned together with SP in a
> similar way as figure 2 -- with the additional DSS.
>
> section 1.4
>
> I am not sure the two bullet style is intentional.
>
> 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.
> I am also wondering if the registration link could be oriented toward the
> registries.
>
> 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.
>
>
> 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
>
> """
>
> 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).
> """
>
> 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.
> """
>
> """
>
> 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 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.
> """
>
> """
> 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....
>
> """
> 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.
>
> 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.
> """
>
> """
>   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 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.
>
> """
>
> """
> 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.
>
>
> section 3.3.
>
> I have the impression we have been using RID, if so I would suggest to
> change Remote ID to RID.
>
> HHIT proof should mention the proof of what. It is probably proof of
> ownership.
>
>
> section 3.4
>
> Maybe
> s/within which is registered/within which it is registered
>
> 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 ?
>
>
> 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.
>
>
> 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.
>
>
> " 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.
>
>
> 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).
>
> """
>
>
> section 6
>
>
>
>
>
> On Thu, Dec 16, 2021 at 2:27 AM <[email-masked]> wrote:
>
>> Hi all,
>>
>>
>>
>> Given the changes made by the authors to address the issues raised in the
>> first WGLC (03/21), we issue this second WGLC to let the WG review these
>> changes.
>>
>>
>>
>> The latest version to review is available at:
>> https://datatracker.ietf.org/doc/draft-ietf-drip-arch/18/
>>
>>
>>
>> For convenience, the changes made since the first WGLC can be tracked at:
>> https://www.ietf.org/rfcdiff?url1=draft-ietf-drip-arch-11&url2=draft-ietf-drip-arch-18
>>
>>
>>
>> If you have any issues or concerns with this version, please share them.
>>
>>
>>
>> This call will last until December 30, 2021.
>>
>>
>>
>> Cheers,
>>
>> Daniel & Med
>>
>> _________________________________________________________________________________________________________________________
>>
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>>
>>
>
> --
> Daniel Migault
> Ericsson
>

-- 
Daniel Migault
Ericsson

---

From: "Card, Stu" <[email-masked]>
Date: Fri, 7 Jan 2022 11:39:53 -0500

I had already submitted my review of -arch & think Shuai had addressed all
my concerns, except maybe a couple where he sought WG consensus before
making any further change.

I will go through all of Daniel's comments. The only one to which I want to
reply right now is the one about the data dictionary. The text does not say
it was defined for Broadcast RID & is being re-used for Network RID. It
says the same data dictionary is the basis of both, which it definitely is
per ASTM F3411, and that needs to be explicitly stated in either -reqs
(which I would rather not edit yet again) or -arch.

Thanks.

On Fri, Jan 7, 2022, 10:58 Daniel Migault <[email-masked]> wrote:

>> 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.
>>
>> defined for the broadcast ID. I have the impression ''using the same
>> data dictionary that is the basis of Broadcast RID messages," could be
>> removed.
>>
>> 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
>>> Given the changes made by the authors to address the issues raised in
>>> the first WGLC (03/21), we issue this second WGLC to let the WG review
>>> these changes.
>>>
>>>
>>>
> Tm-rid mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tm-rid
>

---

From: "Stuart W. Card" <[email-masked]>
Date: Sat, 8 Jan 2022 10:23:15 -0500

responses interleaved

On 12/22/2021 5:53 PM, Daniel Migault wrote:
> <https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-drip-arch-18.txt>
> 
> 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.
> 
> tracking' and I could see tracking as one of the services associated to 
> UAS RID.
> 

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

> data dictionary that is the basis of Broadcast RID messages," couldbe 
> removed.

Addressed in my previous email.

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

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

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

> understand the description easier, while links are never totally 

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.

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

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

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

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

> DSS is expanded multiple times. I suggest expanding it once.

I agree, just the 1st use.

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

> I am not sure the two bullet style is intentional.

Neither am I.

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

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

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

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

>     including one or more DRIP entity identifiers and associated

I agree.

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

As long as we retain, in some form, the justification for _why_ we do this.

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

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

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

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

> 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

I have no objection to re-ordering the text for better flow.

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

> I have the impression we have been using RID, if so I would suggest to 

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.

> HHIT proof should mention the proof of what. It is probably proof of 

Again, someone other than Bob should propose specific language, then Bob 
should vet it.

> s/within which is registered/within which it is registered

Good catch.

> intention to say that HDA and RAA are identified by

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.

> I suggest adding DNSSEC and be prepared to receive some comments regarding the DNS over TLS.

Sorry, I don't understand the comment.

> section 5
> 
> """and be actively used by the party (in most cases the UA)."""
> 

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

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

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

Thanks Daniel!

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

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Wed, 12 Jan 2022 22:51:04 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

    responses interleaved

Shuai/ Expanded GCS at first use

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

Shuai/ Implemented as suggested, Looks good to me. 

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.  

Shuai/ updated

    > I am not sure the two bullet style is intentional.

    Neither am I.
Shuai/ Updated

Shuai/  I think "is given by" is probably better. 

Shuai/ I think that is a good piece information. But remove it now as suggested by Chair 

    I agree.

Shuai/ Updated. 

Shuai/ Updated 

    > The public key is designated as the HI while the ID is designated as the 
Shuai/ This suggestion looks fine to me, implemented as suggested. 

Shuai/ Suggestion is fine to me. 

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. 

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. 

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. 

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.

Shuai/ Can Adam help here? 

    Good catch.

Shuai/  Do you need to add the example explanation here? Or it is clear now

Shuai/ I don’t know what should I do here. It might not be wise to repeat the content from -auth. Need some advice. 

    Thanks Daniel!

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 12 Jan 2022 20:36:40 -0500

Interleaved

On Wed, Jan 12, 2022, 17:51 shuaiizhao(Shuai Zhao) <[email-masked]>
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.
>
> On 1/8/22, 07:23, "Tm-rid on behalf of Stuart W. Card" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     responses interleaved
>
>     > <
>     > [F3411  <
> https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch-18#ref-F3411>],
> using the same data dictionary that is the basis of
> 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
>

That suggests we have a typo in -reqs, so I will check that. "Net-RID SP"
is the correct form that should be used in figures & text in all docs.

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

That changes the meaning. "Given the HI" means enabled by knowing the HI;
"given by the HI" means that the HI _itself_ (alone) provides the
self-assertion, which it does not.

>     >     maximum ASTM RID [F3411  <
> https://datatracker.ietf.org/doc/html/draft-ietf-drip-arch-18#ref-F3411>]
> Authentication Message payload is 201 bytes
> 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.
>
> 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.
>
>     > """
> 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.
>

I suggest inserting the text to clarify.

>     > " 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.
>
> Shuai/ I don’t know what should I do here. It might not be wise to repeat
> the content from -auth. Need some advice.
>
>     Thanks Daniel!
>
>     --

---

From: Daniel Migault <[email-masked]>
Date: Wed, 12 Jan 2022 22:40:31 -0500

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

> keep it for now and will ask Bob for clarification.

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

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

> From memory I think just adding "of ownership" would be sufficient.

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

> Let's say yes.

> the content from -auth. Need some advice.

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

-- 
Daniel Migault
Ericsson

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Thu, 13 Jan 2022 05:59:46 +0000

Hi Stu, please see reply inline.

Best,
Shuai
From: "Card, Stu" <[email-masked]>
Date: Wednesday, January 12, 2022 at 17:37
To: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Cc: Daniel Migault <[email-masked]>, Mohamed Boucadair <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Internet]Re: [Drip] Re: 2nd WGLC of draft-ietf-drip-arch (Ends 30/12/2021)

Interleaved
On Wed, Jan 12, 2022, 17:51 shuaiizhao(Shuai Zhao) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel and Stu,

Best,
Shuai

On 1/8/22, 07:23, "Tm-rid on behalf of Stuart W. Card" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    responses interleaved

That suggests we have a typo in -reqs, so I will check that. "Net-RID SP" is the correct form that should be used in figures & text in all docs.
Shuai/ Updated all to “Net-RID SP”

Shuai/ updated

    Neither am I.
Shuai/ Updated

That changes the meaning. "Given the HI" means enabled by knowing the HI; "given by the HI" means that the HI _itself_ (alone) provides the self-assertion, which it does not.
Shuai/ will ask Bob for clarification.

    I agree.

Shuai/ Updated.

Shuai/ Updated

    Good catch.

Shuai/ updated as following:

   While the DRIP entity identifier is self-asserting, it alone does not
   provide the "trustworthiness" specified in [I-D.ietf-drip-reqs].  For
   that it MUST be registered (under DRIP Registries) and be actively
   used by the party (in most cases the UA).  For example, when A sender
   simply possessing a DET (DRIP Entity Tag which is a 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 well, 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.

    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
    [email-masked]<mailto:[email-masked]>
    https://www.ietf.org/mailman/listinfo/tm-rid

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

---

From: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Date: Thu, 13 Jan 2022 06:01:56 +0000

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 <[email-masked]>
Date: Wednesday, January 12, 2022 at 19:40
To: "shuaiizhao(Shuai Zhao)" <[email-masked]>
Cc: "Stuart W. Card" <[email-masked]>, Mohamed Boucadair <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Daniel and Stu,

Best,
Shuai

    responses interleaved

Shuai/ updated

    Neither am I.
Shuai/ Updated

    I agree.

Shuai/ Updated.

Shuai/ Updated

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

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.

    Good catch.

    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 😊

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!

--
Daniel Migault
Ericsson