Re: [Int-dir] Intdir telechat review of draft-ietf-drip-arch-24

["Eric Vyncke (evyncke)" <[e-mail]>]

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" <[e-mail]> 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