Hey Zach,

Thanks for submitting a PR on this.  I just filed a review with some
specific comments:

https://github.com/ietf-wg-acme/acme/pull/312#pullrequestreview-43769669

This change seems fine to me, especially if we make the change I propose in
there to digest the whole key authorization instead of just the token.  I
don't think there's a security problem here, but I also don't think
stateless clients are tremendously valuable to the ecosystem, and it seems
conservative to require more knowledge on the part of the verification host.

Looking at the thread, I'm not seeing strong objections.   Unless I hear
something here before Zach updates the PR, I'll go ahead and merge once
that's done.

--Richard


On Mon, May 8, 2017 at 6:21 PM, Zach Shepherd <[email protected]> wrote:

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

Reply via email to