Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Tuesday, May 22, 2018 at 1:27:16 PM UTC-4, Ryan Sleevi wrote: > On Tue, May 22, 2018 at 1:03 PM, Paul Wouters wrote: > > > I know of 12400 512 bit RSA ZSK's in a total of about 6.5 million. And I > > consider those to be an operational mistake. > >

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

I believe that Paul Wouters has made a compelling case regarding the current state of keying practices in DNSSEC deployment today. There is sufficient cryptographic rigor to merit logging this data for review of correct assessment as of the point in time at which certificate issuance decisioning

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

Right, this is a fair and excellent summary, and there are things I would improve about my responses if I had access to a time machine. Constraints on my time are pretty brutal right now, and that does not always allow me to express myself as well as I would like. I perceived, possibly

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

You’re free to misattribute whatever motives you want to me. They’re not true. In fact, I would like to call on you yet again to cease speculating and imputing malicious motives onto well-intentioned posts. The CAA logging requirements failed in this instance. How do we make them better?

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On 21 May 2018 14:59, Ryan Sleevi wrote:Given the TTLs and the key sizes in use on DNSSEC records, why do you believe this?This is a smoking gun because it's extremely strong circumstantial evidence. Why else would these records exist except that in fact the "victim" published

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Tuesday, May 22, 2018 at 1:32:51 PM UTC-4, vduk...@gmail.com wrote: > On Tuesday, May 22, 2018 at 1:04:31 PM UTC-4, Paul Wouters wrote: > > On Tue, 22 May 2018, Ryan Sleevi via dev-security-policy wrote: > > > > > However, what does this buy us? Considering that the ZSKs are > > >

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Tuesday, May 22, 2018 at 1:04:31 PM UTC-4, Paul Wouters wrote: > On Tue, 22 May 2018, Ryan Sleevi via dev-security-policy wrote: > > > However, what does this buy us? Considering that the ZSKs are intentionally > > designed to be frequently rotated (24 - 72 hours), thus permitting weaker > >

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Tue, May 22, 2018 at 1:03 PM, Paul Wouters wrote: > On Tue, 22 May 2018, Ryan Sleevi via dev-security-policy wrote: > > However, what does this buy us? Considering that the ZSKs are intentionally >> designed to be frequently rotated (24 - 72 hours), thus permitting weaker >>

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

> > *From:* Ryan Sleevi [mailto:r...@sleevi.com] > *Sent:* Tuesday, May 22, 2018 12:43 PM > *To:* Tim Hollebeek <tim.holleb...@digicert.com> > *Cc:* r...@sleevi.com; Nick Lamb <n...@tlrmx.org>; > mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Tue, 22 May 2018, Ryan Sleevi via dev-security-policy wrote: However, what does this buy us? Considering that the ZSKs are intentionally designed to be frequently rotated (24 - 72 hours), thus permitting weaker key sizes (RSA-512), I don't know anyone who believes or uses these timings or

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

<jacob.hoffmanandr...@gmail.com> Subject: Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident On Tue, May 22, 2018 at 12:14 PM, Tim Hollebeek <tim.holleb...@digicert.com <mailto:tim.holleb...@digicert.com> > wrote: What precisely was the antecedent of “this” i

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Tue, May 22, 2018 at 12:14 PM, Tim Hollebeek wrote: > What precisely was the antecedent of “this” in your message? Re-reading > it, I’m not clear which sentence you were referring to. > > > > The only reasons I can think of for not keeping DNSSEC signed RRs are >

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

What precisely was the antecedent of “this” in your message? Re-reading it, I’m not clear which sentence you were referring to. The only reasons I can think of for not keeping DNSSEC signed RRs are storage and/or performance, and we think those concerns should not be the driving force in

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Tue, May 22, 2018 at 11:17 AM, Tim Hollebeek wrote: > > > Given the TTLs and the key sizes in use on DNSSEC records, why do you > believe > > this? > > DigiCert is not sympathetic to disk space as a reason to not keep > sufficient > information > in order to detect

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

> Given the TTLs and the key sizes in use on DNSSEC records, why do you believe > this? DigiCert is not sympathetic to disk space as a reason to not keep sufficient information in order to detect misissuance due to CAA failures. In fact, inspired by this issue, we are taking a look internally

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

I concur with Mr. Lamb's position. I agree not only with respect to DNSSEC signatures but to the entire query and RR set upon which the CAs decisions relied. I do acknowledge the challenge that Mr. Hoffman-Andrews surfaced: that it may involve significant effort to correlate the various queries

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Mon, May 21, 2018 at 9:06 AM, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > As a lowly relying party, I have to say I'd expect better here. > > In particular, if example.com says their DNSSEC signed CAA forbade Let's > Encrypt from issuing, and Let's

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

As a lowly relying party, I have to say I'd expect better here.In particular, if example.com says their DNSSEC signed CAA forbade Let's Encrypt from issuing, and Let's Encrypt says otherwise, I absolutely would expect Let's Encrypt to produce DNSSEC signed RRs that match up to their story. The

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

to:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of > jacob.hoffmanandrews--- via dev-security-policy > Sent: Friday, May 18, 2018 2:05 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: 2018.05.18 Let's Encrypt CAA tag value case

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Friday, May 18, 2018 at 10:52:25 AM UTC-7, Tim Hollebeek wrote: > > Our logging of the CAA records processed does not provide the case > > information we need to determine whether other issuances were affected by > > this bug. > > We put a requirement in the BRs specifically so this problem

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

> Our logging of the CAA records processed does not provide the case > information we need to determine whether other issuances were affected by > this bug. We put a requirement in the BRs specifically so this problem could not occur: "The CA SHALL log all actions taken, if any, consistent with

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

Oops, I missed item 1, disregard :) On Fri, May 18, 2018, at 13:45, Jonathan Rudenberg via dev-security-policy wrote: > On Fri, May 18, 2018, at 13:00, josh--- via dev-security-policy wrote: > > 2. Performing a scan of current CAA records for the domain names we have > > issued for in the past

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Fri, May 18, 2018, at 13:00, josh--- via dev-security-policy wrote: > 2. Performing a scan of current CAA records for the domain names we have > issued for in the past 90 days, specifically looking for tags in CAA > records with non-lowercase characters. We’ll examine such instances on a >