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

[Michael Richardson <[e-mail]>]

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.
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.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-