Re: [Acme] High level comments on draft-barnes-acme (the GitHub version)

Jonathan Rudenberg <> Wed, 25 March 2015 18:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C8F9D1AC3F7 for <>; Wed, 25 Mar 2015 11:24:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W-q8PUMvbkw0 for <>; Wed, 25 Mar 2015 11:24:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 368A21AC3EC for <>; Wed, 25 Mar 2015 11:24:34 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id B44E02017B for <>; Wed, 25 Mar 2015 14:24:30 -0400 (EDT)
Received: from frontend2 ([]) by compute1.internal (MEProxy); Wed, 25 Mar 2015 14:24:33 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h= x-sasl-enc:content-type:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; s= mesmtp; bh=VQNfbkYEZQ2LyTGrp9avHTUc6io=; b=HxA9HZzaiYxNF9JcaNVAQ y1ZAb0gN2+isf44U4M41Y+5VnqDXD4S9SPHVCFnUePFUuCIck7bi5zBr1TIX63bM BVoCm8xh6RpdZSJhVLVYVKk2ZJ0sg3dxte8dap7fyQOD1XOH7ORcmIXSoiRNLcFC 53TPsiosuDk3pRnoH8x3bY=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=; h=x-sasl-enc:content-type:mime-version :subject:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to; s=smtpout; bh=VQNfbkYEZQ2LyTGrp9avHTU c6io=; b=sLh9exOy49SACks9j0643bqjpfscqwPvcRcLD7pP2J46Ahx7YH7uXqg mcL0IKXfjXJUlc8NdKBWXNmrlLruTkraSbi+Uguy/filPaaeJxdQ0jNerhhLhxjz Q//2DOigVVJX9D5CfHDXzDsjUU5ARS+FR7AKwR8K9bBcyWzlrVPs=
X-Sasl-enc: utcmAMJcatBZYNgUgEWyIOVTlLlUVM40mpWTpvonclVt 1427307873
Received: from [] (unknown []) by (Postfix) with ESMTPA id F13B56800CB; Wed, 25 Mar 2015 14:24:32 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Jonathan Rudenberg <>
In-Reply-To: <>
Date: Wed, 25 Mar 2015 11:24:31 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: John Mattsson <>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <>
Cc: "" <>
Subject: Re: [Acme] High level comments on draft-barnes-acme (the GitHub version)
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, 25 Mar 2015 18:24:35 -0000

> On Mar 25, 2015, at 9:35 AM, John Mattsson <> wrote:
> Hi,
> Some high level comments on draft-barnes-acme (the GitHub version)
> - Security:
> The security of this seems to need some serious rethinking. The “Domain Validation with Server Name Indication” challenge seems totally nonsecure, allowing ANY on-path attacker to get certificates issued. I think this challenge is unacceptable for certificate issuance and I think it should be removed. Just because I let Amazon, Microsoft, Google or any other cloud provider run my web server does not mean I give them the right to request certificates for my domain.

Section 11.1.1 of the Baseline Requirements allows this:

> 6. Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN; or
> 7. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described.

The current status quo is that many CAs allow “put this meta tag or text file on the HTTP server” as a challenge, which is *less* secure than the proposed DVSNI and Simple HTTPS challenge methods.

If the only automated challenge method available is DNS, this puts a *huge* damper on the usability of the system. Do you have any concrete modifications or alternatives to the DVSNI validation method that would improve the security? Do you have the same complaint about the Simple HTTPS validation method?