On Wed, Jan 10, 2018 at 6:35 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Agree. > > Hence my suggestion that TLS-SNI-0next use a name under the customer's > domain (such as the name used for DNS-01), not a name under .invalid.
I thought it had been pointed out, but that doesn't actually address the vulnerability. It presumes a hierarchal nature of certificate/account management that simply does not align with how the real world and how real providers work. I can understand why it might seem intuitive - and, I agree, for providers that create a lock between customer<->domain hierarchy, that might work - but I would assert that they're not unique. And given that the concern is precisely about those that *don't* do such bonding, it simply fails as a solution. In short, any solution that relies solely on the name will be technically deficient in the real world, as this issue shows us. So any 'solution' that proposes to shift the names around is to misunderstand that risk. > Disagree. > > In the world of real hosting providers, sometimes users often don't get > to control the DNS of a domain purchased through that hosting provider, > while they might still have the ability to "purchase" (for free from > letsencrypt.org) their own certificates and the ability to configure > simple aspects of their website, such as available files. > If they can't control the DNS (for permission reasons), then they didn't really purchase the domain. If they can't control the DNS for technical reasons, then that's a deficiency of the hosting provider, and that doesn't mean we should weaken the validation methods to accommodate those hosts who can't invest in infrastructure. But wouldn't the backward compatibility features of TLS itself (and/or > some permissive TLS / https implementations) either ignore ALPN > extensions when they "know" they are only going to serve up HTTP/1.x > (not HTTP/SPDY) or complete the TLS handshake before deciding that they > don't have an "acme" service to connect to? > No. You've misunderstood how ALPN works then. > And even if it wasn't so, most sites that do "control" the whole stack, > and run on their own dedicated machine and IP probably lack the ability > and/or patience to modify the https code in "their" web server. > Do you believe people are bespoke minting these ACME challenges on the fly? Because that's not how it's working in the real world - it's being based on tooling, generally directly integrated in the server to automatically enroll, manage, and renew (and indeed, that is explicitly what is recommended as the ACME integration). In such a model - i.e. how it works today - that lack of ability/patience is a non-issue, because it's simply handled by the ACME client without any additional work by the server operator - the same as it is today. > This may come back to the unfortunate use of BR language to redefine the > plain word "misissuance". > You can blame the BRs, but this is really simply a notion of the language of PKI, and this is not a new debate by any means, so probably not worth haggling about here, in as much as the nuance doesn't alter the conclusions, and the point stands that "The CA met their obligations, but the undesirable result happened". The solution for that is to fix the requirements to prevent undesirable results. If "The CA didn't meet their obligations", well, that's a different conversation. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
