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