Re: [Acme] Want client-defined callback port

Bruce Gaya <gaya@apple.com> Tue, 21 April 2015 22:19 UTC

Return-Path: <gaya@apple.com>
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 C64951B2CC5 for <acme@ietfa.amsl.com>; Tue, 21 Apr 2015 15:19:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.1
X-Spam-Level:
X-Spam-Status: No, score=-4.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 mb3S08GsbNQv for <acme@ietfa.amsl.com>; Tue, 21 Apr 2015 15:19:46 -0700 (PDT)
Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DA781B2CE0 for <acme@ietf.org>; Tue, 21 Apr 2015 15:19:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1429654747; x=2293568347; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YI1EewS3VM4fK2sfxyHzIygT6rdZ/dSjcPW7X6RTBY4=; b=y8snvgWBeepTikXtNt+23VhqGHtaJJnAgDDiEXmpJNAHo+296W9Bu2/YiNUQtqug gmiU+1mtzDpR5CEtM2LppM+ViMQ9qqNHcn0Z5eEjYCNYXRpQb8BXweXVuaS6CJQh eH4jJ10ylUjXJdYAXAMJHHnBMM0sjKlij4mBTPRwtQL3wk0U1Bgw+5i3hPCOoCsS JCGAzN7VVzYHZTHnr0TyQPf1ppCb1ma03FbBnE2cT16Fo/8brY29Ah3IBPQTjQ/1 sIFg1mCzYIIYtczDb2gcsF0NQKf0FeuEgz14YFCs0a0zh0OqojH5GKCZKfI53bBO w/Y5qSTWLYOb35PWTtgLgA==;
Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id F3.18.12430.BDCC6355; Tue, 21 Apr 2015 15:19:07 -0700 (PDT)
X-AuditID: 11973e13-f79d56d00000308e-27-5536ccdb7026
Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id D0.4B.08671.CCCC6355; Tue, 21 Apr 2015 15:18:53 -0700 (PDT)
Received: from [17.153.51.181] by chive.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NN600HFNGNOXBA0@chive.apple.com> for acme@ietf.org; Tue, 21 Apr 2015 15:19:07 -0700 (PDT)
MIME-version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-type: multipart/alternative; boundary="Apple-Mail=_910A7799-F14D-49EC-B9D0-056F7D3CA9B9"
From: Bruce Gaya <gaya@apple.com>
In-reply-to: <CAL02cgSDk0TNYusEkXA3onmqF7=kaAWhHjpW8WjbiqxgQMdQwQ@mail.gmail.com>
Date: Tue, 21 Apr 2015 15:19:00 -0700
Message-id: <555F6C74-2416-4893-BDEA-A3C2E55A6D57@apple.com>
References: <352DA5FE-AC6F-49A7-8F9F-70A74889204F@apple.com> <CAK3OfOjey4bk02qC_jj2c0AzZ54qnP=KAJnG=mXnO6A5gZ4m9g@mail.gmail.com> <CAL02cgQ94ijVrCM9SStcodRW+XSG2w5Zwu3+ny8HriDBnxjdtg@mail.gmail.com> <FF21526F-BA8D-4F54-AAE3-047632706668@apple.com> <CAL02cgSDk0TNYusEkXA3onmqF7=kaAWhHjpW8WjbiqxgQMdQwQ@mail.gmail.com>
To: Richard Barnes <rlb@ipv.sx>
X-Mailer: Apple Mail (2.2098)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUi2FDorHv7jFmowbJDJharngc6MHosWfKT KYAxissmJTUnsyy1SN8ugSvj28mbrAV3nCpu71vD2MC4zqKLkZNDQsBE4vTPO8wQtpjEhXvr 2UBsIYG9jBKz92nA1GzYPxkozgUU72aSeLV9PTuE85FRYtKLl4wgVcICphKH3i0Ds3kF9CTm XF8ANolZIEliwfY7TCA2m4CixPTWF2A2p0CwxO4nb8FqWARUJXYu2M4KUe8l8Xf2RmaIOTYS J3qns0IsO8IksW/7J7BmEQF5idPXHwAlOIDOk5X4ulUO4tK/rBIXnyVMYBSaheSMWUjOgLC1 JZYtfM0MYWtK7O9ezoIpriHR+W0i6wJGtlWMQrmJmTm6mXmmeokFBTmpesn5uZsYQUE/3U54 B+PpVVaHGAU4GJV4eBkmm4YKsSaWFVfmHmKU5mBREuflBcaMkEB6YklqdmpqQWpRfFFpTmrx IUYmDk6pBsbTopf/ir34lWh0qCnh4d3nUybanq+7+ngag+An83T5ZTFpa+JP7BF8qHSXN6zx 5inRxOzvRb+XyhXdC3w0u/bDP56C159FNpUtu8TtcOUSl4ZO4PTpc/7PM84L3Cte7N5851Lu 954zPeuqOe58+SDsnXMw4Mtktkn5yVvjE5zXK8S0Kf4o2MSoxFKckWioxVxUnAgAWU7qNVsC AAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUi2FDMr3v2jFmowYV2NotVzwMdGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJXx7eRN1oI7ThW3961hbGBcZ9HFyMkhIWAisWH/ZDYIW0ziwr31 QDYXh5BAN5PEq+3r2SGcj4wSk168ZASpEhYwlTj0bhmYzSugJzHn+gKwbmaBJIkF2+8wgdhs AooS01tfgNmcAsESu5+8BathEVCV2LlgOytEvZfE39kbmSHm2Eic6J3OCrHsCJPEvu2fwJpF BOQlTl9/AJTgADpPVuLrVrkJjPyzkKyehWQ1hK0tsWzha2YIW1Nif/dyFkxxDYnObxNZFzCy rWIUKErNSaw00kssKMhJ1UvOz93ECA7UQucdjMeWWR1iFOBgVOLhXTHBNFSINbGsuDL3EKME B7OSCO/SBWahQrwpiZVVqUX58UWlOanFhxilOViUxHl/9wNVC6QnlqRmp6YWpBbBZJk4OKUa GA1bnEo2lWbmbF0Vf/ToQ+dlE1VOfH5Q5Tzt887MHdu8/i080MQ+7/OOuJRsb2uRdTO4mV/n y/lkns9RiDi8+q2rxmcG0VqpyalfDvLtXBjx8WvIXfZDXcJd0V/uqe9z2q8SLlmxR+Dz4jVz ZNMbgp87ntB/Yd+9/uHaWYnB07+r+BW6PJ52bqsSS3FGoqEWc1FxIgBJbBPJUAIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/acme/eTOszsvXfW1otbmE8W4RqBNIyD0>
Cc: Nico Williams <nico@cryptonector.com>, "acme@ietf.org" <acme@ietf.org>
Subject: Re: [Acme] Want client-defined callback port
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: Tue, 21 Apr 2015 22:19:48 -0000

