Subject: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token

From: Zach Shepherd <[email-masked]>
Date: Mon, 8 May 2017 22:21:48 +0000

The following feedback is based on cd7c5e9 (current HEAD of master).

Section 8.3 states that the token value for HTTP validation "MUST have at least 128 bits of entropy."

Section 11.3 explains that one goal of this is that "the entropy requirement prevents ACME clients from implementing a “naive” validation server that automatically replies to challenges without participating in the creation of the intial authorization request."

However, because of the way the token is used in the validation process, as a part of the request, this goal is not met. It is possible to configure a webserver to respond to all requests under .well-known/acme-challenge with the ASCII representation of the key authorization. (See, e.g., https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.)

Essentially, the server informs the client of the token during the validation process, removing any need for the client to have known it.

If this is acceptable, the entropy requirement should be removed. If this is unacceptable, the challenge and validation should be revised.

Regards,
Zach Shepherd

---

From: Logan Widick <[email-masked]>
Date: Mon, 8 May 2017 18:37:50 -0500

I think that this may require revising the challenge.

Would a "two-token" challenge pattern help mitigate the risk of stateless
clients for the HTTP challenge and for future challenges that may otherwise
have similar issues? For example, assume that the challenge has two tokens,
which I will call "tokenA" and "tokenB", TokenA would be used to make
request parameters, and tokenB would be used only for responses. The key
authorization would include both tokens to ensure that the tokens were
received correctly. For example, the key authorization could be tokenA ||
tokenB || account key thumbprint. The ACME server could perform HTTP
validation by sending a request to
"http://example.com/.well-known/acme-challenge/tokenA"
and get back the revised key authorization (or anything else with tokenB in
it). Since tokenB was not sent with the request, the server would have to
have known tokenB somehow. One possible drawback of this approach is the
increased storage required for the extra token.

An alternate approach may be to require that a request parameter sent
during validation for any type of challenge (now existing or later
developed) must include a hash of something containing the challenge token
rather than something containing the token itself. For example, the HTTP
challenge could be revised by having the validation go to "
http://example.com/.well-known/acme-challenge/SHA256_hash_of_the_token"
instead of "http://example.com/.well-known/acme-challenge/token". The
TLS-SNI challenge uses this "hashed token for requests" pattern already. In
the TLS-SNI challenge, SAN A (the one requested in the TLS SNI extension
during challenge verification) is constructed by hashing the token, while
the response is constructed with the (hash of) the key authorization. One
possible drawback of having challenges to use this "hashed token for
requests" pattern is that hashing would become such an integral part of the
challenge process that if a hash algorithm is compromised, new versions of
all challenges will need to be released.

In both ideas above, I suggested applying the same general "pattern" (of
what should be used for making validation requests and what should be used
for making validation responses) to all challenges. Although this
statelessness issue solely affects the HTTP challenge at this time, adding
text in the specification (probably in a "security considerations"
subsection) to require or recommend all challenges to use the same pattern
(or choose from a list of multiple approved patterns) would prevent future
challenges from having similar issues.

