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

On 8/12/15 4:16 PM, Andrew Ayer wrote:
> On Wed, 12 Aug 2015 13:55:52 -0700
> yan <yan@eff.org> 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]

Consider us tripped. :)

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

Agree, I like Barnes' proposal above.

>
> 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.

I see James is already fixing this: 
https://github.com/letsencrypt/acme-spec/pull/217/files.

Thanks,
Yan

>
> 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.
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>