Re: Anomalous Certificate Issuances based on historic CAA records

2017-12-01 Thread Gervase Markham via dev-security-policy
On 30/11/17 14:52, Ryan Sleevi wrote: > I think that, as CAA deployment becomes common, this pattern will be > not-uncommon. I would hope we don't sound false alarms when it does. After a little time (as it does seem some bugs are still being shaken out), I am considering having Mozilla adopt a

RE: Anomalous Certificate Issuances based on historic CAA records

2017-11-30 Thread Jeremy Rowley via dev-security-policy
.@nohats.ca <mailto:p...@nohats.ca> >; Ben Laurie <b...@google.com <mailto:b...@google.com> >; Jeremy Rowley <jeremy.row...@digicert.com <mailto:jeremy.row...@digicert.com> > Subject: Re: Anomalous Certificate Issuances based on historic CAA records What problem(s) are you t

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-30 Thread Ryan Sleevi via dev-security-policy
illa.org; Paul Wouters < > p...@nohats.ca>; Ben Laurie <b...@google.com>; Jeremy Rowley < > jeremy.row...@digicert.com> > *Subject:* Re: Anomalous Certificate Issuances based on historic CAA > records > > > > What problem(s) are you trying to solve? > > >

RE: Anomalous Certificate Issuances based on historic CAA records

2017-11-30 Thread Tim Hollebeek via dev-security-policy
Paul, Improving CAA by moving it to a protocol other than DNS is certainly worth considering, going forward. With respect to people using proper DNS libraries and not inventing their own CNAME / DNAME handling, the problem was that RFC 6844 accidentally specified semantics for CNAME / DNAME

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-30 Thread Quirin Scheitle via dev-security-policy
Hi all, just 2 quick comments: > On 30. Nov 2017, at 22:06, Wayne Thayer via dev-security-policy > wrote: > > This thread started as a discussion over possible mis-issuance that was > determined to be false positives We had reported 18 anomalies, of

RE: Anomalous Certificate Issuances based on historic CAA records

2017-11-30 Thread Paul Wouters via dev-security-policy
On Thu, 30 Nov 2017, Tim Hollebeek via dev-security-policy wrote: [somewhat off topic, you can safely hit delete now] So it turns out DNSSEC solves CAA problems for almost nobody, because almost nobody uses DNSSEC. The only people who need to use CAA are the CA's. They can surely manage to

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-30 Thread Paul Wouters via dev-security-policy
On Thu, 30 Nov 2017, Wayne Thayer wrote: [cut CC: list, assuming we're all on the list] - Subscribers already (or soon will) have CT logs and monitors available to detect mis-issued certs. They don't need CAA Transparency. It's not for subscribers, but for CA's. Transparency is nice, but

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-30 Thread Quirin Scheitle via dev-security-policy
> On 30. Nov 2017, at 15:52, Ryan Sleevi wrote: > >> On Thu, Nov 30, 2017 at 4:02 AM, Quirin Scheitle via dev-security-policy >> wrote: >> Similar to the GlobalSign discussion, it is well possible that the domain >> briefly disabled

RE: Anomalous Certificate Issuances based on historic CAA records

2017-11-30 Thread Tim Hollebeek via dev-security-policy
To: Tim Hollebeek <tim.holleb...@digicert.com> Cc: r...@sleevi.com; douglas.beat...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org; Paul Wouters <p...@nohats.ca>; Ben Laurie <b...@google.com>; Jeremy Rowley <jeremy.row...@digicert.com> Subject: Re: Anomalous Cer

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-30 Thread Wayne Thayer via dev-security-policy
What problem(s) are you trying to solve? - Subscribers already (or soon will) have CT logs and monitors available to detect mis-issued certs. They don't need CAA Transparency. - This thread started as a discussion over possible mis-issuance that was determined to be false positives. As has been

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-30 Thread Ryan Sleevi via dev-security-policy
On Thu, Nov 30, 2017 at 3:12 PM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The problem DNSSEC checks for CAA was intended to solve was the fact that > it > is certainly possible that a well-resourced attacker can manipulate the DNS > responses that

RE: Anomalous Certificate Issuances based on historic CAA records

2017-11-30 Thread Tim Hollebeek via dev-security-policy
ca> Cc: douglas.beat...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org; Jeremy Rowley <jeremy.row...@digicert.com> Subject: Re: Anomalous Certificate Issuances based on historic CAA records On 29 November 2017 at 22:33, Paul Wouters <p...@nohats.ca> wrote: > > > > O

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-30 Thread Ryan Sleevi via dev-security-policy
On Thu, Nov 30, 2017 at 4:02 AM, Quirin Scheitle via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Similar to the GlobalSign discussion, it is well possible that the domain > briefly disabled their CAA records when you did the check — and re-enabled > them later. > I

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-30 Thread Quirin Scheitle via dev-security-policy
Hi Jeremy, thank you for sharing that log! The associated bug is here: https://bugzilla.mozilla.org/show_bug.cgi?id=1420861 I do not know how to parse all the details in the log, but I guess the line > 2017-09-13 05:25:09.117 [pool-3058692-thread-1] [] INFO >

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread Nick Lamb via dev-security-policy
On Wed, 29 Nov 2017 22:37:08 + Ben Laurie via dev-security-policy wrote: > Presumably only for non-DNSSEC, actually? For DNSSEC, you have a clear > chain of responsibility for keys, and that is relatively easy to > build on. For DNSSEC a CA could (and

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread Ben Laurie via dev-security-policy
On 29 November 2017 at 22:33, Paul Wouters wrote: > > > > On Nov 29, 2017, at 17:00, Ben Laurie via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > This whole conversation makes me wonder if CAA Transparency should be a > > thing. > > That is a very

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread Paul Wouters via dev-security-policy
> On Nov 29, 2017, at 17:00, Ben Laurie via dev-security-policy > wrote: > > This whole conversation makes me wonder if CAA Transparency should be a > thing. That is a very hard problem, especially for non-DNSSEC signed ones. Paul

RE: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread Jeremy Rowley via dev-security-policy
il.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Anomalous Certificate Issuances based on historic CAA records This whole conversation makes me wonder if CAA Transparency should be a thing. On 29 November 2017 at 20:44, Jeremy Rowley via dev-security-policy <dev-securi

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread Ben Laurie via dev-security-policy
s+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of > douglas.beattie--- via dev-security-policy > Sent: Wednesday, November 29, 2017 4:27 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Anomalous Certificate Issuances based on historic CAA rec

RE: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread Jeremy Rowley via dev-security-policy
Of douglas.beattie--- via dev-security-policy Sent: Wednesday, November 29, 2017 4:27 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Anomalous Certificate Issuances based on historic CAA records Hi Quirin, I'm curious about how you recorded the historical information from DNS

Re: Anomalous Certificate Issuances based on historic CAA records

2017-11-29 Thread douglas.beattie--- via dev-security-policy
Hi Quirin, I'm curious about how you recorded the historical information from DNS, can you explain how this was requested and logged? We logged the data used for issuance of the GlobalSign certificate at the time of issuance and it's different from what you recorded. We logged that there was