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. 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. > 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
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
