On 3/27/2018 9:15 PM, Eric Rescorla wrote:
On Wed, Mar 21, 2018 at 1:55 PM, Roland Bracewell Shoemaker
<rol...@letsencrypt.org <mailto:rol...@letsencrypt.org>> 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.
There's actually a larger problem here that's been overlooked as far as
I can tell. Specifically, an operator of a site may not have
authoritative control of the reverse DNS zone unless they are the owner
of of the internet routable block (/24 or larger with IPv6, /64+ IPv6).
When a block is subdivided for something like Amazon EC2, or Linode,
reverse DNS updates are published through an provider specific method
which then the block owner can publish into their zones.
ARIN: https://www.arin.net/resources/request/reversedns.html
RIPE:
https://www.ripe.net/manage-ips-and-asns/db/support/configuring-reverse-dns
This opens a rather ugly can of worms: the designated owner of the block
can publish whatever records and thus create certificates for *any* IP
address by simply adding a second PTR record to any existing ones,
complete the challenge, and then delete the PTR leaving anyone unaware
short of checking CT logs for their IP address. As previously brought
up, reverse DNS isn't typically used to getting to a website so this
could be essentially invisible attack.
Alan somewhat beat me to this point, I think PTR validation may be
useful for proving "long term" control of an IP address from a provider,
but in and of itself, I think it's a security issue waiting to happen.
If it was combined with a second challenge however which direct control
of the machine on that IP+proof of intent to have a certificate issued,
it would be usable.
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).
What concerns me is that if we don't have a method of validation for IP
addresses that are reasonably secure, people might just take this I-D
and implement it anyway without realizing why. I personally think being
able to have certs issued for IPs is reasonably useful to an extent so
if we can fix the specification, it's a worthwhile thing to do.
Michael
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
