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

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 30 Mar 2020 17:03:32 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-anima-bootstrapping-keyinfra-39: 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 the updates leading to the -39; I believe we're almost there!

Unfortunately, it seems that the "pinned-domain-cert" in the issued voucher
is the registrar's cert, not the CA cert.  (Given that the documented workflow is
to extract this CA cert from the registrar-voucher-request CMS object, and the
registrar-voucher-request in our examples does include both the registrar cert
and the CA cert, I wonder if this reflects a bug in the code itself used to generate
the examples, in that it picks the wrong cert?)  My understanding is that the
protocol requires this field to be populated by a CA cert, and the registrar's
cert is not a CA cert.

I am very hopeful that we can just regenerate the voucher without having to
redo the rest of the examples, since we have all the keys and certificate enshrined
in the document already, and my apologies for not noticing whether this issue was
present in previous revisions as well.

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

I would make this a Discuss point but I think I already had my chance at the text and
missed it: Section C.1.5 says that "The public key is used by the registrar to find the MASA",
but it's really the certificate (via the "MASA URL" extension) and not the public key that
is so used.

I would suggest noting in C.2 that the asn1parse output is truncated at $number
columns, and specifically calling out that this makes it hard to differentiate between
organizationally related name components, specifically "highway-test.example.com CA"
and "highway-test.example.com MASA".  (The full asn1parse output from the live openssl
CLI is much clearer about the distinction.)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Mar 2020 22:10:52 -0400

> is the registrar's cert, not the CA cert.  (Given that the documented

That's entirely correct.
The thing in the voucher validates the TLS connection that the pledge sees.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 Mar 2020 16:19:35 +1300

I'm confused about something. It's my understanding that "Proposed Standard" means that a specification is generally stable, has resolved known design choices, is believed to be well-understood, has received significant community review, and appears to enjoy enough community interest to be considered valuable. However, further experience might result in a change or even retraction of the specification before it advances.

I'm rather baffled as to why BRSKI -39 doesn't meet that standard. It's not as if the authors are claiming that at least two independent and interoperable implementations from different code bases have been developed, for which sufficient successful operational experience has been obtained. If we are asking for Draft Standard status, we wouldn't be ready. But we're not; we're asking for Proposed Standard and it seems to me that the draft has met that standard since at least version -32 when the review team comments had been handled.

I'm not a security expert but I do believe that perfection is the enemy of the good.

Regards
   Brian Carpenter

On 31-Mar-20 15:10, Michael Richardson wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 31 Mar 2020 08:02:02 -0700

Hi Michael,

> The thing in the voucher validates the TLS connection that the pledge sees.

I'm not quite sure if the "that" that is entirely correct is intended to be
"the voucher artifact in the -39" or "pinned-domain-cert should be the CA
cert that signed the registrar's cert".

I agree that the primary role of the pinned-domain-cert is to validate the
provisional TLS connection to the registrar, but validating a TLS
connection can be done by indicating that any certificate in the chain is
trusted, from leaf/end-entity up to root CA.  If the pledge goes on to
perform full EST (which is currently listed as optional), then the exact
contents of the pinned-domain-cert don't matter in practice very much other
than validating the provisional TLS connection, but for the case where the
pledge stops after BRSKI and does not do full EST, having a domain CA
certificate seems much more useful than just knowing that the registrar's
end-entity certificate is trusted.

My interpretation of "pinned-domain-cert is always a CA certificate" seems
to have persistent support throughout the text:

Section 5.5.2:

   The registrar's certificate chain is extracted from the signature
   method.  The entire registrar certificate chain was included in the
   CMS structure, as specified in Section 5.5.  This CA certificate will
   be used to populate the "pinned-domain-cert" of the voucher being
   issued.

Section 5.6:

   pinned-domain-cert:  The domain CA cert.  See Section 5.5.2.  This
      figure is illustrative, for an example, see Appendix C.2

Section 5.6.2:

   The 'pinned-domain-cert' element of the voucher contains the domain
   CA's public key.  The pledge MUST use the 'pinned-domain-cert' trust
   anchor to immediately complete authentication of the provisional TLS
   connection.
   [...]
   The pinned-domain-cert MAY be installed as an trust anchor for future
   operations such as enrollment (e.g.  [RFC7030] as recommended) or
   trust anchor management or raw protocols that do not need full PKI
   based key management.  It can be used to authenticate any dynamically
   discovered EST server that contain the id-kp-cmcRA extended key usage
   extension as detailed in EST RFC7030 section 3.6.1; but to reduce
   system complexity the pledge SHOULD avoid additional discovery
   operations.  Instead the pledge SHOULD communicate directly with the
   [...]

but I'd be happy to learn why I'm misreading things.

