At 14:54 28/03/2018 Wednesday, Michael Casadevall wrote: >Content-Type: multipart/alternative; > boundary="------------834EF402DF7BD9A4D3D7E1FB" >Content-Language: en-US > > > >On 3/27/2018 9:15 PM, Eric Rescorla wrote: >> >> >>On Wed, Mar 21, 2018 at 1:55 PM, Roland Bracewell Shoemaker >><<mailto:[email protected]>[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. > >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.
not really an issue as authorisation keys are mounted in the forward zone (indicated by ptr only) thus as long as the ip supplier(owner) has placed the ptr records the customer(ip leaser) requested once the job is done >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. if your being attacked by your own ip supplier this is the least of your worries as they could as easily route your websites ip to another host momentarily(or just for LE outbounds) to complete the cert validation for any/all other name(s) (and then at will intercept some/all of your visitors undetectably without cert pining, but no methods can defend you from your own isp/ip/connectivity provider, thats why some level of trust is implied in choosing them) ptr really is only an issue where you have an unresponsive ip supplier with stale ptr records and thus the old/previous lease-owner can easily get a cert for your ip (though limited in use to them, except when they can mitm some subset of your visitors) >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>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 >[email protected] >https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
