Re: [auth48] AUTH48: RFC-to-be 9374 <draft-ietf-drip-rid-37> for your review

[Robert Moskowitz <[e-mail]>]

On 3/3/23 16:36, Sandy Ginoza wrote:
> Greetings all,
>
> We believe we have updated the document as requested, but please review closely.  In addition, we have some followup questions below.  Please note that comments have been condensed into the mail below; our comments are preceded by [rfced].
>
> The current files are available here:
>
>     https://www.rfc-editor.org/authors/rfc9374.txt
>     https://www.rfc-editor.org/authors/rfc9374.pdf
>     https://www.rfc-editor.org/authors/rfc9374.html
>     https://www.rfc-editor.org/authors/rfc9374.xml
>
> AUTH48 diff:
>     https://www.rfc-editor.org/authors/rfc9374-auth48diff.html
>
> Comprehensive diffs:
>     https://www.rfc-editor.org/authors/rfc9374-diff.html
>     https://www.rfc-editor.org/authors/rfc9374-rfcdiff.html
>
>
>> On Feb 27, 2023, at 5:33 PM, Robert Moskowitz <[e-mail]> wrote:
> [note that resolved issues have been snipped]
>
>
>>> 2) <!-- [rfced] Does "This" refer to this document or RFC 9153 (i.e., is
>>> RFC 9153 the foundational document)?
>>>
>>> Original:
>>>     Drone Remote ID Protocol (DRIP) Requirements [RFC9153] describe an
>>>     Unmanned Aircraft System Remote ID (UAS ID) as unique (ID-4), non-
>>>     spoofable (ID-5), and identify a registry where the ID is listed (ID-
>>>     2); all within a 19-character identifier (ID-1).
>>>
>>>     This DRIP foundational document (i.e., all else in DRIP enables or
>>>     uses it) describes (per Section 3 of [drip-architecture]) the use of
>>>     Hierarchical Host Identity Tags (HHITs) (Section 3) as self-asserting
>>>     IPv6 addresses and thereby a trustable identifier for use as the UAS
>>>     Remote ID.
>>> -->
>> Yes, this document.  Not 9153.
>>
>> I am not finding any changes to lessen the confusion.  Perhaps:
>>
>> This document, foundational to DRIP as all other documents will enable or
>>     uses it, describes (per Section 3 of [drip-architecture]) the use of
>>
>> I don't know if this helps.
> [rfced] Perhaps:
>     This RFC is a foundational document of DRIP, as it describes  the use of
>     Hierarchical Host Identity Tags (HHITs) (Section 3) as self-asserting
>     IPv6 addresses and thereby a trustable identifier for use as the UAS
>     Remote ID (see Section 3 of [DRIP-ARCH].  All other DRIP-related
>     technologies will enable or use HHITs as multipurpose remote identifiers.

OK.

>>> 4) <!-- [rfced] May we replace instances of "Hierarchical HITs" with
>>> "HHITs" throughout once the abbreviated form has been introduced?
>>> For example:
>>>
>>>     Hierarchical HITs provide ...
>>>
>>>     Hierarchical HITs are valid, ...
>>>
>>>
>>>     Hierarchy ID (HID) ...
>>> -->
>> Yes please, sloppy of me not to consistently just use HHIT (and HID).
> [rfced] For the most part, we have removed expansions once they have been introduced (they are expanded in both the abstract and introduction).  We have left some other expansions in select places, for example:
>
> HIDs are further divided into two fields:
> - 14-bit Registered Assigning Authority (RAA)
> - 14-bit HHIT Domain Authority (HDA)

Good.  Thank you.


