Re: 2020.02.29 Let's Encrypt CAA Rechecking Bug
On Thu, Mar 5, 2020 at 8:09 AM Malcolm Doody via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tuesday, 3 March 2020 15:37:00 UTC, Jacob Hoffman-Andrews wrote: > > We've posted our Incident Report at > https://bugzilla.mozilla.org/show_bug.cgi?id=1619047#c1. > > In light of > https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591/3, > should LE file a 2nd bug report about their decision not to revoke > certificates within the BR limits? https://bugzilla.mozilla.org/show_bug.cgi?id=1619179 was already filed, prior to that decision, in line with best practices. You can see the outstanding CA incidents at https://wiki.mozilla.org/CA/Incident_Dashboard to follow along or ask questions. > ___ 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
On Thursday, 5 March 2020 13:10:38 UTC, Julien Cristau wrote: > I believe that's what https://bugzilla.mozilla.org/show_bug.cgi?id=1619179 > is about. > > Cheers, > Julien > Ah, my bad - that bug hadn't surfaced on MDSP ___ 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
I believe that's what https://bugzilla.mozilla.org/show_bug.cgi?id=1619179 is about. Cheers, Julien On Thu, Mar 5, 2020 at 2:09 PM Malcolm Doody via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tuesday, 3 March 2020 15:37:00 UTC, Jacob Hoffman-Andrews wrote: > > We've posted our Incident Report at > https://bugzilla.mozilla.org/show_bug.cgi?id=1619047#c1. > > In light of > https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591/3, > should LE file a 2nd bug report about their decision not to revoke > certificates within the BR limits? > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ 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
On Tuesday, 3 March 2020 15:37:00 UTC, Jacob Hoffman-Andrews wrote: > We've posted our Incident Report at > https://bugzilla.mozilla.org/show_bug.cgi?id=1619047#c1. In light of https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591/3, should LE file a 2nd bug report about their decision not to revoke certificates within the BR limits? ___ 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
We've posted our Incident Report at https://bugzilla.mozilla.org/show_bug.cgi?id=1619047#c1. ___ 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
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
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