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

[Alissa Cooper via Datatracker <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-22: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I apologize if I'm misunderstanding how this works, but I didn't see much
discussion in the document about the implications of the manufacturer going out
of business. Specifically, it seems like if a device ships with BRSKI as its
only available mechanism for bootstrapping and the manufacturer goes out of
business before the device is enrolled, the ability for the device to function
securely on the network may be significantly impaired if not impossible. It
seems like this document needs to make clear to manufacturers that a fallback
manual enrollment mechanism of some sort needs to be implemented along with
BRSKI in order to avoid this situation.

= Section 1.3.1 =

"But this solution is not exclusive to large equipment: it is intended
   to scale to thousands of devices located in hostile environments,
   such as ISP provided CPE devices which are drop-shipped to the end
   user."

I don't quite understand how this squares with the scope limitation described
in Section 1 and Section 9. If the whole network is professionally managed by
the ISP, what part would be the "hostile environment"?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I think this document would benefit from two concise lists, with notes about
which items in each list are defined in this document and which ones are not
defined: (1) what is operationally required of a manufacturer to support BRSKI,
and (2) what is operationally required of a domain owner to support BRSKI.

= Section 2.3.1 =

What precisely is meant by "TPM identification"? Could a citation be provided?

= Section 10.1 =

"The domain can maintain some privacy since it has not necessarily been
   authenticated and is not authoritatively bound to the supply chain."

What does this mean? That the domain can expect the manufacturer not to trust
the domainID because it hasn't been authenticated?

= Section 10.2 =

"The above situation is to be distinguished from a residential/
   individual person who registers a device from a manufacturer: that an
   enterprise/ISP purchases routing products is hardly worth mentioning.
   Deviations would, however, be notable."

What does the last sentence mean?