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 <tim.holleb...@digicert.com> Cc: r...@sleevi.com; Nick Lamb <n...@tlrmx.org>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org>; Jacob Hoffman-Andrews <jacob.hoffmanandr...@gmail.com> 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 <mailto: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 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.
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
