Last Call Review of draft-ietf-drip-arch-22
review-ietf-drip-arch-22-tsvart-lc-rose-2022-04-05-00

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Status: Ready (with TSVART-nonspecific LC comments)

I don't see any novel transport issues in this document: there is precedent for
everything being proposed, with explicit references to existing RFCs.

Putting my individual reviewer hat on, however:

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

"Frequently changing" is not the right standard for preventing replay attacks:
"novel" is. The idea is that the sender needs to sign data that has never been
signed before and moreover that the receiver knows *a priori* would never have
been signed by the key owner before. This is why, for instance, time codes are
frequently used in such constructions: because time flows in only one
direction, everyone has the ability to agree on what the current time is (even
in a scenario in which participants are moving at relativistic speeds, a single
reference frame can be chosen arbitrarily as the basis for the shared time
scale), and no properly-functioning implementation would sign a future time
code.

> For that it MUST be registered (under DRIP Registries) and be actively used
by the party (in most cases the UA).

"Must" should probably be lowercase given that this is an informational
document. Moreover, given the document overall takes the approach of making
recommendations to others about how they can use IETF protocols in their
technology space, and given that the IETF is not the protocol police, such
recommendations really should be suggestions ("may be registered using
such-and-such a protocol") rather than normative requirements.

Nits aside, my main issue with this draft boils down to one question: why is
this work happening at the IETF? In brief, the draft covers the following
high-level recommendations:

* Construction of an identifier for which only the owner can attest ownership
(section 3)

* Use of DNS as a registry for such identifiers (section 4)

* Maintaining trust over time in messages from a given sender without on-going
access to a trusted third-party (section 5)

* Link-layer concerns (section 6)

* Bootstrapping a persistent secure channel using identifiers currently trusted
(section 7)

None of these requires internet standards development unique to drone
identification.

It seems like the proper standards venue for this work is an aircraft or
aerospace regulatory SDO, with liaisons from the IETF acting as subject matter
experts for use of and integration with IETF protocols. If there is a broad
category of users that heavily leverage internet technologies or that will
likely impact protocol performance, there is precedent for the IETF forming a
non-standards-developing operations group (akin to MOPS, a WG I co-chair)
providing a forum within the IETF for the formulation and dispatch of
requirements to appropriate function-specific WGs, both within and without the
IETF, for further standards activity.

Based on some early feedback I received, I want to make clear that I am *not*
suggesting that the process for setting up a working group was not followed in
the case of drip; rather, I am suggesting the process produced the wrong
outcome. Working groups with very tangential relevance to the core mission of
the IETF---development and maintenance of internet transports and their
prerequisites---are a distraction that consumes valuable resources. While I
risk sounding like Abe Simpson with this objection
(https://www.youtube.com/watch?v=O5dmxBUbzBU), I know I am not the only one who
has expressed concern over scope creep within the IETF, so taking this
opportunity to highlight an example seemed worthwhile.