On Monday, August 15, 2016 at 5:21:44 AM UTC-7, Hanno Böck wrote: > Would you be interested in working on a proposal on that for the > CA/B-Forum? (I'm not allowed to post there, so I can't directly > have that disucssion.)
https://twitter.com/sleevi_/status/573520611139440641 https://twitter.com/sleevi_/status/657451590110982144 Or just apply as an "Interested Party", as described at https://cabforum.org/wp-content/uploads/CA-Browser-Forum-Bylaws-v.-1.4.pdf , as some members of this list already have. > I'm a bit disappointed that this incident hasn't caused more > discussion. I think the domain validation process is one of the most > sensitive pieces of the CA ecosystem and should receive extra security > care. The CA/Browser Forum just passed an update to 3.2.2.4, which took nearly two years, which significantly overhauls the system. It could be that 1) People are somewhat exhausted right now after the significant overhaul that just worked to close much more serious lapses in validation methods 2) This is not, in the scheme of things, as significant a risk as some of the other ways to screw up 3) There hasn't been a concrete proposal that attempts to resolve the various concerns between usability, security, and practicality of attack. > And the verification emails are an extremely common way of doing > domain validation. I hesitate to say "citation needed," but I know there's simply no public source that can support that claim of extremely common. In the grand scheme of things, I don't think this is as urgent a security issue as it would seem you may feel, but I think if you are passionate about finding a solution, and have concrete suggestions and the willingness to understand the tradeoffs, joining/signing the IPR policy and proposing solutions is a great way. You could, alternatively, propose solutions here as they apply to the Mozilla Policy, in the hope they'll be "upstreamed" to the Baseline, but either way, there's plenty of avenues at your disposal to improve things if you feel. > I understand that use-case, yet I still see a significant risk in any > user-controlled content even in text-only mails (there are most likely > mail implementations out there that can be tricked into rendering html > inside a text-only mail). Usually, in cases like this, it helps if you think about the threat models and actually elaborate them, otherwise, there's unlikely to be any improvement or compromise. I certainly agree with Robin here - that there's a real usability issue for such a blanket ban, and I'm not sure it practically improves things in the grander scheme. > If forbidding user-controlled content is a no-go for some I'd like to > see at the very least some very clear and specific guidelines on how to > filter or escape them. What I'd like to have is something that can be > checked and pointed out by security researchers if it isn't done. I'm not sure this is really a practical thing, as you're discussing moreso the hypothetical - indepedendent security researchers doing blackbox testing of the entire CA ecosystem is ... somewhat unreasonable. This is why we have procedures like audits, which ensure a common baseline across the industry. If you think in the mindset of auditable controls (as your first-line defense), rather than thinking blackbox testing (which simply can't scale appropriately to the entire ecosystem to be considered a reasonable defense), it may lead to alternative solutions. Anyways, if you would like to review what's actually in the BRs, apply an "auditable policy" hat (either through disclosure in CP/CPSes or as samples auditors can perform), that'd be good. Ideally, you want to describe something technically enforcible, so it might be able to examine an entire corpus of emails. But, from experience, I would say it's much easier to say what we'd like to see, and much harder to actually word that in a concrete proposal (either for the BRs or for Mozilla Policy) that can actually be consistently evaluated and enforced. Cheers! _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