As far as the bigger picture goes, I think that the BRSKI document as a
whole is essentially done, and only know of the last issues (noted in my
ballot position on the -39) that, given my current understanding of the
document, seems to be factual errors where the document is internally
inconsistent with itself.  Once they get resolved (whether by educating me
on my improper understanding or by updating the text), I expect to change
my ballot position to YES so the document can get approved for publication.
(With Ignas having cycled off the IESG, it currently does not have a YES.)
I am even willing to produce an updated example voucher artifact myself, if
that would help expedite things -- I believe I already have the needed
keys/certs locally from my review of the -39.  As an alternate option, if
more expedient, I could probably even accept just adding a note to the
example that says that the pledge goes on to perform full EST, so the
pinned-domain-cert is only needed to validate the provisional TLS
connection.

Please let me know if I'm missing anything here.

Thanks,

Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 31 Mar 2020 12:29:44 -0700

> keys/certs locally from my review of the -39.  As an alternate option, if

I think I managed to do this (though I didn't adjust my clock to try to
reproduce the signing time); attached.

-Ben

---

From: Eliot Lear <[email-masked]>
Date: Tue, 31 Mar 2020 21:58:35 +0200

Hi Ben,

> On 31 Mar 2020, at 21:29, Benjamin Kaduk <[email-masked]> wrote:
> 

Righto.  Now the point of discussion is whether that is the right thing to do.  If it is, then the example can change to that.  If it isn’t then the text you pointed to has to change.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Mar 2020 16:42:16 -0400

> to have persistent support throughout the text:

I see how you might conclude that the pinned-domain-cert is always a CA
certificate from the text, rather than being a trust-anchor that the pledge
is to use to validate the chain that it got.

It certainly can be a CA certificate. That does work, because when the
pledge puts it into it's trust-anchor list, the result is that it is able to
validate the TLS Server Certificate of the provisional TLS connection.
But, it has no RFC6125 process it can follow to validate a name.

It does not have to be *the* CA root certificate, it could be some
intermediate CA if such a thing existed (such as an Enterprise CA), and in
some cases, if this was a public trust root and there were no path
constraints, that might actually be *insecure*, since that would authenticate
any TLS connection.

I think that this means that the voucher would be able to validate any
owner within that public CA's list.  It's okay if it's a private CA.

Eliot says in the call:
      The pinned-domain-cert must include sufficient chain to validate the TLS
      connection.  This certificate must only be used for this purpose.
      Longer use trust anchors are retrieved as part of the EST /cacerts request.

My implementation of the MASA puts the EE certificate in which is as narrow
as one can be.  The Siemens implementation puts in the CA certificate, and we
interoperate because of how we treat this on the pledge.  Siemens has much
stronger supply chain restrictions though.

This is the diff that I would make.
I am most concerned about the difference in the voucher:

-        <t hangText="pinned-domain-cert:">The domain CA cert. See <xref
+        <t hangText="pinned-domain-cert:">The domain's EE cert. See <xref

Because this is too narrow rather than too wide now.

diff --git a/dtbootstrap-anima-keyinfra.xml b/dtbootstrap-anima-keyinfra.xml
index b800ec3..3bdf797 100644
--- a/dtbootstrap-anima-keyinfra.xml
+++ b/dtbootstrap-anima-keyinfra.xml
@@ -2143,11 +2143,11 @@ locator3  = [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]></artwork>
             The registrar's certificate chain is extracted from the signature
             method.  The entire registrar certificate chain was
             included in the CMS structure, as specified in <xref target="RequestVoucherFromMASA" />.
-            This CA certificate will be used to populate the
+            The EE certificate will be used to populate the
             "pinned-domain-cert" of the voucher being issued.
           </t>
           <t>
-            If this domain CA is unknown to the MASA, then it is to be
+            If this domain's CA is unknown to the MASA, then it is to be
             considered a temporary trust anchor for the rest of the steps
             in this section.  The intention is not to authenticate the
             message as having come from a fully validated origin, but
@@ -2377,7 +2377,7 @@ INSERT_TEXT_FROM_FILE example-voucher.json END
         <t hangText="assertion:">The method used to verify the relationship
         between pledge and registrar. See <xref
           target="MASAassertion"/>.</t>
-        <t hangText="pinned-domain-cert:">The domain CA cert. See <xref
+        <t hangText="pinned-domain-cert:">The domain's EE cert. See <xref
           target="MASApinned"/>. This figure is illustrative, for an example,
         see <xref target="exampleprocess" /></t>
         <t hangText="serial-number:">The serial-number as provided in the
@@ -2454,10 +2454,12 @@ INSERT_TEXT_FROM_FILE example-voucher.json END
         </section>
         <section anchor="PledgeAuthenticationOfProvisionalTLS"
                  title="Pledge authentication of provisional TLS connection">
-          <t>The 'pinned-domain-cert' element of the voucher contains the domain
-            CA's public key. The pledge MUST use the 'pinned-domain-cert' trust
-            anchor to immediately complete authentication of the provisional TLS
-            connection.</t>
+          <t>
+            The 'pinned-domain-cert' element of the voucher contains the
+            domain CA's issued EE certificate. The pledge MUST use the
+            'pinned-domain-cert' trust anchor to immediately complete
+            authentication of the provisional TLS connection.
+          </t>
           <t>If a registrar's credentials cannot be verified using the
             pinned-domain-cert trust anchor from the voucher then the TLS
             connection is immediately

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-