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 < dev-security-policy@lists.mozilla.org> 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 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. > > > > > _______________________________________________ > 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
