Subject: Re: [Acme] CAA in draft-ietf-acme-client-01.txt

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 28 Jul 2020 10:56:45 -0400

Hello Carl,

Thank you for your review and I apologize for my extremely tardy response.

On Mon, May 18, 2020 at 11:41 AM Carl Mehner <[email-masked]> wrote:

> Looking at the latest draft for acme-client, I noticed that it mentions
> CAA:
>    CAA helps as anyone verifying a certificate used for code signing can
>    verify that the CA used has been authorized to issue certificates for
>    that organization.
>
> However, in the CAA RFC it states:
>    Relying Applications MUST
>    NOT use CAA records as part of certificate validation.
>
> I propose removing the statement in acme-client about CAA that is quoted
> above.
>

I recall having gone through this conversation before to wind up where the
draft is now.  RFC8555 has the following:

      caaIdentities (optional, array of string):  The hostnames that the
      ACME server recognizes as referring to itself for the purposes of
      CAA record validation as defined in [RFC6844
<https://tools.ietf.org/html/rfc6844>].  Each string MUST
      represent the same sequence of ASCII code points that the server
      will expect to see as the "Issuer Domain Name" in a CAA issue or
      issuewild property tag.  This allows clients to determine the
      correct issuer domain name to use when configuring CAA records.

 Section 9.7.8 has the following:

   Validation methods do not have to be compatible with ACME in order to

   be registered.  For example, a CA might wish to register a validation
   method to support its use with the ACME extensions to CAA [ACME-CAA
<https://tools.ietf.org/html/rfc8555#ref-ACME-CAA>].

Section 11.2 has the following:

   An ACME-based CA must only use a resolver if it trusts the resolver
   and every component of the network route by which it is accessed.
   Therefore, it is RECOMMENDED that ACME-based CAs operate their own
   DNSSEC-validating resolvers within their trusted network and use
   these resolvers both for CAA record lookups and all record lookups in

       furtherance of a challenge scheme (A, AAAA, TXT, etc.).

As you point out, https://tools.ietf.org/html/rfc6844, advises against its
use.

I am happy to edit to consensus.  If a change is needed, I can turn that
around quickly.

Best regards,
Kathleen

-carl mehner
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

-- 

Best regards,
Kathleen

---

From: Roland Shoemaker <[email-masked]>
Date: Tue, 28 Jul 2020 12:27:15 -0700

I think the disconnect here is between CAs and Relying Applications (i.e.
browsers) using CAA. The CA should use CAA to validate if they have
authority to issue, but the relying application must not because the CAA
records are only applicable at the time of issuance and there is no
guarantee that the current CAA records may match the records that were
present in the past (i.e. I may set my CAA record to allow "example-ca",
issue a certificate, and then set my CAA record to an empty string to
prevent issuance from anyone, the check is valid at the time of issuance,
but anyone trying to do post-issuance validation would fail since the
record has changed).

I would support removing the paragraph.

On Tue, Jul 28, 2020 at 7:57 AM Kathleen Moriarty <
[email-masked]> wrote:

>       CAA record validation as defined in [RFC6844 <https://tools.ietf.org/html/rfc6844>].  Each string MUST
>    method to support its use with the ACME extensions to CAA [ACME-CAA <https://tools.ietf.org/html/rfc8555#ref-ACME-CAA>].
>
>
> As you point out, https://tools.ietf.org/html/rfc6844, advises against
> its use.
>

---

From: <[email-masked]>
Date: Tue, 28 Jul 2020 19:57:21 +0000

Roland,

Thank you, that’s very helpful  Any other opinions?  I’m very happy to delete with consensus and appreciate the reviews on this particular issue as well as on the draft.

Best regards,
Kathleen

From: Roland Shoemaker <[email-masked]>
Sent: Tuesday, July 28, 2020 3:27 PM
To: Kathleen Moriarty
Cc: Carl Mehner; Moriarty, Kathleen; IETF ACME
Subject: Re: [Acme] CAA in draft-ietf-acme-client-01.txt

[EXTERNAL EMAIL]
I think the disconnect here is between CAs and Relying Applications (i.e. browsers) using CAA. The CA should use CAA to validate if they have authority to issue, but the relying application must not because the CAA records are only applicable at the time of issuance and there is no guarantee that the current CAA records may match the records that were present in the past (i.e. I may set my CAA record to allow "example-ca", issue a certificate, and then set my CAA record to an empty string to prevent issuance from anyone, the check is valid at the time of issuance, but anyone trying to do post-issuance validation would fail since the record has changed).

On Tue, Jul 28, 2020 at 7:57 AM Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
Hello Carl,

On Mon, May 18, 2020 at 11:41 AM Carl Mehner <[email-masked]<mailto:[email-masked]>> wrote:
Looking at the latest draft for acme-client, I noticed that it mentions CAA:
   CAA helps as anyone verifying a certificate used for code signing can
   verify that the CA used has been authorized to issue certificates for
   that organization.

I propose removing the statement in acme-client about CAA that is quoted above.

I recall having gone through this conversation before to wind up where the draft is now.  RFC8555 has the following:

      CAA record validation as defined in [RFC6844<https://tools.ietf.org/html/rfc6844>].  Each string MUST

   method to support its use with the ACME extensions to CAA [ACME-CAA<https://tools.ietf.org/html/rfc8555#ref-ACME-CAA>].

As you point out, https://tools.ietf.org/html/rfc6844, advises against its use.

I am happy to edit to consensus.  If a change is needed, I can turn that around quickly.

Best regards,
Kathleen

-carl mehner

_______________________________________________
Acme mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/acme

--

Best regards,
Kathleen
_______________________________________________
Acme mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/acme

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 28 Jul 2020 16:12:14 -0400

RFC 6844 Section 4.1 points out that logged DNSSEC-signed CAA records can
be used when auditing CAs for mis-issuance.  The current draft says "CAA
helps as anyone ... can verify that the CA used has been authorized", which
is true, but only if "anyone" has access to a log of the signed CAA records
used by the CA, and the domain is DNSSEC-signed.

I would like it if CAs published such logs, but I don't know whether it is
a common practice.

On Tue, Jul 28, 2020 at 3:58 PM <[email-masked]> wrote:

> Roland,
>
>
>
> Thank you, that’s very helpful  Any other opinions?  I’m very happy to
> delete with consensus and appreciate the reviews on this particular issue
> as well as on the draft.
>
>
>
> Best regards,
>
> Kathleen
>
>
>
> *From:* Roland Shoemaker <[email-masked]>
> *Sent:* Tuesday, July 28, 2020 3:27 PM
> *To:* Kathleen Moriarty
> *Cc:* Carl Mehner; Moriarty, Kathleen; IETF ACME
> *Subject:* Re: [Acme] CAA in draft-ietf-acme-client-01.txt
>
>
>
> [EXTERNAL EMAIL]
>

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 29 Jul 2020 11:18:33 -0400

Ben: This text was intended towards auditors, and is indeed part of the
ongoing logging requirements imposed on CA. While it’s easy to imagine a
hypothetical world of CAA transparency and talk of it as if it was a thing,
there are a number of real and practical operational challenges that make
it more than “just” a log, particularly given the time-bounded nature of
DNSSEC validity and cryptographic material.

The text in the draft, as is, is problematic, because that’s not been the
goal of CAA, and using it in such a manner, particularly clients, would be
actively harmful to the security value and deployability of CAA, and
further makes migration CAs unnecessarily difficult. This was a hugely
contentious barrier towards the deployment and requirement of CAA support
by CAs, and would have obvious lasting security harm.

Concretely, imagine at Time 0, my CAA record says “foo.example”, and a
certificate with a validity period of 100 is issued. At Time 10, I cease
doing new business with Foo CA, and transition to Bar CA, with CAA record
of “bar.example”

If clients check CAA, I would have to continue to permit Foo to be able to
issue new certificates from T=10 to T=100 in order to continue to use my
existing certificates. Further, I would have no technical means of
disclaiming or proving any misissuance; e.g. due to Foo using validation
methods my organization did not wish to use, because my organization could
not adequately secure them. In such a world, it would be “my” fault, while
CAA provided a way to shift that burden to the CA performing the validation.

This doomsday scenario doesn’t even require “most” clients to do so; just
“enough” and the interoperability risk of CAA would be too great and the
only obvious answer would be to not deploy it.

In code signing, this is even more pronounced, because although the
validity period is T=0 to T=100, code signing that delegates to third party
CAs, as opposed to directly administered by the vendor, tends to
counter-sign such signatures with a timestamp, so that the signed artifact
can be used outside of its validity period. If the counter-signer checked
CAA, you “only” have to worry about keeping CAA around for [T=10, T=100],
but if the client verified CAA, you’d have to keep it around for [T=10,
T=infinity] in order to keep that artifact valid.

As Roland states, CAA is between a site, the CA, and whomever supervises
that CA (e.g. auditors, supervisory bodies, etc). It provides a form of
dispute resolution about whether a certificate was authorized at the time
it was issued, in a consistent and interoperable way. The logs maintained
by CAs are primarily there to aid in that direct dispute resolution, which
is an inherently fuzzy and human process for what is expected to be a truly
exceptional situation, and anything more generic/more broadly would require
significantly greater complexity and design before it could be said to meet
any verification goals.

I support the paragraphs removal.

On Tue, Jul 28, 2020 at 4:12 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

>> I recall having gone through this conversation before to wind up where
>> the draft is now.  RFC8555 has the following:
>>
>> As you point out, https://tools.ietf.org/html/rfc6844
>> <https://tools.ietf..org/html/rfc6844>, advises against its use.
>>
>>
>>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 29 Jul 2020 12:39:29 -0400

Thanks for the explanation.  I certainly agree that the paragraph as
written is incorrect: fetching the CAA record from the DNS, and attempting
to use it for validation, is not possible.  Removing the paragraph seems
fine to me.

My point was mostly that CAA transparency (even without any automation)
could be interesting, but this draft probably isn't the place to speculate
on that.

On Wed, Jul 29, 2020 at 11:19 AM Ryan Sleevi <[email-masked]> wrote:

> disclaiming or proving any misissuance; e.g.. due to Foo using validation
>> helps as anyone .... can verify that the CA used has been authorized",
>> which is true, but only if "anyone" has access to a log of the signed CAA
>> records used by the CA, and the domain is DNSSEC-signed.
>>
>> I would like it if CAs published such logs, but I don't know whether it
>> is a common practice.
>>
>>> I think the disconnect here is between CAs and Relying Applications
>>> (i.e. browsers) using CAA. The CA should use CAA to validate if they have
>>> <https://tools.ietf...org/html/rfc6844>, advises against its use.
>>>
>>>
>>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 29 Jul 2020 13:17:16 -0400

Thank you all for the good discussion.  It seems like a solid discussion
and reasoning towards removing the paragraph.  I'll post a new version soon.

Best regards,
Kathleen

On Wed, Jul 29, 2020 at 12:39 PM Ben Schwartz <[email-masked]> wrote:

>> If clients check CAA, I would have to continue to permit Foo to be able
>> to issue new certificates from T=10 to T=100 in order to continue to use my
>>> RFC 6844 Section 4.1 points out that logged DNSSEC-signed CAA records
>>> can be used when auditing CAs for mis-issuance.  The current draft says
>>> "CAA helps as anyone .... can verify that the CA used has been authorized",

-- 

Best regards,
Kathleen