Re: [Acme] ALPN based TLS challenge

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 23 February 2018 14:13 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A39112E855 for <acme@ietfa.amsl.com>; Fri, 23 Feb 2018 06:13:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 HqdCBmMDzCTL for <acme@ietfa.amsl.com>; Fri, 23 Feb 2018 06:12:58 -0800 (PST)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B577512E054 for <acme@ietf.org>; Fri, 23 Feb 2018 06:12:58 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id AAC4945522; Fri, 23 Feb 2018 16:12:55 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id G1NpV7b7QNPL; Fri, 23 Feb 2018 16:12:55 +0200 (EET)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 38EF779; Fri, 23 Feb 2018 16:12:50 +0200 (EET)
Date: Fri, 23 Feb 2018 16:12:49 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Doug Beattie <doug.beattie@globalsign.com>
Cc: Roland Bracewell Shoemaker <roland@letsencrypt.org>, Rich Salz <rsalz@akamai.com>, IETF ACME <acme@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20180223141249.GA18818@LK-Perkele-VII>
References: <0639F8AA-9E14-4FD4-A9A4-C03EB4D95962@letsencrypt.org> <CABkgnnVgFN57OeuN61rHa9i7teo_TGyA1CNXiQz0n4KcQ=O78Q@mail.gmail.com> <3B21694B-E5D0-4D39-83CE-A7EBD8BF2F48@akamai.com> <01E6B12D-69EE-4104-8E1B-BE1512A1DDCB@letsencrypt.org> <SG2PR0301MB1190E57D534C66731C1E9019F0CC0@SG2PR0301MB1190.apcprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <SG2PR0301MB1190E57D534C66731C1E9019F0CC0@SG2PR0301MB1190.apcprd03.prod.outlook.com>
User-Agent: Mutt/1.9.3 (2018-01-21)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/B7sZq-VQtW4DqBTuaVUlUPuhoU8>
Subject: Re: [Acme] ALPN based TLS challenge
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.22
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, 23 Feb 2018 14:13:00 -0000

On Fri, Feb 23, 2018 at 01:17:53PM +0000, Doug Beattie wrote:
> I'm probably not understanding a key piece of technical info about the
> protocol, but when I see this statement it makes me think it has similar
> issues to tls-sni-01.  If we're relying on the hosting provider enforcing
> certain constraints like this, then we're delegating a critical piece of
> domain control back to the hosting provider which would be a no-go.
> 
> 4.  Security Considerations
> 
>    The design of this challenges relies on some assumptions centered
>    around how a server behaves during validation.
> 
>    The first assumption is that when a server is being used to serve
>    content for multiple DNS names from a single IP address that it
>    properly segregates control of those names to the users on the server
>    that own them.  This means that if User A registers Host A and User B
>    registers Host B the server should not allow a TLS request using a
>    SNI value for Host A that only User A should be able to serve that
>    request.  If the server allows User B to serve this request it allows
>    them to illegitimately validate control of Host A to the ACME server.
> 
> Please let me know what I'm missing.

The assumption that users can only influence HTTPS names they own
probably holds in practice. The entiere security of entiere methods 9
and 10 relies on exactly that. Exploiting TLS-SNI-0x did not require
answering for the name in question.

What I am more worried about is hosting providers which treat HTTP
and HTTPS independent from each other. These are not common, but there
are some. And judging from Globalsign ("oneclick") issue, either these
hosting provoders are relevant, or everyone just misunderstood the
issue. 


-Ilari