>
> 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
> <https://www.arin.net/resources/request/reversedns.html>
> RIPE:
> https://www.ripe.net/manage-ips-and-asns/db/support/configuring-reverse-dns
> <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.
I have a significant amount of IP space registered at ARIN and can speak to the
reverse-DNS delegation configuration.
For IPv4, ARIN allows for the record holder for the IP space to delegate the
lookup zone to name-servers of the resource holder’s choice at the /24 level.
Having said that, if I as an ISP provide a full /24 to an end-user customer, I
can configure the /24 at ARIN with as being SWIP’ed to the customer entity and
update the NS delegation for that /24’s reverse zone to my customer’s name
servers. I could also override that at any time and send it to a name-server
in the middle.
To be clear, the ONLY record that the ARIN resource holder can directly
influence at ARIN is a set of NS records indicating what name servers to
delegate the zone to.
Does this mean that the network provider for the IP space in question can
hijack the validation process? Yes. But this is not materially different from
a registrar being able to similarly hijack the NS delegations for a domain
that’s been registered with them.
If we think of an IP address as a strongly named resource like, say, a
particular domain label, we can see that in both cases it is entirely possible
for the trusted parties in the closer-to-the-root hierarchies to subvert
validation processes by asserting the control inherent in their position as the
“earlier asked party” vs the delegations down the line.
As an aside, for smaller than /24 delegation, an ISP can literally further
delegate reverse lookup to a zone of a single IP address, allowing smaller
customers direct access to update the reverse DNS for those IPs within their
own name servers, if desired. This configuration is rare, but exists.
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