>>> 13) <!-- [rfced] May we update this to specify that the EdDSA HI uses the
>>> value assigned per [ipseckey-eddsa] for IPSECKEY RR encoding?
>>>
>>> Original:
>>>     The new EdDSA HI uses [ipseckey-eddsa] for the IPSECKEY RR encoding.
>>>
>>> Suggested:
>>>     The new EdDSA HI uses value assigned per [ipseckey-eddsa] for IPSECKEY
>>>     RR encoding.
>>> -->
>> It is more than the value.  It is also how the public key is encoded.  Perhaps
>>
>> The 'Algorithm Type' value and EdDSA HI encoding are assigned per [ipseckey-eddsa].
> [rfced] Updated as noted here.  Please confirm that "IPSECKEY RR encoding” is not needed.

It is not needed.  The text I see in the diff is good:

The 'Algorithm Type' value and EdDSA HI encoding are assigned per
                 [RFC9373]..

But note the two periods.

>>> 20) <!-- [rfced] We are having trouble parsing "88-byte self-proof
>>> evidence".  If possible, please clarify.
>>>
>>> Original:
>>>     The EdDSA25519 HI (Section 3.4) underlying the DET can be used in an
>>>     88-byte self-proof evidence (timestamp, HHIT, and signature of these)
>>>     to provide proof to Observers of Remote ID ownership (GEN-1 in
>>>     [RFC9153]).
>>> -->
>> The term "evidence" (and "endorsement") are defined in drip-arch and are from RATS rfc 9334.  Sec 2.3 says to look in drip-arch for terms.  We had quite a debate on the list about where terms are defined in our documents.
>>
>> Perhaps first time "evidence" and "endorsement" are used point to rfc9334?
>>
>> These terms/concepts are really important in DRIP and heavily used in drip-auth.
>
> [rfced] We have not made any changes, but we wonder if “self-proving evidence” is meant?

I can see that is a better way to express the concept.  I see 
"self-proof evidence" used earlier in the para.  Use that.

Don't change self-claims or self-endorsement as those are different beasts.

>>> 25) <!-- [rfced] Section 8.2 seems to create the "Drone Remote ID Protocol"
>>> group of registries, which contains the "Hierarchical HIT (HHIT) Prefixes"
>>> and "Hierarchical HIT (HHIT) Suite ID" registries.  Is it correct that the text about expert review only applies to "Hierarchical HIT (HHIT)
>>> Prefixes", as the registration procedure for "Hierarchical HIT (HHIT) Suite
>>> ID" is IETF Review?
>>>
>>> If this is correct, may we move the text describing criteria for the
>>> designated expert to appear after the table 8, to make it more clear that
>>> it applies to the "Hierarchical HIT (HHIT) Prefixes" registry?  Would it be
>>> helpful to divide 8.2 into the following sections:
>>>
>>> 8.2.1.  Hierarchical HIT (HHIT) Prefixes
>>> 8.2.2.  Hierarchical HIT (HHIT) Suite IDs
>>>
>>> Note that we have removed this sentence entirely, as we believe it is
>>> common practice for IANA to have at least two experts for a given registry.
>>> Please let us know if you prefer otherwise.
>>>
>>> Original:
>>>          It is suggested that multiple
>>> 	designated experts be appointed for registry change requests.
>>> -->
>> Yes, expert review applies to the prefixes only.  Lots of discussions about that.  And SuiteIDs will follow standard IETF review.  Thus the change you recommend for 8.2.1 and 8.2.2 is is good.  And can drop "two experts" sentence.  That text was a copy/paste.
> [rfced] We have added subsections 8.2.1 and 8.2.2.  Please review to ensure the updates are correct.

Looks good.  thanks.


