Subject: [Anima] Call for adoption on draft-kwatsen-netconf-voucher-00

From: Sheng Jiang <[email-masked]>
Date: Tue, 13 Dec 2016 16:57:43 +0000

Hi, all,

This message starts a two-week adoption call for Voucher work, which is a straight-forward definition of common voucher formats as needed in both ANIMA and NETCONF WG. Although it was submitted to netconf WG originally, after discussion with netconf chairs and corresponding ADs, we all agree ANIMA is the right home for it. If adopted, the authors hope to be ready for WGLC before Chicago, giving that our milestone work item bootstrap key infrastructure normatively refer it.

  Title:      Voucher and Voucher Revocation Profiles for Bootstrapping Protocols
                    
  Authors :   Watsen, et al.
  Filename:  draft-kwatsen-netconf-voucher
  
  https://tools.ietf.org/html/draft-kwatsen-netconf-voucher-00

Please express your support or rejection. If you think this document should _not_ be adopted, please also explicitly indicate the reasons.

This adoption call will end on Dec. 27, 2016.

Regards,

Sheng

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Dec 2016 13:05:32 +1300

Hi,

I support adoption of the draft, since we need it as part of Anima.

A couple of points seem to need attention before we get to WGLC:

> NOTE: AT THIS TIME, THE SIGNING STRATEGY HAS NOT BEEN SELECTED

I think that needs to resolved.

>    Implementations MUST ensure devices have
>    an accurate clock when shipped from manufacturing facilities, and
>    take steps to prevent clock tampering.

Doesn't that pose a problem for very low-end devices? That is not
a concern for devices that are in scope for Anima, but I understand the
applicability is intended to be general. As such, the MUST seems
impossible to enforce.

Shouldn't the formulation be like this:

   Implementations SHOULD ensure devices have
   an accurate clock when shipped from manufacturing facilities, and
   MUST then take steps to prevent clock tampering.

   If it is not possible to ensure clock accuracy and integrity,
   implementations MUST disable the aspects of the solution having clock
   sensitivity.

By the same logic,

>    It is important to note that implementations SHOULD NOT rely on NTP
>    for time, as it is not a secure protocol.

I think that should be a MUST NOT. Otherwise product managers will ignore it.

Regards
   Brian

On 14/12/2016 05:57, Sheng Jiang wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Dec 2016 06:37:43 +0100

>    implementations MUST disable the aspects of the solution having clock

I think the security considerations section requires some discussion. 
In particular, a more detailed threat analysis should be given and more
specific recommendations given.  I can say with some certainty that some
devices do not and will not have RTCs.  However, this discussion need
not take place during a call for adoption.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Sat, 17 Dec 2016 14:48:38 -0500

{as an anchor, I support adopting...}

    > I think that needs to resolved.

I STRONGLY agree.
I have been suggesting that we should use CWT:
  https://datatracker.ietf.org/doc/draft-ietf-ace-cbor-web-token/

Reading this is short and sweet, because really all the crypto is in:
  I-D.ietf-cose-msg

and the concepts are from RFC7515.

    >> Implementations MUST ensure devices have an accurate clock when
    >> shipped from manufacturing facilities, and take steps to prevent clock
    >> tampering.

    > Doesn't that pose a problem for very low-end devices? That is not a
    > concern for devices that are in scope for Anima, but I understand the

I think that much of this will be dealt with in the audit vs ownership token
discussion which is currently in the bootstrap document, but will get moved
to this document.

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

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