Re: [Acme] Directory metadata; wildcard support; conditional authz creation

Andrew Ayer <agwa@andrewayer.name> Sun, 31 January 2016 05:26 UTC

Return-Path: <agwa@andrewayer.name>
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 15DAA1B4033 for <acme@ietfa.amsl.com>; Sat, 30 Jan 2016 21:26:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.298
X-Spam-Level: *
X-Spam-Status: No, score=1.298 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_62=0.6, SPF_HELO_PASS=-0.001, 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 8WlxfoVqFiUh for <acme@ietfa.amsl.com>; Sat, 30 Jan 2016 21:26:25 -0800 (PST)
Received: from alcazar.beanwood.com (alcazar.beanwood.com [70.85.129.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC91D1B4032 for <acme@ietf.org>; Sat, 30 Jan 2016 21:26:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=alcazar2; t=1454217984; bh=gfoJX3heGLDXUWoAuix5TpMn9Bu/9f2WaBLvvatbVf4=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=gs1W/NohY99we+hNYtEPsgAJ/MNJ8w/RA/UJr1SmK782VocIjUji+WuaO2/+UrsX9 pxqxcMFrx557D7cCpH1t+MyuvT5FmCo1F/Vbwcr42+MSE+uAQM9msi5uqsAoIZnp7O 8rGFejYalWSPWIKUqthMAbp/NJVZVH79Hg3J5mK/jy5s2uRCETdNv4c5qRqbLK3KO5 eQnRk3m6sXr4tPjw7dRPKxE8FX/yQPuLM4Js6O+U3uN5iWwyoMsagLn7ePGpGQulQM JJGdms6c0nV/2M+ExsYRbtY9ZYO7oZb24HEKwahgIaSD5ezAOSyWv/8wZqA6zja4ka AwduDdEPVgELQ==
Date: Sat, 30 Jan 2016 21:26:24 -0800
From: Andrew Ayer <agwa@andrewayer.name>
To: Hugo Landau <hlandau@devever.net>
Message-Id: <20160130212624.d28caed07b79d3ccb0c24b39@andrewayer.name>
In-Reply-To: <20160131033925.GA29713@andover>
References: <20160131033925.GA29713@andover>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/eLu_xKqW9BYrJvS11qCAwzByUdk>
Cc: acme@ietf.org
Subject: Re: [Acme] Directory metadata; wildcard support; conditional authz creation
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: Sun, 31 Jan 2016 05:26:27 -0000

On Sun, 31 Jan 2016 03:39:25 +0000
Hugo Landau <hlandau@devever.net> wrote:

> A proposed scheme for wildcard support.
> <https://github.com/ietf-wg-acme/acme/pull/74>

1. I don't think ACME should support wildcard characters anywhere but
the leftmost label.  RFC6125 says TLS clients SHOULD NOT match wildcards
in other labels, and in practice neither clients nor CAs support them.

2. The validation mechanism is insecure when a domain allows
users to register arbitrary sub-domains and host content on them
(e.g. github.io, Amazon S3).  For example, if I create a wildcard
authz for *.github.io, the server will issue challenges for some
random sub-domains (e.g. df2icxw7mg5gbbfc636ttbwsmi.github.io,
fonm6ymv77dlpac2qfvyjns4u4.github.io).  I can go register those
sub-domains at github.io (since the sub-domain labels have high entropy,
they will be available with high probability), complete the challenges,
and then be authorized for all of *.github.io.  To fix this, the server
should also require I complete a challenge for the "underlying"
identifier (github.io in this example).

3. It's not specified how the server communicates to the
client what sub-domains need to be validated.

I suggest that the HTTP, DNS, and TLS SNI challenge objects be extended
to include a "hostname" field, which specifies the hostname under which
the challenge must be completed. The server can then make use of the
existing combinations mechanism to require the client complete
challenges under several sub-domains.

Perhaps ACME shouldn't even specify how wildcard identifiers are
validated, but leave it as a matter of CA policy.  Some CAs might be
fine only requiring a challenge on the underlying domain (which is how
some CAs currently validate wildcard certs), while others would require
challenges on random sub-domains.  The policy might even be different
depending on challenge type: the CA might accept either a single DNS
challenge on the underlying domain, or a combination of HTTP challenges
on the underlying domain and several random sub-domains.

-- Andrew