Subject: [Acme] Clarity: DNS validation domain delegated to another zone

From: Jan Broer <[email-masked]>
Date: Tue, 9 Feb 2016 21:29:17 +0100

Hello everyone,

we are discussing whether it is technically legal to validate the DNS
challenge TXT record when the validation domain is delegated away from the
domain to a different zone.

Scenario: a certificate request for domain = "foo.bar.com", which would
have fqdn = "_acme-challenge.foo.bar.com".

Assuming bar.com IN NS ns1.bar.com

which has a record

_acme-challenge.foo.bar.com IN NS ns.confusion.party

and ns.confusion.party has the record

_acme-challenge.foo.bar.com IN TXT "keyauth"

The spec stipulates that:

"the client must demonstrate to the server both (1) that it holds the
private key of the account key pair, and (2) that it has authority over the
identifier being claimed."

One could argue that requirement (2) is not satisfied when the validation
domain is delegated away from the domain: Creating a record under the
validation domain is not indicative of control/authority of the (parent)
certificate domain.

On the other hand, the spec does not specifically exclude this scenario.

Thoughts?

---

From: Michael Wyraz <[email-masked]>
Date: Tue, 9 Feb 2016 21:54:40 +0100

Hello Jan,

IMO it makes no difference weather the one who manages the domain
creates a _acme-challenge.foo.bar.com TXT or NS record to delegate this
to a trusted destination.
Furthermore, the domain admin delegates the "has authority over the
identifier being claimed" explicitly to this dns - so if the client can
demonstrate the control over it, it should satisfy the spec.

It's very unlikely that someone accidently delegates
"_acme-challenge.something" because it's not a valid domain name (in
fact I could not even delegate it by intent for some of my domains
because the domain name is rejected by most of my domain registrar's
nameserver tools).

> challenge TXT record when the validation domain is delegated away from
> the domain to a different zone.
>
> Scenario: a certificate request for domain = "foo.bar.com
> <http://foo.bar.com>", which would have fqdn =
> "_acme-challenge.foo.bar.com <http://acme-challenge.foo.bar.com>".
>
> Assuming bar.com <http://bar.com> IN NS ns1.bar.com <http://ns1.bar.com>
>
> which has a record
>
> _acme-challenge.foo.bar.com <http://acme-challenge.foo.bar.com> IN NS
> ns.confusion.party
>
> _acme-challenge.foo.bar.com <http://acme-challenge.foo.bar.com> IN TXT
> "keyauth"
>
> private key of the account key pair, and (2) that it has authority
> over the identifier being claimed."
>
> One could argue that requirement (2) is not satisfied when the
> validation domain is delegated away from the domain: Creating a record
> under the validation domain is not indicative of control/authority of
> the (parent) certificate domain.
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Ted Hardie <[email-masked]>
Date: Tue, 9 Feb 2016 13:38:56 -0800

On Tue, Feb 9, 2016 at 12:29 PM, Jan Broer <[email-masked]> wrote:

> So, I find the phrase "delegated away' a bit inexact here. Are you
concerned primarily with the case where there is an organizational boundary
which is non-obvious (a la dbound)?  With the case where there is simply a
set of nameservers but no organizational boundary?  Both?

> On the other hand, the spec does not specifically exclude this scenario.
Just to be clear,  in this scenario the client is capable of provisioning
the namesaver at confusion party?

> Thoughts?
regards,

Ted

---

From: Michael Wyraz <[email-masked]>
Date: Tue, 9 Feb 2016 22:46:31 +0100

Hi Jan,

another point is that delegating is "technically legal" for dns - so it
should be for us if we rely on dns. It's the same for http where one
could "delegate" as well (e.g. via reverse proxy or http redirect). It's
technically legal and part of the protocol, and if we try to forbid it,
we will certainly break existing setups which are otherwise
protocol-conform.

Just my 2 cents ;-)

Kind regards,
Michael.