Re: [art] Artart last call review of draft-ietf-acme-tls-alpn-06

Roland Shoemaker <> Tue, 01 October 2019 20:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC067120059 for <>; Tue, 1 Oct 2019 13:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Uo17hMbIv3If for <>; Tue, 1 Oct 2019 13:19:35 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B809212001E for <>; Tue, 1 Oct 2019 13:19:35 -0700 (PDT)
Received: by with SMTP id w144so15643940oia.6 for <>; Tue, 01 Oct 2019 13:19:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5HsBV60NrQ5J6D3n9hHCeeP8TYqkUPA6mKjNRj6+7cQ=; b=A7KqTA71+pljVzWS5hw6XAWCocmfrLVYc98GqeiqnrAb/l+gzhqS8F4LcJFN48rFIs a/JS1E6q9DY12mNbUhumQdKNxPLDBLtAdI02uNwE2kKbHCnO04hAPjnpJFwaVpBV7IZe PBIK6+hDNeMD2Y6bMFWP+BY7LiWI1fzRNb35g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5HsBV60NrQ5J6D3n9hHCeeP8TYqkUPA6mKjNRj6+7cQ=; b=lqIfxv3Emy22QH/68dD7kAUK9A6u03aohSDuqPBM4BIw1an+Vk8fmqpDKWp6oN9sdy /8VqPazv+e3+aDxRBzch1+ds+jCcXeGb1QQC8kCkm0m/OU5fb3yOddZtOLj2dl/5OvJu tzHgl3dxN4dsrdTRfb57QniuzFzNiXYp2PjBxg8ryhIZJ0xeSp5DiBqW69mkqhpOR7dZ K4apNbu3d8R0PAVhKSCRnxxi+MVC1pk8D3O3BeKfZxcmz2mRMVYss4I9/d+vybTuTEQ2 IMWTXWP5QsTI8UGk7WYD3Lbg0Xxyh1+2aO1mFxIOyQIP0+FkQL81+cMKcO1zg64oSVZl hiWA==
X-Gm-Message-State: APjAAAXNDJ0Dl+/GU9WVUlH0k4ou5XbMA4ENuJa5GhT+0svW1q8mZS0E rGDnVnZ+lZi+Xngz80koyabtkQ==
X-Google-Smtp-Source: APXvYqydLRmnLymjQPBNzo4aRg3rRFA0OJ/1hxdKbC4Jq+oGvvs2SVByLDjVRYVMcqnk+z8UP3P8MA==
X-Received: by 2002:aca:56ca:: with SMTP id k193mr5077575oib.155.1569961174834; Tue, 01 Oct 2019 13:19:34 -0700 (PDT)
Received: from ?IPv6:2600:1700:bd50:a5b0:98b6:333c:5dd8:82ec? ([2600:1700:bd50:a5b0:98b6:333c:5dd8:82ec]) by with ESMTPSA id n65sm5591996oib.35.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Oct 2019 13:19:33 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Roland Shoemaker <>
In-Reply-To: <>
Date: Tue, 1 Oct 2019 13:19:32 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Martin Thomson <>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <>
Subject: Re: [art] Artart last call review of draft-ietf-acme-tls-alpn-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Oct 2019 20:19:39 -0000

Hey Martin,

Thanks for the thorough review, I agree with all of the suggestions and will be incorporating the changes into the next revision. Following up on one point about Section 7, I believe you may actually be thinking about another issue we had with the http-01 ACME challenge. The issue here was as described, if the ACME server was using HTTPS to validate a http-01 challenge and the expected domain name didn’t have a proper virtual host configuration many servers would redirect the request to a ‘default’ handler. This is called out in RFC 8555 Section 8.3.


> On Sep 17, 2019, at 12:40 AM, Martin Thomson via Datatracker <> wrote:
> Reviewer: Martin Thomson
> Review result: Ready with Nits
> This is a clear description of a simple protocol that addresses a well-defined
> problem.  I didn't find any real issues, though I have some suggestions that
> might improve the document a little.  My view is that publication without these
> would still produce a useful RFC.
> Suggestions:
> The document should probably talk about minimum TLS versions and expected
> algorithms.  I think that it would be enough to say TLS 1.2 minimum with the
> mandatory cipher suites from that spec.  You might also want to require
> certificates with a PKCS#1v1.5 RSASSA key (as much as those are terrible), but
> to permit use and negotiation of other alternatives.  If your CA supports
> ECDSA, I see no reason not to prepare an ECDSA certificate on that basis, but
> that would be based on extra-textual knowledge, it's no guarantee of
> interoperability.
> Section 4
> I have two suggestions here for making the properties you rely on with the
> protocol clearer to readers.
> You should explicitly say that the "acme-tls/1" protocol as negotiated here
> does not carry application data, it only requires that the server provide
> certificate-based authentication.  AND that the certificate-based
> authentication provided uses an alternative method than that described in RFC
> 5280, even though it uses X.509 certificates.  Both of these are already
> implicit in the text here, but I think that it would help to be very clear
> about these as they are a little surprising ways to use TLS.
> You might also want to explicitly point out that though the protocol does not
> depend on the server providing a valid signature, or even that it successfully
> complete the TLS handshake, these are both required by the protocol and a
> validator MAY withhold authorization if the TLS handshake does not complete
> successfully.  (This is implied in Step 4, but not explained.)
> Nits:
> Section 1
> The history lesson in the appendix is useful.  It helps to articulate why the
> design is this way.  However, I don't think that you need to spend a third of
> the introduction on a reference to that historical information.  I'd cut that
> paragraph entirely.
> Section 3
> Step 3: s/AMCE/ACME; this sentence is two with a comma-splice
> Section 4
> This is taste only, but I find the extra version decoration on these
> identifiers unnecessary.  Decorate v2 if you are unfortunate enough to need one.
> Section 5
> The parallel list construction in this sentence is a little awkward:
>   "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 to be
>   served by User B or Host B to be served by User A."
> The first part of this sentence is fine, but the second part "or Host B to be
> served by User A" might be clearer if it said "or a TLS connection with a
> server_name extension identifying Host B to be answered by User A."  Or similar.
> Section 6.2
> Please don't use uppercase for an identifier when the actual protocol is
> identified using lowercase ASCII.  I know that RFC 7301 did this for HTTP/1.1,
> but that was a confusing mistake that doesn't need to be propagated.
> Section 7
> This is not an appendix.  You can make appendices using `<back>` in XML or by
> moving the section under `---back` in kramdown-rfc2629.
> The implication of this text is to say that this is a replacement for an
> important part of ACME.  I would instead say that this is an iteration on an
> earlier design that used the TLS server_name extension to carry the challenge. 
> And that that earlier design was shown to have some serious issues in practice.
> My understanding of the problem differs from what is described here though: the
> problem - as I recall - was that this used high-entropy, generated values for
> the server_name extension and an HTTP or absent ALPN identifier.  These names
> might not have as strong a binding to the user that controlled the validated
> portion of that name (the suffix) as desired.  Some servers would route these
> SNI values to a "default" handler.  The "default" handler could be under the
> control of any user; in fact, users could in some cases choose a name that
> would greatly improve their chances of having their certificate used as a
> default (e.g., or  As formulated here,
> particularly with the User A/Host B phrasing, you are almost implying that the
> security property you rely on in the ALPN design doesn't hold.  As far as I'm
> aware, that security property does hold because you are including exactly the
> validated name in the SNI.