On Mon, Sep 12, 2016 at 2:46 PM, Ryan Sleevi <[email protected]> wrote: > To that end, I'm going to offer one more suggestion for consideration: > G) Distrust with a Whitelist of Hosts > > 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. > > 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. > 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
I'm not clear from this description, are you proposing to whitelist eTLD+1 or full hostnames? How large would the lists be if you whitelisted eTLD+1? I also think per-issuer whitelists might make more sense than a single massive WoSign/StartCom whitelist. This would have two advantages: 1) Helps limit blast radius of whitelisting a name/domain 2) Provides a path for WoSign/StartCom to continue issuing certificates for use with trust stores and users that continue to trust them. They could create new issuers from the existing roots which wouldn't be subject to the whitelist. Users who want to trust them simply need to add the roots to their trust store if the roots are not already there. Requiring new issuers would also allow #3 to be easily enforced over a disjoint set from the whitelist and allow various pinning-like rules to be created in software (browsers or otherwise). Thanks, Peter _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
