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

[Nick Lamb via dev-security-policy]

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 the time of (or shortly before) issuance?As with a real smoking gun there certainly could be other explanations, but the most obvious (that these were the genuine query answers) will usually be correct.If the reality is that fake records were supplied by a MitM using cracked 512 bit keys in order to fool the CA, the name owner victim is humiliated perhaps but they can take action to secure their names with a better key in future. And the Ecosystem gets a free warning as to the safety (rather otherwise) of short keys.If we suppose the CA systematically produced these fake records afterwards to justify a mis-issuance I'd say that's quite a credibility jump from the level of shenanigans we've gotten used to from CAs and it depends upon their victim having a short key for it to even be possible.These both sound like reasons to increase RSA keylengths for any names that are important for you, not justifications for inadequate logging.___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

InfoCert Acquisition of Camerfirma

[Wayne Thayer via dev-security-policy]

On Thursday, a representative of AC Camerfirma sent an email informing
Mozilla that InfoCert [1] has taken control of Camerfirma. News of the deal
was first published on May 4th. [2]

Section 8.1 of our policy applies here (quoting version 2.6 draft):

If the receiving or acquiring company is new to the Mozilla root program,
> it must demonstrate compliance with the entirety of this policy and there
> MUST be a public discussion regarding their admittance to the root program,
> which Mozilla must resolve with a positive conclusion in order for the
> affected certificate(s) to remain in the root program. If the entire CA
> operation is not included in the scope of the transaction, issuance is not
> permitted until the discussion has been resolved with a positive conclusion.
>

InfoCert is new to the Mozilla root program, so a public discussion
regarding their admittance to the root program is in order. I have
requested clarification, but my current understanding is that AC
Camerfirma's entire CA operation is part of the transaction. Thus,
according to our new policy, certificate issuance may continue during our
discussion period.

Camerfirma has informed me that they will not be able to answer our
questions until the transaction "has been done in the Spanish government's
public registry", which they expect to take approximately 4 weeks.
Meanwhile, I have created a bug [3] to track this request and have posed a
number of questions to InfoCert.

- Wayne
[1] https://infocert.digital/about-us/
[2]
https://www.corrierecomunicazioni.it/digital-economy/infocert-sbarca-allestero-acquisito-il-51-della-spagnola-camerfirma/
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1463597
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matthew Hardeman via dev-security-policy]

Copying message accidentally sent directly to a list participant.

-- Forwarded message --
From: Matthew Hardeman 
Date: Tue, May 22, 2018 at 3:47 PM
Subject: Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity
incident
To: Ryan Sleevi 


Ultimately it seems reasonable to, as Mr. Lamb suggested, log the DNS
result set such that it is possible to reproduce the point-in-time signed
confirmation of the CAA record (or signed non-existence) to within the
constraints of the DNSSEC mechanisms available and provisioned for the
zone, following the delegations down from the root zone.

Are there badly chosen keys and TTLs out there today in practice?  Yes, but
they're a decreasing proportion of zones.  Some TLDs are aggressively
deploying DNSSEC and encouraging proper implementation.

There's an opportunity here to provide for a best effort cryptographic
proof to within the boundaries of what the domain holder has configured.
Why not match the domain holder's effort with proportionate supporting
documentation?


