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

Reply via email to