Subject: Opsdir last call review of draft-ietf-anima-voucher-05

From: Joe Clarke <[email-masked]>
Date: Wed, 04 Oct 2017 10:39:32 -0700

Reviewer: Joe Clarke
Review result: Has Issues

I am reviewing draft-ietf-anima-voucher-05 as the representative from the OPS
directorate (OPS-DIR).  This draft describes the format and signing for voucher
artifacts used in various bootstrapping protocols.  This document does not
describe those protocols.

Overall I struggled a bit to understand this document and how to interpret some
items.  In part, some of the difficulty comes from the fact that this is broken
out from the bootstrapping protocols that use the voucher.  But also, there
seem to be some gaps in terms of what a device _does_ with the voucher.  There
was also an issue with terminology that made the first read-through a bit
confusing (which I describe below).

The biggest thing I want to call out is "processing" is expected on the device
given a specific voucher?  The YANG module makes reference to what should
happen relative to this processing based on the value of certain fields, but I
am uncertain as to exactly what a device will do once it receives the voucher. 
One case in particular that caused some confusion is around the assertion:

"The assertion is a statement from the MASA regarding how
the owner was verified.   This statement enables pledges
to support more detailed policy checks.  Pledges MUST
ensure that the assertion provided is acceptable before
processing the voucher."

How does the pledge (i.e., device) ensure the assertion is acceptable?  If this
is bootstrap protocol-specific, perhaps there can be some references here to
help.

In terms of revocation tests, it might be worth mentioning (from an operator
perspective) that doing this may require broader internet connectivity than a
bootstrapping device may typically have.  Opening up that connectivity may be
problematic from a security standpoint.  There might, therefore, be some
requirements or recommendations put on the bootstrapping services to make sure
a device is both protected and can verify the validity of a cert.

>From a terminology standpoint, the use of the word "pledge" seems odd.  The use
of this word may not translate as clearly outside of the US.  Why not something
like candidate?

Below are my section-by-section reviews:

Section 1:

There is a reference to a "second category" of vouchers, but this is not
referenced anywhere else.  I'm not sure what the "categories" of vouchers are. 
More explanation (or rephrasing) is required here.

You misspelled "programmatic" as "programatic".

===

Section 2:

You use mixed case of terminology here and throughout the document (domain vs.
Domain seems to be the most egregious).  I recommend making sure that key terms
are used with consistent case throughout.

MASA server is not well-defined.  You expand the acronym, but you do not really
explain what a MASA server _is_.  Maybe this isn't the right document for that,
but then there should be a reference to where one can really understand this
element.

===

Section 5:

Typo:

"This does not direct prevent the MiTM but provides a response"

Maybe you mean, "This does not directly prevent" or "This does not prevent"

Section 6:

You have a duplicate word, "use":

A possible other use use could be as a "signed voucher request" format
originating from pledge or registrar toward the MASA.

===

Section 6.1:

Is this needed?  Can you simply refer to draft-ietf-netmod-yang-tree-diagrams?

===

Section 6.3:

In the description for created-on, you state that this node is not mandatory. 
However, it is defined as "mandatory true".