On Tue, May 22, 2018 at 11:43 AM, Ryan Sleevi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Tue, May 22, 2018 at 12:14 PM, Tim Hollebeek <
> tim.holleb...@digicert.com>
> 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, and we think those concerns should not be the
> > driving force in logging requirements (within reason).
> >
> >
> >
> > Are there other good reasons not to keep the DNSSEC signed RRs associated
> > with DNSSEC CAA lookups?
> >
>
> I believe you are operating on a flawed understanding of the value of
> DNSSEC for forensic purposes, given the statement that "I absolutely would
> expect Let's Encrypt to produce DNSSEC signed RRs that match up to their
> story. The smoking gun for such scenarios exists, and CAs are, or should
> be, under no illusions that it's their job to produce it."
>
> To me, this demonstrates a flawed, naive understanding of DNSSEC, and in
> particular, its value in forensic post-issuance claims, and also a flawed
> understanding about how DNS works, in a way that, as proposed, would be
> rather severely damaging to good operation and expected use of DNS. While
> it's easy to take shots on the basis of this, or to claim that the only
> reason not to store is because disk space, it would be better to take a
> step back before making those claims.
>
> DNSSEC works as short-lived signatures, in which the proper operation of
> DNSSEC is accounted for through frequent key rotation. DNS works through
> relying on factors such as TTLs to serve as effective safeguards against
> overloading the DNS system, and its hierarchal distribution allows for
> effective scaling of that system.
>
> A good primer to DNSSEC can be had at
> https://www.cloudflare.com/dns/dnssec/how-dnssec-works/ , although I'm
> sure
> many other introductory texts would suffice to highlight the problem.
>
> Let us start with a naive claim that the CA should be able to produce the
> entire provenance chain for the DNSSEC-signed leaf record. This would be
> the chain of KSKs, ZSKs, the signed RRSets, as well as the DS records,
> disabling caching for all of these (or, presumably, duplicating it such
> that the .com KSK and ZSK are recorded for millions of certs).
>
> 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), a provenance chain ultimately merely serves to
> establish, in practice, one of a series of 512-bit RSA signatures. Are we
> to believe that these 512-bit signatures, on whose keys have explicitly
> expired, are somehow a smoking gun? Surely not, that'd be laughably
> ludicrous - and yet that is explicitly what you propose in the quoted text.
>
> So, again I ask, what is it you're trying to achieve? Are you trying to
> provide an audit trail? If so, what LE did is fully conformant with that,
> and any CA that wishes to disagree should look inward, and see whether
> their audit trail records actual phone calls (versus records of such phone
> calls), whether their filing systems store the actual records (versus
> scanned copies of those records), whether all mail is delivered certified
> delivery, and how they recall the results of that certified delivery.
>
> However, let us not pretend that recording the bytes-on-the-wire DNS
> responses, including for DNSSEC, necessarily helps us achieve some goal
> about repudiation. Rather, it helps us identify issues such as what LE
> highlighted - a need for quick and efficient information scanning to
> discover possible impact - which is hugely valuable in its own right, and
> is an area where I am certain that a majority of CAs are 

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

[Wayne Thayer via dev-security-policy]

On Tue, May 22, 2018 at 12:11 PM Ryan Sleevi  wrote:

> Overall, I think this would be good to proceed, but there's certain
> discrepancies called out under Questions that I think should be resolved
> before doing so. I would suggest contacting WISeKey for follow-up on these,
> and not proceed until we've got a satisfactory response. With the upcoming
> CA/Browser Forum F2F, I think that effectively means a delay of
> approximately two weeks, to allow both WISeKey to respond and the community
> (and maintainers) to review for sufficiency. I think that, provided a
> response is provided, than barring any further feedback raising additional
> concerns, proceeding by June 14 would be a reasonable timeframe? Does that
> seem like a reasonable set of expectations and timing?
>
> This sounds reasonable, but I will note that there is no time limit on
public discussions - this one will end after WISeKey has responded to these
questions and sufficient time has passed for any additional concerns to be
raised.

>
> * As noted, the key generation was performed in May, and this audit is a
> period of time audit beginning in September. This does mean that there is a
> gap in the audit coverage - from May through September - that's difficult
> to reason about. Are there any other supporting documents that would help
> assuage these concerns?
>
> I would have expected this new root to be included on WISeKey's next
regular audit statements for the period ending June 2nd 2017, but WISeKey
apparently chooses to perform separate audits (or at least procure separate
audit statements) for each of it's roots. Given these circumstances, I
share Ryan's concerns and would like an explanation.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

[Ryan Sleevi via dev-security-policy]

