[Acme] Client-controlled values

Jacob Hoffman-Andrews <jsha@eff.org> Wed, 07 January 2015 19:29 UTC

Message-ID: <54AD890A.1030004@eff.org>
Date: Wed, 07 Jan 2015 14:29:14 -0500
From: Jacob Hoffman-Andrews <jsha@eff.org>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: acme@ietf.org
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/ryMg9u_xHlW9O3Y_FDo2KpUBU2U
Subject: [Acme] Client-controlled values
Precedence: list

In the current version of the spec, for SimpleHTTPS Validation, the 
client can specify the path (under .well-known/acme-challenge) where the 
server should expect to find a copy of the token. The goal as I 
understand it is to allow a single client to manage multiple pending 
authorization requests without file collisions. However, I think this 
adds unnecessary complexity and risk.

Proposal: For the SimpleHTTPS challenge, the client should not provide a 
path. The server should always fetch 
.well-known/acme-challenge/<token>.txt, and should expect the contents 
to equal <token>.

For DVSNI and DNS challenges, the client provides a random string `s', 
to be hashed with the server's random string `r'. What sort of attack 
does this protect against? It seems unnecessarily risky to allow the 
client input into the hash, and leads to some issues like 
https://github.com/letsencrypt/acme-spec/issues/12.

Proposal: For the DVSNI and DNS challenges, the client should not 
provide a random string `s', but should directly sign the server's 
random string `r'.a

[Acme] Client-controlled values Jacob Hoffman-Andrews
Re: [Acme] Client-controlled values Jacob Hoffman-Andrews
Re: [Acme] Client-controlled values James Kasten