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

Jonathan Rudenberg <> Wed, 25 March 2015 19:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C6CB71B2B45 for <>; Wed, 25 Mar 2015 12:50:33 -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 yIh5AoGlrkYZ for <>; Wed, 25 Mar 2015 12:50:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58F1C1A8941 for <>; Wed, 25 Mar 2015 12:50:32 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id D03C52074B for <>; Wed, 25 Mar 2015 15:50:28 -0400 (EDT)
Received: from frontend2 ([]) by compute6.internal (MEProxy); Wed, 25 Mar 2015 15:50:31 -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=5jlfD3ZvctEO5eGlHUW8VFXYr0s=; b=zsLr4GDYzBmkIZ9gKLVG1 6ADJOi3yfhkJgLwwHA1USMvSEPZ/lBILY4BDn0bfLJlrM7amdcC7aP8jqK5xMRV5 GzQejwwDZlPEPqlMIvNENdeoXtKOSoDNaPHxphr63WrTZ/bUBZFhJWs3THJ/3PNs 4Wsq8E/VDI+FY0peC5zHQ8=
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=5jlfD3ZvctEO5eGlHUW8VFX Yr0s=; b=dYQb8M+pe7rjO7KXpiBQwpb/60Mrr6FaFHPSk2V0XVWPOZ1bN9ru0dv u53gSswZV4/irKt0OKNqwtK1QjPE71NZp83WEa2fs+yrG7cevIu6XQUyQ7E1wlAv xv6HQAQxzyClQb0cRIbMpJsWK6GD6BYxR4bqbrJAP0EUZmhYIgJ0=
X-Sasl-enc: dencTZnXTNNLhGcqPFv86ekU+Ys/RKnpishlUmphwCfI 1427313031
Received: from [] (unknown []) by (Postfix) with ESMTPA id 187776800B8; Wed, 25 Mar 2015 15:50:31 -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 12:50:30 -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 19:50:34 -0000

> On Mar 25, 2015, at 12:42 PM, John Mattsson <> wrote:
>> On 25 Mar 2015, at 13:24, Jonathan Rudenberg <> wrote:
>>> 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.
> Yes, but that CAs is doing something does not mean that IETF should standardise or recommend something. I think DVSNI and Simple HTTPS challenge methods are fundamentally different. In DVSNI and “put this meta tag or text file on the HTTP server” the root of trust is being on-path. In the Simple HTTPS challenge the root of trust is the HTTPS certificate.

I’m not clear on your definition of “on-path” and distinction between the two challenges. Both Simple HTTPS and DVSNI allow anyone who can respond to TCP connections to a domain to request a certificate for it.

>> If the only automated challenge method available is DNS, this puts a *huge* damper on the usability of the system.
> I would prefer dropping DVSNI and only use Simple HTTPS and DNS. That would damper the usability somewhat, but I think it’s worth it. But in the end it boils done to what presenting a domain certificate is supposed to prove...
>  The point that DNS configuration damper the usability indicates that somebody should look at automatic DNS management as well….

Sure, but practically speaking this isn’t going to happen any time soon.