Subject: [Anima] dealing with many the secdir and genart comments

From: Michael Richardson <[email-masked]>
Date: Thu, 29 Nov 2018 22:36:14 -0000

{This is the first of many replies to the various reviews}

Jari Arkko <[email-masked]> wrote:
> My first bigger comment is that I believe the security and privacy
> considerations section should have provided an actual in-depth
> analysis of the characteristics offered by the protocol, perhaps under
> several different situations, as the protocol can be operated in
> different modes.

The authors seriously believe that this will result in an attempt to boil the
ocean.  Yes, BRSKI is exciting for many and opens many doors, but in
the context of the *ANIMA* Charter, we strongly think that this
document should leave the oceans alone, and deal only with the
ANIMA ACP usage.

Other users of BRSKI *SHOULD* write a new profile.
Would it be acceptable for us to provide a section that might be
entitled:
        "The ACP mode of operation of BRSKI"

or perhaps some other section that would clarify the applicability of this
document?

We would list the assumptions and maybe even reduce the options for use
in the ACP?

The authors do not object to writing more documents about more situations
where BRSKI might be used, but we think that putting it all into one
document is a way for continuing scope creep.

In accepting the constrained work into the ANIMA WG, the chairs and area
director have already been very generous.

> My second comment is that the protocol as defined is quite focused on
> manufacturer-controlled situations. As Christian mentioned, there is
> some discussion of other situations in the document (Section 6.4), but
> not much, and there's little information on what happens if one tries
> to use the protocol in this way.

The above comments would seem to apply to this as well.

As I previously indicated when you first wrote this, we have turned your
comments into a series of issues on github, and we will be closing those
issues as quickly as we can.

Some will come with proposed text changes, but a number will need discussion,
and we will start new subject lines in this thread for them.   I don't want
to innudate you, so I've set the Reply-To.

--
]               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 =-

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Nov 2018 13:57:26 +1300

> document should leave the oceans alone, and deal only with the

Yes, violent agreement. From all the interest outside ANIMA, the basic
idea of BRSKI is a big hit and will be re-used in other contexts. I think
a strong statement about the specific scope of *this* document belongs
in the Abstract and Introduction, with a comment that variant usages
of BRSKI in other scenarios will be documented separately.
 
> or perhaps some other section that would clarify the applicability of this

That too, but make sure that the reader gets the point in the first
few seconds of reading.

> The above comments would seem to apply to this as well.

Correct. The last call discussion has convinced me for one that we need
to tackle the issue of non-MASA scenarios, and I have some ideas about
it, but *the scope of this document* is MASA-based scenarios for
professionally managed networks. Let's make that clear (see above)
but not dilute the present text with it.

   Brian

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Nov 2018 01:59:34 -0000

https://github.com/anima-wg/anima-bootstrap/issues/95

    Jari> Section 3.1:

    Jari> grouping voucher-request-grouping
    Jari> +---- voucher
    Jari> +---- created-on? yang:date-and-time
    Jari> +---- expires-on? yang:date-and-time
    Jari> +---- assertion enumeration
    Jari> +---- serial-number string

    Jari> I'm not sure it is necessary to base everything on a serial number.

I wrote this down, and then went back for context, and found little.
So, let's discuss this.  You have another idea?

The serial-number, as explained in section 2.3.1, the serial-number is pretty
critical.  It goes into the certificate and the MASA uses it as it's primary
key.

So I'm not really sure how to proceed with this comment.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 30 Nov 2018 02:26:53 -0000

https://github.com/anima-wg/anima-bootstrap/issues/88

> What happens if the MASA refuses to provide a voucher, or provides a wrong
> voucher? Can the MASA be used to restrain commerce with specific countries?
> Is that a feature or a bug?

BRSKI does not eliminate other mechanisms of enrolling devices.
If the vendor eliminates all other ways of enrolling devices, then yes, it
could be used as a restraint.  But, many vendors already restrict which
firmware can be used in which countries, and by which customers.

It's a feature that the MASA can be used to defer theft.
It's a bug that the MASA can be used to prevent resale.
I'd love to resolve the situation, but I don't know how.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 30 Nov 2018 16:45:03 +1300

> I'd love to resolve the situation, but I don't know how.

The feature is good. The bug is a regulatory issue; IANAL
but in any case (as with DRM) it's completely outside the IETF's
control.

Imagine a military device in such a context. You pull the trigger
and the gun pops up a window saying "Not authorised for use
in Elbonia." From most viewpoints, that's a Good Thing.

   Brian

---

From: Kent Watsen <[email-masked]>
Date: Fri, 30 Nov 2018 17:37:09 +0000

IEEE 802.1AR-2018 says:

  An IDevID certificate "subject" field shall be non-null and should
  include a unique device serial number encoded as the "serialNumber"
  attribute (RFC 5280, X520SerialNumber).

Maybe the voucher (RFC 8366) could've called it "unique-id", and then
bootstrapping protocols could likewise guide implementations to put
a "unique-id" into the DevID's serialNumber field.  Thus, from a
standards perspective, IETF is not requiring the use of the device's
serial number.  But to what end?

I believe that this is a privacy issue more so than a security issue.
That is, the security of a device should not hinge on knowledge of
its serial number, or any information that might be derived from 
the serial number (e.g., model number, manufacturing facility,  
manufacturing date, etc.).

Separately, as long as we're raising issues with RFC 8366, I strongly
believe that the pinned-domain-certificate should've be a list of 
certificates.  Or, in crypto-types [1] terms, a trust-anchor-cert-cms,
not a trust-anchor-cert-x509.  To enable the pinned-domain-certificate
for an intermediate CA to be a chain that includes the root self-signed
certificate, thus supporting tooling unable to validate partial-chains.

[1] https://tools.ietf.org/html/draft-ietf-netconf-crypto-types

Kent

-----Original Message-----
From: Anima <[email-masked]> on behalf of Michael Richardson <[email-masked]>
Date: Thursday, November 29, 2018 at 9:00 PM
To: "[email-masked]" <[email-masked]>
Subject: [Anima] gen art issue 7: serial-number in voucher issue #95

    Jari> Section 3.1: