[Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 10 July 2019 16:14 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: anima@ietf.org
Delivered-To: anima@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7F512003E; Wed, 10 Jul 2019 09:14:59 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert <tte+ietf@cs.fau.de>, anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.3
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <156277529950.15124.2390956674545685683.idtracker@ietfa.amsl.com>
Date: Wed, 10 Jul 2019 09:14:59 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/mff9ZyGBk4EflTqYS6fENWOFRpI>
Subject: [Anima] Roman Danyliw's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Jul 2019 16:14:59 -0000
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/
- [Anima] Roman Danyliw's Discuss on draft-ietf-ani… Roman Danyliw via Datatracker
- Re: [Anima] Roman Danyliw's Discuss on draft-ietf… Michael Richardson
- Re: [Anima] Roman Danyliw's Discuss on draft-ietf… Michael Richardson
- Re: [Anima] Roman Danyliw's Discuss on draft-ietf… Michael Richardson
- Re: [Anima] Roman Danyliw's Discuss on draft-ietf… Michael Richardson
- Re: [Anima] Roman Danyliw's Discuss on draft-ietf… Michael Richardson
- Re: [Anima] Roman Danyliw's Discuss on draft-ietf… Max Pritikin (pritikin)
- Re: [Anima] Roman Danyliw's Discuss on draft-ietf… Roman Danyliw