On a different note, would requiring the provisioned challenge resource (in
this case, the response to the "http://example.com/.well-know
n/acme-challenge/some_token_or_hash_of_the_token" request) to be digitally
signed by the account JWK and/or the CSR key (most likely by having the
response be a JWS containing the key authorization rather than the key
authorization itself) improve security, worsen security, or have no impact
on security? If it would improve security, would this be feasible for each
type of challenge?

Sincerely,
Logan Widick

On Mon, May 8, 2017 at 5:21 PM, Zach Shepherd <[email-masked]> wrote:

> Section 11.3 explains that one goal of this is that "the entropy
> requirement prevents ACME clients from implementing a “naive” validation
> server that automatically replies to challenges without participating in
> the creation of the intial authorization request."
>
> However, because of the way the token is used in the validation process,
> as a part of the request, this goal is not met. It is possible to configure
> a webserver to respond to all requests under .well-known/acme-challenge
> with the ASCII representation of the key authorization. (See, e.g.,
> https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.)
>
> Essentially, the server informs the client of the token during the
> validation process, removing any need for the client to have known it.
>
> If this is acceptable, the entropy requirement should be removed. If this
> is unacceptable, the challenge and validation should be revised.
>
> Regards,
> Zach Shepherd
>
>
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 9 May 2017 09:05:03 +0300

> increased storage required for the extra token.

The way TLS-SNI-02 does it is to derive the challenge and response
tokens out of the master random value.

TLS-SNI-01 had a similar problem, but in that case, the problem was
compounded by:

- TLS-SNI not even weakly binding the hostname to validate into
  validation (-02 does not fix this), and
- TLS-SNI-01 not binding the account key into validation (and even
  in -02, this is not verifiably done).

(For these problems, I consider TLS-SNI-01/-02 to validate the
underlying IP, not the domain itself... In CABForum BRs, this is known
as method 8 validation. Method 10 was intended to cover TLS-SNI, but
the definition looks just screwed up).

Whereas HTTP-01 does (weakly) bind both the hostname and the account
key into validation in verifiable way. This renders "stateless mode"
quite a bit harder to exploit.

And if one moved to challenge-response token scheme, most likely the
response would not contain challenge at all. So the storage amount
would remain the same, unless implementation backed things with
database table. Some extra storage is unlikely to be an issue for such
implementation.

> on security? If it would improve security, would this be feasible for each

I don't think having it signed by account key would affect security.
Rendering responses unpredictable to the CA and strongly binding the
hostname could have some benefits tho.

Also note that you can't assume that signature binds the key it was
done using: For that, you need to include the public key in data to
be signed. Yes, some signatures like Ed25519 do such binding anyway,
but IIRC ECDSA doesn't.

Signing with CSR key would have negative impact (cross-protocol attack
possibility! Not to mention it would really interfere with properly
protecting the TLS key).

There actually was a message that was signed with TLS key in past
versions, but it was removed because of cross-protocol attack
possibilities and such problems.

-Ilari

---

From: Zach Shepherd <[email-masked]>
Date: Tue, 9 May 2017 16:13:37 +0000

I like the "hashed token for requests" pattern, assuming that the [unhashed] token would be present as a part of the response.

I think the drawback of hash algorithm compromise can be mitigated by the choice of hash algorithm; compromise of SHA-256 would already have substantial impact on ACME such that the net impact of further use of it would be relatively insignificant.

Regards,

Zach

________________________________
From: Logan Widick <[email-masked]>
Sent: Monday, May 8, 2017 4:37 PM
To: Zach Shepherd
Cc: [email-masked]
Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token

Would a "two-token" challenge pattern help mitigate the risk of stateless clients for the HTTP challenge and for future challenges that may otherwise have similar issues? For example, assume that the challenge has two tokens, which I will call "tokenA" and "tokenB", TokenA would be used to make request parameters, and tokenB would be used only for responses. The key authorization would include both tokens to ensure that the tokens were received correctly. For example, the key authorization could be tokenA || tokenB || account key thumbprint. The ACME server could perform HTTP validation by sending a request to "http://example.com/.well-know<https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_.well-2Dknow&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=p7InnW2mQOs0PbG3CIC1CU7a5ElnIRQgh5Q0jlexC7Y&e=>n/acme-challenge/tokenA" and get back the revised key authorization (or anything else with tokenB in it). Since tokenB was not sent with the request, the server would have to have known tokenB somehow. One possible drawback of this approach is the increased storage required for the extra token.

An alternate approach may be to require that a request parameter sent during validation for any type of challenge (now existing or later developed) must include a hash of something containing the challenge token rather than something containing the token itself. For example, the HTTP challenge could be revised by having the validation go to "http://example.com/.well-know<https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_.well-2Dknow&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=p7InnW2mQOs0PbG3CIC1CU7a5ElnIRQgh5Q0jlexC7Y&e=>n/acme-challenge/SHA256_hash_of_the_token" instead of "http://example.com/.well-know<https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_.well-2Dknow&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=p7InnW2mQOs0PbG3CIC1CU7a5ElnIRQgh5Q0jlexC7Y&e=>n/acme-challenge/token". The TLS-SNI challenge uses this "hashed token for requests" pattern already. In the TLS-SNI challenge, SAN A (the one requested in the TLS SNI extension during challenge verification) is constructed by hashing the token, while the response is constructed with the (hash of) the key authorization. One possible drawback of having challenges to use this "hashed token for requests" pattern is that hashing would become such an integral part of the challenge process that if a hash algorithm is compromised, new versions of all challenges will need to be released.

In both ideas above, I suggested applying the same general "pattern" (of what should be used for making validation requests and what should be used for making validation responses) to all challenges. Although this statelessness issue solely affects the HTTP challenge at this time, adding text in the specification (probably in a "security considerations" subsection) to require or recommend all challenges to use the same pattern (or choose from a list of multiple approved patterns) would prevent future challenges from having similar issues.

On a different note, would requiring the provisioned challenge resource (in this case, the response to the "http://example.com/.well-know<https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_.well-2Dknow&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=p7InnW2mQOs0PbG3CIC1CU7a5ElnIRQgh5Q0jlexC7Y&e=>n/acme-challenge/some_token_or_hash_of_the_token" request) to be digitally signed by the account JWK and/or the CSR key (most likely by having the response be a JWS containing the key authorization rather than the key authorization itself) improve security, worsen security, or have no impact on security? If it would improve security, would this be feasible for each type of challenge?

Sincerely,
Logan Widick

On Mon, May 8, 2017 at 5:21 PM, Zach Shepherd <[email-masked]<mailto:[email-masked]>> wrote:

However, because of the way the token is used in the validation process, as a part of the request, this goal is not met. It is possible to configure a webserver to respond to all requests under .well-known/acme-challenge with the ASCII representation of the key authorization. (See, e.g., https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Neilpang_acme.sh_wiki_Stateless-2DMode&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=btrBKR5yx_x7Q_6OImGiTK6osiKun9UWrYmNvGluGt8&e=>.)

Regards,
Zach Shepherd

_______________________________________________
Acme mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/acme<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=_aG2-51Ootcw6Q1nkZQwL2V5Xcf2U9t2fc1Y_iB_d80&e=>

---

From: Zach Shepherd <[email-masked]>
Date: Thu, 11 May 2017 03:00:30 +0000

To make things more concrete, here is a PR that introduces a new version of the HTTP challenge: https://github.com/ietf-wg-acme/acme/pull/312

Regards,

Zach

________________________________
From: Zach Shepherd
Sent: Tuesday, May 9, 2017 9:13:37 AM
To: Logan Widick
Cc: [email-masked]
Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token

Regards,

Zach

Sincerely,
Logan Widick

Regards,
Zach Shepherd

---

From: Jehiah Czebotar <[email-masked]>
Date: Wed, 10 May 2017 23:12:40 -0400

I'm not convinced of a need to change the http-01 validation method here.

As Ilari addressed, this assumption isn't correct. The token (provided in
the request) alone isn't sufficient to implement a stateless response for
http-01.

