Re: [Acme] various issues with the spec

Fraser Tweedale <frase@frase.id.au> Sun, 14 June 2015 07:23 UTC

Return-Path: <frase@frase.id.au>
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 875AD1B2B3A for <acme@ietfa.amsl.com>; Sun, 14 Jun 2015 00:23:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.827
X-Spam-Level: ***
X-Spam-Status: No, score=3.827 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HOST_EQ_STATIC=1.172, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 wYyxN92cLRMO for <acme@ietfa.amsl.com>; Sun, 14 Jun 2015 00:23:07 -0700 (PDT)
Received: from captainmorgan.hollandpark.frase.id.au (110-174-235-130.static.tpgi.com.au [110.174.235.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DAF1B2B3C for <acme@ietf.org>; Sun, 14 Jun 2015 00:23:06 -0700 (PDT)
Received: from bacardi.hollandpark.frase.id.au (bacardi.hollandpark.frase.id.au [192.168.0.100]) by captainmorgan.hollandpark.frase.id.au (8.14.9/8.14.9) with ESMTP id t5E7MsJA049663; Sun, 14 Jun 2015 17:22:54 +1000 (EST) (envelope-from frase@frase.id.au)
Received: from bacardi.hollandpark.frase.id.au (localhost [127.0.0.1]) by bacardi.hollandpark.frase.id.au (8.14.9/8.14.9) with ESMTP id t5E7Msfp009397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Jun 2015 17:22:54 +1000 (EST) (envelope-from frase@frase.id.au)
Received: (from fraser@localhost) by bacardi.hollandpark.frase.id.au (8.14.9/8.14.9/Submit) id t5E71cwE009354; Sun, 14 Jun 2015 17:01:38 +1000 (EST) (envelope-from frase@frase.id.au)
X-Authentication-Warning: bacardi.hollandpark.frase.id.au: fraser set sender to frase@frase.id.au using -f
Date: Sun, 14 Jun 2015 17:01:37 +1000
From: Fraser Tweedale <frase@frase.id.au>
To: Stefan =?iso-8859-1?Q?B=FChler?= <acme@stbuehler.de>
Message-ID: <20150614070136.GE79627@bacardi.hollandpark.frase.id.au>
References: <20150609221325.63935a29@chromobil.localdomain> <20150613232121.51f292af@chromobil.localdomain> <7ed545b29d5149ebba5582dfec9777f5@ustx2ex-dag1mb2.msg.corp.akamai.com> <20150614002432.58be28e7@chromobil.localdomain> <20150614011738.GC79627@bacardi.hollandpark.frase.id.au> <20150614080646.38a87686@chromobil.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20150614080646.38a87686@chromobil.localdomain>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/k_NwzuBH9PdiJy3EClzBg30aB9I>
Cc: acme@ietf.org
Subject: Re: [Acme] various issues with the spec
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: Sun, 14 Jun 2015 07:23:08 -0000

On Sun, Jun 14, 2015 at 08:06:46AM +0200, Stefan Bühler wrote:
> On Sun, 14 Jun 2015 11:17:38 +1000
> Fraser Tweedale <frase@frase.id.au>; wrote:
> 
> > On Sun, Jun 14, 2015 at 12:24:32AM +0200, Stefan Bühler wrote:
> > > * dvsni: Please don't require the domain name which is being
> > > validated to be part of subjectAltName; configuring such
> > > certificate might break a working setup in production, when it
> > > "wins" over an already present and valid certificate for the domain.
> > > 
> > No, this certificate is only presented for the host
> > `<nonce>.acme.invalid'.
> 
> You are thinking of a setup where you configure explicitly which
> certificate is used for which SNI value. But gnutls for example has a
> nice feature where you can just give it all your certificates, and it
> will pick the matching one automatically.
> 
Do you propose that the certificate *not* bear the domain name being
validated in *either* the Subject DN or subjectAltName extension?

This probably does not affect the protocol, but I think is nice to
include it anyway for the sake of being explicit.  Can you identify
any existing server software which would is incompatible with ACME
dvsni due to the validation certificate bearing the name being
validated?

> > > * dvsni: `The public key is the public key for the key pair being
> > >   authorized`. I hope this was just an accident, this would be
> > > *really* wrong to require.
> > > 
> > Why would this be wrong?  Remember that this certificate is
> > generated as part of, and intented for use only as part of the
> > authorization workflow.  It has no bearing on certificates
> > eventually issued for the domain name being authorized.
> 
> I don't want my webserver to see my account private key, ever. Am I
> really the first guy to have a problem with that?
> 
> > > * dvsni: Don't require it to be a self-signed certificate - what
> > > does it matter who signed it?
> > > 
> > It must be signed by the account key as evidence that the entity
> > performing the authorization controls the account key.
> 
> What exactly is the attack scenario here if this is not checked?
> Person A playing MITM to give control over domain B to account C, and
> account C started the authorization but didn't actually want it to
> succeed?
> 
> If you really require such evidence, perhaps it could be required to
> have the certificate signed by the account key instead of being
> self-signed.
> 
> regards,
> Stefan

You've convinced me on these latter points - the certificate should
be signed by the account key but the key could be a different key
(i.e. not a self-signed cert) - and this means that the web server
need not have access to the account private key.

Cheers,
Fraser