[Anima] Benjamin Kaduk's Yes on draft-ietf-anima-bootstrapping-keyinfra-40: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Fri, 03 April 2020 01:56 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 A355A3A0BB3; Thu, 2 Apr 2020 18:56:14 -0700 (PDT)
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, anima-chairs@ietf.org, anima@ietf.org, Toerless Eckert <tte+ietf@cs.fau.de>, tte+ietf@cs.fau.de
X-Test-IDTracker: no
X-IETF-IDTracker: 6.123.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158587897464.26434.15420396933429472759@ietfa.amsl.com>
Date: Thu, 02 Apr 2020 18:56:14 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/r3gkikWLFuXbFmkldgxYJdRWJJI>
Subject: [Anima] Benjamin Kaduk's Yes on draft-ietf-anima-bootstrapping-keyinfra-40: (with 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, 03 Apr 2020 01:56:15 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-40: Yes

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/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for putting in all the work to get this over the finish line!
I did a final read-through before entering my YES, which produced some
non-blocking comments.

Section 5.1

   The signatures in the certificate MUST be validated even if a signing

nit: just "signature" singular?

Section 5.2

   assertion:  The pledge indicates support for the mechanism described
      in this document, by putting the value "proximity" in the voucher-
      request, and MUST include the "proximity-registrar-cert" field
      (below).

Sorry if I asked this already, but is the "MUST include" only when the
"proximity" assertion is used?  The current text could be read that it
applies always.

Section 5.4

It's too bad we can't mention SCRAM in addition to Basic and Digest, but I
guess that ship has sailed.

Section 5.5

   The voucher media type "application/voucher-cms+json" is defined in
   [RFC8366] and is also used for the registrar voucher-request.  It is
   a JSON document that has been signed using a CMS structure.  The
   registrar MUST sign the registrar voucher-request.
   [...]
   [...]
   [...]
   MASA impementations SHOULD anticipate future media types but of
   course will simply fail the request if those types are not yet known.

I think these two paragraphs were originally next to each other but with the
large amount of intervening text it seems like the transition could be
improved.

Section 5.5.2

   A certificate chain is extracted from the Registrar's signed CMS
   container.  This chain may be as short as a single End-Entity

(I guess technically the CMS structure is an unordered set of certificates,
not a chain, but we're using it as a chain so I don't mind this usage.)

   The MASA MAY use the highest certificate from the certificate chain
   that it received from the Registrar, as determined by MASA policy.  A

"highest certificate" is not a particularly common usage; "farthest in the
chain from the end entity" might be more conventional.

Section 5.5.3

   As described in Section 5.5.2, the MASA has extracted Registrar's
   domain CA.  This is used to validate the CMS signature ([RFC5652]) on
   the voucher-request.

   Normal PKIX revocation checking is assumed during voucher-request
   signature validation.  This CA certificate MAY have Certificate
   Revocation List distribution points, or Online Certificate Status
   Protocol (OCSP) information ([RFC6960]).  If they are present, the

We could maybe wordsmith this a bit to only cover the case when the
pinned-domain-cert is a CA cert (vs. end entity).

Section 5.5.4

This section mentions that checking for the presence of id-kp-cmcRA in the
registrar's cert protects the domain in some cases, but that protection is
probably weakend in cases when the pinned-domain-cert is not the domain's
root CA.  That said, the failure mode is not catastrophic, since the
registrar still has to authenticate to the MASA somehow, and the MASA logic
can account for the different cases.

Section 5.6

   correct registrar, the pledge MUST NOT follow more than one
   redirection (3xx code) to another web origins.  EST supports

s/web origins/web origin/

Section 5.6.1

 missing close parenthesis for "(according to local policy[...]"

Section 5.8.2

   The domainID is determined from the certificate chain associated with
   the pinned-domain-cert and is used to update the audit-log.

Is it determined from the "chain associated with" or just the
"pinned-domain-cert" itself?

Section 7.1

   Join Proxy:  Provides proxy functionalities but is not involved in
      security considerations.

The Join Proxy is not involved in crypto, as noted here, but could drop or
delay traffic.

Section 7.3

       X.509 IDevID factory installed credential.  New Entities without
       an X.509 IDevID credential MAY form the Section 5.2 request using
       the Section 5.5 format to ensure the pledge's serial number
       information is provided to the registrar (this includes the
       IDevID AuthorityKeyIdentifier value, which would be statically
       configured on the pledge.)  The pledge MAY refuse to provide a

It's not entirely clear to me why "(this includes the IDevID
AuthorityKeyIdentifier value" holds (it's not in the idevid-issuer, I
think), but if it's clear to others that's fine.

Section 9.1.1

   full sales channel integration where Domain Owners need to be
   positively identified by TLS Client Certicate pinned, or HTTP

I'm not sure if this was intended to be "by a pinned TLS Client Certificate" or
"by the pinned-domain-cert".

Section 10.3

It looks like the second paragraph may be an editing remnant (copy of text
being modified in the first paragraph).

Section 11.6.2.1

I guess the vouchers created by an attacker with access to the MASA signing
key would not necessarily be in the audit log, which is probably worth
mentioning.

Appendix B

   Discovery of registrar MAY also be performed with DNS-based service
   discovery by searching for the service "_brski-
   registrar._tcp.<domain>".  In this case the domain "example.com" is
   discovered as described in [RFC6763] section 11 (Appendix A.2
   suggests the use of DHCP parameters).

Is there a mismatch between "<domain>" and "example.com"?