Copying message accidentally sent directly to a list participant. ---------- Forwarded message ---------- From: Matthew Hardeman <mharde...@gmail.com> 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 <r...@sleevi.com>
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 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
