Subject: [Anima] Cross-WGs WGLC (second) on draft-ietf-anima-voucher-04 - Respond by Aug 08, 2017

From: Sheng Jiang <[email-masked]>
Date: Tue, 1 Aug 2017 08:01:34 +0000

Hi, 6tisch, netconf,

This message starts an one-week cross-WGs Working Group Last Call on draft-ietf-anima-voucher-04, Voucher Profile for Bootstrapping Protocols, which passed two-week ANIMA WGLC in June, but relevant to 6tisch and netconf. This document's intended status is Standards Track. At present, there is no IPR file against this document.

Please send your comments by August 08, 2017. If you do not feel this  document should advance, please state your reasons why.

Sheng JIANG (ANIMA co-chair) is the assigned shepherd.

Regards,

Sheng (another ANIMA co-chair, Toerless, who as a co-author is staying neutral)

---

From: peter van der Stok <[email-masked]>
Date: Tue, 01 Aug 2017 12:48:00 +0200

Hi all,

I read this document, and find it well written and understandable.
I do have some remarks about the content and several editing remarks.

Content remarks:

section 6, leaf prior-signed-voucher, at the end:
The MASA SHOULD remove all "prior-signed-voucher".
I would encourage a "MUST" instead of a "SHOULD" when thinking of 
transporting vouchers over constrained networks.

section 6.3: leaf idevid-issuer, description, paragraph 2,
"populated for serial numbers that are not otherwise unique" to be 
replaced by
"populated when serial numbers are not unique".
My proposed text is less selective, and consequently less error prone.

Can a discussion section about "manufacturer additions" be added. 
Pointing out the consequences for interoperability when using "Augment" 
to add manufacturer specifics can be helpful.

Editing remarks:

Introduction, first phrase: pledge -> candidate device (pledge)

page 3, PKCS#7 add RFC2315 reference, and may be add RFC7154 as JSON 
reference.

Section 2; mention terminology from RFC7950

page 4 line 5; "process. i Typically" remove the "i"

page 4, Voucher: add: that "acknowledges ownership of the pledge and" 
indicates...

page 5 Authentication of: First appearances of PKIX, DNS-ID, and CN-ID 
abbreviations.

page 5, add (MiTM) after Man-in-The-Middle.

page 6 table: Voucher name -> Voucher type

Nonceless Audit Voucher: "to support network partitions" -> "to 
withstand network partitions"

Owenership audit Voucher: "Voucher's" -> "Vouchers", and remove "an 
ideal" otherwise explain what that means and why it is true.

Add type in:
Ownership ID voucher "type" is named
Bearer Voucher "type" is named

section 6
"The voucher is signing structure that" -> "The voucher signing 
structure"

section 6, paragraph 6, all "of" the certificate, remove "of"

section 6 page 7 below, First appearance of CA and JWS abbreviations

section 6.1 (see section 4) add "see"

section 6.3 page 10, module description: "securely assign one or more 
pledges to an 'owner'" seems to contradict section 7.2 voucher per 
pledge

section 7.1 last line: "there is a delay" is that delay between creation 
and consumption and when is the delay unacceptable? the text is (on 
purpose?) vague.

section 8.1 first paragraph: "no understandING of time", add "ing"
section 8.1 paragraph 2: ephermal -> ephemeral

section 8.2 compromized -> compromised?

Hope this helps

peter

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Aug 2017 05:42:55 -0400

> transporting vouchers over constrained networks.

I believe that users of vouchers over constrained networks will want to
"sub-class" the voucher.  (I'm sure that's the wrong YANG term)
There will be an example of how to do this in BRSKI, so we don't need to do that.

    > Hope this helps

It does. Also proves you read every word.
We also accept patches via github :-)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Kent Watsen <[email-masked]>
Date: Wed, 16 Aug 2017 18:24:42 +0000

Hi Peter,

Thanks for your review.   Please find responses
to your comments below.

Max, please note your attention is needed.

Thanks,
Kent

--

Hi all,

Content remarks:

<Kent> this leaf has been moved to the BRSKI draft, so this comment
is no longer an issue on this draft.

section 6.3: leaf idevid-issuer, description, paragraph 2,
 "populated for serial numbers that are not otherwise unique"
to be replaced by
 "populated when serial numbers are not unique".
My proposed text is less selective, and consequently less error prone.

<Kent> Fine, text updated.

> Can a discussion section about "manufacturer additions" be
> added. Pointing out the consequences for interoperability
> when using "Augment" to add manufacturer specifics can be
> helpful.

I'm confused, which section does this comment regard?

Editing remarks:

<KENT> done.

<KENT> done.

<KENT> What is this?  Are you asking for the draft to import terms
from RFC7950?  Which terms 

<KENT> fixed.

<KENT> what does "acknowledges ownership of the pledge" mean?  how
is it different than "indicates to a Pledge the cryptographic identity
of the Domain it should trust"?

<KENT> I added a definition for PKIX, but I think that Max needs to take
care of the DNS-ID and CN-ID parts.  It's his text, and there things have
since been removed from the YANG.  Max, these show up in three places...

<KENT> added.

<KENT> changed.

<KENT> changed.

<KENT> I'll leave this for Max.

> Bearer Voucher "type" is named

