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

[Adam Wiethuechter <[e-mail]>]

Hello Roman,

v47 is now out with changes directly related to your DISCUSS and COMMENTs.

I have responded inline, once again, with the explicit changes made.

Thank you again for your thorough review.

--------
73,
Adam T. Wiethuechter
Software Engineer; AX Enterprize, LLC

________________________________
From: Roman Danyliw via Datatracker <[e-mail]>
Sent: Tuesday, January 30, 2024 6:21 PM
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Roman Danyliw's Discuss on draft-ietf-drip-auth-46: (with DISCUSS and COMMENT)

Roman Danyliw has entered the following ballot position for
draft-ietf-drip-auth-46: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-drip-auth/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 4.1.  I missed something very basic. Where is the signature
algorithm that computes the value of “UA Signature” defined?

<atw>
Added the following line to the UA Signature definition: "The signature algorithm is specified by the HHIT Suite ID of the DET."
</atw>

** Section 4.4.

(a)  An Observer who has been listening for any length of time MUST hash
   received messages and cross-check them against the Manifest hashes.

(b) A receiver SHOULD use the Manifest to verify each ASTM Message hashed
   therein that it has previously received.

-- Per (a), Can “any length of time” please be qualified in some way since
there is normative behavior specified?

-- These appear to be similar statements, but one is stronger than the other.
Doesn’t (a) require a check, but (b) is only strongly recommending it?  They
should be consistent.

<atw>
Issue B is resolved as they are both now MUST.

Issue A is resolved with the following text change:
OLD:

    An Observer who has been listening for any length of time MUST hash
    received messages and cross-check them against the Manifest hashes.

NEW:

    Observers MUST hash all received ASTM Messages and cross-check them
    against hashes in received Manifests.
</atw>

** Section 4.4.3
   For OGAs other than "5" [RFC9374], use the construct appropriate for
   the associated hash.  For example, for "2" which is ECDSA/SHA-384:

My understanding is that cSHAKE128 must be used as the hash for manifest
hashes.  However, this text is introducing the possibility of other OGAs and
associate hash algorithms.  When would they be used in a DRIP manifest and how
would one know they are in use instead of cSHAKE128?

<atw>
OLD:

    The hash algorithm used for the Manifest is the same hash algorithm
    used in creation of the DET [RFC9374] that is signing the Manifest.

NEW:

    The hash algorithm used for the Manifest is the same hash algorithm
    used in creation of the DET [RFC9374] that is signing the Manifest.
    This is encoded as part of the DET using the HHIT Suite ID.
</atw>

** Section 4.5.  What should an observer do if such a frame is seen in the wild?

<atw>
>From Section 4.5:
OLD:

    The content of Frame Evidence Data is not defined in this document.
    Other specifications MUST define the contents and register for a
    Frame Type.

NEW:

    The content format of Frame Evidence Data is not defined in this
    document.  Other specifications MUST define the contents and register
    for a Frame Type.  At the time of publication there are no defined
    Frame Types other than an Experimental range.

    Observers MUST check the signature of the structure (Section 4.1) per
    Section 3.1.2.2 and MAY, if the specification of Frame Type is known,
    parse the content in Frame Evidence Data.
</atw>

** Section 6.3

   4.  MUST: send any other DRIP Authentication Format (RECOMMENDED:
       DRIP Manifest (Section 4.4) or DRIP Wrapper (Section 4.3)) where
       the UA is dynamically signing data that is guaranteed to be
       unique, unpredictable and easily cross checked by the receiving
       device (satisfying ID-5, GEN-1 and GEN-2); at least once per 5
       seconds

Thank you for the clarity of the UA behavior provided in this section.  This
bullet needs to be refined.

It starts by saying “any other DRIP Authentication Formats”, which I took to
mean all those in Table 2 other than Link (to include future ones registered in
the corresponding IANA registry) need to do something (be sent once per 5/sec).
 However, there is a “RECOMMENDED” parenthetical which is a smaller number of
messages.  Which is it, all non-Link messages, or only those in the recommended
list?

<atw>
Section 3., paragraph 1:
OLD:

    4.  MUST: send any other DRIP Authentication Format (RECOMMENDED:
        DRIP Manifest (Section 4.4) or DRIP Wrapper (Section 4.3)) where
        the UA is dynamically signing data that is guaranteed to be
        unique, unpredictable and easily cross checked by the receiving
        device (satisfying ID-5, GEN-1 and GEN-2); at least once per 5
        seconds

NEW:

    4.  MUST: send any other DRIP Authentication Format (non-DRIP Link)
        where the UA is dynamically signing data that is guaranteed to be
        unique, unpredictable and easily cross checked by the receiving
        device (satisfying ID-5, GEN-1 and GEN-2); at least once per 5
        seconds
</atw>

** Appendix A.  If this appendix is informative, normative language should not
be used here.

<atw>
A singular MUST was removed.
</atw>

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Rich Salz for the early SECDIR review.

I lacked access to [F3411] which is a critical normative reference for this
document.  In particular, I am unable to evaluate Section 4.3.2.  Some of the
above DISCUSS may be related to this lack of access.

** Editorial.  “Sanity check” is used throughout the document to describe some
validation activity.  Please consider replacing this phrase with a more precise
expression.

<atw>
Throughout the document the term "sanity check" has been replaced with "validation" as appropriate.
</atw>

** Section 3.1.1.  Editorial.
   An Observer SHOULD query DNS for the UA's HI.  If not available it
   may have been revoked.   Note that accurate revocation status is a
   DIME inquiry; DNS non-response is a hint that a DET is expired or
   revoked

-- My initial read of the “If not available text” text was that if “DNS was not
available”, not that the HIT wasn’t found in DNS.

-- what’s a “DIME inquiry”?  what’s makes a revocation status “accurate”; are
there other kinds?

<atw>
The entirety of Section 3.1 has been reorganized to hopefully rectify your comment here (along with others who shared similar views). Please see v47.
</atw>

** Section 3.2.1.
      Authentication Type (4 bits) and Page Number (4 bits)

Which one is first?  Does this come from [F3411]?

** Section 3.2.2.
   Additional Data: (255 octets max)

Isn’t there more nuance to this than up to “255 octets max”.  Doesn’t the size
of the Signature determine how much Additional data can be present?  Something
like (368 – sizeof(Signature) – 7) <= Sizeof(Additional Data) <= 255 octets.

<atw>
This has been fixed by explaining in the definition of ADL how to calculate its value and then used directly as the size for Additional Data in its definition.

Section 3.2.2., paragraph 9:
OLD:

       Length in octets of Additional Data.

NEW:

       Length in octets of Additional Data.  The value of ADL is
       calculated as the minimum of 361 - Authentication Data / Signature
       Length and 255.  Only present with Additional Data.

</atw>

** Section 3.2.4.2
   Under Broadcast
   RID, the Extended Transport that can hold the least amount of
   authentication data is Bluetooth 5.x at 9 pages.

Didn’t the section prior indicate that Bluetooth 4.x was the most constrained?

** Section 4.2.
   A hash of the final link (BE: HDA on UA) in the Broadcast Endorsement
   chain MUST be included in each DRIP Manifest Section 4.4.

It would have been helpful to provide more prose on computing and using a
“Broadcast Endorsement chain”.

** Section 4.3.1.  Given that Figure 6 must be implemented but it is described
in pseudo-code, further clarity is needed.  Specifically, this algorithm
appears to be a validation check.  There appears to be two “return” statement
indicating failure.  I’m assuming that the two comments (“//”) are to be read
as validation success.  If that’s accurate, please say so.

** Section 4.4
   Judicious use of a Manifest enables an entire Broadcast RID message
   stream to be strongly authenticated with less than 100% overhead
   relative to a completely unauthenticated message stream

Recommend pointing to Section 6.3 to quantify what "judicious use" means.

** Section 4.4.3

   For the first built Manifest this value
   is filled with a random nonce.

How does the observer get this nonce to validate the observed message?

** Section 6.4

   UAS operation may impact the frequency of sending DRIP Authentication
   messages.  When a UA dwells at an approximate location, and the
   channel is heavily used by other devices, less frequent message
   authentication may be effective (to minimize RF packet collisions)
   for an Observer.  Contrast this with a UA transiting an area, where
   authenticated messages SHOULD be sufficiently frequent for an
   Observer to have a high probability of receiving an adequate number
   for validation during the transit.

Would these “less frequent” or “sufficiently frequent” broadcasts qualitatively
described above alter the quantitate, mandatory transmission rates in Section
6.3?

** Section 11.1.  Can [F3411] provide more identifying information.  For
example, can the name of the SDO be provided.

** Section 11.1.  I believe that [drip-registries] needs to be a normative
reference given the importance of this reference for Section 4.1 and 9.2