>>> 35) <!-- [rfced] We are having trouble parsing this sentence.  Does "the
>>> observer can see the UA or that information is validated" mean that the
>>> "observer can see that the UA or the information in question is validated"?
>>> Please clarify.
>>>
>>> Original:
>>>     Proof of UA transmission comes when the Authentication Message
>>>     includes proofs for the ASTM Location/Vector Message (Msg Type 0x1)
>>>     and the observer can see the UA or that information is validated by
>>>     ground multilateration.
>>> -->
>> A UA broadcasts its location.  And the observer can even authenticate the message came from a UA with a specific DET.  Is it really at that location?  What is the proof?
>>
>> The observer "sees" a UA at that location.
>> ground multilateration of the broadcast messages compute the same location as the validated location broadcast.
>>
>> Now how do you say this without a paragraph or two?  Well there is the prior para to set the stage.
>>
>> Proof of a specific UA as the source of a transmission comes when...
>
> <atw>
> In conference with Stu, multilateration is neither required nor always feasible. Whatever text we
> settle upon must make clear that we are not specifying a particular method of validation. We are
> stating that signed novel information must be somehow validated to provide trust that the sender
> actually possesses the private key corresponding to the HHIT. This could be a simple sanity check
> that the UA visually sighted by the observer appears to be in approximately the location reported
> in a signed Location/Vector Message.
> </atw>
>
>
> Bob:
> IMO the text only presents multilateration as one method of proof.  It is not a requirement.
>
> Visual sighting is included as well.
>
> It is the whole point that this is a broadcast media.  So you can trust the messages coming from something, but can you trust the content?
>
> My position is leave the text as is.
>
>
>
> [rfced] Perhaps:
>     Proof of UA transmission comes, for example, when the Authentication Message
>     includes proof of the ASTM Location/Vector Message (Msg Type 0x1)
>     and a) the observer can see the UA or b) the location information is validated by
>     ground multilateration.

This is fine.  thanks.

>
>>> 45) <!-- [rfced] Would you like to make use of <sup> for superscript
>>> in this document? You can see how it looks here:
>>>
>>> https://www.rfc-editor.org/authors/rfc9374-sup.html
>>> https://www.rfc-editor.org/authors/rfc9374-sup.pdf
>>> https://www.rfc-editor.org/authors/rfc9374-sup.txt
>>>
>>> Note: In the HTML and PDF, it appears as superscript.
>>> In the text output, <sup> generates a^b.
>>> -->
>> I did not even consider what would work here for .txt and .pdf and .html.
>>
>> So please do what works best!  Maybe I will learn something for future use!
>
> [rfced] We have updated the document to use superscript.  Please review.  In particular, please review this instance in the text and html output (at minimum) to ensure the groupings are correct:
>
> Original:
>         p = 1 - e^{-k^2/(2n)}
>
> TXT:
>         p = 1 - e^({-k^2/(2n)})
>
> HTML:
>     https://www.rfc-editor.org/authors/rfc9374.html#appendix-D

Both changes are fine.  Just as a comment, in pure math precedence rules 
the added set of parens is not needed.

I do see that you also changed table 15 for superscripts and that is 
fine too.


>
>>> 46) <!-- [rfced] Please review the following regarding terminology:
>>>
>>> a) Throughout the text, the following term appears to be used
>>> inconsistently. Please review these occurrences and let us know if/how they
>>> may be made consistent.
>>>
>>> authentication message vs Authentication Message
>>>
>>> b) Note that instances of "IPV6" have been updated to "IPv6" (lowercase v).
>>>
>>> c) In addition, note that we have used the following articles.  Please let us know if any corrections are needed.
>>>
>>> an HI (read "hy")
>>> an HDA (read as letters, i.e., an eche dee aye)
>>> a HIP (read as the word hip)
>>> a HIT (read as the word hit)
>>> a HHIT - how is this read?
>>> -->
>> We were very careful where we capitalized authentication message vs Authentication Message
>>
>> Are we talking about the actual ASTM Authentication Message (msg type 0x2) or speaking about an authentication message.  So please the case alone.  Lots of reviews on this usage.
>>
>> b)  thank you.
>>
>> HI should probably be "a HI" as you allude?
>> HDA, HIP, and HIT are right above.
>>
>> HHIT is read by letter or "H HIT".  So that seems it should be an HHIT.
> <atw>
> in conference with Stu, user may not understand this subtle distinction! Perhaps text is needed the terminology section to enlighten that capitalization means F3411 specifically and uncapitalized is generic.
> <atw>
>
>
> [rfced] We have not made any changes - please let me know if any corrections are needed.

