i did mail the author with the textual changes needed to explicitly handle multiple ptrs but no response
------------------------------------------------------------- apologies for direct contact as im not aware of protocol but wanted to suggest amendments to https://datatracker.ietf.org/doc/draft-ietf-acme-ip/?include_text=1 not alterations just clarifying detail as some ips have multiple PTR records 4.1. instead of The client constructs the validation domain name by prepending the label "_acme-challenge" to the domain name referenced in the PTR resource record for the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] reverse mapping of the IP address. The client then provisions a TXT record with the digest for this name. (altered additions 'one of' and '(s)' ) The client constructs the validation domain name by prepending the label "_acme-challenge" to one of the domain name(s) referenced in the PTR resource record for the IN-ADDR.ARPA [RFC1034] or IP6.ARPA [RFC3596] reverse mapping of the IP address. The client then provisions a TXT record with the digest for this name. instead of On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's ACME account key. If they do not match, then the server MUST return an HTTP error in response to the POST request in which the client sent the challenge. To validate a DNS challenge, the server performs the following steps: 1. Compute the SHA-256 digest of the key authorization 2. Query for a PTR record for the IP identifier's relevant reverse mapping based on its version 3. Query for TXT records for the computed validation domain name 4. Verify that the contents of one of the TXT records matches the digest value altered r/a/all and added (s) twice On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's ACME account key. If they do not match, then the server MUST return an HTTP error in response to the POST request in which the client sent the challenge. To validate a DNS challenge, the server performs the following steps: 1. Compute the SHA-256 digest of the key authorization 2. Query for all the PTR record(s) for the IP identifier's relevant reverse mapping based on its version 3. Query for TXT records for the computed validation domain name(s) 4. Verify that the contents of one of the TXT records matches the digest value At 00:16 29/03/2018 Thursday, Michael Casadevall wrote: >I went back and forth and re-read several RFCs, the baseline requirements, and >the draft, and ended three or four drafts of this email before replying so >just some broad thoughts. On 3/28/2018 1:46 PM, Matthew D. Hardeman wrote: > > >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 wha t 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. > You bring up a good point, and while I'm not sure I 100% agree with this, mootness comes into play as after checking the literal text of CA/B BR, and it says under 3.2.2.5. "3. Performing a reverse-IP address lookup and then verifying control over the resulting Domain Name under Section 3.2.2.4 [Validation of Domain Authorization or Control]" Which at looking at the specification, and the CA/B rules side by side, it *does* meet 3.2.2.5. I know per RFC 1034, there's only supposed to be one PTR per domain, but in practice people have published multiple ones. What happens in that case? As far as I understand it, it's protocol legal to send multiple PTRs, although I'm n ot sure how the resolver handles that, or if it's even easily detectable in Boulder. Furthermore, I do have one remaining niggle I spotted on the third or fourth re-reading. Specifically, nowhere in the DNS token generation do we actually put the IP address we want to validate; the token is generated from the hash of the host. I doubt this is a security concern, but wanted to make sure this wasn't a mistake. > 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. > From a reverse-DNS perspective, that's true since the PTR (in theory) is supposed to point to the most authoritative name a server may have. That being said, I have issues thinking of IPs as a strongly name d resource in general fairly transitory compared to the domain names they're attached to, and useless in and of them selves due to multitenant/virtual hosting. Hope this isn't too rambling, and thanks Matt for the insight and patience on the ARIN reverse DNS zone. I do have concerns on actually using the reverse zone for any sort of validation, but as CA/B has approved it so I won't comment on those grounds due to out-of-scopiness. Michael _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme </x-flowed> _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
