Re: [Acme] Signature misuse vulnerability in draft-barnes-acme-04

[Andrew Ayer <[e-mail]>]

On Wed, 12 Aug 2015 13:55:52 -0700
yan <[e-mail]> wrote:

> On 8/11/15 10:52 PM, Richard Barnes wrote:
> 
> > Smallest diff change from the current document would be simply to
> > explicitly require validation value bound to account key that
> > created it -- not the one the signs the response.  Since the attack
> > requires that the attacker change keys (using recovery) after
> > receiving the token, the attack only works if the validation is
> > done against the new public key.  This option introduces
> > non-trivial implementation complexity, though, since the server now
> > has to remember what key signed the new-authorization request that
> > caused the challenges to be issued.
> 
> Doesn't it already have to remember this? The current instructions
> for verifying a DNS challenge says: "1. Verify the validation JWS
> using the account key for which this challenge was issued."
> 
> Since the challenge was issued before the attacker initiated account 
> recovery to do the key change, the wording implies that the server 
> remembers the original key at validation time.

That wording is bound to trip up implementers - in fact, a quick look
at the Boulder source indicates it validates against the current account
key, not the account key at the time the challenge was issued[1] :-)

I think this would be a pretty fragile way to work around what is
fundamentally a crypto problem.

Also, only DVSNI and DNS currently use this language - the wording for
the Simple HTTP challenge is "Verify that the body of the response is
[...] signed with the client's account key".  The wording should
probably be clarified and made consistent among the challenges.

Regards,
Andrew

[1]
https://github.com/letsencrypt/boulder/blob/7eae93873d394c359c371621c4e9064c9e780f19/va/validation-authority.go#L381,
which is ultimately called from
https://github.com/letsencrypt/boulder/blob/7eae93873d394c359c371621c4e9064c9e780f19/ra/registration-authority.go#L380,
where the account key comes from the registration object.