From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Monday, January 15, 2018 4:14 PM To: Doug Beattie <doug.beat...@globalsign.com> Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org; Gervase Markham <g...@mozilla.org>; Wayne Thayer <wtha...@mozilla.com> Subject: Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment
On Mon, Jan 15, 2018 at 3:36 PM, Doug Beattie via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: Ryan, I’m not sure where we go from here. As suggested, we encourage you to work on devising technical mitigations or alternative methods of validating such certificates that can meet the use case. We don't think that, as described, the OneClick method meets the necessary level of assurance, nor do the necessary level of mitigating factors exist, to consider such certificates trustworthy. Ryan – I’m at a loss. The security threat is that a user can request a certificate for a domain they don’t own from hosting companies that permit SNI mappings to domains the user doesn’t own or control. This permits them to pass validation for a domain they don’t control that is on the same IP address as their legitimate site (or at least to which they have this level of SNI control). We will verify that our OneClick customers will request certificates for domains the hosting company is actively managing for their users and not permit malicious actions (much like LE verifying that their hosting companies do not permit “acme.invalid” domains to be used). This eliminates the problems of SNI being used as an avenue for domain validation for malicious actors. Is this not sufficient for some reason? Surely you agree that within non-shared hosting environments OneClick is not vulnerable and can be used. We have customers that need certificates and they have demonstrated they can comply with not permitting the creation and use of certificates for domains other than those that the hosting company is hosting for that customer. All certificates will continue to be posted to CT logs. While understanding and sensitive to this, what you're asking is that, on the basis of an abstract need, that known-insecure methods be used, with the assurance that the CA has taken steps (which are fundamentally non-interoperable) to mitigate, and for which an improper decision by a CA has no further mitigating factors. This does not provide a sufficient level of assurance to permit its continued use. As far as the wildcard question, when someone asks for a wildcard cert for a domain like *.us.example.com<http://us.example.com>, we validate on that minus the * (so, us.example.com<http://us.example.com> in this case). I'm afraid you're still missing the point of FQDN versus Authorization Domain Name. This further does not instill confidence that it's fully been described. We’re using us.example.com as the ADN for validation in this example. We always use the FQDN minus “*.” For the ADN. We’d like to move forward with issuing certificates with controls in place. I'm sorry, but at present, we do not feel it is in the appropriate interests of users, sites, or the ecosystem to permit this. If there are any other controls you need us to implement to resume issuance, let us know. For example, if we limit validity to 1 year (possibly up to 15 months) and if we put a firm end date for OneClick for July 1, 2018, would that suffice? As stated, we believe 90 days is an appropriate and necessary upper-bound for such certificates. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