All "an HHIT" should be changed to "a HHIT", as we always say the "H":  
"H HIT" or "H H I T".  As I believe "a" is used for the the letter "H".

I prefer to leave the mixed writing of "authentication message" and 
"Authentication Message".

Some may not even see this.  Others will catch that we have different 
intents and let the die land as they may.

>  From Med:
> * Section 3.5: revert to the old wording
>
> OLD:
>    *  the use of cSHAKE, NIST SP 800-185 [NIST.SP.800-185] for the
>       hashing function.
>
> NEW:
>    *  the use of cSHAKE, NIST SP 800-185 [NIST.SP.800-185], for the
>       hashing function.
>
>
> [rfced] The text currently reads as follows:
>
>    *  the use of cSHAKE [NIST.SP.800-185] for the hashing function.
>
>
>
>
> - From Bob: ALL the definitions were IMPROPERLY altered.
>
> [rfced] Apologies - we have revered the order of the expansions and abbreviations.
>
>
> - From Bob:
>
> One further thought.  Where the term comes from NIST, I have that in the parenthetical expansion of the term.  But I don't do that for when the term is from another RFC.  Should the RFC reference be moved up as in:
>
>     HI (Host Identity [RFC9063]):
>        The public key portion of an asymmetric key pair.
>
>     HIT (Host Identity Tag [RFC7401]):
>        A 128-bit handle on the HI.  HITs are valid
>        IPv6 addresses.
>
>     RVS (Rendezvous Server [RFC8004]):
>        A Rendezvous Server such as the HIP Rendezvous Server for enabling
>        mobility.
>
> Note that this only applies to those terms that have the text "as defined in" (and HIT should have it).
>
> [rfced] We have not moved the citation tags, as the current format is more typical in RFCs.  Please let us know if you prefer otherwise.

I have reviewed sec 2.3 in the rfc diff and agree with the new content 
in it.

>   
> Also, the definitions are preceded by the following:
>     This document uses the terms defined in Section 2.2 of [RFC9153] and
>     in Section 2 of [DRIP-ARCH].  The following new terms are used in the
>     document:
>
> Perhaps we should change the last sentence as follows to remove “new”, as many of these terms are not new:
>     In addition, the following terms are used in this document.

Yes.  Thank you.

>   
> - [rfced] New questions regarding Section 4.5: DRIP Entity Tag (DET) Registry
>
> a) Apologies if I am missing something obvious here, but to what registry does this refer?  This document uses "DET Registry” and Section 4.5 is entitled "DRIP Entity Tag (DET) Registry”.  Section 4.5 references draft-ietf-drip-registries.  I expected draft-ietf-drip-registries to create a DET registry, but it refers back to this document, which creates the "Drone Remote ID Protocol” Registry.  Is it correct that DET Registry refers to the DRIP Registry <https://www.iana.org/assignments/drip/drip.xhtml>?   Can this text be clarified?

In sec 4.5 the registries for DETs that will be maintained by HDAs is 
discussed with pointer to drip-registries where the process and some of 
these registries (public and private) are defined.  This section does 
not reference any IANA registries.

> b) Is [DRIP-REG] being referred to here because it defines the registration process?  If so, where are these procedures defined?

In drip-reg which is not complete and so referencing any sections in it 
would be problematic.

> Original:
> A registration process, [DRIP-REG], ensures DET global uniqueness (ID-4 in Section 4.2.1 of [RFC9153]).
>
> c) In the sentence above: if [DRIP-REG] defines the registration process, may we update the text as follows?
>
> Perhaps:
> The registration process defined in [DRIP-REG] ensures DET global uniqueness (ID-4 in Section 4.2.1 of [RFC9153]).

Yes.

> Thank you!
> RFC Editor/sg

And thank you!

Bob

Hopefully only one more round.  Remember I am basically offline on 
Tuesday (until late evening) and Monday afternoon on, I will be pretty 
much offline as well.