1398427 - Let's Encrypt: CAA Misissuances

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Andrew Ayer]

I just reported the following to [e-mail]:

Let's Encrypt has issued the following certificates in violation of the
Baseline Requirements' CAA checking requirement: 

1. https://crt.sh/?sha256=C396951C4C594897BE11B09494DD567B00A0A946735F3DECC01A9D966A179F41
2. https://crt.sh/?sha256=435F08B5A9536E2B8F91AB8970FF9F8D93A1A0A5529C2D8388A10FA59FF3758C

Certificate 1 contains a single DNS identifier for
cname-deny-sub.basic.caatestsuite.com.  The following DNS records
are relevant:

cname-deny-sub.basic.caatestsuite.com. IN CNAME sub.deny.basic.caatestsuite.com.

deny.basic.caatestsuite.com. IN CAA 0 issue "caatestsuite.com"

There is no CAA record at sub.deny.basic.caatestsuite.com.  According to
RFC 6844, the only CA allowed to issue for cname-deny-sub.basic.caatestsuite.com
is caatestsuite.com.

Certificate 2 contains a single DNS identifier for
expired.caatestsuite-dnssec.com.  This DNS name has no CAA record, but at
the time I requested an authorization for it (Sat Sep  9 03:07:05 2017 UTC),
the RRSIGs for expired.caatestsuite-dnssec.com were expired.

It appears from https://unboundtest.com/ that Let's Encrypt's DNS resolver
does not consider expired DNSSEC signatures to be an error.  This violates
RFC 4033 Section 8.1:

"The signatures associated with signed zone data are only valid for the
time period specified by these fields in the RRSIG RRs in question."

and RFC 4034 Section 3.1.5:

"The RRSIG record MUST NOT be used for authentication prior to the
inception date and MUST NOT be used for authentication after the
expiration date."

Therefore, the CAA record lookup for this DNS name should fail and since
there is a DNSSEC validation chain from this zone to the ICANN root,
this failure cannot be treated by the CA as permission to issue.

Comment 1

[Kathleen Wilson]

Josh,

Please update this bug promptly to indicate acknowledgement of the problem and a timeline for resolving the immediate problem.

Then provide an incident report in this bug, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 2

[Josh Aas]

We received an email about this on Friday September 8 at 10:04pm Pacific. Within 24 hours of receiving the report we:

* investigated both reported compliance issues
* confirmed certificate details and revoked both certificates in question
* deployed all necessary fixes to our production infrastructure
* communicated the results of our investigation to the reporter

With the exception of any necessary wider communication, we consider the matter closed.

Regarding Certificate #1
========================

We are aware that the observed behavior is technically non-compliant, however:

* We believe our behavior is preferable and that the CA community generally agrees.
* We believe the BRs will be amended soon to make our current behavior compliant.
* We believe root programs will not have an issue with our current behavior.
* We believe a short-term change in longstanding behavior may be confusing to subscribers.
* We believe fixing this short-term will create unnecessary code churn, which introduces risk.

So long as a ballot to fix the BRs is proceeding, or until a root program objects, we are not planning to change our behavior in this regard. We will revoke certificates for this issue if requested in good faith by the subscriber.

If Mozilla would like us to change our behavior please let us know as soon as possible. We advise against it.

Regarding Certificate #2
========================

Our resolver accepted the expired response because by default it allowed for some clock skew (i.e. there was an expiration grace period). Within 24 hours of the initial report we deployed a change to our production environment that eliminates the clock skew allowance.

Comment 3

[Josh Aas]

On Thursday September 14 between 10am and 11am Pacific Let's Encrypt deployed a change bringing our CAA checking algorithm into compliance.

Since deploying that change we have received numerous reports of problems due to the compliant but problematic algorithm and we expect problems to mount as certificate renewal cycles come around. We have asked for public permission from the Mozilla root program to return to the algorithm we were originally using, which is generally believed to be better and will likely become compliant over the next couple of months:

https://groups.google.com/d/msg/mozilla.dev.security.policy/9y-XTajmOCw/5hicEUHqAAAJ

Comment 4

[Gervase Markham [:gerv]]

https://groups.google.com/d/msg/mozilla.dev.security.policy/9y-XTajmOCw/Hjqta1ETAQAJ

Gerv

Comment 5

[Gervase Markham [:gerv]]

Given Mozilla's position, cert #1 is not misissued. The issue relating to cert #2 has been remediated.

Gerv