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

Andrew Ayer <> Wed, 12 August 2015 23:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2DF801B2A01 for <>; Wed, 12 Aug 2015 16:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k2lX8amg1aZv for <>; Wed, 12 Aug 2015 16:16:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21DFA1B2A09 for <>; Wed, 12 Aug 2015 16:16:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=alcazar2; t=1439421377; bh=M4YzLrd+44tGG2Jys1lGnZdMlQTzn8aD6Ji3UKz83zg=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=bAWHpwLNErRchaQCFOQwIkVdn8XGpDCUPa/k2SnyvEV4Ym/gEux9ay3gDL66/dwvn zJwN+wWt/gpfdg1jyDplr4qXudqBnHqEeLVLDm7KNK0ndccCBjzJV4SJbBTS1zQDD2 tdnD/Z218xHFGrwBseDWG/ctuuRKr7Zfx/Wi3hFJ7b2wAaKFNIfqWldkO5gxpuwTOs KR57o+jk44ZIWfc5ObYrOcJ50BLo1OWXqvK5z4A7xRv8odlTT6WzkhH8mzu0OUbC1E 0R6n11Y1Nb0BNMCWeAp2/ywmTnh2L6kVsptiZOkpsrD0q+4ADqzyAp9hcqTlJbO2Ac A+s8DVTos1TTw==
Date: Wed, 12 Aug 2015 16:16:17 -0700
From: Andrew Ayer <>
To: yan <>
Message-Id: <>
In-Reply-To: <>
References: <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: Richard Barnes <>, "" <>
Subject: Re: [Acme] Signature misuse vulnerability in draft-barnes-acme-04
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Aug 2015 23:16:22 -0000

On Wed, 12 Aug 2015 13:55:52 -0700
yan <> 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.


which is ultimately called from,
where the account key comes from the registration object.