As another tangent question on the advisability of resuming the TLS-SNI-01 validation method, can/will Let's Encrypt share any data on prevalence of the various validation mechanisms over time and how they stack up against each other in terms of prevalence. Also, it might be helpful to know attempted versus completed successfully.
I wonder how big a problem it is if all of the TLS-SNI-01/02 mechanisms go away? On Wed, Jan 10, 2018 at 3:45 PM, Matthew Hardeman <mharde...@gmail.com> wrote: > I agree with Nick's questions, and I can certainly see the relevance in > matching what actually happens out there to the effectiveness and > appropriateness of the various domain validation mechanisms. > > Having said that, I think it should effectively be a "read only" affair, > shaping community and CA response to the conditions that exist rather than > striving for better conditions. I think it would be impractical to assume > that the community can persuade the entire web hosting industry to effect > meaningful universal change in a relevantly short time frame. > > On Wed, Jan 10, 2018 at 3:05 PM, Nick Lamb via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Wed, 10 Jan 2018 15:10:41 +0100 >> Patrick Figel via dev-security-policy >> <dev-security-policy@lists.mozilla.org> wrote: >> >> > A user on Hacker News brought up the possibility that the fairly >> > popular DirectAdmin control panel might also demonstrate the >> > problematic behaviour mentioned in your report[1]. >> >> Although arguably tangential to the purpose of m.d.s.policy, I think it >> would be really valuable to understand what behaviours are actually out >> there and in what sort of volumes. >> >> I know from personal experience that my own popular host lets me create >> web hosting for a 2LD I don't actually control. I had management >> agreement to take control, began setting up the web site and then >> technical inertia meant control over the name was never actually >> transferred, the site is still there but obviously in that case needs >> an /etc/hosts override to visit from a normal web browser. >> >> Would that host: >> >> * Let me do this even if another of their customers was hosting that >> exact site ? If so, would mine sometimes "win" over theirs, perhaps if >> they temporarily disabled access or due to some third criteria like >> our usernames or seniority of account age ? >> >> * Let me do this for sub-domains or sub-sub-domains of other customers, >> including perhaps ones which have a wildcard DNS entry so that "my" >> site would actually get served to ordinary users ? >> >> * Let me do this for DNS names that can't exist (like *.acme.invalid, >> leading to the Let's Encrypt issue we started discussing) ? >> >> >> I don't know the answer to any of those questions, but I think that >> even if they're tangential to m.d.s.policy somebody needs to find out, >> and not just for the company I happen to use. >> _______________________________________________ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy >> > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
