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

[Matthew Hardeman via dev-security-policy]

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 was made.

I concur in full with the assertions and positions of Paul Wouters and Nick
Lamb in the matters discussed in this thread up to this point.

I believe CAA validation checks should incorporate the DNSSEC data where
DNSSEC has been deployed.  I believe the logs recorded by a CA should
preserve that data which was relied upon in the issuance decisioning.

I have some concerns pertaining to the state of logging as would appear to
be alluded to by Jacob Hoffman-Andrews.  Specifically, I find some cause
for concern in the fragment "because it was not possible to associate
specific query/response pairs with the validation request that caused them
(for instance, consider NS referrals, CNAME indirection, and caching)".

This would appear to indicate that while Let's Encrypt may log either the
final response from their recursive resolver or some derivation of data
from the final response from their recursive resolver, Let's Encrypt may
not be logging _which_ particular entity within the DNS hierarchy they are
utilizing as the controlling CAA record - or at least, this language
suggests that for some circumstances they are not recording the underlying
delegations/reasons for which a given CAA record somewhere in the
DNS hierarchy was utilized when attempting to clear issuance for a given
domain label.  That becomes a bit concerning, as I would expect that a CA
relying on a CAA record at "
ok-sure.multiple-layers-of-indirection.my-crazy-dns-service.com" bearing
tag "issue" with value "letsencrypt.org" when authorizing issuance of a
certificate for dnsName "a.example.com" should be able to explain the chain
of facts which made that CAA record at that position within the
DNS hierarchy authoritative for the domain label in question.

There arises a potential further concern if this logging of DNS data upon
which a CA's decisions rely pertains to DNS queries for function beyond CAA
clearance.  For example, the DNS queries associated with domain control
validation over a given domain label.  Consider the software package
acme-dns which assists domain holders with delegating the ACME dns-01
validation records onto a specialized DNS server which responds with the
correct dynamic responses while allowing the underlying domain to have
static delegations for the TXT records back in the actual authoritative
zones of any number of domains that they don't want to migrate to dynamic
DNS services.  That's a great use case and should not be discouraged.
Neither, however, should it the case that the CA's logging only has the
response of the final result from the acme-dns server.  The logs should
contain the DNS query responses which connected that record served up by
the acme-dns server to the delegation that granted that authority to the
acme-dns server on behalf of the authorization domain name.

On Wed, May 23, 2018 at 11:25 AM, Paul Wouters via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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/tma
>> 2017_paper58.pdf has some fairly damning empirical data about the
>> reliability of those
>> records, which is not in line with your anecdata.
>>
>
> My "anecdata" is Viktor Dukhovni's constant monitoring of all known
> DNSSEC zones. It's data is current to a few days. The article you
> quote used data up to Jan 2017, so is 1.5 years old. Still, it only
> listed 275k out of 7M ZSK's being 512 bit RSA. I suspect it to be
> due to one or a few providers who used to do that, but clearly no
> longer do this since the current total is far lower at 12k out of
> roughly the same sample size of 7M. Calling this data anecdata
> isn't going to change anything other then my professional opinion
> of you.
>
> 512 bit RSA keys was never a real thing in DNSSEC. I packaged up the
> earliest versions of DNSSEC software for RHEL/CentOS/Fedora and it
> never did anything less then 1024 for ZSKs, which was changed to 2048
> bit on Mar 27 2014. KSK's were always 2048. I'm pretty sure the Debian
> and Ubuntu packagers also didn't reduce the default upstream ZSK
> keysizes to 512 bit.
>
> But I'd love to read your research on where people advised you to roll
> the ZSK at "24 - 72 hours" intervals. Do you have any links to
> presentations given at any technology conference like DNS-OARC, RIPE,
> IETF or ICANN?
>
>   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 

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

[Tim Hollebeek via dev-security-policy]

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 incorrectly, a hesitation that adding at least some 
information about DNSSEC lookups would blow up the size of log files and would 
be difficult at scale.  Our discussion internally reached the conclusion that 
we’re supportive of requiring even more extensive CAA logging, even if it is 
expensive.  At Let’s Encrypt’s scale and our scale, that’s an important 
concern, and we think it should be publicly discussed (Comodo’s perspective 
would be interesting too).  So that’s what I was thinking and ended up saying 
really, really badly.

 

Your discussion here is excellent and worthy of a longer term discussion.  I 
was thinking more along the lines of “are there any appropriate quick fixes we 
might want to consider?”  The answer may be no.  But I do find it dangerous 
that minimal compliance with the current requirement can lead to situations 
like this.  That alone makes me want to improve the requirement.

 

