Subject: [Acme] Client-controlled values

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 07 Jan 2015 14:29:14 -0500

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

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 13 Jan 2015 14:27:19 -0800

James Kasten and I discussed this offline. He pointed out that you don't
want to ask the client to sign a completely server-controlled token,
even if that value is constrained, because of collision attacks. As
illustrated by the forged root cert based on an MD5 collision, the
server could ask you to sign a token:

acme-token-7e8ebcaef83c9f6a5ffa891934f4c79bebc8cdeea2fe17a314de79b50b1e040c

After having offline found that that token collides with some other
string, e.g. a handshake message for which they want to spoof a
signature by your TLS private key.

I proposed removing the client random string `s' largely because the
current specification hard codes SHA-256(r || s). Ideally we should
either specify algorithm agility for that hash, or remove it entirely.

Proposal: Instead of having the client send its random string to the
server and have the server perform the hash, replace Z = SHA-256(R || S)
with Z = R || "." || S. When validating the provided certificate, the
server should look for a subjectAltName of R.*.acme.invalid. This
simplifies the spec so it doesn't have to hard-code SHA-256. It uses S
in a similar method to CA-controlled serial numbers, to make collision
attacks harder.

Auxiliary proposal: In the DVSNI section, add:

3. Verify the following properties of the certificate provided by the
TLS server:
   ...
   * Its hash algorithm and signing key type and size are acceptable by
server policy. At a minimum, servers SHOULD reject MD5 and SHA1
self-signed certificates, and RSA signing keys shorter than 2048 bits.

On 01/07/2015 11:29 AM, Jacob Hoffman-Andrews wrote:
> 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
> Proposal: For the SimpleHTTPS challenge, the client should not provide
> a path. The server should always fetch

---

From: James Kasten <[email-masked]>
Date: Thu, 15 Jan 2015 16:48:45 -0800

I agree with Jacob regarding the removal of the hash algorithm.  I believe
simply appending R and S together is a good solution to produce Z.  S now
becomes a publicly known value but this shouldn't cause any security
concerns as the challenges are tied to the authorization (account) key in
the spec.

One more potential problem with the current specification (and the proposed
solution) is that individual DNS labels can technically only be 63 octets
(RFC 1035 Section 2.3.4 https://www.ietf.org/rfc/rfc1035.txt).  Our choice
of HEX encoded 32 byte random values makes our DNS labels invalid.
Although this shouldn't be a problem within X.509 itself, I wouldn't be
surprised if some X.509 parsing software would refuse to read in/write out
SAN DNS entries that are invalid.

I believe we have a few options.
1.  We could take over the Subject CN field to specify the R.S.acme.invalid
entry.  Since the subject CN field does not have any explicit notion of DNS
this should avoid the problem.
2.  We could break up the R and S value into two separate 16 byte (32 hex)
labels.  Thus R[0:16].R[16:32].S[0:16].S[16:32].acme.invalid
3.  We could place the value in some other X.509 OID (this was avoided
initially to ease the client implementation.  The SAN extension is
generally well-supported.)
4. We could change R and S to be 30-byte octet strings.

On Tue, Jan 13, 2015 at 2:27 PM, Jacob Hoffman-Andrews <[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>