On 6/28/22 20:51, Dave Thaler via Datatracker wrote:
Reviewer: Dave Thaler
Review result: Ready with Issues
I am an assigned INT directorate reviewer for draft-ietf-drip-arch-24. These
comments were written primarily for the benefit of the Internet Area Directors.
Document editors and shepherd(s) should treat these comments just like they
would treat comments from any other IETF contributors and resolve them along
with any other Last Call comments that have been received. For more details on
the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.
Overall I found the document very well-written.
I have the following comments/questions for the authors/WG that I feel SHOULD
be addressed:
1. I found the discussion of time to be a bit lacking and would like to see it
clarified. Specifically, section 3.2 talks about attestation including a
timestamp, though it is unclear to me what requirements this places on the UA
for having a trusted source of time, such as a local clock. Section 8.2 says
"UAs and Broadcast Remote ID communications are so constrained that current
post quantum computing cryptography is not applicable" so if UAs are that
constrained, can you really rely on them having a trusted source of time? For
example, I know in many TEEs, a trusted source of relative time (e.g.,
monotonic counter) is not even available, and I could imagine that there are
many uses (e.g., defense) whereby a UA might want/need a TEE for attestation.
The level of trust in time gets to the issue about how robust the architecture
is against replay attacks.
GPS is generally used for the trusted time on a UA.
But overall, and we discussed this a LOT on ASTM calls, the time from
the UA is always slewed. There is some natural lag between reading the
time from the internal source (kept correct via GPS) and the time the
packet was sent, let alone when the Observer received it. This is one
of the points I make in draft-moskowitz-drip-crowd-sourced-rid.
And this ties into the whole trust authentication now added to
draft-ietf-auth, sec 1.1. If all the authentication proves out, now
verify it via a local source. (eyes, multilateration, etc.)
2. Somewhat related to the above, Section 5 talks about DRIP Wrapper
Authentication messages that sign over dynamically changing data "such as UA
location data". I observe that time is not mentioned in this example, and
further observe that I don't see how UA location data alone can be robust
against replay attacks, e.g., an attacker might attempt to replay the fact that
a different UA was where real-time evidence just detects a UA of some sort
currently present. I would like to see the replay attack prevention elaborated
on here, especially since section 8.3 says "this whole architecture is put
forth to make ... replay attacks very hard".
The location/vector message contains a 2 byte timestamp that we have
argued extensively over and I found an edge case where interpreting logs
will result in the wrong hour. And how to deal with this.
but the Message Pack (not possible over BT4 and mandated for other RF)
now contains a full 4-byte timestamp demanded by the FAA (they did not
approve of the 2-byte timestamp either). This timestamp of course is as
accurate as the GPS signal expected to be processed by the UA.
So timestamp is 'given' and out of scope (assumed for all means of it)
for our work.
3. In my reading [I-D.ietf-drip-auth] and [I-D.ietf-drip-registries] are used
normatively in sections 5 and 8 since they are used by way of limitation to
those references, rather than by way of example where alternatives may be
applied. But they are listed as informative, not normative references. I think
both should be moved to be normative unless the WG changes language like "as
described in" to "such as described in" or similar, to make them exemplary.
Chairs/AD call.
In addition, a number of nits (typos, misspellings, etc.) are called out in the
marked up PDF at https://1drv.ms/b/s!Aqj-Bj9PNivcn5QXjfM63l-gFYIJhg?e=9hyYBP
Dave
thank you Dave. I hope these answers help.
Bob
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
