Re: [Acme] kinds of proof

Paul Hoffman <paul.hoffman@vpnc.org> Fri, 28 November 2014 18:37 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 84B101A00C5 for <acme@ietfa.amsl.com>; Fri, 28 Nov 2014 10:37:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Level:
X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 wI8ufrJLpjvp for <acme@ietfa.amsl.com>; Fri, 28 Nov 2014 10:37:02 -0800 (PST)
Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7844B1A00BB for <acme@ietf.org>; Fri, 28 Nov 2014 10:37:02 -0800 (PST)
Received: from [10.20.30.90] (142-254-17-143.dsl.dynamic.fusionbroadband.com [142.254.17.143]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sASIb1xx042669 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <acme@ietf.org>; Fri, 28 Nov 2014 11:37:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 142-254-17-143.dsl.dynamic.fusionbroadband.com [142.254.17.143] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <20141128170917.GC285@mournblade.imrryr.org>
Date: Fri, 28 Nov 2014 10:37:01 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <88B49E1D-1601-4B86-8D93-14CF71501DFC@vpnc.org>
References: <AD5940AA-6F01-4D0E-A4E0-19AEA56BBED3@vpnc.org> <CAL02cgTgpjQffow2XuaNuT7BtqYVttXdVUgyqBFbsAbN4g0VzQ@mail.gmail.com> <DEC7A8A8-563D-41B3-94AC-71DC7219D3F8@cisco.com> <m27fyg4yzg.wl%randy@psg.com> <547754C0.9050306@cs.tcd.ie> <20141127211348.GE25114@mournblade.imrryr.org> <54784C61.2080508@cs.tcd.ie> <20141128170917.GC285@mournblade.imrryr.org>
To: acme@ietf.org
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/2C3kV3zrK-vkXi6dmCl9d7H8abA
Subject: Re: [Acme] kinds of proof
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: <http://www.ietf.org/mail-archive/web/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, 28 Nov 2014 18:37:03 -0000

On Nov 28, 2014, at 9:09 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> Related issues:
> 
>  * Does the web server have to be on port 443 with TLS enabled
>    (perhaps with a temporary self-signed certificate)?  Or is it
>    sufficient to control port 80 or some other port with or without
>    TLS?
> 
>  * If on port 443, is an existing certificate from any of the
>    usual public CAs (other than LE) (if also usable as a TLS client
>    cert to authenticate to the provisioning system) accepted as
>    evidence of authenticity for bootstrapping trust with LE?

Why should ability to control port 80 or 443 be a determinant for proving control of "web server" at "domain name"? Not all web service is run on port 80, and not all secure web service is run on port 443. A CA can validate that the requestor can control some HTTP service on some port at the domain name. If a CA has a policy that is more restrictive than that, ACME can trivially support that policy with more error codes.

>  * If the domain is DNSSEC signed, is it reasonable (I hope)
>    to raise the bar, and require proof of DNS control?  Since
>    bootstrapping with just web server control and no existing
>    credentials is vulnerable to MiTM, and signed domains are
>    making an effort to harden against such attacks?

I disagree that ACME-the-protocol should raise the bar past what we use for domain verification today. It's fine if a CA who uses ACME does.

--Paul Hoffman