Subject: Re: [Acme] Assisted-DNS challenge type [invalid signature!]

From: "Sebastian Nielsen" <[email-masked]>
Date: Tue, 23 Jan 2018 17:50:04 +0100

I think that it could be acceptable to "reuse" an old validation provided WHOIS is checked right?
Eg, if a hash is made of all the WHOIS data, and all the WHOIS data stays identical from last validation, then theres proof that control of domain has not shifted in the meantime, which is the main reason to implement random challenge checks.

Because if you sell, transfer, change owner, renew, change DNS server, the domain is disabled, or if domain expires, then some data in the WHOIS will change.
Especially the "last update" date.
And same also applies to the DNS servers and/or DNSSEC keys.

So combining a static entry with a WHOIS hash check, would propably suffice, but the static entry must be randomly generated AND contain a key, to prevent "preloading" malicious software with challenges.
Of course, for the scheme to be secure, there must be something that enforces the challenge is passed in a short time, for example 24 hours, but once challenge is passed, it will stay valid until WHOIS changes.

Of course, such a check could only be accepted for base level domains, where the person validating the domain effectively is the person who paid for the domain aswell, NOT subdomains, as subdomains can be part of "free webhosting services" which will stay static for a very long period.

-----Ursprungligt meddelande-----
Från: Acme [mailto:[email-masked]] För Tim Hollebeek
Skickat: den 23 januari 2018 17:38
Till: Jacob Hoffman-Andrews <[email-masked]>; [email-masked]
Ämne: [invalid signature!]

> This challenge has the big advantage that subscribers only need to do a one-
> time CNAME setup, and renewals can be reliably automated without requiring
> that renewing systems have permission to update DNS. In effect, the CNAME
> record would act like a long-term delegation permitting the CA to issue
> continuously for the base domain.

Yes, not having to validate domains saves customers a lot of time and effort!
See BR validation methods #1 and #5 for more information!! 😊

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.  That's why the existing, approved
validation methods require random numbers to guarantee the validation is
fresh and not based on some previous validation.

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).

-Tim

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 23 Jan 2018 16:54:00 +0000

> I think that it could be acceptable to "reuse" an old validation provided 
> WHOIS
> is checked right?
> Eg, if a hash is made of all the WHOIS data, and all the WHOIS data stays
> identical from last validation, then theres proof that control of domain has 
> not
> shifted in the meantime, which is the main reason to implement random
> challenge checks.

No.  See the BRs for what "reuse" means.  People have to stop re-interpreting
the BRs to mean what they want them to mean.

You don't get to make up your own methods that satisfy whatever "main
reason" that you believe motivates the requirements.  That's method 11,
which we spent over a year removing (and for good reason).

-Tim

---

From: "Sebastian Nielsen" <[email-masked]>
Date: Tue, 23 Jan 2018 18:00:08 +0100

I have seen the BR, and what I understand, the purpose of BRs are to provide a specific security goal.
In this case, to prevent someone from aquiring control of a domain, and then subsuquently, after losing control of said domain, being able to still renew and reissue certificates for said domain.

If the same security goal can be implemented using another method, my understanding is that its acceptable, provided that method provides equal or greater security than one of the accepted methods in BR right?
Think like "compensating controls" in PCI/DSS.

-----Ursprungligt meddelande-----
Från: Tim Hollebeek [mailto:[email-masked]] 
Skickat: den 23 januari 2018 17:54
Till: Sebastian Nielsen <[email-masked]>; 'Jacob Hoffman-Andrews' <[email-masked]>; [email-masked]
Ämne: RE: Re: [Acme] Assisted-DNS challenge type [invalid signature!] [invalid signature!]

-Tim

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 23 Jan 2018 17:03:37 +0000

No, the BRs codify requirements, not security goals.  The Mozilla root program
requires all CAs to comply with the baseline requirements at all times.

Something similar to PCI/DSS compensating controls existed as Method 11 in
the BRs previously.  It was removed last year in favor of explicit requirements.

It is not acceptable to validate domains with a method that does not comply
with one of the ten approved methods.  Any certificates issued based on such
validations are mississued and should be revoked.

-Tim

