[Acme] High level comments on draft-barnes-acme (the GitHub version)

John Mattsson <john.mattsson@ericsson.com> Wed, 25 March 2015 16:35 UTC

Return-Path: <john.mattsson@ericsson.com>
X-Original-To: acme@ietfa.amsl.com
Delivered-To: acme@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 244651A88FA for <acme@ietfa.amsl.com>; Wed, 25 Mar 2015 09:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id OoOk49uR7lig for <acme@ietfa.amsl.com>; Wed, 25 Mar 2015 09:35:05 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16B8B1A88D8 for <acme@ietf.org>; Wed, 25 Mar 2015 09:35:04 -0700 (PDT)
X-AuditID: c1b4fb25-f79126d000004b89-d2-5512e3b7891f
Received: from ESESSHC014.ericsson.se (Unknown_Domain []) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A0.48.19337.7B3E2155; Wed, 25 Mar 2015 17:35:03 +0100 (CET)
Received: from ESESSMB307.ericsson.se ([]) by ESESSHC014.ericsson.se ([]) with mapi id 14.03.0210.002; Wed, 25 Mar 2015 17:35:02 +0100
From: John Mattsson <john.mattsson@ericsson.com>
To: "acme@ietf.org" <acme@ietf.org>
Thread-Topic: High level comments on draft-barnes-acme (the GitHub version)
Thread-Index: AQHQZxmk1M68c5H69UWO2PH8xj5dVQ==
Date: Wed, 25 Mar 2015 16:35:01 +0000
Message-ID: <92B826AA-48E3-454C-85A9-600F84D539DD@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <DC3650E15A2E6B49A551565004540AD2@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvje72x0KhBuffCVuseh7owOixZMlP pgDGKC6blNSczLLUIn27BK6M7bMXsBUska842L+JqYFxj1wXIyeHhICJxJ31uxghbDGJC/fW s3UxcnEICRxhlJhy7BMjhLOEUWLlyrdgVWwCBhJz9zSwgdgiAsoS11c3sYPYwgJuEoe3/mOB iHtLPF/1ihHC1pN4seIgWJxFQFXiWVcrUxcjBwevgL3Ek+XSIGFGoMXfT61hArGZBcQlbj2Z zwRxkIDEkj3nmSFsUYmXj/+xQthKEmsPb2cBGcMsoCmxfpc+RKu1xIcJq1ggbEWJKd0PwS7j FRCUODnzCcsERpFZSDbMQuiehaR7FpLuWUi6FzCyrmIULU4tTspNNzLWSy3KTC4uzs/Ty0st 2cQIjIaDW36r7mC8/MbxEKMAB6MSD+8GFaFQIdbEsuLK3EOM0hwsSuK8dsaHQoQE0hNLUrNT UwtSi+KLSnNSiw8xMnFwSjUwRl0WKmmwW+LwYJmzrnxOcGNt4XYl6Y2BH9MzV4jocL3PYdn2 n2FL7tMDLtffb7/89EhEy8wSvh6rm34M2btuWjiynFE76sQeLyZ2IPSw23fm6eyXP0qXxWif a/psbS3F9jenvfNazO1Nfr8/zToeytR9x5NRbPGRFDbH/XIaCmYH1+Sv5pulxFKckWioxVxU nAgA8SJCeWcCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/nZUEnS29PFmS-emjtwARkJbclBA>
Subject: [Acme] High level comments on draft-barnes-acme (the GitHub version)
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: Wed, 25 Mar 2015 16:35:07 -0000


Some high level comments on draft-barnes-acme (the GitHub version)

- Security:
The security of this seems to need some serious rethinking. The “Domain Validation with Server Name Indication” challenge seems totally nonsecure, allowing ANY on-path attacker to get certificates issued. I think this challenge is unacceptable for certificate issuance and I think it should be removed. Just because I let Amazon, Microsoft, Google or any other cloud provider run my web server does not mean I give them the right to request certificates for my domain.

And no, the account key pair and recovery token does not help:
- Most domains will not have any registration with an ACME CA, allowing an on-path attacker to get certificates from any ACME CA.
- And if a domain has registered with ACME CA1, the attacker can just use ACME CA2 instead. This not only allows the on-path attacker to get certificates for the domain, it also allows the attacker to highjack the registration with ACME CA1 as the ultimate recovery mechanism is “Recertification by another CA + PoP of that key”.

We cannot standardize a solution were the security depends on domains registering with all CAs supporting ACME, and standardizing something that lets on-path attackers request certificates does more harm than good. I hope that I am missing something...

- Validation methods:
The Introduction mentions three methods for domain validation:
 - Put a CA-provided challenge at a specific place on the web server.
 - Put a CA-provided challenge at a DNS location corresponding to the target domain.
 - Receive CA challenge at a (hopefully) administrator-controlled e-mail address
   corresponding to the domain and then respond to it on the CA's web page.

But the e-mail method does not seem to be described at all in the draft and the DNS method is not listed in the table in the Section “Identifier Validation Challenges”.

- Scope:
The current name and draft suggest the broad scope of certificate management for HTTPS servers. And in “Deployment Model and Operator and Operator Experience” the ACME client is clearly a newly deployed HTTPS server. I think this is the right scope, but as I stated earlier I think this scope must include certificate import.

If certificate import is not in scope, then the work is not the currently stated certificate management for HTTPS servers, then it’s just Interface to Certificate Authority (I2CA), and in that case I think the ACME client will not and should not be the HTTPS server. A web server is definitely the wrong place to store the recovery token, and for virtualized cloud based web servers my view is that they in many cases should not even have an ACME account key pair.


John Mattsson
Ericsson IETF Security Coordinator 
Senior Researcher, Security