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

From: Eliot Lear <[email-masked]>
Date: Fri, 3 Apr 2020 08:49:59 +0200

Dear Max,

It has taken quite a while, but I want to congratulate you and your coauthors, particularly Michael Richardson.  With Ben Kaduk’s “YES” vote, we can now expect to see an approval announcement issued from the IETF Secretariat for BRSKI.  This is a very novel use of existing technology that took approximately six years to reach this point, and has been adapted by a number of companies as a means to onboard IoT devices.  In putting forward your ideas, you not only demonstrated innovation, but also the need for follow-up work.  I hope you will continue to engage in such areas as early discovery and registration of the MASA, offline use cases, and the latter part of the development cycle.

As you can see below, there are small nits remaining, but I suspect these will be covered during AUTH48 or as a quick revision just prior to the approval announcement.

Best wishes,

Eliot

> Begin forwarded message:
> 
> From: Benjamin Kaduk via Datatracker <[email-masked]>
> Subject: [Anima] Benjamin Kaduk's Yes on draft-ietf-anima-bootstrapping-keyinfra-40: (with COMMENT)
> Date: 3 April 2020 at 03:56:14 CEST
> To: "The IESG" <[email-masked]>
> Cc: [email-masked], [email-masked], [email-masked], [email-masked]
> Reply-To: Benjamin Kaduk <[email-masked]>
> 
> 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"?
> 
> 
> 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima