Whoops - quickie fix on this: It’s been a long day.
Update permission to the dynamic DNS zone that is being delegated to should be bound to the account key that has most recently demonstrated control of the same label, such as via a one-time DNS-01 challenge to set up the delegation. Anyone should be able to “challenge” for control of the dynamic zone by having the authentication to update the dynamic zone rebind to the account key of whoever most recently executes a one-time DNS-01 challenge for the label in question. > On Jan 24, 2018, at 12:42 AM, Matthew D. Hardeman <[email protected]> > wrote: > > Allow me to throw in a twist which might more tighten the academic discussion > over whether a static CNAME for a TXT record to a special zone at a CA (or > other third party), over which dynamic updates to the CNAM target are > available. > > The opposition seems to be that chasing the CNAME to the other party’s server > is a static delegation to a target for which the game is stacked: they’ll > always have the right challenge value? > > Let’s make it even more core to the DNS. > > What if _acme-challenge.domain-to-validate.example.com > <http://acme-challenge.domain-to-validate.example.com/> has one or more NS > delegation records to a DNS server(s) run by the CA or CA dynamic DNS partner? > > At the DNS servers maintained by this service, each validation label is its > own zone. At the root level of that zone is a dynamically updateable TXT > record with the challenge response. This scheme is really easy for > authentication credentials, too, because it’s easy to have different dynamic > policies on just about any DNS server if we only care about zone-level > security. > > DNS is hierarchical. Any proper resolver would follow this. Furthermore, in > that light, it is entirely non-differentiated from DNS-01, with the exception > that the assisted mechanism could pre-check to see if such delegation exists > and offer up in the challenge a hint as to what the needed NS delegation > record(s) would be. > > To be clear, I do propose that the delegation target NS run by the CA or > partner require a dynamic update via some API from the ACME client to the CA > or dynamic DNS partner’s infrastructure. > > As the correct challenge response is generated by signing with the client’s > account key, there almost doesn’t even have to be security over adds of TXT > records to the delegated to dynamic zone. In practice, it may be smarter to > customize the DNS server to allow for update via a temporary key generated by > the CA and communicated to the dynamic DNS zone config and sent to the > party-attempting-challenge to use to add the TXT zone to the record. The > custom DNS server could even do its own TXT record cleanups as a certain time > period is exceeded from challenge initiation. > > My scheme has the advantage that it’s very difficult to accept DNS as a > security gating measure at all (as it is for domain validation) without also > accepting that the scheme herein described merely involves further standards > compliant delegation of subsets of the domain to another DNS server. > > A random challenge is still created. The challenge is still updated in the > “real” DNS, in the sense that following normal strict resolution for the TXT > record will follow the NS delegation to the special dynamic server, which > still requires that the zone get updated by the ACME client in order to > achieve the challenge successfully. I don’t see how the BR can fault the > mechanism I’ve described, as all the elements are still covered. The same > rule that would fault this type of delegation would also fault departmental > level delegations of DNS hierarchy within a municipal domain or university > domain. Or of the root to a TLD for that matter. > > Thoughts? > >> On Jan 23, 2018, at 9:01 PM, Jacob Hoffman-Andrews <[email protected] >> <mailto:[email protected]>> wrote: >> >> [Starting a new thread for this particular fork of the conversation] >> >> Thanks for the input, Tim! As a member of the CA/Browser Forum >> Validation Working Group, and a big contributor to the BR validation >> methods, your perspective on this is particularly helpful. >> >> On 01/23/2018 08:37 AM, Tim Hollebeek wrote: >>> Your proposed method defeats one of the goals of the BR domain >>> control validation requirements, which is to demonstrate control >>> at time of validation, not just as some previous time in the past. >> >> For the moment, let's continue to assume that the CA fully resolves the >> TXT record during validation. >> >> I think continuing to present a delegation of the authorization label to >> an authorized party (in this case the CA) does constitute demonstration >> of continued control. >> >>> That's why the existing, approved validation methods require >>> random numbers to guarantee the validation is fresh and not >>> based on some previous validation. >> >> I'm sure the intent of "freshness tokens" in the BRs was discussed >> extensively in the validation WG, but I don't think it made it to the >> final document. If you happen to recall any thread titles, would you be >> willing to link to the previous discussion? >> >> I'm specifically interested in why you would consider this form of >> automation to have a separate risk profile from HTTP-style automation. >> For instance, if someone leaves software like Certbot running on a >> server, with instructions to continue to request and respond to >> validation from a given CA, why is that safer than leaving a particular >> CNAME record in DNS? >> >>> If control at some time in the past is sufficient, you can >>> just re-use the previous validation, which is allowed in some >>> circumstances(see the BRs). >> >> This is fundamentally different from validation reuse. With validation >> reuse, a CA might say "I validated that a year ago; I'll assume it's >> still good." The goal of automated validation methods is to allow the CA >> to actually re-check the validation data at intervals that would be >> impractical with manual intervention. So for instance, under >> assisted-dns-01, a CA would actually be going out to the network and >> fetching DNS records with each validation. >> >>>> Oh, and the method very similar to the propose one (static >>>> CNAME as persistent authentication) is being used in the wild. >>>> And due to fundamential nature of DNS, even static zone can >>>> result variable results for names under the zone. >>> By who? I don't think it's possible for such a method to be >>> compliant with any of the current BR methods. If it is, we'll >>> fix it. >> >> Are you saying that the proposed assisted-dns-01 method is also >> not compliant with 3.2.2.4.7 DNS Change? Why not? If you think >> assisted-dns-01 is compliant, but should not be, what is your proposed fix? >> >> _______________________________________________ >> Acme mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/acme > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