--
Jehiah

On Wed, May 10, 2017 at 11:00 PM, Zach Shepherd <[email-masked]>
wrote:

> To make things more concrete, here is a PR that introduces a new version
> of the HTTP challenge: https://github.com/ietf-wg-acme/acme/pull/312
>
>
> Regards,
>
> Zach
> ------------------------------
> *From:* Zach Shepherd
> *Sent:* Tuesday, May 9, 2017 9:13:37 AM
> *To:* Logan Widick
>
> *Cc:* [email-masked]
> *Subject:* Re: [Acme] Bypassing the intended purpose of requiring 128
> bits of entropy for the http-01 token
>
>
> I like the "hashed token for requests" pattern, assuming that the
> [unhashed] token would be present as a part of the response.
>
>
> I think the drawback of hash algorithm compromise can be mitigated by the
> choice of hash algorithm; compromise of SHA-256 would already have
> substantial impact on ACME such that the net impact of further use of it
> would be relatively insignificant.
>
>
> Regards,
>
> Zach
>
> ------------------------------
> *From:* Logan Widick <[email-masked]>
> *Sent:* Monday, May 8, 2017 4:37 PM
> *To:* Zach Shepherd
> *Cc:* [email-masked]
> *Subject:* Re: [Acme] Bypassing the intended purpose of requiring 128
> bits of entropy for the http-01 token
>
> validation by sending a request to "http://example.com/.well-know
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_.well-2Dknow&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=p7InnW2mQOs0PbG3CIC1CU7a5ElnIRQgh5Q0jlexC7Y&e=>n/acme-challenge/tokenA"
> http://example.com/.well-know
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_.well-2Dknow&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=p7InnW2mQOs0PbG3CIC1CU7a5ElnIRQgh5Q0jlexC7Y&e=>
> n/acme-challenge/SHA256_hash_of_the_token" instead of "
> http://example.com/.well-know
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_.well-2Dknow&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=p7InnW2mQOs0PbG3CIC1CU7a5ElnIRQgh5Q0jlexC7Y&e=>n/acme-challenge/token".
> The TLS-SNI challenge uses this "hashed token for requests" pattern
> already. In the TLS-SNI challenge, SAN A (the one requested in the TLS SNI
> extension during challenge verification) is constructed by hashing the
> token, while the response is constructed with the (hash of) the key
> authorization. One possible drawback of having challenges to use this
> "hashed token for requests" pattern is that hashing would become such an
> integral part of the challenge process that if a hash algorithm is
> compromised, new versions of all challenges will need to be released.
>
> On a different note, would requiring the provisioned challenge resource
> (in this case, the response to the "http://example.com/.well-know
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__example.com_.well-2Dknow&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=p7InnW2mQOs0PbG3CIC1CU7a5ElnIRQgh5Q0jlexC7Y&e=>
> n/acme-challenge/some_token_or_hash_of_the_token" request) to be
> digitally signed by the account JWK and/or the CSR key (most likely by
> having the response be a JWS containing the key authorization rather than
> the key authorization itself) improve security, worsen security, or have no
> impact on security? If it would improve security, would this be feasible
> for each type of challenge?
>
> Sincerely,
> Logan Widick
>
>> https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Neilpang_acme.sh_wiki_Stateless-2DMode&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=btrBKR5yx_x7Q_6OImGiTK6osiKun9UWrYmNvGluGt8&e=>
>> .)
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_acme&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=1OYaxm691BQpeh5nwZFtk7nxKEdzaq6FGnsOUXQWC_4&s=_aG2-51Ootcw6Q1nkZQwL2V5Xcf2U9t2fc1Y_iB_d80&e=>
>>
>>
>

