Re: [Acme] Client-controlled values

[James Kasten <[e-mail]>]

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 <[e-mail]> wrote:

> 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:
> > 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 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>