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 <tim.holleb...@digicert.com> 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 <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> 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