-- 
Jehiah

---

From: Jehiah Czebotar <[email-masked]>
Date: Wed, 10 May 2017 23:18:42 -0400

ok nevermind, my brain is slowly working (sorry Zach); this is different
from the problems in tls-sni-01 where you could respond with a stateless
response to all requests from any account (which confused me at first as i
thought you were reporting the same type of stateless issue).

The issue here is you can provide a stateless response to all response for
given account(s). I don't know if that's desirable but as it still requires
some amount of authorization that seems like it might still be ok and at
least isn't a security issue.

-- 
Jehiah

On Wed, May 10, 2017 at 11:12 PM, Jehiah Czebotar <[email-masked]> wrote:

>>> If this is acceptable, the entropy requirement should be removed. If
>>> this is unacceptable, the challenge and validation should be revised.
>>>
>>> Regards,
>>> Zach Shepherd
>>>
>>>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 11 May 2017 14:03:55 -0700

Thanks for the detailed look at this.

On 05/08/2017 03:21 PM, Zach Shepherd wrote:
> requirement prevents ACME clients from implementing a “naive”
> validation server that automatically replies to challenges without
> participating in the creation of the intial authorization request."
>
> However, because of the way the token is used in the validation
> process, as a part of the request, this goal is not met. It is
> possible to configure a webserver to respond to all requests under
> .well-known/acme-challenge with the ASCII representation of the key
> authorization. (See, e.g.,
> <https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode>.)
I think this type of "stateless" validation server, as opposed to the
"naive" validation server described in ACME, is fine. Though I am of
course open to being convinced otherwise.

