On 18/07/17 17:51, Matthew Hardeman wrote:
> The broader point I wish to make is that much can be done do improve the 
> strength of the various subset of the 10 methods which do rely solely on 
> network reliant automated validation methodologies.  The upside would be a 
> significant, demonstrable increase in difficulty for even well placed ISP 
> admins to compromise a compliant CAs validation processes.  The downside 
> would be increases in cost and complexity borne by the compliant CA.

Your point, in the abstract, is a reasonable one, but so is your further
point about trade-offs. The only way we can really make progress is for
you to propose specific changes to the language, and we can then discuss
the trade-offs of each.

> I noticed that too.  I assume it is still tied up in IPR hell?

No. IPR issues are solved. We are currently in arguments about what, if
any, additional necessary fixes to the text should go into the "restore
the text" ballot and what should go into a subsequent ballot, along with
the question of whether and which existing domain validations to
grandfather in and which to require that they be redone.

> I would advocate a level playing field here.  This would have the bonus 
> upside of helping to fix bad DNSSEC deployments.  If broken DNSSEC broke 
> ability to get a certificate anywhere, either the incorrect deployment would 
> likely be rolled back in the worst case or fixed in the best.

Certainly for CAA, we don't allow broken DNSSEC to fail open. I hope
that will be true of DNS-based validation methods - either after 190
passes, or soon after that.

> I believe there would be a massive improvement in the security of DNS query 
> and HTTP client fetch type validations if the CA were required to execute 
> multiple queries (ideally at least 3 or 4), sourced from different physical 
> locations (said locations having substantial network and geographic distance 
> between them) and each location utilizing significantly different internet 
> interconnection providers.

How could such a requirement be concretely specced in an auditable way?

dev-security-policy mailing list

Reply via email to