Early Review of draft-ietf-anima-constrained-voucher-12
review-ietf-anima-constrained-voucher-12-iotdir-early-birkholz-2021-07-19-00

Reviewer: Henk Birkholz
Review result: Not Ready

I am the assigned IoT Directorate reviewer for
I-D.ietf-anima-constrained-voucher-12 as part of the IoT Directorate's effort
to provide early feedback to IoT-related IETF documents before being processed
by the IESG. Document authors, document editors, WG chairs and Area Directors
should treat these comments just like any other WG comments. This early review
focuses on the body of the memo and does not extend to the examples in the
appendices.

Summary: The document proposes a solution that introduces CBOR-based voucher
and EST-CoAPS based enrollment as a more concise variant of JSON-based vouchers
and EST over HTTPS based enrollment as defined by RFC8995 and RFC8366. The
general concept makes a lot of sense as CBOR's (and in consequence COSE's)
footprint on message size, processing code size, and computation resources
combined is significantly lower in comparison with JSON (and CMS), ultimately
enabling future interoperability with a host of constrained node types. The
document is work in progress as indicated by editor's notes and various TBD
placeholders.

(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.

(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.

(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.

(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.

(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?

(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.

(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?

(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?

(8) Registrar Extensions

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

(9) BRSKI-MASA Protocol

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

(10) Registrar Identity Selection and Encoding

'which participate' -> 'that participate'

(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.

(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?

Viele Grüße,

Henk