On Mon, Sep 12, 2016 at 5:46 PM Ryan Sleevi <[email protected]> wrote: > On Wednesday, August 31, 2016 at 12:43:50 PM UTC-7, Nick Lamb wrote: > > I have spent some time thinking about this, but I am only one person, > and one with relatively little in-depth knowledge of the Mozilla project, > so I think I will lay out the options I've thought about and invite > feedback though particularly any alternative suggestions. > > Returning to the topic of this thread, there were a number of alternatives > put forward that didn't raise to the summary level captured here: > > > https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/hj_KMPGUDAAJ > > To recap, and to combine your suggestions, we have: > A) Distrust with option to manually add back > B) Distrust with no option to manually add back (aka Blacklist) > C) Distrust with Whitelist of Certs > C.1) Whitelist based on all certs (several hundred thousand) > C.2) Whitelist based Alexa Top 1M (~60 thousand) > D) Trust w/ Heuristic > D.1) Certs with notBefore < some date trusted implicitly, certs with > notBefore > some date are CT logged > D.2) Trust if C=CN is present in subject name (WoSign's proposal) > E) Trust w/ PR > E.1) Require some form of mandatory disclosure of misissuance > F) Trust w/o any action > > > Nick's proposal #1 is was already captured by D1 in the previous thread. > Nick's proposal #2 is captured by E1 > Nick's proposal #3 is captured by F (no concrete steps were proposed) > > I've not included the RP discussion in the above summary, because I don't > believe it talks to actions short of distrust, but about alternative > methods of determining trustworthiness. It doesn't provide an actionable > framework, for, say dealing with issues that arise when a CA behaves > against the public interest. > > > To that end, I'm going to offer one more suggestion for consideration: > G) Distrust with a Whitelist of Hosts >
In general, I like Option G idea purely as a space saving version of Option C. That is, whitelisting certificates would be ideal. > > The issue with C is that it becomes easily inflated by issuing > certificates, even if they're not used; that is, a free certificate > provider can easily exceed a reasonable size of a whitelist, by issuing > many certificates for a given host, even if they're not used. > > Whitelisting by hostname may offer a reasonable solution that balances > user need and performance. > > > Consider if we start with the list of certificates issued by StartCom and > WoSign, assuming the two are the same party (as all reasonable evidence > suggests). Extract the subjectAltName from every one of these certificates, > and then compare against the Alexa Top 1M. This yields more than 60K > certificates, at 1920K in a 'naive' whitelist. > > However, if you compare based on base domain (as it appears in Alexa), you > end up with 18,763 unique names, with a much better compressibility. For > example, when compared with Chrome's Public Suffix List DAFSA > implementation (as one such compressed data structure implementation), this > ends up occupying 126K of storage. > While I personally have no issue drawing the distinction at the Alexa Top 1M, this is still somewhat of an arbitrary cut off. Beyond the arbitrary nature, there's a large amount of churn of domains within the Top 1M. A co-researcher in my group encountered over 1.5M unique domains in the Top 1M over a two month period from March-May 2016. I haven't ran the long term numbers myself, but will note that Censys/ScansIO have historical Top 1M inclusion data [1]. Should this churn be factored into the whitelist? Which Top 1M list is the "right" Top 1M list? > 126K may be within the range of acceptable to ship within a binary. > Further, there are a number of things that can be done to reduce this > overhead: > > 1) Large vendors (such as microsoft.com and amazonaws.com) appear within > this list, but likely don't wish to; this gives a natural reduction function > 2) This doesn't fully account for revocations > 3) It could be combined with, say, requiring CT for new certs. While this > is hardly a perfect function, given the backdating, it could effectively > monitor the issuance of new certificates. > Given that we _know_ backdating is an issue, I don't really see the point of requiring CT for new certs, especially if the end goal is to remove StartCom/WoSign (I don't know what any other end goal would be). If we're worried about actual malicious issuance, acquiring a backdated certificate seems well within reason. That being said, in the current post-Symantec-require-CT-world, the bar to adding this requirement seems low, provided StartCom/WoSign are embedding SCTs in new certificates. > 4) The Alexa list includes known third-party domain providers (e.x. > myqnapcloud.com, myasustor.com) that could be factored out, as they're > not centrally managed > 5) Names naturally expire on this list, giving a reasonable stepping > function > 6) I would also add that some domains will likely change certificate authorities, as the WoSign news percolates outside of the "HTTPS Enthusiast" circles, enabling the list to be stepped down even faster. > This could be combined with a large scale distrust, and operates on the > theory that the primary concerns with a distrust event are minimizing user > impact, while allowing sites sufficient time to migrate, and this could > offer a one-or-two-release-cycle "graceful turndown" of a CA. If other > browsers were able to adopt such a solution, such that the industry could > be in rough harmony, this could offer a graduated point to distrust. > [1]: https://scans.io/series/alexa-dl-top1mil > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
