Re: [Anima] Iotdir early review of draft-ietf-anima-constrained-voucher-12

[Michael Richardson <[e-mail]>]

Henk Birkholz via Datatracker <[e-mail]> wrote:
    > Reviewer: Henk Birkholz

Thank you for this review!

    > (0) Title

    > The title implies that this document defines a message or document called
    > 'Constrained Voucher Artifacts' used in 'Bootstrapping Protocols'. The first
    > sentence contradicts this by saying 'This document defines a protocol'. This
    > "IETF'ler Human" also suspects that "Voucher Artifacts" are kind of redundant,
    > but that was okay in RFC8366 so that seems to be okay here.

https://github.com/anima-wg/constrained-voucher/issues/132
The title reflects a history that thought we'd write two documents.

    > (1) Abstract

    > The abstract requires more (concise!) context and outline of the general
    > problem so that context-specific terms used can be easily understood, e.g.,
    > 'Pledge' or its relationship to 'owner'. Imagine the abstract being the only
    > thing visible in a document indexing and management system and phrase it as
    > such. The "new" CoAP protocol defined seems to be a complement to an HTTPS
    > protocol, which the reader has to guess is defined either by RFC8366 or BRSKI
    > (this is cleared up early in the Intro). Why is it not CoAPS, if its complement
    > is HTTPS? Ultimately, you shall not use references in an abstract and that is
    > the root cause for this need for guessing here, I think.

https://github.com/anima-wg/constrained-voucher/issues/133

    > (2) Introduction

    > OSCORE and EDHOC are suddenly used and not introduced.
    > Terms, such as 'Pledge' or 'Registrar' could be better introduced or it should
    > be very clearly stated that this memo cannot be used without a clear
    > understanding of other documents (and which documents that exactly are and
    > why). It is not very clear to the reader why YANG and SID are suddenly
    > appearing here (which again becomes pretty obvious when you read other
    > documents). In general, the Intro requires more context.

I've tacked this onto the issue:
     https://github.com/anima-wg/constrained-voucher/issues/124

    > (3) Overview of Protocol

    > It is not immediately clear what 'proximity' means here (the term is not listed
    > in the Terminology section). A quick recap of roles and interactions would not
    > hurt, I think, but that can also be addressed by adding more contextual text to
    > the Intro. "Most Pledges using these constrained": maybe just remove the
    > "these" - it made me read it as a back-reference to time-based vouchers. The
    > term "pinned" used here could benefit a from a tad bit more expositional text -
    > it is a term relevant to a lot of security aspects in this memo and deserves a
    > proper introduction.

https://github.com/anima-wg/constrained-voucher/issues/134

    > (4) Discovery, URIs and Content Formats

    > Maybe an example of EST and BRSKI URIs helps the reader to see the
    > difference/optimization more easily? The terms URI and URL or both used in this
    > section. Are they used dedicatedly with their distinct meanings or are they
    > used interchangeably? Sometimes the term 'end point' is also spelled
    > 'end-point'. Why is there a fall-back (as MAY) to Content-Format 50 for the
    > shorter URLs?

https://github.com/anima-wg/constrained-voucher/issues/135

    > (5) Extensions to BRSKI

    > 'CoRE Link Format parsing' is suddenly used and it is not clear here in the
    > context why avoiding that is useful. I am not sure that 'reconnect' is the
    > appropriate term to use when writing about resources available via a single UDP
    > port.

https://github.com/anima-wg/constrained-voucher/issues/136
Reconnect because DTLS might get renegotiated, because we might go from COAP
to COAPS, and it's just extra round trips.

    > (6) Extensions to EST-coaps

    > The example '/sen' for simple enrollment is used here, but not really
    > introduced in the document. Is that intentionally so?

Yes, because it's in draft-ietf-ace-est-coaps.
https://github.com/anima-wg/constrained-voucher/issues/137

    > (7) Pledge Extensions

    > '/att' is introduced here and it might not be obvious to a reader where that
    > comes from and what it exactly represents. Maybe a small example for "it MUST
    > use the Subject Distinguished Name fields from its IDevID unmodified." would
    > help here? Is '/crts' the short-name for '/cacerts'? So - in general, maybe
    > there should be a complete list of short-names used or are these intentionally
    > just used as examples?

https://github.com/anima-wg/constrained-voucher/issues/138

    > (8) Registrar Extensions

    > "for operational or security reasons" - that could be a topic for the TBD in
    > the Security Considerations.

Agreed.

    > (9) BRSKI-MASA Protocol

    > Some of the consideration about "CoAPS for the BRSKI MASA is deemed
    > unrealistic" can probably also fuel the Security Considerations.

https://github.com/anima-wg/constrained-voucher/issues/139

    > (10) Registrar Identity Selection and Encoding
    > 'which participate' -> 'that participate'

fixed in my copy.

    > (11) MASA Pinning Policy

    > Maybe explicitly highlight that in the case of the nonce-less vouchers, the
    > makeup of the x5bag provides the knobs and dials to exactly influence which
    > certificate will be pinned. That is only expressed implicitly, I think, or I
    > did not get the meaning of the text properly.

https://github.com/anima-wg/constrained-voucher/issues/140

    > (12) Pinning of Raw Public Keys

    > "However, if the Pledge is known to also support RPK pinning and the MASA
    > intends to pin the Registrar's identity (not a CA), then MASA SHOULD pin the
    > RPK (RPK3 in Figure 2) of the Registrar instead of the Registrar's End-Entity
    > certificate to save space in the voucher.": why is that not a MUST? What are
    > the consequences, if that is not done as highlighted?

https://github.com/anima-wg/constrained-voucher/issues/141

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide