On Wed, Apr 26, 2017 at 3:17 PM, Peter Kurrasch <fhw...@gmail.com> wrote:
> Hi Ryan-- > > To your first comment, I'm afraid I won't have the time to take a closer > look at the discussion on 3.2.2.4. Hopefully a path from single domain to > unlimited domains exists (or will). It makes sense to me (without fully > considering the consequences) that a "special" validation path be used for > wildcards. Perhaps it could be part of an existing validation method, I'm > not sure. Bottom line though, I don't think it makes sense that anyone and > everyone be allowed to obtain a wildcard cert. > Right, but there's definitely a more careful argument you'll need to make, because that is _precisely_ what is (effectively) desired, not just by CAs, but most users of more than a few TLS certificates. I'm not even sure that I disagree with you - my history in the CA/Browser Forum hopefully demonstrates Google's deep concern with the security of the validation methods, the capabilities possible with each validation method, and the frequency of which they're performed. However, finding consensus is, at this point, difficult, despite it being plainly obvious to folks with a security background :) For context, I've been pushing for exploring CAA methods to reduce the permissible validation methods, and CAA already has the ability to restrict wildcard issuance via issuewild to set a of CAs, for which you can then establish a defined procedure. So if your concern is helping protect a _competent_ organization from a rogue wildcard, that already exists and is (in the process of) being required. Let's suppose we break up everyone with a server on the Internet into 3 > categories based on the size of their Internet presence: substantial, > intermediate, and tiny. A "substantial" presence almost certainly has a > large enterprise behind it with staff and capital resources to maintain the > service. If we can assume that such organizations have tighter controls > over use of the domain name space, servers, certificates, and so forth, > then I think some of the risks posed by wildcard certs are reduced. That > being the case, I'm less concerned about this category. > Regrettably, I think this inverts the priority. "substantial" presence are often the slowest to deploy, have the most complexity in their infrastructure, and similarly, suffer the greatest risk from a rogue wildcard. > For an "intermediate" presence, I'm thinking of places like universities > that have a large number of subdomains in use but might not have a good set > of controls over use of the domain name space and certificates and so > forth. In this type of setting I think the use of wildcards might be > appealing because it simplifies management of the network but if the > controls are not in place, there remains a certain level of risk that these > certs pose. (And to be fair, this isn't to say that only academic > environments face this situation or that all academic environments are not > suitably managed.) This category can be of concern. > This is most organizations :) > The "tiny" category almost speaks for itself and probably applies to all > individuals and small businesses--people who want some presence but might > not be all that diligent about it. In other words, these are the systems > that probably have the weakest security measures in place. These are the > systems that are regularly compromised and used for spam campaigns, fake > login screens, and such. This is also the category for whom wildcard certs > pose the greatest risk to everyone else. > I disagree that you can attribute that cost to wildcards. That's the cost of the organization itself. The wildcard doesn't really contribute or change that calculus. > ...and all sorts of variants of the above. Per the wildcard cert, all of > the above domains are perfectly valid. Per the actual intent of the domain > holder, most of the above are surely not valid. > CAA solves that ;) > So, the problem becomes how a relying party may determine if the > site/domain is legitimate. If I have some indicator in the browser UI that > says "secure" because the FQDN matching has been satisfied, I'll probably > proceed to use the page that is presented. If the indicator is missing, > there is a chance I'll think twice about proceeding any further. The > trouble in this situation is that if the FQDN is nefarious but satisfies > the wildcard contained in the cert, I will probably make the wrong decision > and open myself up to who knows what. > But that's no different than shopping Target or Home Depot and their credit card processor / POS terminal being compromised, is it? You trusted an organization with an insufficient security practice relative to the threats faced. We don't say credit cards caused Target to be hacked though! _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