And while I’m on the subject, since it’s related: Jeremy and I do have a new 
policy of trying to err on the side of publicly oversharing internal 
information and deliberations, whenever we can.  We think it’s the right thing 
to do.

 

-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 offering other 
interpretations (such as it being about disk space [2]), when the concern was 
precisely about trying to find a full cryptographic proof that can be stable 
over the lifetime of the certificate - which for Let's Encrypt is 90 days, but 
for some CAs, is up to 825-days [3].

 

As a systemic improvement, I think we're in violent agreement about the goal - 
which is to make sure that when things go wrong, there are reliable ways to 
identify where and why they went wrong - and perhaps simply in disagreement on 
the means and ways to effect that. You posited that the original motivation was 
that this specifically could not occur - but I don't think that was actually 
shared or expressed, precisely because there were going to be inherent limits 
to that information. I provided examples of where and how, under the existing 
BRs, that the steps taken are both consistent with and, arguably, above and 
beyond, what is required elsewhere - which is not to say we should not strive 
for more, but is to put down the notion from (other) contributors that somehow 
there's been less here.

 

I encouraged you to share more of your thinking, precisely because this is what 
allows us to collectively evaluate the fitness for purpose [4] - and the 
potential risks that well-intentioned changes can pose [5]. I don't think it 
makes sense to anchor on the CAA aspect as the basis to improve [6], when the 
real risk is the validation methods themselves. If our intent is to provide 
full data for diagnostic purposes, then how far does that rabbit hole go - do 
HTTP file-based validations need to record their DNS lookup chains? Their IP 
flows? Their BGP peer broadcasts? The question of this extreme rests on what is 
it we're trying to achieve - and the same issue here (namely, CAA being 
misparsed) could just as equally apply to HTTP streams, to WHOIS dataflows, or 
to BGP peers.

 

That's why I say it's systemic, and why I say that we should figure out what it 
is we're trying to achieve - and misguided framing [1] does not help further 
that.

 

[1] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/7L2_zfgfCwAJ

[2] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/gUT3t7B1CwAJ

[3] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/O7QTGmInCwAJ

[4] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/juHBkWV4CwAJ

[5] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/O5rwCV96CwAJ

[6] 
https://groups.google.com/d/msg/mozilla.dev.security.policy/7AcHi_MgKWE/lpU2dpl8CwAJ

 

 

On Wed, May 23, 2018 at 11:29 AM, Tim Hollebeek via dev-security-policy 
 > wrote:

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?  I’ll repeat that this isn’t a criticism of Let’s Encrypt, other than 
they had a bug like many of us have.  Mozilla wants this to be 

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

[Tim Hollebeek via dev-security-policy]

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?  I’ll repeat that this isn’t a criticism of Let’s Encrypt, other than 
they had a bug like many of us have.  Mozilla wants this to be a place where we 
can reflect on incidents and improve requirements.

 

I’m not looking for something that is full cryptographic proof, that’s can’t be 
made to work.  What are the minimum logging requirements so that CAA logs can 
be used to reliably identify affected certificates when CAA bugs happen?  
That’s the discussion going on internally here.  Love to hear other thoughts on 
this issue.

 

Also, we’re trying to be increasingly transparent about what goes on at 
DigiCert.  I believe we’re the only CA that publishes what we will deliver 
*next* sprint.  I would actually like to share much MORE information than we 
currently do, and have authorization to do so, but the current climate is not 
conducive to that.

 

The fact that I tend to get attacked in response to my sharing of internal 
thinking and incomplete ideas is not helpful or productive.  It will 
unfortunately just cause us to have to stop being as transparent.

 

-Tim

 

I am opposed to unnecessary grand-standing and hand-wringing, when demonstrably 
worse things are practiced.

 



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: OISTE WISeKey Global Root GC CA Root Inclusion Request

[Pedro Fuentes via dev-security-policy]

Thanks Wayne and Ryan, your feedback always helps us to improve.

I'll respond in a separate message to Ryan concerns/questions.

Only about the audit periods... it's not easy to synchronize everything, so 
what we did is the following:
- A point-in-time audit after the Root was created
- A three-month first period audit, as required by the different root store 
policies

We supplied the positive audit reports for these PiT and Period audits, but not 
the seals, as we typically would do that once the Roots are included and part 
of the annual audit.
  
From that point on, the Root and its hierarchy is included in the annual audit, 
that already engaged with the auditors. This would produce the adequate audit 
reports and the respective Webtrust seals.

As said, more answers to come in a while.

Best,
Pedro

El martes, 22 de mayo de 2018, 22:38:42 (UTC+2), Wayne Thayer  escribió:
> 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