Re: [Acme] kinds of proof (was: Re: ACME or EST?)

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 28 November 2014 17:09 UTC

Return-Path: <ietf-dane@dukhovni.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 168521A0196 for <acme@ietfa.amsl.com>; Fri, 28 Nov 2014 09:09:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 VMTXs7WhOlre for <acme@ietfa.amsl.com>; Fri, 28 Nov 2014 09:09:19 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94DB1A0149 for <acme@ietf.org>; Fri, 28 Nov 2014 09:09:18 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9B094284AD4; Fri, 28 Nov 2014 17:09:17 +0000 (UTC)
Date: Fri, 28 Nov 2014 17:09:17 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: acme@ietf.org
Message-ID: <20141128170917.GC285@mournblade.imrryr.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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <54784C61.2080508@cs.tcd.ie>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/acme/vhE1FqqpBDqraEG8jQPZ8OOWKWQ
Subject: Re: [Acme] kinds of proof (was: Re: ACME or EST?)
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: acme@ietf.org
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 17:09:24 -0000

On Fri, Nov 28, 2014 at 10:20:17AM +0000, Stephen Farrell wrote:

> > I agree that the wire format (syntax) is less important than the
> > feature set (semantics).  In particular, there I'd like to see some
> > discussion of what kind of "proofs of control" should be acceptable
> > with a lights-out DV certification authority.
> 
> Yep. Fully agree about DV. But DV isn't the only kind of
> validation I'd like to be supported here.

I did not know that DV necessarily implied control of DNS.  I was
using the term to mean something other than EV where the petitioner
though some "high touch" process demonstrates possession of a business
name and associated domains.  Are there certificates for TLS servers
other than EV or DV?

In any case, the details of the supported proofs are I think worthy
of discussion.

> I'd like if it were possible to extend that to include cases
> where one has control over the web server, but not the DNS.

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?

  * 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?

  ...

> The current spec [2] seems to allow for that via the "provision
> a file on the web server" method, but the details of that
> ("simpleHttps" I guess?) aren't clear.

That's an important part of what I'd like to see discussed?

> But I'd very much like to just update apache on my servers
> and have that go get certs that work.

Right, security and convenience are, roughly speaking, at opposite
ends of a set of trade-off decisions.  So one needs to make choices
with some care.

To Phillip's reply, yes these choices are largely orthogonal to
the protocol, except to the extent that the protocol needs to be
sufficiently expressive to communicate the various proofs.  And
yet I'd still like to see a discussion of the substance before we
dive into analysis of the form.

-- 
	Viktor.