> On 17 Apr 2015, at 05:08, Richard Barnes <rlb@ipv.sx> wrote:
> 
> 
> 
> On Thu, Apr 16, 2015 at 10:50 PM, Bruce Gaya <gaya@apple.com <mailto:gaya@apple.com>> wrote:
> 
>> On 16 Apr 2015, at 18:57, Richard Barnes <rlb@ipv.sx <mailto:rlb@ipv.sx>> wrote:
>> 
>> Right.  The property that we're trying to authenticate here is that the ACME client controls something associated with the hostname.  Ideally, this would be the person with write access to the zone file (cf. DNS challenges), but to facilitate validation, modern validation accepts validation of things like controlling an HTTP or HTTPS server.  It's less clear that it would be acceptable to validate that someone can provision a service on, say, port 36707.
>> 
>> That said, the ability to do domain validation without service interruption seems like an important requirement.  It seems like the DNS challenge listed in the current draft meets that requirement.  We should be able to design the simpleHttps challenge so that you just have to to provision an extra file on an HTTPS server, not reconfigure it.
>> 
>> --Richard
>> 
>> On Thu, Apr 16, 2015 at 8:56 PM, Nico Williams <nico@cryptonector.com <mailto:nico@cryptonector.com>> wrote:
>> You have to be able to prevent unauthorized users from using this
>> alternative callback port to get certs with which to impersonate your
>> service.
> 
> 
> The server (ACME client) computer may be shared between various administrators.  It may also have multiple DNS names and host multiple services.  If I use ACME to get a certificate for a non-web service, like a CalDAV service (default https port = 8443). I do not want to touch or reconfigure the web server or (whatever happens to be using port 443) just to get a cert for CalDAV.
> 
> This argument seems a little confused.  The certificates that CalDAV uses are not “certs for CalDAV", they're DV certificates just like any others -- if you can get a cert for CalDAV, then you can use it for, say, HTTPS as well.  

The real scenario is that some application may already have a web server instance running on port 443 for any number of reasons.  Now another application, say CalDAV administration, wants to get a certificate using ACME. With the current port 443 callback requirement, all the CalDAV administration application can do is display an error message.  But this is completely unnecessary and adds nothing, IMHO, to system security.  It would be much, much better for certificate issuance to “just work”. (I note that the current Let’s Encrypt Demo client has this same issue even when using the “stand-alone” authenticator.)

Of course a particular CA may require port 443 callbacks to issue a certificate, fine. But that policy should not be built into the ACME protocol.

I would encourage the Let’s Encrypt CA to allow *any* client-defined port for SimpleHTTS and DVSNI callbacks because I want the ACME client to “just work” without unneeded user actions.

Bruce