Subject: [Anima] 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".

---

From: Michael Richardson <[email-masked]>
Date: Wed, 25 Oct 2017 15:08:05 -0400

Joe,
   Max, Kent and I worked through your comments, and this will result in
a version -06 shortly.  (06 will also include changes to CMS)

> a device is both protected and can verify the validity of a cert.

In general, the need for connectivity to check revocation is why we
prefer short-lived vouchers.

> of this word may not translate as clearly outside of the US.  Why not something

That's an interesting suggestion. It has a slightly different
connotation and implies some kind of contest.

We picked pledge based upon the traditions of fraternities, with
inspiration from movies like Animal House.  Dictionary definitions of
Pledge reinforce our usage.

> More explanation (or rephrasing) is required here.

We have clarified the "second category".  Also removed the word
ephemeral in the intro as being confusing here.

The categories are essentially: "nonce" (freshness by being online, and
containing data from the pledge), and "time-based" (freshness by having
a useful real-time clock and paying attention to the expires-on
attribute).  So we changed that paragraph to:

   The lifetimes of vouchers may vary.  In some bootstrapping protocols
   the vouchers may include a nonce restricting them to a single use,
   whereas in others the vouchers may have an indicated lifetime.  In
   order to support long lifetimes this document recommends using short
   lifetimes with programatic renewal, see Section 7.1.

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

We ripped out section 4, and referenced the document informatively, and
hope that it will get published.

---

From: Joe Clarke <[email-masked]>
Date: Wed, 25 Oct 2017 18:06:53 -0400

On 10/25/17 15:08, Michael Richardson wrote:
> Joe, Max, Kent and I worked through your comments, and this will
> result in a version -06 shortly.  (06 will also include changes to
> CMS)
> 
>> 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.
> 
> In general, the need for connectivity to check revocation is why
> we prefer short-lived vouchers.

That's fine.  My point was in doing this there should be some callout
to the fact that the certs will require connectivity for validation.

> 
>> 
>> 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?
> 
> inspiration from movies like Animal House.  Dictionary definitions
> of Pledge reinforce our usage.

I speak US English, and I knew what you meant.  But I, too, looked it
up, and I didn't find this as a common definition.  If I'm the only
one commenting, pledge is likely fine.  I was just curious if this
would be as obvious for non-US English speakers.

>> 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.
> 
> ephemeral in the intro as being confusing here
> 
> The categories are essentially: "nonce" (freshness by being online,
> and containing data from the pledge), and "time-based" (freshness
> by having a useful real-time clock and paying attention to the
> expires-on attribute).  So we changed that paragraph to:
> 
> The lifetimes of vouchers may vary.  In some bootstrapping
> protocols the vouchers may include a nonce restricting them to a
> single use, whereas in others the vouchers may have an indicated
> lifetime.  In order to support long lifetimes this document
> recommends using short lifetimes with programatic renewal, see
> Section 7.1.

Thanks.

> We ripped out section 4, and referenced the document informatively,
> and hope that it will get published.

Thanks.

Joe

---

From: Michael Richardson <[email-masked]>
Date: Thu, 26 Oct 2017 11:35:19 -0400

Joe Clarke <[email-masked]> wrote:
    >>> odd.  The use of this word may not translate as clearly outside of
    >>> the US.  Why not something like candidate?
    >>

    > up, and I didn't find this as a common definition.  If I'm the only one
    > commenting, pledge is likely fine.  I was just curious if this would be
    > as obvious for non-US English speakers.

I first concocted it in 6tisch and convinced the others.
I also made Max put the (aargh! --pirate) R into BRSKI.
So please blame me!!

In a 6tisch document, I reference http://www.dictionary.com/browse/pledge
definition #6 is the one, but it's interesting how the other definitions also
provide interesting connections.  The key was to pick a term that wasn't
otherwise used in another document.

1. a solemn promise or agreement to do or refrain from doing something:
   a pledge of aid; a pledge not to wage war.
2. something delivered as security for the payment of a debt or fulfillment of a
   promise, and subject to forfeiture on failure to pay or fulfill the promise.
3. the state of being given or held as security:
   to put a thing in pledge.
4. Law.
        the act of delivering goods, property, etc., to another for security.
        the resulting legal relationship.
5. something given or regarded as a security.
6. a person accepted for membership in a club, fraternity, or sorority, but not
   yet formally approved.
7. an assurance of support or goodwill conveyed by drinking a person's health; a toast.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [