So, if what is below can actually be made to work, it would be very interesting as it would be a demonstration of how to use CNAME to evade the intent of the current BR validation requirements! Luckily I don't think it works.
"_acme-challenge.label-to-validate.example.com CNAME _acme- challenge.label-to-validate.example.com.account-id-ref-to-account- pubkey.shard1.dynamic-dns-service.theca.example.net" If this succeeds, you are ONLY allowed to issue for "_acme-challenge.label-to-validate.example.com" and not "label-to-validate.example.com". I realize there's a proposal in this thread to change that but I think this discussion shows why that would be a very bad idea and would weaken the existing Baseline Requirements. It definitely wasn't the intent to allow this sort of thing, where the customer (or their software) does not actually make any changes at all and everything just happens on the CA end through clever manipulations of CNAMEs. I'm actually going to add it to next week's validation WG agenda for discussion to make sure there are no holes here. With regards to Jacob's point about whether the freshness requirement made it into the BRs, it definitely did. Any place where it is missing was unintentional and should be fixed. Many root program representatives have been very vocal about the fact that re-validations should actually re-validate, and should not just happen to succeed based on detritus left behind from a previous validation -- a position I agree with. That said, I'm not surprised if the point was missed by those who didn't spend entire weeks (cumulative) of their lives following the Ballot 190 process 😊 The BR validation methods just use "random number" all over the place without any clarity about how or why the random number is being used. This was actually discussed in Taipei and I have some draft language to try to clarify the issue in github that I've been trying since October to get around to getting into a ballot: https://github.com/cabforum/documents/pull/82 Digicert is actually a huge fan of ACME, and now that I'm here I intend to keep a close eye on developments here and hopefully we can avoid another TLS-SNI-0X fiasco, while continuing to provide improved and more automated ways of validating domains. -Tim > -----Original Message----- > From: Matthew D. Hardeman [mailto:mharde...@ipifony.com] > Sent: Wednesday, January 24, 2018 12:21 AM > To: Jacob Hoffman-Andrews <j...@eff.org> > Cc: acme@ietf.org; Tim Hollebeek <tim.holleb...@digicert.com> > Subject: Re: [Acme] Assisted DNS, freshness tokens, and BR validation methods > > Note as a further point of clarification: there may be more ease in the CNAME > delegation method, most especially because mutations on the target zone > name are possible in a way that the NS delegations could not accommodate. > i.e - _acme-challenge.label-to-validate.example.com CNAME _acme- > challenge.label-to-validate.example.com.account-id-ref-to-account- > pubkey.shard1.dynamic-dns-service.theca.example.net could be terribly > convenient, as the target label could also imply the necessary authentication > mechanism for the update to the hosted dynamic TXT record. > > The NS delegation mechanism that I’ve illustrated is, I believe, reasonably > secure and additionally shows that a mechanism of achieving a static config in > the main “real” zone is still able to be delegated in a way that no one’s > validation routines today would even “detect” in any way that matters to the > domain validation. It’s just chasing name servers for one more level of > delegation. > > If this delegation — which is being followed today by any recursive resolver, > without even considering TXT records — is sufficient, then why not allow the > logical delegation by CNAME? Both achieve the same ends, which is to allow > for a primarily static configuration over the domain’s principle zone, while > delegating particular records to another dynamically updatable DNS zone. This > allows for providing the servers needing automated update and retrieval of > certificates to do so without exposing security credentials of high privilege > over > the primary DNS zone to the various systems needing certificates. > Simultaneously, it still requires proof of control over the DNS, albeit at > the end > of the delegation, by having the secure random value incorporated in the > challenge response which must be dynamically updated into the delegation > target’s TXT record. > > I don’t think there’s any question that the NS zone delegation would be > followed today, so why not CNAME? > > > On Jan 24, 2018, at 1:01 AM, Matthew D. Hardeman > <mharde...@ipifony.com> wrote: > > > > 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 > <mharde...@ipifony.com> 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 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 <j...@eff.org> > 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 > >>> Acme@ietf.org > >>> https://clicktime.symantec.com/a/1/uKairD16kjXul6IUNts9jksUPkkryv7P4 > >>> > 0DnRSEmugI=?d=6NoHOGvU7qQMTNQYr2GR2tpY9818SGXA4uPVl9TdYSmpaX > v1bLDglf > >>> 4p1Ln64hbwhdTWz9BPJdw4eKWrPk5y21q8PRUUesmufgHY- > yhCza2YEO5DJW6NsbB0QD > >>> > WTNDI1J08s6VSaLDdw16zKrA8X5T9nU95N_0msN1ePTH4WG0aEWtRE1xEUGx > YTE95S63 > >>> > 4ByAxDhyJVWSA5AJ03ErxU6iBU1XtSHbW4Fctd0Yofotl2zG7K5eEpD8boBmfMu > vCOIX > >>> miqgUS7WkIF5QiNB4xMKBx0iChTElFMRc67NX6CP8MayXKKH1- > HaeCF5Eca4X0FTGbzj > >>> zLY_F0-K-sggMvzzpxx3nr_TlgaZ_aWegUEy69fi78MeWMiam_JN0gXuY- > WIxSemwZ9L > >>> uL2jsco- > bP7MWwBwttqlXcuw8CqLpPeNGE&u=https%3A%2F%2Fwww.ietf.org%2Fma > >>> ilman%2Flistinfo%2Facme > >> > >> _______________________________________________ > >> Acme mailing list > >> Acme@ietf.org > >> https://clicktime.symantec.com/a/1/uKairD16kjXul6IUNts9jksUPkkryv7P40 > >> > DnRSEmugI=?d=6NoHOGvU7qQMTNQYr2GR2tpY9818SGXA4uPVl9TdYSmpaXv > 1bLDglf4p > >> 1Ln64hbwhdTWz9BPJdw4eKWrPk5y21q8PRUUesmufgHY- > yhCza2YEO5DJW6NsbB0QDWTN > >> > DI1J08s6VSaLDdw16zKrA8X5T9nU95N_0msN1ePTH4WG0aEWtRE1xEUGxYTE9 > 5S634ByA > >> > xDhyJVWSA5AJ03ErxU6iBU1XtSHbW4Fctd0Yofotl2zG7K5eEpD8boBmfMuvCOI > XmiqgU > >> S7WkIF5QiNB4xMKBx0iChTElFMRc67NX6CP8MayXKKH1- > HaeCF5Eca4X0FTGbzjzLY_F0 > >> -K-sggMvzzpxx3nr_TlgaZ_aWegUEy69fi78MeWMiam_JN0gXuY- > WIxSemwZ9LuL2jsco > >> - > bP7MWwBwttqlXcuw8CqLpPeNGE&u=https%3A%2F%2Fwww.ietf.org%2Fmail > man%2F > >> listinfo%2Facme > > > > _______________________________________________ > > Acme mailing list > > Acme@ietf.org > > https://clicktime.symantec.com/a/1/uKairD16kjXul6IUNts9jksUPkkryv7P40D > > > nRSEmugI=?d=6NoHOGvU7qQMTNQYr2GR2tpY9818SGXA4uPVl9TdYSmpaXv1 > bLDglf4p1L > > n64hbwhdTWz9BPJdw4eKWrPk5y21q8PRUUesmufgHY- > yhCza2YEO5DJW6NsbB0QDWTNDI1 > > > J08s6VSaLDdw16zKrA8X5T9nU95N_0msN1ePTH4WG0aEWtRE1xEUGxYTE95S > 634ByAxDhy > > > JVWSA5AJ03ErxU6iBU1XtSHbW4Fctd0Yofotl2zG7K5eEpD8boBmfMuvCOIXmiq > gUS7WkI > > F5QiNB4xMKBx0iChTElFMRc67NX6CP8MayXKKH1- > HaeCF5Eca4X0FTGbzjzLY_F0-K-sgg > > Mvzzpxx3nr_TlgaZ_aWegUEy69fi78MeWMiam_JN0gXuY- > WIxSemwZ9LuL2jsco-bP7MWw > > > BwttqlXcuw8CqLpPeNGE&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Fli > stinfo > > %2Facme
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
