Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Whoops, this one apparently got skipped over amid some other deluge in my
inbox; sorry.

On Sun, Aug 18, 2019 at 04:09:50PM -0400, Michael Richardson wrote:
> 
> Benjamin Kaduk <[e-mail]> wrote:
>     > That specific construction would seem like an "optional feature" per
>     > https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/
>     > ...
> 
> I re-read this, and this as to do with References, and so anything optional
> referenced in section 7 would still need to be a Normative Reference.
> 
> The stickler I see right now is [I-D.ietf-netconf-keystore].
> I don't want to hang on MISREF on that document; it's just one of many that
> could be used, and I do not want to tell manufacturers that they have
> to use this specific protocol to update trust anchors.
> There are many other protocols that they presently support which they could
> use, in particular, a CLI interface would be fine.
> 
> I think that this 7.4.3 section that creates a factory default which isn't
> the default from the factory should be worry people who care about remote
> attestation of software.
> 
> Adam has been particularly vocal about the need to specify something
> normative that manufacturers have to provide in order to resale and operation
> with the availability of the MASA.
> 
> It seems that we might need another round of discussion on this topic.
> I feel that we are being pushed to describe the entire security lifetime of
> the device; that we need to solve the entire management problem of devices in
> our document.  (i.e. the 25 years of SNMPv3, plus YANG...) Maybe I just don't
> understand what would be a reasonable answer, if what I've written is not enough.
> 
> Maybe a virtual interim discussion!   If so, please let me know.

I think I'm going to have to leave this one to Adam et al.

> ANIMA/Iot-Onboarding has some time booked already:
>     https://datatracker.ietf.org/meeting/interim-2019-anima-01/materials/agenda-interim-2019-anima-01-anima-01
> 
> ps: (s/IPv6 NAT44/IPv4 NAT44/ for section 7.4.2, btw)
> 
> 
>     >> section 9:
>     >> In recognition of this, some mechanisms are presented in
>     >> Section 7.2.  The manufacturer MUST provide at least one of the one-
>     >> touch mechanisms described that permit enrollment to be proceed
>     >> without availability of any manufacturer server (such as the MASA).
> 
>     > ... but this is a somewhat different construction.  In isolation, it looks
>     > more like "MUST do at least one of X, Y, Z" without condition on "wish to
>     > do W", and if X, Y, and Z are all in the same place, that place seems
>     > normative to me.  (I will confess I've rather lost track of exactly why
>     > we're debating if this is normative or not; I guess it's just the
>     > disclaimer in Section 7 about "considered non-normative in the generality
>     > of the protocol".)
> 
> Yes, it's MUST do one of X,Y,Z.
> So that implies: MAY do X, MAY do Y, MAY do Z, but not the case of all being false.

If "ignore all of Section 7.2" is not an option, then at least some part of
it is normative.  "You just get to choose which part" :)

-Ben