A diff against -31 is at: https://tinyurl.com/vuls2ge and will be posted as -32 in a few minutes. Commit with edits here: https://github.com/anima-wg/anima-bootstrap/commit/0bdd9aaf206b0f2d70c51a7c9636a8249fd1366f
BTW: I haven't heard from Roman since IETF107. I am also converting to v3 format now, so there are some slight formatting changes. (*->o, some extra spaces in places) I have addressed all of your comments, and I've checked that all the -29 comments have been addressed. Benjamin Kaduk via Datatracker <[email protected]> wrote: > ---------------------------------------------------------------------- > 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. Fixed. > 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. Yes, I believe that there will be time to update them while in RFC editor queue. I want the examples to be produced by code that has interoperated. > ---------------------------------------------------------------------- > 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. okay. > 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?) I have used your text. The fail was capitalized because bold is not available. Further down, we capitalize SUCCESS. > 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). Done. > 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.) Done. > 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). okay, section 4 is "base64", added. > Section 9.1 > Other use cases likely have similar, but MAY different requirements. > nit: ", but MAY have different, requirements" fixed. > 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/ fixed. > Section 9.1.3 > (Do we need to say "DULL" specifically again here for Join Proxy > discovery? Maybe not...) yes, I think that we need to say this again, as many people get upset about having a full GRASP daemon visible on the insecure side. > [All new comments for the -28] rechecking. > Please respond to the secdir re-review. This is in message: to recap: 1) 10.3, "The so-called "call-home" mechanism that occurs as part of the was toned down. 2) the TLS 1.3 text was already improved. 3) section 5.4.1, "This document does not make a specific recommendation" (regarding whether to use public PKI, DANE, or pinned certificates for MASA authentication. I don't think we can make a statement about the needs here at this point, and why we have the PS->IS step. Note that I wrote https://datatracker.ietf.org/doc/draft-richardson-anima-registrar-considerations/ > 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). I see now, fixed. > Section 4 > This section applies is normative for uses with an ANIMA ACP. The > nit: pick one of "applies to" or "is normative for". already fixed. > [...] The use of GRASP mechanism part of the ACP. Other users of > BRSKI will need > nit: missing "is", "the" fixing. > 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""". already fixed. > Section 10.6 > Section Section 7.4.3 describes some ways in which a manufacturer > nit: duplicate "Section". already fixed. > 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/ already fixed. > 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/ already fixed with different text. > 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] We did. We worked hard to create the Rm attack situation, and had to assume some other failures to even get to this discussion. I think that this follows into the "if these ten unlikely things all occur, then you should consider if you are living in simulation" category. > ======================================================================= > 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. Thank you.
-- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
