Skip to main content

Telechat Review of draft-ietf-drip-arch-24
review-ietf-drip-arch-24-intdir-telechat-thaler-2022-06-28-00

Request Review of draft-ietf-drip-arch
Requested revision No specific revision (document currently at 31)
Type Telechat Review
Team Internet Area Directorate (intdir)
Deadline 2022-06-27
Requested 2022-06-13
Requested by Éric Vyncke
Authors Stuart W. Card , Adam Wiethuechter , Robert Moskowitz , Shuai Zhao , Andrei Gurtov
I-D last updated 2022-06-28
Completed reviews Secdir Last Call review of -22 by Valery Smyslov (diff)
Iotdir Last Call review of -22 by Thomas Fossati (diff)
Genart Last Call review of -22 by Roni Even (diff)
Tsvart Last Call review of -22 by Kyle Rose (diff)
Intdir Telechat review of -24 by Dave Thaler (diff)
Secdir Telechat review of -24 by Valery Smyslov (diff)
Comments
A telechat review is really required as the last call one was not completed. Many thanks in advance.

-éric
Assignment Reviewer Dave Thaler
State Completed
Request Telechat review on draft-ietf-drip-arch by Internet Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/int-dir/o54ZoxBIO9bLyq6UWV6v1Dxk1a4
Reviewed revision 24 (document currently at 31)
Result Ready w/issues
Completed 2022-06-28
review-ietf-drip-arch-24-intdir-telechat-thaler-2022-06-28-00
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