Thanks for the reminder, Wayne.

I've reviewed the CPS and Audit Reports and have the following comments. I
will note that, due to having already had someone else look at it, I only
focused on information validation related to domains and IPs, and did not
examine the policies around OV and EV, as those are generally not
applicable to trust on the Web.

Overall, I think this would be good to proceed, but there's certain
discrepancies called out under Questions that I think should be resolved
before doing so. I would suggest contacting WISeKey for follow-up on these,
and not proceed until we've got a satisfactory response. With the upcoming
CA/Browser Forum F2F, I think that effectively means a delay of
approximately two weeks, to allow both WISeKey to respond and the community
(and maintainers) to review for sufficiency. I think that, provided a
response is provided, than barring any further feedback raising additional
concerns, proceeding by June 14 would be a reasonable timeframe? Does that
seem like a reasonable set of expectations and timing?

== Good ==
* 2.1 notes that they make a public repository of issued certificates
available, which is good to see positive affirmation of certificates being
public
* 3.1.4 and Annex B provide ample detail about the certificate fields and
their validated context, which provides a reasonable basis for
understanding their certificate profile and validation practices
* 3.1.6 "In any event, the OWGTM will not attempt to intermediate nor
resolve conflicts regarding ownership of names or trademarks." - It is good
to CA recognize its role in not independently trying to determine trademark
issues, and instead defer those to proper adjudication. I wish all CAs
would recognize this.
* 4.9.7 publishes CRLs in 3 days, effectively half the BR-required time (of
7 days), leading to more effective revocation distribution.
* 7.2.2 notes a quality profile for CRLs
  * Note: It could be improved to document the maximum size (worst case) of
CRLs or how sharding is done (across issuerDistributionPoint extensions),
to ensure that the worst case CRL size (if all certs pointing to that CRL
were revoked) is kept within a reasonable size limit, such as 64K. That's
an opportunity for improvement, but admittedly requires more careful
engineering design to implement.
* 9.4.2 notes that "private information" does NOT include information
contained within a certificate or CRL, which is the correct interpretation
* 9.6.1 explicitly notes MITM is prohibited. While implicit, it's also
encouraging to see this explicitly called out.
* Annex E notes that they support IODEF, and the supported methods (this is
a SHOULD, not a MUST, in the BRs)

== Meh ==
* 1.4.1.2, which details the validation process for server certificates,
explicitly calls out domain verification for DV, but not for OV/EV.
  * It's unclear if this implies the use of the (deprecated) 3.2.2.4.1 /
3.2.2.4.5 as demonstrations of domain "ownership" independent of domain
"control"
  * Annex E makes it clear that .1 and .5 are in scope as validation
