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] :-) 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. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
