Re: [Acme] ACME draft is now in WGLC.

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 14 March 2017 05:13 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7462A1294A1 for <acme@ietfa.amsl.com>; Mon, 13 Mar 2017 22:13:12 -0700 (PDT)
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 autolearn_force=no
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 oMxd1ZkvXofC for <acme@ietfa.amsl.com>; Mon, 13 Mar 2017 22:13:11 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25FD129443 for <acme@ietf.org>; Mon, 13 Mar 2017 22:13:10 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2B87E7A3309; Tue, 14 Mar 2017 05:13:10 +0000 (UTC)
Date: Tue, 14 Mar 2017 05:13:10 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: acme@ietf.org
Message-ID: <20170314051309.GR7733@mournblade.imrryr.org>
References: <8473d9ba84894d49b2f2232370d66b46@usma1ex-dag1mb3.msg.corp.akamai.com> <20170307031510.GN7733@mournblade.imrryr.org> <20170307032023.GO7733@mournblade.imrryr.org> <9471a5323a98405eaf0ee111fb0350b0@usma1ex-dag1mb3.msg.corp.akamai.com> <20170313201410.GG4095@mournblade.imrryr.org> <3b319b98-64f2-5ed9-fa2e-460c574459d1@eff.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <3b319b98-64f2-5ed9-fa2e-460c574459d1@eff.org>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/4DrldzAf_mFCGkuR9UV5isgl4fM>
Subject: Re: [Acme] ACME draft is now in WGLC.
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 14 Mar 2017 05:13:12 -0000

On Mon, Mar 13, 2017 at 02:00:40PM -0700, Jacob Hoffman-Andrews wrote:

> > by CA/B forum as a "recommendation", which meant that the constraint
> > was meaningless.  Rumour has it that CAA will soon be a requirement,
> > so I've now published CAA records.  The CAA check is/was easy to
> > make and crippling it by not making it a requirement was IMNSHO a
> > mistake.
>
> I think by this you mean that the CA/Browser Forum should have mandated
> CAA support in its Baseline Requirements, back when it first adopted CAA
> as "recommended." Is that right?

Yes.

> I think the analogous goal here is that you'd like the CA/Browser Forum
> to mandate use of a DNSSEC-validating recursive resolver during
> DNS-based validation procedures.

No, dragging the CA/B forum into this discussion (by way of analogy)
was perhaps a mistake.  I am trying to say is that wiggle room to
not do DNSSEC ACME serves no purpose.  ACME should *require* DNSSEC
resolvers in *ACME conformant CAs.

> That's great! However, I don't think mandating use of a DNSSEC-validating
> resolver in the ACME spec will achieve that goal, since the CA/Browser
> Forum is not planning to mandate use of the ACME spec.

Convincing non-ACME CAs that issue DV certs do use DNSSEC for DNS
challenges is a separate issue (windmill for my Quixotic battles)
and is out of scope for this group.  So one thing at a time, I urge
the ACME WG to require DNSSEC for DNS challenges, so that security
of DNSSEC signed domains is not downgraded by ACME CAs negligently
running security-oblivious resolvers.

-- 
	Viktor.