On 8/12/15 4:16 PM, Andrew Ayer wrote:
On Wed, 12 Aug 2015 13:55:52 -0700
yan <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
