Subject: [Drip] Roman Danyliw's Discuss on draft-ietf-drip-reqs-16: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 29 Jun 2021 14:31:03 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-drip-reqs-16: 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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

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

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

** Section 6.

It may be inferred from the general requirements (Section 4.1) for
   provable ownership, provable binding, and provable registration,
   together with the identifier requirements (Section 4.2), that DRIP
   must provide:

   *  message integrity

   *  non-repudiation

   *  defense against replay attacks

   *  defense against spoofing

Thanks for enumerating these highly desirable security properties as part of
DRIP.  A bit more clarifying language is needed to explain which communication
paths in the DRIP architecture (Figure 3 and 4) have these properties and under
what circumstances.  Section 4.1 and 4.2 seem specific to properties between
particular parties or messages.  Likewise, subsequent text in this section such
as “… there may be caveats on the extent to which requirements can be satisfied
…” seems to suggest these are not universal across the architecture.

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

Thank you to Linda Dunbar for the SECDIR review.

** Abstract.
Complementing external technical standards as regulator-accepted
   means of compliance with UAS RID regulations ...
I had trouble parsing this sentence.  Is it saying that DRIP is a complementing
way to comply with UAS RID regulations?  Have “regulators” confirmed that 
compliance with DRIP satisfies “UAS RID regulations”

** Section 1.1.  Is there a reference for IEEE 802.11 Beacon modes?

** Section 1.1.  Editorial.
s/to authorities; enable authorities/to authorities; and enable authorities/

** Section 4.1.1.  GEN-2 and GEN-3.  Since the name of the requirement is
“provable binding” and “provable registration”, should the corresponding text
convey the equivalently strong language.  For example:

GEN-2
 s/MUST enable binding all/MUST enable the cryptographic binding of all/

GEN-3
s/MUST enable verification/MUST enable cryptographically-secure verification/

** Section 4.1.1.  Per Gen-6, it would be helpful to more clearly state the
pair wise communications that will be secured.

** Section 4.2.2.  Per “In Network RID, it would be used by the application
running over HTTPS (and possibly other protocols)”, to be clear, is HTTPS a
requirement?

** Section 4.3.1. Is there a clear definition somewhere of (a) private
information; and (b) safety critical information?

** Section 4.3.1.  PRIV-2.

DRIP MUST NOT encrypt safety critical data to be
           transmitted over Broadcast RID in any situation where it is
           unlikely that local Observers authorized to access the
           plaintext will be able to decrypt it or obtain it from a
           service able to decrypt it.

How would DRIP “know” that the local Observers are unlikely to be to be able to
decrypt the information?

** Section 4.4.1.  REG-2 makes a point of enforcing AAA but REG-1 explicitly
states “MUST NOT restrict access to this information based on identity or role
of the party submitting the query”.  Would this normative MUST per REG-1 rule
out denial of service mitigation (e.g., rate limited high volume queries from
an IP address) or attempts to scrape the entire database?

** Section 4.4.1.  REG-3.  What is “Internet direct contact information”?

---

From: "Card, Stu" <[email-masked]>
Date: Wed, 30 Jun 2021 11:02:05 -0400

Roman --

Thanks for the review! I will address all your comments ASAP. For now, I'll
only give quick responses on a couple of them, where a little more context
on the UAS RID application, environment and externally partially specified
architecture might help...

On Tue, Jun 29, 2021 at 5:31 PM Roman Danyliw via Datatracker <
[email-masked]> wrote:

> draft-ietf-drip-reqs-16: Discuss...
> ** Section 6...
> A bit more clarifying language is needed to explain which communication
> what circumstances... subsequent text in this section such

Right. Some connectivity paths do or do not exist depending upon the
scenario, e.g., if C2 is running over LTE or the like, then there is
typically not a direct wireless link GCS<->UA but both the GCS and the UA
have Internet connectivity, whereas if C2 is running over a direct wireless
link, then typically the GCS has but the UA lacks Internet connectivity.
Further, paths that nominally exist may be severely intermittent. These
connectivity constraints are likely to have an impact on, e.g., how
reliably requirements can be satisfied. We can clarify this in the draft.

> ...
> compliance with DRIP satisfies “UAS RID regulations”?
>

Regulators such as the FAA won't confirm anything about DRIP until we have
published RFCs. However, FAA is collaborating with ASTM, and has expressed
interest in DRIP solutions to some problems not being addressed by ASTM,
especially how to issue single use Session IDs such that the FAA (only) can
look up other information from them.

That's all for now, but I'll get back on this later today. Thanks again!

-- Stu