On September 8, 2017, Let’s Encrypt received a report from researcher Andrew Ayer that we accepted an expired DNSSEC RRSIG during certificate issuance. The RRSIG was very recently expired (< 1hr).
This violates RFC 4033 Section 8.1 [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 [2]: “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.” This happened because the Let’s Encrypt DNS resolver used a default "grace period" of 1 hour for DNSSEC RRSIGs to help with clock skew. The certificate [1] was revoked and a fix was deployed less than 24 hours after receiving the report. The grace period for RRSIG expiration was disabled. We believe that the risk to relying parties based on validating stale DNSSEC records was extremely low. A hypothetical attacker would have to take over an IP address pointed to by a previously signed zone, and the proper owner of that zone would have had to change the zone to point to a new IP address within less than an hour, in order for the stale signature to make any material difference in validation. [1] https://tools.ietf.org/html/rfc4033#section-8.1 [2] https://tools.ietf.org/html/rfc4034#section-3.1.5 [3] https://crt.sh/?sha256=435F08B5A9536E2B8F91AB8970FF9F8D93A1A0A5529C2D8388A10FA59FF3758C This is information is also available on our community site: https://community.letsencrypt.org/t/2017-09-08-expired-dnssec-response-incident/42517 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