methods, which should be phased out by August.
* 1.5.4 requires a full meeting of the CAA to convene for updates, which
may make it difficult to have the CPS (and the attendant CA policies)
reflect the BRs
* 3.2.6 notes an accreditation process for interoperating, but doesn't note
whether that includes audits consistent with section 8 of the BRs
* 4.3 states "The OWGTM is not responsible for monitoring, research or
confirmation of the correctness of the information contained in a
certificate during the intermediate period between its issuance and
renewal, ", which in one read, is entirely consistent with 9.6.1 of the BRs
(consistent in that it's at time of issuance), but in another read, could
be seen as conflicting with 4.9.1.1 of the BRs
* Section 4.9.1 lists 13 items, but there are 15 in the corresponding BRs.
Item #4 from the BRs is combined with Item #3 in the CPS, and Item #7 is
missing from the BRs as an explicit callout. #14 and #15 in the BRs are
seemingly not present, as the place where they would be expected - #12 and
#13 - from the CPS are different.
* Section 5.2.2 / 5.2.4 don't detail the minimum number of people required
for certain activities.
* Section 6.2.4 states that CA backup keys are "typically" store encrypted.
What protections are in place if they're not encrypted?
* Section 7.3.2 misunderstands OCSP extensions as being about the
certificates, rather than extensions within OCSP responses (such as CT
extensions, should that be supported, or nonces, if that should
unfortunately be supported [and it shouldn't])
* Annex B, 11.3.1, lists SAN in the base certificate profile, rather than
as an X.509v3 extension, and doesn't explicitly list the CN as being one of
the SAN values

== Bad ==
* Annex B, 11.3.1, does not list the extendedKeyUsage in the profile for
SSL certificates which is mandatory per the BRs 7.1.2.3.
  * Other profiles under Annex B do list it (under the misnamed 

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

[vdukhovni--- via dev-security-policy]

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 
> > > 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 key sizes. It
> > might be done as an _attack_ but it would be a very questionable
> > deployment.
> > 
> > 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.
> 
> These are "legacy" zones where ~3 operators are having some trouble getting 
> better keys in place, but the swamp is slowly getting drained, a few months 
> back the total was ~12900, out of a smaller overall total.  ZSKs are 
> predominantly 1024-bit, with a noticeably large minority using 1280 bits.  
> Latest stats:
> 
>   https://lists.dns-oarc.net/pipermail/dns-operations/2018-May/017628.html

As for ZSK lifetime, among still extant domains the average (last seen - first 
seen) time of no longer published ZSKs is 59 days.  This is strongly indicative 
of a 60-day cycle at the larger DNSSEC-hosting providers.  The sample size is 
"5187051" retired ZSKs.

The standard deviation is 34 days. So we can estimate that most ZSKs are 
rotated in 30-90 days.  The sample size is ~5.2 million domains.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[vdukhovni--- via dev-security-policy]

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
> > key sizes (RSA-512),
> 
> I don't know anyone who believes or uses these timings or key sizes. It
> might be done as an _attack_ but it would be a very questionable
> deployment.
> 
> 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.

These are "legacy" zones where ~3 operators are having some trouble getting 
better keys in place, but the swamp is slowly getting drained, a few months 
back the total was ~12900, out of a smaller overall total.  ZSKs are 
predominantly 1024-bit, with a noticeably large minority using 1280 bits.  
Latest stats:

  https://lists.dns-oarc.net/pipermail/dns-operations/2018-May/017628.html

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

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),
>>
>
> I don't know anyone who believes or uses these timings or key sizes. It
> might be done as an _attack_ but it would be a very questionable
> deployment.
>
> 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 the reliability of those
records, which is not in line with your anecdata.


>
>
> However, let us not pretend that recording the bytes-on-the-wire DNS
>> responses, including for DNSSEC, necessarily helps us achieve some goal
>> about repudiation. Rather, it helps us identify issues such as what LE
>> highlighted - a need for quick and efficient information scanning to
>> discover possible impact - which is hugely valuable in its own right, and
>> is an area where I am certain that a majority of CAs are woefully lagging
>> in. That LE recorded this at all, beyond simply "checked DNS", is more of
>> a
>> credit than a disservice, and a mitigating factor more than malfeasance.
>>
>
> I see no reason why not to log the entire chain to the root. The only
> exception being maliciously long chains, which you can easilly cap
> and error out on after following about 50 DS records?


"Why not" is not a very compelling argument, especially given the
complexity involved, and the return to value being low (and itself being
inconsistent with other matters)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

I think your position is both misguided and unrealistic, and I think you're
using it as an opportunity to pursue a technical issue, when there is both
a systemic issue at play (and can be demonstrated through all validation
methods) and a fundamental misunderstanding as to the value it would
provided.

I'm glad you find the technical explanation a wall of text. Bad ideas do
take disproportionately more effort to shoot down then they do to propose.
That is an unfortunate asymmetric cost, and one the Web PKI has had to bear
for quite some time.

I'm not opposed to systemic improvements. I am opposed to unnecessary
grand-standing and hand-wringing, when demonstrably worse things are
practiced.

On Tue, May 22, 2018 at 12:51 PM, Tim Hollebeek 
wrote:

> What that wall of text completely misses is the point I and others have
> been trying to make.
>
>
>
> The logs have to have enough information so you don’t end up in the
> situation Let’s Encrypt is currently, and unfortunately, in.  Yes, what
> they did is compliant, and that’s exactly what most concerns me.  It’s not
> about Let’s Encrypt, which just appears to have made a mistake, it
> happens.  It’s about whether the rules need to be improved to reduce the
> likelihood of another CA ending up in the same situation.
>
>
>
> As a separate issue, we’re looking into making sure we never end up in
> that situation, and as you say, other CAs should be too.  We always reserve
> the right to do things that vastly exceed minimal compliance.
>
>
>
> That should be something you should support, instead of producing
> increasingly long and condescending walls of text.  I know how DNSSEC works.
>
>
>
> -Tim
>
>
>
> *From:* 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 12:14 PM, Tim Hollebeek <
> tim.holleb...@digicert.com> 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, and we think those concerns should not be the
> driving force in logging requirements (within reason).
>
>
>
> Are there other good reasons not to keep the DNSSEC signed RRs associated
> with DNSSEC CAA lookups?
>
>
>
> I believe you are operating on a flawed understanding of the value of
> DNSSEC for forensic purposes, given the statement that "I absolutely would
> expect Let's Encrypt to produce DNSSEC signed RRs that match up to their
> story. The smoking gun for such scenarios exists, and CAs are, or should
> be, under no illusions that it's their job to produce it."
>
>
>
> To me, this demonstrates a flawed, naive understanding of DNSSEC, and in
> particular, its value in forensic post-issuance claims, and also a flawed
> understanding about how DNS works, in a way that, as proposed, would be
> rather severely damaging to good operation and expected use of DNS. While
> it's easy to take shots on the basis of this, or to claim that the only
> reason not to store is because disk space, it would be better to take a
> step back before making those claims.
>
>
>
> DNSSEC works as short-lived signatures, in which the proper operation of
> DNSSEC is accounted for through frequent key rotation. DNS works through
> relying on factors such as TTLs to serve as effective safeguards against
> overloading the DNS system, and its hierarchal distribution allows for
> effective scaling of that system.
>
>
>
> A good primer to DNSSEC can be had at https://www.cloudflare.com/
> dns/dnssec/how-dnssec-works/ , although I'm sure many other introductory
> texts would suffice to highlight the problem.
>
>
>
> Let us start with a naive claim that the CA should be able to produce the
> entire provenance chain for the DNSSEC-signed leaf record. This would be
> the chain of KSKs, ZSKs, the signed RRSets, as well as the DS records,
> disabling caching for all of these (or, presumably, duplicating it such
> that the .com KSK and ZSK are recorded for millions of certs).
>
>
>
> 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), a provenance chain ultimately merely
> serves to establish, in practice, one of a series of 512-bit RSA
> signatures. Are we to believe that these 512-bit signatures, on whose keys
> have explicitly expired, are somehow a smoking gun? Surely not, that'd be
> laughably ludicrous - and yet that is explicitly what you propose in the
> quoted text.
>
>
>
> So, again I ask, 

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

[Paul Wouters via dev-security-policy]

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 key sizes. It
might be done as an _attack_ but it would be a very questionable
deployment.

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.


However, let us not pretend that recording the bytes-on-the-wire DNS
responses, including for DNSSEC, necessarily helps us achieve some goal
about repudiation. Rather, it helps us identify issues such as what LE
highlighted - a need for quick and efficient information scanning to
discover possible impact - which is hugely valuable in its own right, and
is an area where I am certain that a majority of CAs are woefully lagging
in. That LE recorded this at all, beyond simply "checked DNS", is more of a
credit than a disservice, and a mitigating factor more than malfeasance.


I see no reason why not to log the entire chain to the root. The only
exception being maliciously long chains, which you can easilly cap
and error out on after following about 50 DS records?

Paul
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Tim Hollebeek via dev-security-policy]

What that wall of text completely misses is the point I and others have been 
trying to make.

 

The logs have to have enough information so you don’t end up in the situation 
Let’s Encrypt is currently, and unfortunately, in.  Yes, what they did is 
compliant, and that’s exactly what most concerns me.  It’s not about Let’s 
Encrypt, which just appears to have made a mistake, it happens.  It’s about 
whether the rules need to be improved to reduce the likelihood of another CA 
ending up in the same situation.

 

As a separate issue, we’re looking into making sure we never end up in that 
situation, and as you say, other CAs should be too.  We always reserve the 
right to do things that vastly exceed minimal compliance.

 

That should be something you should support, instead of producing increasingly 
long and condescending walls of text.  I know how DNSSEC works.

 

-Tim

 

From: 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 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, and we think those concerns should not be the driving force 
in logging requirements (within reason).

 

Are there other good reasons not to keep the DNSSEC signed RRs associated with 
DNSSEC CAA lookups?

 

I believe you are operating on a flawed understanding of the value of DNSSEC 
for forensic purposes, given the statement that "I absolutely would expect 
Let's Encrypt to produce DNSSEC signed RRs that match up to their story. The 
smoking gun for such scenarios exists, and CAs are, or should be, under no 
illusions that it's their job to produce it."

 

To me, this demonstrates a flawed, naive understanding of DNSSEC, and in 
particular, its value in forensic post-issuance claims, and also a flawed 
understanding about how DNS works, in a way that, as proposed, would be rather 
severely damaging to good operation and expected use of DNS. While it's easy to 
take shots on the basis of this, or to claim that the only reason not to store 
is because disk space, it would be better to take a step back before making 
those claims.

 

DNSSEC works as short-lived signatures, in which the proper operation of DNSSEC 
is accounted for through frequent key rotation. DNS works through relying on 
factors such as TTLs to serve as effective safeguards against overloading the 
DNS system, and its hierarchal distribution allows for effective scaling of 
that system.

 

A good primer to DNSSEC can be had at 
https://www.cloudflare.com/dns/dnssec/how-dnssec-works/ , although I'm sure 
many other introductory texts would suffice to highlight the problem.

 

Let us start with a naive claim that the CA should be able to produce the 
entire provenance chain for the DNSSEC-signed leaf record. This would be the 
chain of KSKs, ZSKs, the signed RRSets, as well as the DS records, disabling 
caching for all of these (or, presumably, duplicating it such that the .com KSK 
and ZSK are recorded for millions of certs).

 

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), a provenance chain ultimately merely serves to establish, in 
practice, one of a series of 512-bit RSA signatures. Are we to believe that 
these 512-bit signatures, on whose keys have explicitly expired, are somehow a 
smoking gun? Surely not, that'd be laughably ludicrous - and yet that is 
explicitly what you propose in the quoted text.

 

