On Fri, Jan 12, 2018 at 4:24 PM, Doug Beattie <doug.beat...@globalsign.com> wrote:
> Wayne, > > > > We didn’t really investigate wildcard issuance yet, but we can. > > > > Given the discuss so far, we’re planning to proceed with a whitelisting > approach tomorrow and we will plan to end the use of Method 9 (schedule > TBD) which follows Let’s Encrypt handling of Method 10. If there are any > additional security concerns that we need to be made aware of, please let > me know and we can adjust the plan accordingly. > (Wearing a Google Hat) Doug, Thanks for sharing additional details. On the basis of what you've shared so far, we do not believe this results in an appropriate level of security for the ecosystem, and request that you do not re-enable issuance at this time. This applies for any CA using methods similar to what you're using. Broadly speaking, https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/HACyY9tMAAAJ has shared the some of the principles we've used in this consideration. If there is additional details that GlobalSign can share, related to those principles, this would be invaluable. This assessment is based on a number of factors, but includes: - The validity period of certificates issued via this method means that there is an unacceptably large window for certificates improperly issued to be used. - Based on the available information of expiration times and the potential difficulty in renewing certificates using this method, the ecosystem risk of disallowing this method is much less. - The subtleties regarding Authorization Domain Names means that the risk analysis provided is not sufficient - namely, it is unclear, as described, whether it is possible to obtain a certificate for "www.example.com", on a host that has a customer already configured on that domain (and checking/enforcing certificates), by first applying for a certificate for " example.com" as an attacker, providing and provisioning a test certificate using that method (which is not configured to serve a certificate by the 'victim'), and then using that subsequent authorization of the Authorization Domain Name to then apply for "www.example.com". Mitigating this as a site operator would necessitate blocking not just on existant domains, but also by the notion of Authorization Domain Name, and thus represents a significant greater complexity in both assessing compliance (for those on the whitelist) and for minimizing risk. - The potential risk in maintaining this whitelist, given both the statements provided by plans to move to deprecate this method post-haste (e.g. no such plans) and the validity period of issued certificates (up to 39 months or, soon, 825 days). - The lack of preexisting review and documentation of the specific protocol being employed - The potential risk of both domain name wildcards and of wildcard issuance, which remains While it is possible that you may be correct that the underlying root cause of TLS-SNI presents greater risk, compared to this method, the many mitigating factors that influenced our decision are not applicable here. As this thread shows, we anticipate we will continue to find variants of risk, and thus the whitelist approach, combined with the validity periods caused by the risk (both of issued certificates and "completed validations"), poses a long-term risk, even if we catch issues 'within days'. We'd like to continue discussing with GlobalSign and the community as to the risk posed by immediately and permanently disabling this method, as well as possible mitigations to the risk - both through issuance policies of GlobalSign and technical measures in the usage - that may permit its usage for a short-time to transition this method away. This is a conversation we look forward to having over the next week. In the interim, we'd ask you not re-enable this method. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
