Skip to main content

Early Review of draft-ietf-anima-constrained-voucher-10
review-ietf-anima-constrained-voucher-10-genart-early-housley-2021-05-13-00

Request Review of draft-ietf-anima-constrained-voucher-10
Requested revision 10 (document currently at 24)
Type Early Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2021-06-30
Requested 2021-05-13
Requested by Toerless Eckert
Authors Michael Richardson , Peter Van der Stok , Panos Kampanakis , Esko Dijk
I-D last updated 2021-05-13
Completed reviews Iotdir Early review of -21 by Henk Birkholz (diff)
Genart Last Call review of -21 by Russ Housley (diff)
Yangdoctors Last Call review of -21 by Xufeng Liu (diff)
Secdir Early review of -23 by Kathleen Moriarty (diff)
Yangdoctors Early review of -00 by Carl Moberg (diff)
Secdir Early review of -11 by Daniel Fox Franke (diff)
Genart Early review of -10 by Russ Housley (diff)
Iotdir Early review of -12 by Henk Birkholz (diff)
Comments
This draft specifies a DTLS/CoAP based variation of BRSKI (RFC8995) which uses HTTPs instead. We think the text is mature enough such that early review would help to move the document forward faster. Multiple implementers are currently working on implementations and planning for interop testing at IETF111.

We suggest to reach out to the IESG reviewers of BRSKI/RFC8995 as they would be most familiar with the subject matter and review:

Jari Arkko (GEN)
Russ Housley (IOT)
Christian Huitema (ART)
Roman Danyliv (SEC)

(i'll be happy to ping those past reviewers as well, if that is the right process).
Assignment Reviewer Russ Housley
State Completed
Request Early review on draft-ietf-anima-constrained-voucher by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/Q_-j3v9dNrepws2RwqqkEwVl92w
Reviewed revision 10 (document currently at 24)
Result Not ready
Completed 2021-05-13
review-ietf-anima-constrained-voucher-10-genart-early-housley-2021-05-13-00
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-anima-constrained-voucher-10
Reviewer: Russ Housley
Review Date: 2021-05-13
IETF LC End Date: unknown
IESG Telechat date: unknown

Summary: Not Ready


Note:  I did not review Section 9 or the Appendices.


Major Concerns:

Section 4 says:
   "... sign using its IDevID X.509 certificate, or if an IDevID is not
   available its manufacturer-installed raw public key (RPK)."

This is not accurate.  Signatures are created with a private key, and
then they are validated with the public key in a certificate.  A sign
operation cannot use an RPK; a signnature validation operation might.

Section 6.2 says: "... and MUST NOT distinguish between them."  There
are many different contexts that one might "distinguish" that are fine.
I think you mean that the implementation MUST respond to the two in the
same manner.

Section 6.4.1 is confusing to me.  The section says that a "constrained
Pledge MAY use the following optimized EST-coaps procedure", however,
there are MUST statements in the numbered paragraphs that follow.


Minor Concerns:

Section 1 says:
   "...  As the tooling to
   convert YANG documents into a list of SID keys is still in its
   infancy, the table of SID values presented here should be considered
   normative rather than the output of the pyang tool."

It is unclear to me what this means to an implementer.  When does
this situation change?  This seems to be begging for a MUST or SHOULD.

Section 5 says: "Saving header space is important...".  Okay.  It is not
just the headers.  Maybe something like: "To keep the protocol messages
small..."

Section 5 ends with: "For example, the following more complete response
is possible."  Nothing follows.  Not sure what is meant.

Section 6 and Section 6.1 say the same thing.  Drop one.

The last paragraph of Section 6.4.1 and the only paragraph in
Section 6.4.2 say the same thing.  Drop one.

Section 8.1 ends with:

   When the Registrar is using a COSE-signed constrained format voucher
   request towards MASA, instead of a regular CMS-signed voucher
   request, the COSE_Sign1 object contains a protected and an
   unprotected header, and according to [I-D.ietf-cose-x509], would
   carry all the certificates of the chain in an "x5bag" attribute
   placed in the unprotected header.

I think there should be a MUST statement in this paragraph.  Maybe:

   When the Registrar is using a COSE-signed voucher instead of a
   CMS-signed voucher, the COSE_Sign1 object contains a protected
   header and an unprotected header.  The Registrar MUST place all
   all the certificates for the chain in an "x5bag" attribute in
   the unprotected header [I-D.ietf-cose-x509].

Section 8.2 says: "... reduce on average the duration ...".  I cannot
figure out what is actually being reduced.  Please add more explanation
or drop the bulk of the sentence.  Rationale that comes later in the
section does not say anything about duration being reduced, but it does
talk about avoiding retransmission of the same certificates.


Nits:

Abstract: Please remove the references.  The RFC Editor Guidlines for
Abstracts include: "An Abstract should be complete in itself; it should
not contain citations unless they are completely defined within the
Abstract."

Section 1, paragraph 1:
  s/such as [I-D.ietf-anima-bootstrapping-keyinfra]/
   /such as BRSKI [I-D.ietf-anima-bootstrapping-keyinfra]/

Section 1, paragraph 3:
  s/either OSCORE+EDHOC, or/either OSCORE+EDHOC or/

Section 4, paragraph 7:
   s/section Section 8./Section 8./

Section 6.4.1, last paragraph:
   s/needs to use at least multiple CAs/needs to use multiple CAs/

Section 6.4.2, only paragraph:
   s/needs to use at least multiple CAs/needs to use multiple CAs/

Section 8, only paragraph: The first sentence is very awkward.  I
suggest something like: "The voucher is a statement by the MASA for
use by the Pledge that provide the identity of the Pledge's owner."

Section 8.2, paragraph 1:
   s/pin in the voucher in case there are multiple available/pin/
   
Section 8.3, Figure 2:  Please find fome other way to represent [RPK3].
This looks like a reference, and that is not the intent.

Section 8.3, first paragraph after Figure 2:
   s/certificate-less enrollment/enrollment without certificates/