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

John Mattsson <> Wed, 25 March 2015 19:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 904211A8A27 for <>; Wed, 25 Mar 2015 12:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U0Cq0zr7dJFp for <>; Wed, 25 Mar 2015 12:42:28 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF96D1A8A23 for <>; Wed, 25 Mar 2015 12:42:27 -0700 (PDT)
X-AuditID: c1b4fb30-f79996d000006ebb-24-55130fa1f6cd
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id C9.1D.28347.1AF03155; Wed, 25 Mar 2015 20:42:25 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Wed, 25 Mar 2015 20:42:25 +0100
From: John Mattsson <>
To: Jonathan Rudenberg <>
Thread-Topic: [Acme] High level comments on draft-barnes-acme (the GitHub version)
Thread-Index: AQHQZxmk1M68c5H69UWO2PH8xj5dVZ0tcuiAgAAVwYA=
Date: Wed, 25 Mar 2015 19:42:25 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B4953448093A4DB7B81DB09FE31E7B3Fericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGfG3Rnchv3CowZn35harngdazH/M4cDk sWTJTyaPPafusQQwRXHZpKTmZJalFunbJXBlPOl8zF5wNK5i970zLA2M36K7GDk5JARMJCbu nc0IYYtJXLi3nq2LkYtDSOAIo8STpj8sEM4SRonfb5exgFSxCRhIzN3TwAZiiwjoSRz7do8V xGYWUJZoa18JZgsLBEs0vLvAAlETItG3vp8ZwraSmHtsNlgNi4CqxMnHf8Dm8ArYS1yb9IsJ xBYSKJWYubcPLM4p4CAxdf4esHpGoOu+n1rDBLFLXOLWk/lMEFcLSCzZc54ZwhaVePn4HyuE rSSxYvslRoj6ZInbVx6yQuwSlDg58wnLBEbRWUhGzUJSNgtJ2SxGDqC4psT6XfoQJYoSU7of skPYGhKtc+ZC2dYSS1c/ZkNWs4CRYxWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYAwe3PLb YAfjy+eOhxgFOBiVeHg3qAiFCrEmlhVX5h5ilOZgURLntTM+FCIkkJ5YkpqdmlqQWhRfVJqT WnyIkYmDU6qBccKkW/depf+W6rtSujIz/5NXJuvJB3oBlpPWZ8hYSU3rPbtRYyKz8ZepRdqt XD6+D/e4XHde4sNoufCtSO3a175dq9JZOS93Fb/NmpER8njerOkey8PNV8Rv/nxeY2qUDfda ITmPq7+L/s/zUIs99O27abai+LPP/zRWmBv8u3foYP1TaZ01P5RYijMSDbWYi4oTAU2+YFui AgAA
Archived-At: <>
Cc: "" <>
Subject: Re: [Acme] High level comments on draft-barnes-acme (the GitHub version)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Automated Certificate Management Environment <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Mar 2015 19:42:30 -0000

On 25 Mar 2015, at 13:24, Jonathan Rudenberg <<>> wrote:

On Mar 25, 2015, at 9:35 AM, John Mattsson <<>> wrote:


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.

Section 11.1.1 of the Baseline Requirements allows this:

Thanks for pointing this out.

6. Having the Applicant demonstrate practical control over the FQDN by making an agreed-upon change to information found on an online Web page identified by a uniform resource identifier containing the FQDN; or

I would state that making a change to an online web page (http://) does not prove control of the FQDN, it only proves being on-path...

7. Using any other method of confirmation, provided that the CA maintains documented evidence that the method of confirmation establishes that the Applicant is the Domain Name Registrant or has control over the FQDN to at least the same level of assurance as those methods previously described.

The current status quo is that many CAs allow “put this meta tag or text file on the HTTP server” as a challenge, which is *less* secure than the proposed DVSNI and Simple HTTPS challenge methods.

Yes, but that CAs is doing something does not mean that IETF should standardise or recommend something. I think DVSNI and Simple HTTPS challenge methods are fundamentally different. In DVSNI and “put this meta tag or text file on the HTTP server” the root of trust is being on-path. In the Simple HTTPS challenge the root of trust is the HTTPS certificate.

If the only automated challenge method available is DNS, this puts a *huge* damper on the usability of the system.

I would prefer dropping DVSNI and only use Simple HTTPS and DNS. That would damper the usability somewhat, but I think it’s worth it. But in the end it boils done to what presenting a domain certificate is supposed to prove...

 The point that DNS configuration damper the usability indicates that somebody should look at automatic DNS management as well….

Do you have any concrete modifications or alternatives to the DVSNI validation method that would improve the security?

I don’t think it’s theoretically possible to hinder on-path attackers in a system that uses being on-path as the root of trust.

Do you have the same complaint about the Simple HTTPS validation method?

No, see above.