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

Michael Richardson <> Fri, 01 November 2019 19:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 75BD812007A; Fri, 1 Nov 2019 12:48:04 -0700 (PDT)
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 4dui_IzXiGGT; Fri, 1 Nov 2019 12:48:01 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 437DA1201CE; Fri, 1 Nov 2019 12:47:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 31E633818F; Fri, 1 Nov 2019 15:45:06 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 3372DA0; Fri, 1 Nov 2019 15:47:54 -0400 (EDT)
From: Michael Richardson <>
To: Benjamin Kaduk <>
cc: The IESG <>,, Toerless Eckert <>,,
In-Reply-To: <>
References: <> <25780.1571775837@localhost> <>
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: Fri, 01 Nov 2019 15:47:54 -0400
Message-ID: <26670.1572637674@localhost>
Archived-At: <>
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT) [COMMENTS]
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: Fri, 01 Nov 2019 19:48:05 -0000

I may post this as -30 on Monday, or I may wait as your requested changes are

Benjamin Kaduk <> wrote:
    >> The original purpose of the subjectKeyIdentifier was to indicate which
    >> keypair the client (pledge) had attempted to enroll. Upon successful
    >> enrollment, a new TLS connection is started (usually), which proves that the
    >> enrollment is success, and so no KeyIdentifier is needed.
    >> In the case of a failure, the existing TLS connection is maintained, so
    >> the server (Registrar) can associate the failure with the previous attempt
    >> to enroll.
    >> This change (removing the subjectKeyIdentifier) was made in -05, but the
    >> prose was not updated. The use of a subjectKeyIdentifier, which might no
    >> longer be a SHA-1 hash of a public key, is problematic, as the CSR does
    >> not include an appropriate KeyIdentifier, so the server would be left
    >> trying to calculate it, using the default (and now obsolete) SHA-1
    >> mechanism. Including the KeyIdentifier has proved more trouble than
    >> benefit.

    > The removal of SKI seems okay, but I'm still looking for something like
    > "the body of the POST is a JSON object with the following [whoops, I forget
    > the right terminology for name/value pairs]"

I have added some text, and some CDDL.
+   enrollstatus-post = {
+       "version": uint,
+       "status": bool,
+       "reason": text,
+       ? "reason-context" : { $$arbitrary-map }
+     }
+   }
+                Figure 18: CDDL for enrollment status POST

    >> Esko has complained that we have 14 open issues; that's probably negligence
    >> on my part about not closing them as we solved the issues.
    >> So we also closed all but three "auth48" tickets that had been opened.
    >> > Section 2.5.1
    >> >    The pledge is the device that is attempting to join.  The pledge can
    >> > talk to the Join Proxy using link-local network connectivity.  In most
    >> > cases, the pledge has no other connectivity until the pledge completes
    >> > the enrollment process and receives some kind of network credential.
    >> > I'd consider s/can talk to/is assumed to talk to/.
    >> okay.  some have complained this isn't strong enough.
    >> Maybe MUST talk to?

    > I don't have a strong opinion on this, but it feels like something that
    > will probably be different for ACP vs. other deployments -- MUST feels
    > right for ACP but is probably not universal.

I am leaving the text as I put it above.

    >> > How painful would it be to require 1.3 at this point?  RFC 8446 has
    >> > been out for more than a year, and the TLS WG is leaning on me to
    >> > tighten up on this...
    >> Yes, but how many FIPS-140 validated TLS 1.3 implementations are there that
    >> are drop-in available to router platforms with 3-5 year R&D cycles?
    >> OpenSSL is FIPS for 1.0.1 and 1.0.2 which do not include TLS 1.3, for
    >> instance (which is 1.1.x).

    > I take it that FIPS-140 validation is required for those $100k BFRs, then?

That's what implementers said awhile ago.

    >> WolfSSL has FIPS-140 for TLS 1.3 (to read the press releases), and some
    >> entities could drop it in, but others might have license issues.
    >> How about if I change the text to say:
    >> Use of TLS 1.3 (or newer) is encouraged.
    >> TLS 1.2 or newer is REQUIRED on the Pledge side.
    >> TLS 1.3 (or newer) SHOULD be available on the Registrar server interface,
    >> and the Registrar client interface, but TLS 1.2 MAY be used.
    >> TLS 1.3 (or newer) SHOULD be available on the MASA server interface, but TLS
    >> 1.2 MAY be used.

    > That's an okay compromise on the 1.3-encouragement front, but I don't think
    > that everyone will read "Foo server interface" and "Foo client interface"
    > in the same way.


    > editorial nits on the linked diff:

    > Section 2.5.3 talks about the set of MASA that are trusted being limited
    > by the MASA TA database, but in the paragraph about the BRSKI-EST client
    > TA database.

2.5.3.  Domain Registrar

   The registrar uses an Implicit Trust Anchor database for
   authenticating the BRSKI-MASA connection's MASA TLS Server
   Certificate.  Configuration or distribution of trust anchors is out-
   of-scope for this specification.

   The registrar uses a different Implicit Trust Anchor database for
   authenticating the BRSKI-EST connection's Pledge TLS Client
   Certificate.  Configuration or distribution of the BRSKI-EST client
   trust anchors is out-of-scope of this specification.  Note that the
   trust anchors in/excluded from the database will affect which
   manufacturers' devices are acceptable to the registrar as pledges,
   and can also be used to limit the set of MASAs that are trusted for

I'm not seeing the issue.  We split up paragraphs to clarify things, but
maybe we failed.

    > s/described Appendix B/described in Appendix B/ (sorry, section number
    > not visible from diff; maybe 40% through the diff)


    > Section 5.4 is missing an "for" in "SHOULD be used for authentication of
    > the MASA".


    > s/accesptable/acceptable/


    > Figure 17 is introduced as an "abstract example", though it seems more
    > of a concrete one after this diff.


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