Subject: [Acme] Assisted DNS, freshness tokens, and BR validation methods

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 23 Jan 2018 19:01:13 -0800

[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?

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Wed, 24 Jan 2018 00:42:13 -0600

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-masked]> wrote:
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Wed, 24 Jan 2018 01:01:43 -0600

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-masked]> wrote:
> 
>> On Jan 23, 2018, at 9:01 PM, Jacob Hoffman-Andrews <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Wed, 24 Jan 2018 01:20:54 -0600

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 <[email-masked]> wrote:
> 
>> 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?
>>

---

From: Tim Hollebeek <[email-masked]>
Date: Wed, 24 Jan 2018 17:54:56 +0000

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:[email-masked]]
> Sent: Wednesday, January 24, 2018 12:21 AM
> To: Jacob Hoffman-Andrews <[email-masked]>
> Cc: [email-masked]; Tim Hollebeek <[email-masked]>
> 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.
> 
> > 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.
> >
> >> 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?
> >>
> >> 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?
> >>
> >>>> 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.
> >>>
> >>> 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?
> >>>
> >>> 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
> >>> 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.
> >>>> 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
> >>> 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
> >>
> >> 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
> >
> > 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

---

From: "Matthew D. Hardeman" <[email-masked]>
Date: Wed, 24 Jan 2018 12:40:08 -0600

It is the case today that DNS-01 validation of a TXT record at _acme-challenge.label-to-validate.example.com <http://acme-challenge.label-to-validate.example.com/> is the mechanism of validating for issuance on label-to-validate.example.com <http://label-to-validate.example.com/>.

That’s how the ACME protocol has always done it.  Broadly it has been assumed that the ability to create an immediate DNS child of a particular label implies authority over that immediate parent level.

Perhaps that requires further codification in the BRs?

In any event, my intention was to lay to rest the notion of CNAME chasing of a TXT record being improper in the context of the validation.

DNS is hierarchical.  Following to a TXT record via a CNAME is proper DNS lookup.  The continued existence of a CNAME delegation to an external zone is evidence of a continuing intention to grant the target label authority to answer in place of the original queried label.

My exercise with NS record zone delegation was to illustrate how absurd it would be to try to redefine DNS delegations in the BRs for purposes of validations.  DNS is inherently hierarchical by design.  Delegations are a thing.  A legitimate thing.  Even if you managed to ban CNAME delegation of the TXT records for validation, the natural response would be that you could achieve the same with a NS zone delegation concept.  I used that type of delegation because it demonstrates a way to achieve the same effect as the CNAME delegation but does so in a way that would be difficult if not impossible for the BRs to restrict.

Sure, you could try saying “We won’t allow following of NS delegation beyond the level of the delegation to the public suffix", but that would have all kinds of real world consequences that would make it unworkable.  Can the Computer Science department at Oregon not be allowed to run their own name servers over cs.oregon.edu <http://cs.oregon.edu/>?

> On Jan 24, 2018, at 11:54 AM, Tim Hollebeek <[email-masked]> wrote:
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 24 Jan 2018 21:24:37 +0200

> bad idea and would weaken the existing Baseline Requirements.

There is no "proposal" to allow it, it _is_ allowed by the BRs, the
very definition of DNS validation.

-Ilari