> -----Original Message-----
> From: Sebastian Nielsen [mailto:[email-masked]]
> Sent: Tuesday, January 23, 2018 10:00 AM
> To: Tim Hollebeek <[email-masked]>; 'Jacob Hoffman-Andrews'
> <[email-masked]>; [email-masked]
> Subject: SV: Re: [Acme] Assisted-DNS challenge type [invalid signature!]
> [invalid signature!]
> 
> In this case, to prevent someone from aquiring control of a domain, and then
> subsuquently, after losing control of said domain, being able to still renew and
> reissue certificates for said domain.
> 
> If the same security goal can be implemented using another method, my
> understanding is that its acceptable, provided that method provides equal or
> greater security than one of the accepted methods in BR right?

---

From: Jim Reid <[email-masked]>
Date: Tue, 23 Jan 2018 17:08:58 +0000

> On 23 Jan 2018, at 16:50, Sebastian Nielsen <[email-masked]> wrote:
> 

As a general rule, relying on the accuracy of whois data for *anything* is remarkably stupid.

Some registries try hard to publish accurate whois data, but there are only a few who do that.

> if a hash is made of all the WHOIS data, and all the WHOIS data stays identical from last validation, then theres proof that control of domain has not shifted in the meantime,

No. All that "proves" is the whois data were not changed. Control of the domain may well have taken place without a corresponding update to the whois data. For instance, lazy/incompetent registrars or registries that get this wrong. Or the use of privacy/proxy services which may well leave the whois data unchanged whenever the domain name holder changes. Or when a domain name holder's business gets acquired by another.

Oh and in some cases, contact data about a domain name holder can't be published in whois because of data protection legislation. This issue is going to get a *whole lot* worse once GDPR kicks in.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 23 Jan 2018 20:59:27 +0200

> validations are mississued and should be revoked.

The 10 methods are woefully underspecified for security. There is NO
way anyone can evaluate actual security of the validation methods.

There is at least one method that definitely allow practices with no
compensating controls that are deemed too insecure elsewhere in
security even with compensating controls. Then there at least two
methods that are argued to be insecure in their strongest forms. Many
methods that can easily be read in all sorts of weird ways. And
sometimes those weird ways are so bizarre I can not fathom the logic.
Then there are methods where there are major disagreements on what
those actually allow or not.

Oh, and the method very similar to the propose one (involving 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.

-Ilari

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 23 Jan 2018 19:53:12 +0000

> Oh, and the method very similar to the propose one (involving 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.

-Tim

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 23 Jan 2018 22:48:03 +0200

> of the current BR methods.  If it is, we'll fix it.

Amazon ACM DNS validation based on descriptions I have seen.

And the reading that is complies with 10 methods is way less bizarre
than the reading that ACME HTTP-01 complies.

And DNS specifications are darn clear that TXT lookups chase CNAMEs.
And CNAMEs are not the only authority transfer mechanism. And then
there are DNS servers that can run arbitrary computable impure(!)
functions to answer queries. Versus those you do not even have
snowball's chance in hell.

-Ilari

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 23 Jan 2018 20:52:44 +0000

It doesn't matter if lookups chase CNAMEs, because the answer has to
include a cryptographically secure random number that was created
especially for that particular validation and was not used in previous
validations, in order to be compliant with the BRs.

Your arbitrary computable impure function is not going to successfully
guess a secure random number.

-Tim

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 23, 2018 1:48 PM
> To: Tim Hollebeek <[email-masked]>
> Cc: [email-masked]; 'Jacob Hoffman-Andrews' <[email-masked]>; Sebastian
> Nielsen <[email-masked]>
> Subject: Re: [Acme] Assisted-DNS challenge type [invalid signature!] 
> [invalid
> signature!]
>
> > > 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.
>
> And the reading that is complies with 10 methods is way less bizarre than 
> the
> reading that ACME HTTP-01 complies.
>
>
> And CNAMEs are not the only authority transfer mechanism. And then there
> are DNS servers that can run arbitrary computable impure(!) functions to
> answer queries. Versus those you do not even have snowball's chance in hell.
>
>
> -Ilari

---

From: Thomas Lußnig <[email-masked]>
Date: Wed, 24 Jan 2018 07:26:43 +0100

But there is one difference between the two proves.
1) DNS-01 : Prove is with TXT record is that you have current DNS access
2) CNAME : Prove that you have once DNS access and now Account Key access

And here is no difference to the idea to publish account key via TXT record.
Both prove one time dns access and current account key access. With TLSA 
record
you would have the same security like DANE which is handled as successor 
of the CA system.

On 1/23/2018 9:52 PM, Tim Hollebeek wrote:t
>> _______________________________________________
>> Acme mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/acme