At 18:46 28/03/2018 Wednesday, Matthew D. Hardeman wrote:
>>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. with all our sub-24 ranges we just have the owner setup uuu.xx.yy.zz.in-addr.arpa cname uuu.xx.yy.zz.r-ptrs.orionnetworks.ie. then we setup and manage the ptrs within our own sub-zone, it works well for us >_______________________________________________ >Acme mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
