[Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-31: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Fri, 20 December 2019 22:31 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 B94591200C1; Fri, 20 Dec 2019 14:31:11 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk 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.114.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <157688107174.4079.10454309821544008060.idtracker@ietfa.amsl.com>
Date: Fri, 20 Dec 2019 14:31:11 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/uKhleBhgUpFGY3mWNmbx0zHDeqE>
Subject: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-31: (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: Fri, 20 Dec 2019 22:31:12 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-31: 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: ---------------------------------------------------------------------- Thanks for providing a clear specification of the /enrollstatus EST endpoint in the -30. The following two points still seem unaddressed, though. The -29 reworks the definition of the 'nonce' field to be: strong random or pseudo-random number nonce (see [RFC4086] section 6.2). As the nonce is usually generated very early in the boot sequence there is a concern that the same nonce might generated across multiple boots, or after a factory reset. Difference nonces MUST NOT generated for each bootstrapping attempt, whether in series or concurrently. The freshness of this nonce mitigates against the lack of real-time clock as explained in Section 2.6.1. This needs to either be "Different nonces MUST be generated" or "the same nonce MUST NOT be reused"; this mashup is no good. Email exchange with mcr notes: > > An RFC Editor note about the RFC 8366 assignment of OID > > 1.2.840.113549.1.9.16.1.40 was removed from -23 to -28; do the examples > > properly use that assigned OID now? > > We got a MASA URL Extension OID for: > 1.3.6.1.5.5.7.1.32 > > the examples date from before that, and do not use it yet. We need to fix the examples before publication. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few new comments on the -30 and -31 to start. I think some of my comments on the -29 are still valid, and will try to remove ones that have been addressed. To reiterate: to the best of my knowledge, all the comments in this ballot position are actionable and have not been overtaken by events. In Section 5.9.4: In the case of a FAIL, the same TLS connection MUST be used. The Reason string indicates why the most recent enrollment failed. I'd suggest something more like "In the case of a failed enrollment, the client MUST send the telemetry information over the same TLS connection that was used for the enrollment attempt, with a Reason string indicating why the most recent enrollment failed. (For failed attempts, the TLS connection is the most reliable way to correlate server-side information with what the client provides.)" (Also, why is "FAIL" capitalized?) Thanks for the text in Section 11.2 about second-preimage-resistance of DomainID calculation; the grammar needs a tweak or two, though. My suggestion would be to either drop "The consequences of" or add "be to" to make "would be to allow" (but not both). Section 11.3 has gone back to just "Devices which are reset to factory default in order to perform a second bootstrap with a new owner MUST NOT use idential seeds", but I think it's important to be clear about what the scope of uniqueness is. The text in Section 5.2 is pretty good in this regard, with respect to the nonces (which are generally derived from the seed); I wonder if we might want to restructure this text to be more like "The random seed used by a device at boot MUST be unique across all devices and all bootstraps. Resetting a device to factory default state does not obviate this requirement." (FWIW, I think the text in the -29 was that way because of my request.) [A few comments on the -29, some of which I think might be repeats of ones I made on a WIP interim draft; sorry if I say something again that was already debunked. The comment section from the -28 is preserved later.] In Section 3.3, we now cite RFC 4648; I note that RFC 4648 specifies both base64 and base64url, so a section reference is usually appropriate (and in Section 5 we do give a section reference into RFC 4648). Section 9.1 Other use cases likely have similar, but MAY different requirements. nit: ", but MAY have different, requirements" Section 9.1.1 Authentication process. The MASA creates signed voucher artifacts according to a it's internally defined policies. nit: s/a it's/its/ Section 9.1.3 (Do we need to say "DULL" specifically again here for Join Proxy discovery? Maybe not...) [All new comments for the -28] Please respond to the secdir re-review. Section 2.6.1 A pledge with a real time clock in which it has confidence in, MUST check the above time fields in all certificates and signatures that it processes. nit: s/in// from "in which it has confidence in" (your choice which one). Section 4 This section applies is normative for uses with an ANIMA ACP. The nit: pick one of "applies to" or "is normative for". [...] The use of GRASP mechanism part of the ACP. Other users of BRSKI will need nit: missing "is", "the" Section 5.7 The Status field indicates if the voucher was acceptable. Boolean values are acceptable. nit: I suggest """acceptable, as a boolean, where "true" indicates the voucher was acceptable""". Section 10.6 Section Section 7.4.3 describes some ways in which a manufacturer nit: duplicate "Section". Section 10.7 existing products. Said products might be previous deployed and need to be re-initialized, purchased used, or just kept in a warehouse as long-term spares. nit: s/previous deployed and need/previously deployed that need/ Section 11.2 In particular implementations should pay attention to the advance in [RFC4086] section 3, particulary section 3.4. Devices which are reset to factory default in order to perform a second bootstrap with a new owner MUST NOT seed their random number generators in the same way. nit: s/same way/same way across bootstraps/ Section 11.3 We had some discussion around my previous comment: % Additionally, in order to successfully use the resulting voucher the % Rm would have to attack the pledge and return it to a bootstrapping % enabled state. This would require wiping the pledge of current % % ... and I think there is a different attack if the Rm is in a position % to delay or drop network traffic between the pledge and the intended % registrar, to cause Rm's voucher to be delivered first even though it is % generated after the intended registrar's authorization process. The % intended registrar would need to require reports on voucher processing % status (or investigate their absence) in order to detect such a case. but I can't remember if we decided that we didn't need to discuss the risk in the document. [ed. I also can't remember if we had discussion about this comment] ======================================================================= I trimmed all the "Additional comments since posted ballot position on -28" that were in my previous ballot position, as they are likely stale by now.
- [Anima] Benjamin Kaduk's Discuss on draft-ietf-an… Benjamin Kaduk via Datatracker
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Michael Richardson
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Brian E Carpenter
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Benjamin Kaduk
- Re: [Anima] Benjamin Kaduk's Discuss on draft-iet… Warren Kumari