Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-31: (with DISCUSS and COMMENT)

[Brian E Carpenter <[e-mail]>]

Michael, thanks for all your effort on this.

At this time my personal opinion is that the multiple reviews of this document are well above and beyond the threshold set by RFC 2026 for Proposed Standard status:
  "... generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable."

Regards
   Brian Carpenter

On 01-Jan-20 09:15, Michael Richardson wrote:
> 
> 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 <[e-mail]> 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   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [
> 
> 
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 
> 
> _______________________________________________
> Anima mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/anima
>