IETF Logo Mail Archive

Re: [Acme] Proposed changes to TLS-SNI, autorenewal removal

Hugo Landau <hlandau@devever.net> Fri, 22 January 2016 18:54 UTC

Return-Path: <hlandau@devever.net>
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 BE7CA1B2C0C for <acme@ietfa.amsl.com>; Fri, 22 Jan 2016 10:54:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 AazQY_glGQy9 for <acme@ietfa.amsl.com>; Fri, 22 Jan 2016 10:54:44 -0800 (PST)
Received: from umbriel.devever.net (umbriel.devever.net [149.202.51.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA971A0155 for <acme@ietf.org>; Fri, 22 Jan 2016 10:54:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with ESMTP id 636351C38D; Fri, 22 Jan 2016 19:54:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=devever.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mimas; t=1453488883; x=1471678244; bh=CVAKVpQJGOScdQEzAQmE6JSE1qY0Hf7L/kJMxQw5Md4=; b= T1QL0cJa344ENsBxNkO79ZO4S++AEw3rzXV48C9GONp6ocV/CPdW18fYqSGG9v/E tpd/+lzn1NzJOR/scb+rU/J95punJb3iCUiK0DhX8tDm14iAGnhQzVIWjCDndLNS dohwNoIC53B+4Bjm4+BFTsGuIlwNezXlrk1F+quUHYDoaohgcDvW201labZa5u7c LM/PZgE9i7y1u800aCqEcw/Y4gcYTcFiu8MA193A1vOwKO6+moqYClqgih0kHVAS LS3FsXK1kB1R/pGyra7IgLf/B9TVrwiHysgKeM8unmtCPwGt2QmIE1iq6cbA478t TIsSQUN4d/d5vf0kgMMKdw==
Received: from umbriel.devever.net ([127.0.0.1]) by localhost (umbriel.devever.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id TX77MOG0y1ZX; Fri, 22 Jan 2016 19:54:43 +0100 (CET)
Received: from andover (localhost [127.0.0.1]) by umbriel.devever.net (Postfix) with SMTP id 2A5221C38B; Fri, 22 Jan 2016 19:54:43 +0100 (CET)
Date: Fri, 22 Jan 2016 18:54:43 +0000
From: Hugo Landau <hlandau@devever.net>
To: Andrew Ayer <agwa@andrewayer.name>
Message-ID: <20160122185442.GA27811@andover>
References: <20160122161306.GA19607@andover> <20160122102725.5f4c2d02825dccf312513a9a@andrewayer.name>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20160122102725.5f4c2d02825dccf312513a9a@andrewayer.name>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/ILEqZSeQ3aodLUg98eiKeJ8p-VA>
Cc: acme@ietf.org
Subject: Re: [Acme] Proposed changes to TLS-SNI, autorenewal removal
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: <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: Fri, 22 Jan 2016 18:54:45 -0000

I've reversed the roles of SAN A and SAN B. The branch has been updated.

Certificates should probably contain SAN A. If they don't, this is
liable to confuse TLS implementations and supporting infrastructure,
which doesn't expect that an SNI request for x should result in a
certificate not listing x.

You could allow extra names (which could be SAN A, or something else
entirely), but, well, why allow extra names? If you have SANs of
foo.token.acme.invalid, bar.ka.acme.invalid and example.com, something
is wrong. If you don't allow extra names, you need to check that all
naems are in {SAN A, SAN B} anyway. Or you require a SNI request for SAN
A lead to a certificate with {SAN B}, which is rather bizarre and will
probably cause problems somewhere.

This is a request-response procedure but it's a request-response
procedure being conducted in a byzantine fashion using TLS's certificate
presentation functionality. The practicalities of that mechanism must be
considered.

On Fri, Jan 22, 2016 at 10:27:25AM -0800, Andrew Ayer wrote:
> On Fri, 22 Jan 2016 16:13:07 +0000
> Hugo Landau <hlandau@devever.net> wrote:
> 
> > Firstly, I've drafted a specification for tls-sni-02
> > which resolves Jehiah's concerns.
> >   <https://github.com/ietf-wg-acme/acme/pull/71>
> 
> I agree with jehiah's comment on GitHub that for consistency with the
> http-01 challenge, SAN A (the token) should be used for the SNI
> request, and SAN B (the keyAuthorization) should be the SAN which the
> ACME server looks for.
> 
> Also, it's not necessary for the ACME server to verify that the
> returned certificate contains SAN A (the token).  Seeing the
> keyAuthorization in a SAN is sufficient.
> 
> I think these changes should be made because paring the challenges down
> to their essentials and making them as similar as possible makes them
> much easier to reason about.  For both http-01 and tls-sni-02, the
> basic procedure would be:
> 
> 1. Request a resource (file or certificate) at the domain using the
> token to identify the resource.
> 
> 2. Verify that the returned resource contains the keyAuthorization.
> 
> -- Andrew
> 
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme

v2.23.0 | Report a Bug | By Email