Subject: Re: [Acme] New draft and DANGER

From: Andrew Ayer <[email-masked]>
Date: Thu, 1 Oct 2015 19:04:17 -0700

On Wed, 30 Sep 2015 21:48:32 -0700
Richard Barnes <[email-masked]> wrote:

> The authorized key object is JSON, which means that the number of
> serializations for it is bounded only be the size of the object the
> server will accept.  If a malicious client can generate an authorized
> key object that collides with a legitimate one (a second preimage),
> then he can authorize his own key.  Having the server generate the
> object puts all of the entropy that goes into the digest under the
> control of the server.
> [...]
> In other words, there's a trade-off here between a little more surety
> in the crypto and a little more protection against the CDN.  Given
> that ambiguity about crypto bit us last time, I opted for the former.

Well... previously, the protocol was relying on a non-existent property
of digital signatures.  With a client-constructed authorized
key object, it would be relying on the second-preimage resistance of
SHA-256, which is a pretty safe bet, to put it mildly.  (Also, if I
were an attacker with a second-preimage attack against SHA-256, I
wouldn't bother attacking a CA - I'd just mint my own certs ;-)

> Would it help to clarify that the CA MUST verify the token before
> accepting the response, and the client MUST NOT provision the
> validation until after the response is accepted?

It would help in that the client would have to make two mistakes
instead of just one.  Nevertheless, if the choice is between counting
on client implementers to not make mistakes and counting on SHA-256 to
have second-preimage resistance, I think the choice is clear.

-- Andrew

---

From: Ashok Bommisetti <[email-masked]>
Date: Thu, 1 Oct 2015 19:35:47 -0700

Bbbbbb b. Bbbbbb  by b      bbbbb by bbbbb.  Hxbbb. BBB. BBB b bbh huh.  H. N.   F by by bbbbb BBB b.        

On Oct 1, 2015 7:04 PM, Andrew Ayer <[email-masked]> wrote:
> _______________________________________________ 
> Acme mailing list 
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/acme

---

From: Ashok Bommisetti <[email-masked]>
Date: Thu, 1 Oct 2015 19:43:00 -0700

Hello All

It was completely pocket. Apologize for the spam

Regards
Ashok

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 2 Oct 2015 11:41:33 -0700

On 10/01/2015 07:04 PM, Andrew Ayer wrote:
> Well... previously, the protocol was relying on a non-existent
> property of digital signatures. With a client-constructed authorized
I agree here: If the goal is to defend against a second-preimage attack
on the same hash we are issuing certs with, I don't think that goal is
sensible and I'd rather go with the design that makes it harder for
clients to make mistakes.

Also, Richard, when we talked about this last week we discussed how
adding another layer of base64-encoded JSON (the authorizedKeys object)
was an anti-pattern. One alternate design we discussed was to have the
validation resource be a sha256 hash of the exact bytes the client
POSTed to the challenge resource.

This has the advantage of introducing one fewer object type. We can do
away with the "authorizedKeys" object entirely, since the posted
challenge object contains the account key (in JWS headers) and the token
(if we require it so).

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 2 Oct 2015 12:43:43 -0700

I'm fine with having the client generate the object, but I think I'd be more
comfortable if the data that the client had to provision for the challenge
was deterministic, less for cryptographic reasons but simply to make it
easier to reason about the protocol properties.

Maybe this is a case for a non-JSON encoding.

-Ekr

---

From: Richard Barnes <[email-masked]>
Date: Fri, 2 Oct 2015 14:00:18 -0700

How about something like this:

Authorized key object is TOKEN.FINGERPRINT, where:
* TOKEN is the token in the challenge
* FINGERPRINT is the JWK thumbprint of the account key (per the relevant
JOSE spec)

Same processing, except neither side has to send the object.  (Might still
have the client echo the token.)

Jacob, that gets you no base64(JSON), and EKR, that gets you determinacy.

Copasetic?

--Richard

On Friday, October 2, 2015, Eric Rescorla <[email-masked]> wrote:

> On Thu, Oct 1, 2015 at 7:04 PM, Andrew Ayer <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Richard Barnes <[email-masked]>
Date: Fri, 2 Oct 2015 18:57:54 -0400

I have implemented this solution in this PR:

https://github.com/ietf-wg-acme/acme/pull/13

Last call for comments...

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 2 Oct 2015 16:16:40 -0700

On 10/02/2015 02:00 PM, Richard Barnes wrote:
> * FINGERPRINT is the JWK thumbprint of the account key (per the
> relevant JOSE spec)
This sounds reasonable. I don't see a reason to have the client echo the
token.

In the vein of reasoning about the protocol, it probably makes sense to
specify the length of the token in more detail, and just say "64 random
octets, base64-encoded."

---

From: Martin Thomson <[email-masked]>
Date: Fri, 2 Oct 2015 16:20:05 -0700

> specify the length of the token in more detail, and just say "64 random

There is a less-precise specification in the PR: it mandates >= 128
bits of entropy using the base64url alphabet.  Is that insufficient
somehow?  Or would you prefer to be stricter and say "exactly 128 bits
of uniformly distributed random data encoded using base64url".

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 3 Oct 2015 15:57:41 -0700

This seems OK to me.

-Ekr

---

From: Andrew Ayer <[email-masked]>
Date: Sat, 3 Oct 2015 19:49:31 -0700

On Fri, 2 Oct 2015 18:57:54 -0400

> Last call for comments...

Looks good to me.

-- Andrew