Re: 2020.02.29 Let's Encrypt CAA Rechecking Bug

2020-02-29 Thread Jacob Hoffman-Andrews via dev-security-policy
On Saturday, February 29, 2020 at 4:10:40 AM UTC-8, Nick Lamb wrote:
> Hi Jacob, was there a reason not to use the ordinary incident reporting
> format ? This is pretty good for ensuring you cover all the questions
> we're otherwise likely to ask anyway.

Thanks for the reminder. My goal here was to post a preliminary notification 
promptly, and follow up with more detail. I'm definitely open to hearing from 
the community, and from Mozilla, if people prefer to have the preliminary 
notification filed in the incident reporting format, even if many fields will 
have to be left blank.

> If it's not very difficult it would also be useful to have some idea
> how many certificates might be affected. That is, how many certificates
> were really issued to multiple FQDNs (if a single FQDN the bug described
> has no effect) more than 8 hours after initial correct CAA checks ?
> Intuitively this should be almost none, but intuitions can be
> misleading.

We're working on this analysis today.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: 2020.02.29 Let's Encrypt CAA Rechecking Bug

2020-02-29 Thread Nick Lamb via dev-security-policy
On Fri, 28 Feb 2020 21:50:47 -0800 (PST)
Jacob Hoffman-Andrews via dev-security-policy
 wrote:

> Also posted to https://bugzilla.mozilla.org/show_bug.cgi?id=1619047

Hi Jacob, was there a reason not to use the ordinary incident reporting
format ? This is pretty good for ensuring you cover all the questions
we're otherwise likely to ask anyway.

> On 2020-02-29 UTC, Let’s Encrypt found a bug in our CAA code. Our CA
> software, Boulder,  checks for CAA records at the same time it
> validates a subscriber’s control of a domain name. Most subscribers
> issue a certificate immediately after domain control validation, but
> we consider a validation good for 30 days. That means in some cases
> we need to check CAA records a second time, just before issuance.
> Specifically, we have to check CAA within 8 hours prior to issuance
> (per BRs §3.2.2.8), so any domain name that was validated more than 8
> hours ago requires rechecking.

For example "found a bug" _probably_ means that programmers in the
course of their ordinary work realised there was a logical error in the
Boulder software, but people might also use it to describe figuring out
the cause of problems reported to them by a third party, which has
different implications for security. The usual "How did you learn of
this incident?" question ensure a clear answer.

> The bug: when a certificate request contained N domain names that
> needed CAA rechecking, Boulder would pick one domain name and check
> it N times. What this means in practice is that if a subscriber
> validated a domain name at time X, and the CAA records for that
> domain at time X allowed Let’s Encrypt issuance, that subscriber
> would be able to issue a certificate containing that domain name
> until X+30 days, even if someone later installed CAA records on that
> domain name that prohibit issuance by Let’s Encrypt.

It seems unlikely that in practice this bug has inconvenienced a
subscriber, let alone enabled adversaries to actually get miss-issued
certificates - but given Let's Encrypt operates a self-help forum for
users it may be worth spending a few minutes searching for related
problems in those forums once the timespan involved is clear to see if
any of your users reported symptoms from this bug that were missed.

If it's not very difficult it would also be useful to have some idea
how many certificates might be affected. That is, how many certificates
were really issued to multiple FQDNs (if a single FQDN the bug described
has no effect) more than 8 hours after initial correct CAA checks ?
Intuitively this should be almost none, but intuitions can be
misleading.

Nick.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy