Thank you, Dave, for the review.
I have updated my YES ballot by mentioning your review.
Regards
-éric
On 29/06/2022, 02:52, "Dave Thaler via Datatracker" <noreply@xxxxxxxx> 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.
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".
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.
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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