So, again I ask, what is it you're trying to achieve? Are you trying to provide 
an audit trail? If so, what LE did is fully conformant with that, and any CA 
that wishes to disagree should look inward, and see whether their audit trail 
records actual phone calls (versus records of such phone calls), whether their 
filing systems store the actual records (versus scanned copies of those 
records), whether all mail is delivered certified delivery, and how they recall 
the results of that certified delivery.

 

However, let us not pretend that recording the bytes-on-the-wire DNS responses, 
including for DNSSEC, necessarily helps us achieve some goal about repudiation. 
Rather, it helps us identify issues such as what LE highlighted - a need for 
quick and efficient information scanning to discover possible impact - which is 
hugely valuable in its own right, and is an area where I am 

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

[Ryan Sleevi via dev-security-policy]

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, and we think those concerns should not be the
> driving force in logging requirements (within reason).
>
>
>
> Are there other good reasons not to keep the DNSSEC signed RRs associated
> with DNSSEC CAA lookups?
>

I believe you are operating on a flawed understanding of the value of
DNSSEC for forensic purposes, given the statement that "I absolutely would
expect Let's Encrypt to produce DNSSEC signed RRs that match up to their
story. The smoking gun for such scenarios exists, and CAs are, or should
be, under no illusions that it's their job to produce it."