You're right that the second part of the token entropy requirement isn't
quite correct. Specifically, the thing we want to avoid is that by
setting up some ACME software on a server, someone accidentally allows a
third party to come along and get a certificate for that server without
actually controlling it, by exploiting that ACME software's willingness
to automatically reply to challenges. This is why we include the account
key thumbprint as part of the keyAuthorization. An attacker cannot get a
certificate for a "stateless" validation server setup like the one you
described because the account key thumbprint that server is echoing
belongs to the actual administrator of the server, not the attacker.

In practice we have seen this happen in non-malicious ways: recently I
answered a question on Let's Encrypt's forum from someone who had a
"stateless" validation server set up. They were actually getting
validation failures, because they started trying to validate using a
different client with a different account key, but the old stateless
setup was taking precedence:
https://community.letsencrypt.org/t/letsencrypt-vesta-client-error-the-key-authorization-file-from-the-server-did-not-match/32822/12?u=jsha.

---

From: Zach Shepherd <[email-masked]>
Date: Thu, 11 May 2017 23:46:10 +0000

If this sort of "stateless" server is acceptable, why do we require 128 bits of entropy for the token?

I'm not sure whether or not a "stateless" server like this is fine, but I do think requiring use of a high-entropy token which can essentially be ignored is inconsistent. It seems like it is either not serving its intended purpose (in which case we should revise the HTTP challenge to ensure the sever doesn't "give away" the token during the validation) or it's not actually necessary (in which case we should consider revising the HTTP challenge, and perhaps others*, to get rid of the requirements for the token).

Regards,

Zach

* - If stateless http clients are acceptable, why not stateless DNS clients? I think allowing administrators to set a single TXT record containing the account key thumbprint and have it be re-used for multiple challenges would make it much more feasible to use the DNS challenge in environments where DNS management access is tightly controlled.

________________________________
From: Jacob Hoffman-Andrews <[email-masked]>
Sent: Thursday, May 11, 2017 2:03 PM
To: Zach Shepherd; [email-masked]
Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token

However, because of the way the token is used in the validation process, as a part of the request, this goal is not met. It is possible to configure a webserver to respond to all requests under .well-known/acme-challenge with the ASCII representation of the key authorization. (See, e.g., https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Neilpang_acme.sh_wiki_Stateless-2DMode&d=DwMD-g&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=tLnXJDyIaDj0bKzE9u06X0JX1cdo4ztRNuoXNfI-bKA&s=pK0eJEAfMHRry2wiLazpWzC3OzUSlcuUJPFztuwoxVg&e=>.)
I think this type of "stateless" validation server, as opposed to the "naive" validation server described in ACME, is fine. Though I am of course open to being convinced otherwise.

You're right that the second part of the token entropy requirement isn't quite correct. Specifically, the thing we want to avoid is that by setting up some ACME software on a server, someone accidentally allows a third party to come along and get a certificate for that server without actually controlling it, by exploiting that ACME software's willingness to automatically reply to challenges. This is why we include the account key thumbprint as part of the keyAuthorization. An attacker cannot get a certificate for a "stateless" validation server setup like the one you described because the account key thumbprint that server is echoing belongs to the actual administrator of the server, not the attacker.

In practice we have seen this happen in non-malicious ways: recently I answered a question on Let's Encrypt's forum from someone who had a "stateless" validation server set up. They were actually getting validation failures, because they started trying to validate using a different client with a different account key, but the old stateless setup was taking precedence: https://community.letsencrypt.org/t/letsencrypt-vesta-client-error-the-key-authorization-file-from-the-server-did-not-match/32822/12?u=jsha<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.letsencrypt.org_t_letsencrypt-2Dvesta-2Dclient-2Derror-2Dthe-2Dkey-2Dauthorization-2Dfile-2Dfrom-2Dthe-2Dserver-2Ddid-2Dnot-2Dmatch_32822_12-3Fu-3Djsha&d=DwMD-g&c=uilaK90D4TOVoH58JNXRgQ&r=Z9jmRNJFc0_mrYgZ7k4FWDuC1AsqA1UJKUYIM6ZnnNk&m=tLnXJDyIaDj0bKzE9u06X0JX1cdo4ztRNuoXNfI-bKA&s=fi-VbyQUwwVsPadbbOfc1pTIg83uEWIQNK81g_cuJAc&e=>.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 12 May 2017 14:23:22 +0300

