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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Fri, 20 Dec 2019 14:31:11 -0800

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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Dec 2019 15:15:53 -0500

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.

    > Thanks for providing a clear specification of the /enrollstatus EST
    > endpoint in the -30.  The following two points still seem unaddressed,
    > though.

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

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

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

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

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

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

    > nit: ", but MAY have different, requirements"

fixed.

    > nit: s/a it's/its/

fixed.

    > (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/

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

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

    > voucher was acceptable""".

already fixed.

    > nit: duplicate "Section".

already fixed.

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

    > [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.

    > % 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.

    > 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-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 1 Jan 2020 10:08:23 +1300

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:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>