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 <dev-security-policy@lists.mozilla.org <mailto: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 <mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy
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