To me, this demonstrates a flawed, naive understanding of DNSSEC, and in
particular, its value in forensic post-issuance claims, and also a flawed
understanding about how DNS works, in a way that, as proposed, would be
rather severely damaging to good operation and expected use of DNS. While
it's easy to take shots on the basis of this, or to claim that the only
reason not to store is because disk space, it would be better to take a
step back before making those claims.

DNSSEC works as short-lived signatures, in which the proper operation of
DNSSEC is accounted for through frequent key rotation. DNS works through
relying on factors such as TTLs to serve as effective safeguards against
overloading the DNS system, and its hierarchal distribution allows for
effective scaling of that system.

A good primer to DNSSEC can be had at
https://www.cloudflare.com/dns/dnssec/how-dnssec-works/ , although I'm sure
many other introductory texts would suffice to highlight the problem.

Let us start with a naive claim that the CA should be able to produce the
entire provenance chain for the DNSSEC-signed leaf record. This would be
the chain of KSKs, ZSKs, the signed RRSets, as well as the DS records,
disabling caching for all of these (or, presumably, duplicating it such
that the .com KSK and ZSK are recorded for millions of certs).

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), a provenance chain ultimately merely serves to
establish, in practice, one of a series of 512-bit RSA signatures. Are we
to believe that these 512-bit signatures, on whose keys have explicitly
expired, are somehow a smoking gun? Surely not, that'd be laughably
ludicrous - and yet that is explicitly what you propose in the quoted text.

