> On Mar 28, 2018, at 3:15 AM, Eric Rescorla <[email protected]> wrote: > > > > On Wed, Mar 21, 2018 at 1:55 PM, Roland Bracewell Shoemaker > <[email protected]> wrote: > The argument for removing this was that there are no technical issues with > the method as-is but that the reverse DNS zones are historically badly > managed and that using them for validation will cause problems down the line > (presumably misissuance by a person who controls the zone but doesn’t > actually control the IPs the zone represents). > > I'm not sure why you don't think this is a technical issue. >
I don’t think this is a technical issue because technically it is essential exactly the same as the existing DNS validation method. The only difference being instead of needing to trust the root and TLD zones you need to trust the reverse zones. I think the DNS method is technically sound but if it were managed in the way you and others are suggesting then it would be equally broken. To me the issue is not technical but operational. If for whatever reason the management of the reverse zone was brought into line with the defined expectations of how it is meant to be managed this method would seemingly not be an issue for everyone. > In any case, this is part of the argument, but not the only part. The reason > that the forward DNS lookup check is reasonable (to the extent to which it > is) is that forward DNS resolution is an integral part of going to the site, > and therefore control of the DNS substantively *is* control of the site > (i.e., there is fate sharing). By contrast, reverse resolution forms no part > of addressing the site, and therefore control of this region of the DNS > proves nothing about your control of the site. This is, of course, why the > reverse tree is in such bad shape. > Again I think this is an operational issue, as defined in RFC 1034, 1912, 3172, 5855, etc etc the reverse zones are meant to be a reliable inverse mapping from address to host name, which if believed should allow us to use them as a viable method for validating control of addresses. While I agree this is a weaker guarantee of control than forward DNS I don’t think it is so substantively worse that it sould not be used (again as defined, I take no issue with the arguments that it is badly managed). > > The argument for keeping it is that the IETF (or more specifically the ACME > WG) should not be where CA or browser policy is dictated and that given these > methods are currently allowed under the CABF BRs and browser root programs it > would actually be useful to have a technically defined method for validation > that can at least be used as a tool for further research on the topic. > > It's not a matter of dictating CA or browser policy, but of not standardizing > a method of validation which we know to be severely flawed. In no way does > this preclude other people from deploying this authentication mechanism; the > standard for registering an identifier in this space is "Specification > Required" and the standard the expert is supposed to evaluate is quite low > (https://tools.ietf.org/html/draft-ietf-acme-acme-11#section-9.7.8). > > When evaluating a request for an assignment in this registry, the > designated expert should ensure that the method being registered has > a clear, interoperable definition and does not overlap with existing > validation methods. That is, it should not be possible for a client > and server to follow the same set of actions to fulfill two different > validation methods. > > If CAs wish to experiment with -- or even use -- this technique, they need > only publish a specification. The difference is that the IETF would not be > endorsing it. > > -Ekr > > I personally think it would be nice to standardize a method of doing this type of validation, given it is something currently being used in the wild be CAs, but since there seems to be staunch oppopsition to doing so and at least the one user we had whom was interested in doing this have found another way of doing what they want I think at this point it makes sense to just scrap it. Unless someone else pops out of the woodwork with strong opinions I’ll remove the method and publish a new version of the draft after I return from vacation. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
