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

2018-05-21 Thread Matthew Hardeman via dev-security-policy
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

2018-05-21 Thread Ryan Sleevi via dev-security-policy
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

2018-05-21 Thread Nick Lamb via dev-security-policy
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

2018-05-21 Thread Tim Hollebeek via dev-security-policy
Ok. My biggest concern is not you guys, who are pretty security conscious, but whether we need to improve the language to make it more clear that the logging has to be sufficient so that in the event of a bug in the CAA logic, it is possible to determine which issued certificates are affected and