So, again I ask, what is it you're trying to achieve? Are you trying to
provide an audit trail? If so, what LE did is fully conformant with that,
and any CA that wishes to disagree should look inward, and see whether
their audit trail records actual phone calls (versus records of such phone
calls), whether their filing systems store the actual records (versus
scanned copies of those records), whether all mail is delivered certified
delivery, and how they recall the results of that certified delivery.

However, let us not pretend that recording the bytes-on-the-wire DNS
responses, including for DNSSEC, necessarily helps us achieve some goal
about repudiation. Rather, it helps us identify issues such as what LE
highlighted - a need for quick and efficient information scanning to
discover possible impact - which is hugely valuable in its own right, and
is an area where I am certain that a majority of CAs are woefully lagging
in. That LE recorded this at all, beyond simply "checked DNS", is more of a
credit than a disservice, and a mitigating factor more than malfeasance.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Tim Hollebeek via dev-security-policy]

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 logging requirements (within reason).

 

Are there other good reasons not to keep the DNSSEC signed RRs associated with 
DNSSEC CAA lookups?

 

-Tim



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

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 failures.
>
> In fact, inspired by this issue, we are taking a look internally at what we
> log, and
> considering the feasibility of logging even more information, including
> full
> DNSSEC
> signed RRs.
>

Hi Tim,

I'm not sure why you mentioned disk space - could you help me understand
why you brought that up?

It doesn't actually seem to respond to the question - which is the TTLs and
key sizes of DNSSEC records affect both the verifiability of such
information and its ability to be used for non-repudiation (which is
ostensibly the goal of such record keeping)

I think your response presently rather severely misunderstands DNSSEC or
what the implications of what you propose mean, but I look forward to
DigiCert actually sharing what it proposes to do, so that the community can
discuss whether it reasonably achieves those goals with a proposed
implementation. Otherwise, we are arguably no different from where we are
today, in which CAs do what they believe is reasonable for one purpose, but
perhaps fail to achieve that in light of potential risks.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Tim Hollebeek via dev-security-policy]

> 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 what we
log, and
considering the feasibility of logging even more information, including full
DNSSEC 
signed RRs.

-Tim



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy