Re: [Acme] Predictability of http-01 challenge response

Jacob Hoffman-Andrews <jsha@eff.org> Tue, 26 January 2016 20:41 UTC

Return-Path: <jsha@eff.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78891B30BB for <acme@ietfa.amsl.com>; Tue, 26 Jan 2016 12:41:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.003
X-Spam-Level:
X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9HFOD89cChI for <acme@ietfa.amsl.com>; Tue, 26 Jan 2016 12:41:15 -0800 (PST)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2E3B1B2D4B for <acme@ietf.org>; Tue, 26 Jan 2016 12:41:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=IIrAI16ufUt25yTzI/Ijqz4Zan/cLwhmNP3USYbB4zA=; b=DhhjELR+PuH/xB83UI/Y1VahiZel/PxQJos3BFG4LpvMSFRaN3xgXqAqCarvTBcWuT6HbHnKp8VTqdLOLGAFYwSIkG+axbid3/OXg4CIE6CsfEDhLqvSGZHLQIIPV5sLlcXhqtx+1f6AlOD9NFia47GtLZw/9Emr9/7vwfJ0grk=;
Received: ; Tue, 26 Jan 2016 12:41:14 -0800
To: Hugo Landau <hlandau@devever.net>, acme@ietf.org
References: <20160126014833.GA16635@andover>
From: Jacob Hoffman-Andrews <jsha@eff.org>
X-Enigmail-Draft-Status: N1110
Message-ID: <56A7D9E9.3030009@eff.org>
Date: Tue, 26 Jan 2016 12:41:13 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160126014833.GA16635@andover>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Received-SPF: skipped for local relay
Received-SPF: skipped for local relay
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/RoWyf5p1YBmKobuHbxF1X1KAVbk>
Subject: Re: [Acme] Predictability of http-01 challenge response
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jan 2016 20:41:17 -0000

On 01/25/2016 05:48 PM, Hugo Landau wrote:
> Was this an intended design feature of the http-01 challenge?
I think it was not specifically intended or discussed.
> Perhaps more pertinently I should ask, is this property desirable?
The main property we want from challenges is that they are unlikely to
be satisfied accidentally by a party other than the requester. I believe
that's the main value of random tokens as challenges. It's extremely
unlikely that someone will unintentionally have a file on their server
matching the random token.

It's likely that some people using Let's Encrypt will use the sort of
automated response you described, so they could unintentionally response
with a challenge they did not intend to make. However, the inclusion of
the account key thumbprint would ensure that they are not authorizing an
account other than their own.


> This reduces the http-01 challenge to what is essentially an account key
> nomination, alebit with a random token (probably needed to satisfy CA/B
> forum requirements). I've previously suggested that e.g. the DNS
> challenge be changed similarly. In that regard it's quite convenient.
> I'm just mildly worried that this property doesn't seem to have been
> particularly noticed or discussed, in terms of its security properties.
I think treating challenges as account key nominations is valuable and
has the potential to make repeated challenge fulfillment easier. But
you're right, we should document the specific security properties that
the DV challenges are intended to provide.
> Musing a little, if this property was deemed desirable, the possibility
> of multiple account keys could be better accommodated by including say,
> a hash of the account key thumbprint in the URL.
This is an interesting idea, but I think if we want to go further down
this road, it makes more sense to have a challenge that returns all
account keys that the subscriber considers to be authorized for issuance
on the requested domain.