Re: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-19.txt

[Michael Richardson <[e-mail]>]

[e-mail] wrote:
    > Title           : Bootstrapping Remote Secure Key Infrastructures (BRSKI)
    > Authors         : Max Pritikin
    > Michael C. Richardson
    > Michael H. Behringer
    > Steinthor Bjarnason
    > Kent Watsen
    > Filename        : draft-ietf-anima-bootstrapping-keyinfra-19.txt


    > A diff from the previous version is available at:
    > https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-19

While the 18 to 19 diff is probably of interest to those who have most
recently reviewed the document a diff against version 16 is probably most
useful to those who last read during the WGLC.
   https://www.ietf.org/rfcdiff?url1=draft-ietf-anima-bootstrapping-keyinfra-16&url2=draft-ietf-anima-bootstrapping-keyinfra-19

We believe that we dealt with all of the review comments raised during WGLC
and reviews, and we are ready to proceed to the IESG.

The reviews are at:
secdir:  https://mailarchive.ietf.org/arch/browse/anima/?gbt=1&index=NGsR9xGIL7k_j06FXkI_GBeJZMo
genart:  https://mailarchive.ietf.org/arch/msg/anima/iVg7MRMdBQBVFA5VFiksYFHchBU
iotdir:  https://mailarchive.ietf.org/arch/msg/anima/1N7AR8hqu2oIWuTFFd9OQOab8SI

The issues that were opened are at:
    https://github.com/anima-wg/anima-bootstrap/issues?utf8=%E2%9C%93&q=is%3Aissue+

In most cases, we have used the #issue notation that github (and trac, and..)
supports in order to link the diffs that we made to the issue number.

Major changes:
      1) new section 5.3: Registrar Authorization of Pledge
      2) new section 3.1: Nonceless Voucher Requests
      3) new section 8: Applicability to the Autonomic Control Plane (plus
      other details in the document)
      4) new section 9: Privacy Considerations:

   9.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  60
     9.1.  MASA audit log  . . . . . . . . . . . . . . . . . . . . .  60
     9.2.  What BRSKI-MASA reveals to the manufacturer . . . . . . .  61
     9.3.  Manufacturers and Used or Stolen Equipment  . . . . . . .  63
     9.4.  Manufacturers and Grey market equipment . . . . . . . . .  64
     9.5.  Some mitigations for meddling by manufacturers  . . . . .  64

      5) additions to Security Considerations:
           10.1.  DoS against MASA . . . . . . . . . . . . . . . . . . . .  66
           10.4.  Manufacturer Maintainance of trust anchors . . . . . . .  69


Issues that we have not dealt with using text.
If you want to re-open the ticket, please go ahead, but please also bring
some text that is in-scope for ANIMA ACP:

    https://github.com/anima-wg/anima-bootstrap/issues/112
    add discussion of each major mode of the protocol #112

        * We are focused on the proximity assertion that we think is the most
          secure version of the protocol.  We have described this in detail.
        * We have expanded discussion about the nonceless (offline) mechanism
          that vouchers can use.
        * There are some additional ways the protocol can be used, but we
          feel that they should be dealt with in other documents.

    https://github.com/anima-wg/anima-bootstrap/issues/110
    gen art issue #22: permanent vouchers... feature or bug. explain further
        * we think that further discussion about this is needed.
        * this is a "major mode" that belongs in an operational document.


    https://github.com/anima-wg/anima-bootstrap/issues/79
    security review issue 6: ship and forget not supported
        * a new major mode, which we do not support, and we don't know how.
        * it is out of scope for ANIMA.
        * we did add text that existing mechanisms (craft consoles) continue
          to be available.

    https://github.com/anima-wg/anima-bootstrap/issues/82
    security review issue 7: what if MASA always issues vouchers
        * "It is mentioned in
           section 6.4, which recommend that manufacturers should not do that. What
           are the consequences if they still do?"
        -> it's hard to say what will happen if implementers violate the protocol.
           Some other set of assumptions need to be made about how many
           violations the other components do.

    https://github.com/anima-wg/anima-bootstrap/issues/83
    security review issue 8: device refuses to be imprinted
        * we think the answer is that the customer ships it back.
        * we provide telemetry as to success, but if the device is broken,
          it's broken.

    https://github.com/anima-wg/anima-bootstrap/issues/86
    security review issue 13: individualization
        * the issue asks about the per-device step in manufacturing.
        *** we think that this is out-of-scope for ANI use ***
        * we considered talking about technology like:
          https://en.wikipedia.org/wiki/Physical_unclonable_function
          but ultimately, that's just another way to do TPM, so
          skirts the question.

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