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.
>
> http://tma.ifip.org/wordpress/wp-content/uplo
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 wa
On Tue, 22 May 2018, Ryan Sleevi 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.
http://tma.ifip.org/wordpress/wp-content/uploads/2017/06/tma2017_paper58.pdf
has some fairly damning empirical data about th
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 inco
Tim,
I definitely think we've gone off the rails here, so I want to try to right
the cart here. You jumped in on a thread talking about DNSSEC providing
smoking guns [1] - which is a grandstanding bad idea. It wasn't yours, but
it's one that you jumped into the middle of the discussion, and began
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?
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 these DNS records at
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
> > > intentionall
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
> > ke
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
>> key sizes (RSA-512
yan Sleevi [mailto:r...@sleevi.com]
> *Sent:* Tuesday, May 22, 2018 12:43 PM
> *To:* Tim Hollebeek
> *Cc:* r...@sleevi.com; Nick Lamb ;
> mozilla-dev-security-policy ;
> Jacob Hoffman-Andrews
> *Subject:* Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity
> inciden
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 k
: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Tuesday, May 22, 2018 12:43 PM
To: Tim Hollebeek
Cc: r...@sleevi.com; Nick Lamb ; mozilla-dev-security-policy
; Jacob Hoffman-Andrews
Subject: Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident
On Tue, May 22, 2018 at
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
> storage and/or performance, a
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 lo
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 misissuance due to CAA failu
> 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 at
On Mon, May 21, 2018, 9:07 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 Encrypt s
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 a
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 Encryp
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 smok
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
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 cou
> 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 i
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 9
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
> ca
26 matches
Mail list logo