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
.@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
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?
>
>
>
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
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
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
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
> 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
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
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
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
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
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
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
>
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
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
> 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
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
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
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
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
21 matches
Mail list logo