Re: [Acme] tls-sni-01 validation compromise

Jehiah Czebotar <jehiah@gmail.com> Fri, 22 January 2016 04:31 UTC

Return-Path: <jehiah@gmail.com>
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 7781F1B37EA for <acme@ietfa.amsl.com>; Thu, 21 Jan 2016 20:31:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 Burp9tEApM-b for <acme@ietfa.amsl.com>; Thu, 21 Jan 2016 20:31:23 -0800 (PST)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B75691B37EB for <acme@ietf.org>; Thu, 21 Jan 2016 20:31:23 -0800 (PST)
Received: by mail-vk0-x234.google.com with SMTP id e185so35187623vkb.1 for <acme@ietf.org>; Thu, 21 Jan 2016 20:31:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fLnanx9jblqG2WDcsyfsH8EV16dbatPKuW/sBYQUSNM=; b=v5CIIQSHQVi6ZQUeCCFd6qodaAiPNq01Nhn2URC+aVBy3z7rZf+SABX1au2y1m2Yjh +eWXooARcFqlDxBiSI9ogg4Vd5CJ7cNdyktq2+jV7UEVvH/rmXVXM0n3fRQubkVbplbx FuBUV9eTvtfewdZVS0DJy3U4NheBoH2uc97Pk0BlXJ45RaiYeTRqoKh/1Pg8cUllDOMJ JmuR+ihdSYfGXuwx9s0+jyOfJaGDbvqqk6lbt7G3SugNj/IjPQRZGRwfA49/GjYX25Xl yT2YaXnMW4XONlMCFqGY46OLdjoLxLkBRJZ/qlEhyNZh1ysH3m/sSFjiqulzMcu8jtl6 tgXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fLnanx9jblqG2WDcsyfsH8EV16dbatPKuW/sBYQUSNM=; b=fKD+4GEFW+dYiJ5NpnpA2D9OTH/H8DOtcXnN/aZbqq/XLaLu1ITRw9W2JmpEgOGaz3 RiRqxlFBVBdDPmr27/QnQv8AkZN4/kAqJqVc6wmc7wgeMG0qwd3nk1uA25fSUKmJpifK qWNmF+fnVq1CRGSUrdzZ6C/p6O6Z6R4Y83q9h8YV5yuRcunGzx+13hcyFleaYnRycTZz rXRFIGE9gVkxmUPeDUBFWlS+0napWG71KiWdajViWUrF3wnho3GHWg4hlJ4SYeOlWTDY oglNbU26m0BZrSxQRdsX3hIEsyjy5Lo91BYIMh8re33RQmMlJ/AlsunQ5O59ejrJTSrN GaRQ==
X-Gm-Message-State: AG10YOQZ0/Dq7WE2HHHmGWBXeLxglg0Drz6gTolSKgYLJ2xihNEDAMhNvz8p34trIRRbuYyK5uKegtFgBIoMlQ==
MIME-Version: 1.0
X-Received: by 10.31.47.88 with SMTP id v85mr596787vkv.118.1453437082457; Thu, 21 Jan 2016 20:31:22 -0800 (PST)
Received: by 10.31.92.77 with HTTP; Thu, 21 Jan 2016 20:31:22 -0800 (PST)
In-Reply-To: <CABkgnnVZy-vycuZ86DnVCwy57nuv62Buut+Gt2=TbXERUwmd+g@mail.gmail.com>
References: <CAES3dxRZ7ieQ+G0Zv0oZmehUFPGU36KUdvrkSL+MMLSQWbP08w@mail.gmail.com> <CABkgnnVMDFnz3EARBBw=OhnHo3USsJo4ynpBCrca_Df6XGDSeQ@mail.gmail.com> <CABkgnnVZy-vycuZ86DnVCwy57nuv62Buut+Gt2=TbXERUwmd+g@mail.gmail.com>
Date: Thu, 21 Jan 2016 23:31:22 -0500
Message-ID: <CAES3dxThfq3iob4h7YLgWBEC-sWdR0e5jvOfhm+t8+eJ3SPPQw@mail.gmail.com>
From: Jehiah Czebotar <jehiah@gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/2TfJpQ_0rKPgHc5lHHdFePJzt54>
Cc: "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] tls-sni-01 validation compromise
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: Fri, 22 Jan 2016 04:31:25 -0000

Yes, I agree it's odd that the validation request is based on the key
authorization not the token. That's really the crux of the issue and
more succinct than my original message.

In option 1) I proposed, to be clear it would make sense to update
tls-sni-01 validation to use Z(token) as the SNI hostname, and use two
entries in the DNSName cert response. One matching the SNI hostname
based on Z(token) so the right cert is chosen, and one based on Z(key
authorization) that serves as the secret.

As you mentioned a new `tls-01` could depend on just the
request/response like `http-01` and not depend on details of the cert
so that you don't have to mess with configurations of both cert &
request handling as much.

--
Jehiah

On Thu, Jan 21, 2016 at 11:09 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> Thinking more about this, if the intent is to make the tls-sni-xx
> challenge analogous to the http-xx one, then the request would encode
> the token (not a hash of the key authorization) and the response to
> that challenge would include the key authorization (as I suggest
> below).
>
> On 22 January 2016 at 14:03, Martin Thomson <martin.thomson@gmail.com> wrote:
>> On 22 January 2016 at 13:38, Jehiah Czebotar <jehiah@gmail.com> wrote:
>>> 1) Change the requirement that the self signed cert have one DNSName,
>>> and require the response to have TWO DNS names. One that matches the
>>> requested hostname, and a second that is secret which proves it can
>>> only be created by the appropriate party initiating validation
>>> 2) Remove reliance on SNI matching, and make the challenge `tls-01`
>>> and fulfill the same HTTP response requirements as `http-01` where the
>>> Hostname, and request path are untrusted, but the response body with
>>> full keyAuthorization proves the connection to the requestor. This
>>> opens up the possibility of TLS validation against the $domain being
>>> validated instead of relying on a .acme.invalid hostname.
>>
>> I think that the suggestion that the challenge response include
>> something unique to the challenge (as http-01 already does) is a fine
>> suggestion.  I don't think that it matters much how that is done.  If
>> the intent is to verify that the requester exercises control over the
>> TLS server, having this restricted to things that are part of the TLS
>> server configuration is probably advisable.
>>
>> To that end, adding a key authorization to the certificate would seem
>> to be the best option.  Whether that is done as a second
>> subjectAltName or as a separate extension probably doesn't matter
>> much.
>>
>> Following through with a challenge like http-01 would work, but it
>> means playing with the configuration of the server in two places.