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

Michael Richardson <> Tue, 31 December 2019 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80052120013; Tue, 31 Dec 2019 12:15:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lfpRs3C-B_hf; Tue, 31 Dec 2019 12:15:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D707912001E; Tue, 31 Dec 2019 12:15:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1E52438981; Tue, 31 Dec 2019 15:15:40 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id A6E423FE; Tue, 31 Dec 2019 15:15:53 -0500 (EST)
From: Michael Richardson <>
To: Benjamin Kaduk <>
cc: "The IESG" <>,,,,
In-Reply-To: <>
References: <>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Tue, 31 Dec 2019 15:15:53 -0500
Message-ID: <5018.1577823353@localhost>
Archived-At: <>
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-31: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Dec 2019 20:15:58 -0000

A diff against -31 is at:
and will be posted as -32 in a few minutes.
Commit with edits here:

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


    > Email exchange with mcr notes:
    >> > An RFC Editor note about the RFC 8366 assignment of OID >
    >> 1.2.840.113549. was removed from -23 to -28; do the
    >> examples > properly use that assigned OID now?
    >> We got a MASA URL Extension OID for:
    >> 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.


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


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


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


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

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]


    > 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

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

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


    > 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   [
]        |   ruby on rails    [

Michael Richardson <>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-