<KENT> you only mention these two, but none of the voucher type 
descriptions have "type" in them, or maybe I'm missing something.

> "The voucher is signing structure that" -> "The voucher signing 

<KENT> done.

<KENT> done.

<KENT> acronym expansions introduced.

<KENT> done.

<KENT> correct, fixed.

> and consumption and when is the delay unacceptable? the text is (on 

<KENT> The previous sentence says "...there may be a significant
delay between when a voucher is created and when it is consumed."
and the remainder of the line you're citing says "to ensure that
the assertions made when the voucher was created are still valid 
when it is consumed."   This is vague?

<KENT> done.

<KENT> fixed.

<KENT> fixed.

---

From: peter van der Stok <[email-masked]>
Date: Fri, 18 Aug 2017 09:45:43 +0200

> I'm confused, which section does this comment regard?

It refers to the document as a whole and especially section 7.
Usually, manufacturers want manufacturer-specific additions to 
documents.
They may consider to use Augment for that purpose.
My suggestion is to discuss ways to add manufacturer additions to the 
voucher and the consequences.
That may turn out to be a big NO-NO to manufacturer additions.
I think it would be worthwhile to point that out.

> from RFC7950?  Which terms

Reading RFC7950 is useful to understand section 4 for example; and 
needed when reading the voucher YANG text.
So not especially terms, but complete knowledge of RFC7950 is required.
> of the Domain it should trust"?

Now I am confused. I thought it was 2 ways. Pledge trusts domain, and 
domain partners trust pledge.

> descriptions have "type" in them, or maybe I'm missing something.

The name of the voucher is taken from the type I understand.
Only ownership ID voucher and Bearer voucher have text starting with 
"xxxx is named".
I see that I forgot: An audit voucher "type" is named .....

> when it is consumed."   This is vague?

To me yes. It sounds like a circular definition.
To paraphrase: When the voucher is consumed, the assertions are valid by 
definition.
I would expect a pointer to a delay definition and then an assertion 
that states:
  when consumption time is larger than the creation time + delay, the 
voucher is invalid.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 18 Aug 2017 13:21:17 +0000

Hi Peter,

<KENT> Are you asking for the voucher to contain a node
called something like 'opaque' having YANG type 'anyData'?
A sanctioned place where the MASA can stash some extra
stuff not defined by this document?  Recall that some of
the motivation for this work being standardized is to
enable inspection by intermediates, and while the opaque
data could be presented to a human, it might be base64
data.  Any concerns bout that?

<KENT> I added an introductory sentence to Section 6.3:

   Following is a YANG [RFC7950] module formally describing the
   voucher's JSON document structure.

Good?

<KENT> The pledge trusts the MASA (which signs the voucher) and then
the pledge trusts the domain (whose cert is inside the voucher).
Perhaps you're conflating signing the voucher with acknowledging
ownership?

<KENT> Max, this is your section, can you reply to Peter on this?

To me yes. It sounds like a circular definition.
To paraphrase: When the voucher is consumed, the assertions are valid by 
definition.   I would expect a pointer to a delay definition and then an
assertion that states: when consumption time is larger than the creation time + delay, the voucher is invalid.

<KENT> I'm modified the paragraph slightly (s/delay/time delay/ + end
of last sentence):

   The lifetimes of vouchers may vary.  In some bootstrapping protocols,
   the vouchers may be created and consumed immediately whereas, in
   other bootstrapping solutions, there may be a significant time delay
   between when a voucher is created and when it is consumed.  In cases
   when there is a time delay, there is a need for the pledge to ensure
   that the assertions made when the voucher was created are still
   valid.

and the 3rd paragraph, to call out the 'expires-on' leaf:

   Addressing the short-comings of revocations, this document recommends
   instead the use of lightweight renewals of short-lived non-revocable
   vouchers.  That is, rather than issue a long-lived voucher, where the
   'expires-on' leaf is set to some distant date, the expectation is for
   the MASA to instead issue a short-lived voucher, where the 'expires-
   on' leaf is set to a relatively near date, along with a promise
   (reflected in the 'last-renewal-date' field) to re-issue the voucher
   again when needed.  Importantly, while issuing the initial voucher

Better?

Kent

---

From: peter van der Stok <[email-masked]>
Date: Mon, 21 Aug 2017 09:36:55 +0200

Hi Kent,

> data.  Any concerns bout that?

<pvds>
My suggestion is a discussion not a standardization. So, no additions to 
the voucher in this document.
However, pointing out the base64 format would be helpful for those 
thinking about an addition with opaque.
</pvds>
> Perhaps you're conflating signing the voucher with acknowledging

<pvds>
I am afraid, that I made the voucher responsible for all keyinfra 
protocol objectives.
Sorry, for the confusion.
</pvds>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 21 Aug 2017 15:53:02 +0000

Hi Peter,

Thanks, I think we've reached closure.
Please review the diffs to the latest.

  https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-voucher-05

Thanks again,
Kent

--

Hi Kent,

<pvds>

<pvds>

---

From: peter van der Stok <[email-masked]>
Date: Tue, 22 Aug 2017 08:42:53 +0200

Hi Kent,

Thanks for your work,

Peter

Kent Watsen schreef op 2017-08-21 17:53:
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch