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

[Adam Wiethuechter <[e-mail]>]

Roman,

Thank you for your view. See inline for my responses.
All the authors are currently on travel or have some other obligations so our responses in the next few days will be sparse.
I hope my initial responses help, I should have a -47 out by tomorrow addressing the concerns of yours and other ballots.

--------
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>
It comes from the use of the DET. The DET has the HHIT Suite ID (sometimes referred to as the OGA ID) that encodes in the IPv6 address both the key algorithm and hashing algorithm. It is specifically in the DET the byte before the hash.
This should be called out explicitly. Thanks for the catch.
</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?

<atw>
Perhaps something more like this for (a): "Observers that support decoding of Manifest messages MUST hash all received ASTM Messages and cross-check them against hashes in received Manifests."
The removes the length of time issue.
</atw>

-- 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>
Thank you for catching this discrepancy. I believe both statements are a MUST.
</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>
Again, this goes back to the DET. The DET has (via the HHIT Suite ID) encoded into it the specific hashing algorithm used for the DET that MUST also be used for Manifest.
</atw>

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

<atw>
There are currently no defined Frame Types, so if DRIP Frame is seen in the wild it should be ignored.
If there were Frame Types defined the Observer would first perform signature verification/validation, then read the single byte at the start of the evidence data to determine format of the evidence contents for further decoding.
</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>
It is all non-Link messages. The only reason the RECOMMEND exists is that currently there are no Frame Types defined and we came up with the schedule in Appendix B.2 that uses Manifest and Wrapper well.
</atw>

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

<atw>
I shall scrub for normative language and remove it. Thank you.
</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>
I remember having a similar discussion for either requirements or architecture. I will find the wording from that document and splice it in here 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.

<atw>
It could be both, especially if the Observer is offline. However, the wording at this moment is the latter (HIT wasn't found in DNS).
</atw>

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

<atw>
We are currently working in [drip-registries] for a way (other than a full removal resulting in an NXDOMAIN) to indicate a DETs status.
</atw>

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

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

<atw>
This does come from [F3411]. It is written in the correct order.
</atw>

** 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>
You are correct a glaring omission on my part. I will get the correct math and insert it there.
</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?

<atw>
Bluetooth 4.x is the most constrained under Legacy Transports. Bluetooth 5.x is the currently known least constrained Extended Transport. This was discovered by Soren Friis and was actually posted on the list: https://mailarchive.ietf.org/arch/browse/tm-rid/?q=%22comments%20on%20drip%20authentication%20formats%22#
</atw>

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

<atw>
This "Broadcast Endorsement chain" only comes from a DIME as Broadcast Endorsements are the direct result of a successful registration.
So, this very directly relates to your comment on the [drip-registries] reference being informative or normative.
</atw>

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

<atw>
I will correct the pseudo-code to have comments as follows:
"// decode success; next step"
</atw>

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

<atw>
Thank you, that is a good idea.
</atw>

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

<atw>
The nonce is left in the Previous Manifest Hash field so the Observer obtains it over the broadcast.
</atw>

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

<atw>
We do not believe so. As seen in Appendix B.2 we can exceed the Section 6.3 requirements.
</atw>

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

<atw>
Interesting that ASTM International is not here, I thought it was at one point.
Thanks for the catch.
</atw>

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