> 128 bits of entropy for the token?
 
CAB Forum Baseline Requirements.

> * - If stateless http clients are acceptable, why not stateless DNS
> clients? I think allowing administrators to set a single TXT record
> containing the account key thumbprint and have it be re-used for
> multiple challenges would make it much more feasible to use the DNS
> challenge in environments where DNS management access is tightly
> controlled.

Again, CAB Forum Baseline Requirements.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 12 May 2017 19:39:27 +0300

> course open to being convinced otherwise.

Well, the general tone of the "10 methods" is against such "stateless"
setups. But that might be because those are written assuming much more
primitive capabilities than what ACME provodes.
 
> belongs to the actual administrator of the server, not the attacker.

The key does not necressarily belong to the adminstrator of the server!

It can also belong to the administrator of the virtual host, in setups
that delegate certificate maintenance (which is common in shared
hosting setups that don't just grab certs for all their residents
from one CA). 

Also, I consider ACME too complicated to be implemented in the web-
server or closely associated software. However, the needed support
functions, certificate provisioning and challenge provisioning (with
the remaining logic being replaceable) are simple enough.

However, to split those functions, you need to be able to perform
approprate access control. With HTTP-01 and DNS-01 this is possible (not
that you need often do do it with DNS-01). However, not with TLS-SNI-02,
because the requests are not verifiably bound into the domain being
validated.

-Ilari

---

From: Zach Shepherd <[email-masked]>
Date: Fri, 12 May 2017 22:33:40 +0000

For use of a token with http-01, it seems like the relevant section of the baseline requirements would be 3.2.2.4.6 Agreed‐Upon Change to Website. Is that correct?

That section seems to explicitly state "where the Request Token or Random Value MUST NOT appear in the request". Including the token (which the document seems to refer to as the "Random Value") in the request path (as http-01 does) would seem to violate this normative language. Am I misunderstanding the content of that section?

________________________________
From: [email-masked] <[email-masked]> on behalf of Ilari Liusvaara <[email-masked]>
Sent: Friday, May 12, 2017 4:23 AM
To: Zach Shepherd
Cc: Jacob Hoffman-Andrews; [email-masked]
Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 31 May 2017 15:30:01 +0300

On Fri, May 12, 2017 at 10:33:40PM +0000, Zach Shepherd wrote:
> For use of a token with http-01, it seems like the relevant section of
> the baseline requirements would be 3.2.2.4.6 Agreed‐Upon Change to
> Website. Is that correct?

Yes, that is correct.

> That section seems to explicitly state "where the Request Token or
> Random Value MUST NOT appear in the request". Including the token
> (which the document seems to refer to as the "Random Value") in the
> request path (as http-01 does) would seem to violate this normative
> language. Am I misunderstanding the content of that section?

This was actually briefly discussed on this list. I had the same
understanding, that was apparently mistaken.

On changing validation methods, the current Key Authorization does not
seem to be sufficient. It does not bind the name to be validated.

Now, HTTP and DNS validation weakly binds the validated name (via host
header and owner name, respectively). Even this weak binding is
sufficient to consider the domain itself validated (the validation can
be deputized).

However TLS-SNI (including -02) does not bind the name in any way. This
results in TLS-SNI failing to actually validate the domain name itself,
instead validating the underlying IP address (it is not possible to
deputized the validation).

Furthermore, I have real problems matching up TLS-SNI-02 and method
#10 (Section 3.2.2.4.10) validation. Reading the phrases in a way that
would match seemingly unavoidably results other validation methods with
the same phrases becoming very insecure. This is ignoring other problems
with method #10 validation (e.g. seemingly allowing the PZB's insecure
certificate chaining validation, due to seemingly not restricting random
values properly).

-Ilari