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

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw 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 support Eric’s Discuss position. Also a big thanks to Christian Huitema’s
thorough SECDIR reviews and the associated improvements made as a result.  I
have a few more items:

(1) Section 5.7.  The format of a pledge status telemetry message seems
underspecified.

** what are all of the fields (e.g., version appears in the example but no the
text)

** what are the field formats (e.g., the format of the status field is inferred
from the unlabeled example

** which fields are mandatory?

** Per the JSON snippet, is that normative is some way in describing the format?

** Also, how does a server receiving the telemetry messages behave when
receiving unexpected JSON attributes?

(2) Section 5.8.1.  The format of the MASA audit log seems underspecified.  Is
the JSON snippet presented here normative to describe the MASA audit log
response?

(3) Why is Section 7.x in this document if it explains how to use BRSKI but is
considered non-normative?

-- How should implementers take this language?
-- Why are normative sections, like Section 11, discussing it?

(4) Thank you for documenting “manufacturer control issues” in Sections 10.3
and 10.4.  It helpfully lays justifies the current design approach.  I strongly
concur with the premise that “facilitate[ing] a few new operat[i]onal modes
without making any changes to the BRSKI protocol” is exactly what is needed.

My concern is that even with the current applicability statement in Section 9,
the current text appears to have only standardized the first part of the
lifecycle that BRSKI equipment might see -- equipment on first sale as long as
the manufacturer supports it or stays in business.  The text doesn’t appear to
cover the practical aspects of the proposed mitigations in Section 10.5 or the
situations described in Section 10.3/10.4 – various situations possible in the
full lifecycle usage of a BRSKI device and needed support the “additional
operational modes”.  Specifically:

** There appears to be little discussion on how owners/manufacturers/vendors
can facilitate second sale/used equipment beyond narrative words (in Section
10.3 and 10.4)

** There is appears to be little discussion on how to practically implement a
MASA (i.e., the offline use case).  For example, (Per Section 10.5) “A
manufacturer could provide a mechanism to manage the trust anchors and built-in
certificates (IDevID) as an extension.  This is a substantial amount of work,
and may be an area for future standardization work”.  Without the ability to
change anchors on the device the additional operational modes such as offline
mode seems challenging.


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

(5) Section 1.3.2.  Cite the origin of the taxonomy which defines “class 2+”
devices – likely RFC7228

(6) Section 1.5.  Per “Upon successfully validating a voucher artiface, a
status telemetry MUST be returned.”, what is a “voucher artiface”?  is that
just a “voucher”?

(7) Section 2.6.1.  What is a “Network Time Protocols” – specifically why is
protocols plural?  Is this something more than NTP?

(8) Section 4.1.  Per “The communication between the pledge is over IPv6
Link-Local addresses”, if that is the case, why does Figure 3 show IPv4 and
Appendix A describes an IPv5 approach?

(9) Section 5.1., Per “The pledge maintains a security paranoia concerning the
provisional state …”, what does it mean to “maintain a security paranoia”?

(10) Section 5.1.  Per “A pledge that can not maintain as many connections as
there are eligible proxies.”, this is an unfinished sentence.  What should the
pledge do?

(11) Section 5.2.  created-on.  The value to use in this field of this field is
not described here.

(12) Section 5.2.  Per “All other fields MAY be omitted in the pledge
voucher-request”, should this be read as guidance that the fields mentioned
above this text are mandatory (i.e., created-on, nonce,
proximity-registrar-cert). If so, what value should pledges without clocks use?

(13) Section 5.3.  Per “If these validations fail the registrar SHOULD respond
with an appropriate HTTP error code”, a few questions:

** Is this text suggesting that silent failure?  Given the text says SHOULD,
validation could fail and the registrar would not share this failure?

** What specific codes should be used?

(14) Section 5.4.  Per “The registrar initiates the connection and uses the
MASA URL obtained as described in Section 2.8 for [RFC6125] authentication of
the MASA.”, RFC6125 doesn’t have a Section 2.8.  Please clarify how this
connection is made.

(15) Section 5.5.  What is the relationship between the value of the created-on
field passed by the pledge per Section 5.2, and described in Section 5.5 as
being populated by the registrar.

(16) Section 5.5. What is a “statistically unique identity” per the
“idevid-issuer” field?

(17) Section 5.7.  Per the JSON snippet:

** It isn’t labeled as a figure or example; and isn’t referenced in the text.

** This isn’t valid JSON: no commas between items.  What does the notation “/*
TRUE=Success, FALSE=Fail”” mean – opening with a /* and closing with a “?

(18) Section 5.8.2.  Per “Each time the Manufacturer Authorized Signing
Authority (MASA) issues a voucher, it places it into the audit log for that
device.  The details are described in Section 5.8.”, this reference to Section
5.8 on how the MASA logs doesn’t seem correct.  Section 5.8 describes how a
registrar asks a MASA about its logs.

(19) Section 5.9.4.  What happens if the pledge doesn’t re-negotiate an EST TLS
session after been successful enrolled?

(20) Section 5.9.4.  In what way is a the SubjectKeyIdentifier included in the
success telemetry message?

(21) Section 6.  What is “../voucherrequest”?

(22) Section 7.  Per “This section is considered non-normative: use suggested
methods MUST be detailed in specific profiles of BRSKI” -- the clause after the
colon doesn’t parse.  What is the guidance relative to profiles?

(23) Section 11.0.  The caution about untrusted data and HTTP libraries seems
warranted.  Wouldn’t this also apply to the application code too?

(24) Section 11.1.  Per the list of examples where a MASA is unavailable or
uncooperative, wouldn’t a manufacturing going out of business also be a concern?

(25) Section D.1.4.  Provide an openssl version and reference that generated
this output

(26) Per Christian Huitema’s Last Call SecDir Review
(https://datatracker.ietf.org/doc/review-ietf-anima-bootstrapping-keyinfra-20-secdir-lc-huitema-2019-06-04/),
please respond to the last two issues – random number generation and the
missing assertion leaf.

(27) Editorial

Section 1.  Duplicate Word.  s/Section Section/Section/

Section 1.  Editorial. /(or be discovered by)/(or are discovered by)/

Section 1.1.  Typo.  s/transfered/transferred/

Section 1.1. Typo. s/serveral/several/

Section 1.2.  The term “drop ship” is initial stated with a space, but is later
used with a hyphen in the definition.  Consistency is recommended.

Section 1.3.1.  Typo.  s/aquire/acquire/

Section 1.3.3.  Typo.  s/consistant/consistent/

Section 1.3.4.  Typo. s/transfered/transferred

Section 2.3.2.  Typo. s/docucment/document/

Section 2.3.2.  Typo.  s/registrary/registrar/

Section 2.5.4.  Typo.  s/seperate/separate/

Section 2.6.1. Typo.  s/certificiate/certificate/

Section 3.4. Missing letter.  s/conn ection/connection/

Section 3.4.  Typo.  s/occurance/occurrence/

Section 4.  Typo.  s/refered/referred/

Section 4.  Typo.  s/occuring/occurring/

Section 5.  Typo.  s/boostrap/bootstrap/

Section 5.1.  Typo.  s/atttempts/attempts/

Section 5.1.  Typo.  s/making process/making progress/

Section 5.2.  Typo.  s/impementations/implementations/

Section 5.5.  Typo.  s/impementations/implementations/

Section 5.5. Typo.  s/recieved/received/

Section 5.5.7. Typo. s/is exist/exists/

Section 5.6.  Typo.  s/approriate/appropriate/

Section 5.6. Duplicate word.  s/section Section/Section/

Section 5.6.  Typo.  s/sufficent/sufficient/

Section 5.6.1.  Typo.  s/manufacter/manufacturer/

Section 5.8.1.  Duplicate word. s/the the/the/

Section 5.8.2.  Typo.  s/dicussion/discussion/

Section 5.8.2.  Typo.  s/evens/events/

Section 5.8.2.  Typo.  s/anomoly/anomaly/

Section 5.9.2.  Typo.  s/boostrapping/bootstrapping/

Section 5.9.4.  Typo.  s/adminstrative/administrative/

Section 5.9.6.  Typo.  s/defintion/definition/

Section 7.2.  Typo. s/innappropriate/inappropriate/

Section 9.  Typo. s/signficant/significant/

Section 9.  Typo. s/consistenting/consisting/

Section 9.  Duplicate Word.  s/like like/like/

Section 9.  Editorial.  The sentence “Such an operator also is …” does not
parse without the parenthetical.  Perhaps it should read like “Such an operator
is also capable of performing bootstrapping of a device using a serial-console.”

Section 9.  Typo. s/signficiant/significant/

Section 9.  Duplicate word.  s/still still/still/

Section 10.2.  Typo.  s/targetted/targeted/

Section 10.2.  Typo.  s/comissioning/commissioning/

Section 10.2.  Typo.  s/constrast/contrast/

Section 10.2.  Typo.  s/redesigs/re-designs/

Section 10.2.  Typo.  s/seperate/separate/

Section 10.3.  Typo.  s/responsability/ responsibility/

Section 10.3.  Duplicate Word.  s/the the/the/

Section 10.3.  Typo.  s/occurrance/occurrence/

Section 10.4.  Typo.  s/informatin/information/

Section 10.5.  Typo.  s/gratutiously/gratuitously/

Section 10.5.  Duplicate word.  s/these these/these/

Section 10.5.  Typo.  s/facilitiates/facilitates/

Section 10.5.  Typo.  s/operatonal/operational/

Section 10.5.  Typo.  s/warantee/warrantee/

Section 10.5.  Typo. s/requiments/requirements/

Section 11.0.  Typo. s/truely/truly/

Section 11.2.  Typo.  s/Retreival/Retrieval/

Section 11.2.  Typo.  s/occurance/occurrence/

Section 11.4. Typo.  s/Maintainance/Maintenance/

Section 11.4.  Typo.  s/environements/environments/