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

[Michael Richardson <[e-mail]>]

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 =-