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

[Kathleen Moriarty <[e-mail]>]

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 <[e-mail]> wrote:

> 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 <[e-mail]> wrote:
>
>> 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=
>> [e-mail]> wrote:
>>
>>> 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 <[e-mail]> 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 <[e-mail]>
>>>> *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).
>>>>
>>>>
>>>>
>>>> I would support removing the paragraph.
>>>>
>>>>
>>>>
>>>> On Tue, Jul 28, 2020 at 7:57 AM Kathleen Moriarty <
>>>> [e-mail]> wrote:
>>>>
>>>> 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 <[e-mail]> 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
>>>> <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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/acme
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>> Best regards,
>>>>
>>>> Kathleen
>>>>
>>>> _______________________________________________
>>>> Acme mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/acme
>>>>
>>>> _______________________________________________
>>>> Acme mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/acme
>>>>
>>> _______________________________________________
>>> Acme mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>>

-- 

Best regards,
Kathleen