From nobody Sun Jan 15 05:51:59 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCF74129553 for ; Sun, 15 Jan 2017 05:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 z2IYckLErb-W for ; Sun, 15 Jan 2017 05:51:56 -0800 (PST) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A1A129432 for ; Sun, 15 Jan 2017 05:51:55 -0800 (PST) Received: from beeb.leiden.webweaving.org (5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v0FDocHp043905 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 15 Jan 2017 14:50:38 +0100 (CET) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6] claimed to be beeb.leiden.webweaving.org From: Dirk-Willem van Gulik Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <9099A621-D460-47B6-9172-0984CF3A0DC8@webweaving.org> Date: Sun, 15 Jan 2017 14:50:37 +0100 To: acme@ietf.org X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Sun, 15 Jan 2017 14:50:38 +0100 (CET) Archived-At: Subject: [Acme] Well Known CA->client poll on port 80/443 in http-acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 13:51:58 -0000 W.r.t. http-acme =E2=80=94 as far as I understand; the current 0.4 draft = (https://tools.ietf.org/html/draft-ietf-acme-acme-04) has the Well known = fetch going to port 80: Section 7.2, page 47 3. Dereference the URI using an HTTP GET request. =20 This request MUST be sent to TCP port 80 on the server. The new draft: (https://letsencrypt.github.io/acme-spec/ also numbered = =E2=80=98=E2=80=9904=E2=80=9D) in section 7.1 =E2=80=98Simple HTTP=E2=80=99= , does a 180 degree change on this =E2=80=98default=E2=80=99: to an = httpS default with an option to explicitly move it to HTTP with: "tls": false / false With the explanation that: If this attribute is present and set to =E2=80=9Cfalse=E2=80=9D, = the server will perform its validation check over unencrypted HTTP (on = port 80) rather than over HTTPS. Otherwise the check will be done over = HTTPS, on port 443. without the clarity of a MUST. And it then continues 3 paragraphs down = with solving* the bootstrap issue by If using HTTPS, the ACME server MUST ignore the certificate = provided by the HTTPS server. I am currently puzzling over an implementation that makes it as easy as = possible to bring up an HTTPS webserver if you do =E2=80=98nothing=E2=80=99= but flag the VirtualHost config with something like 'letsencrypt on=E2=80= =99 - and then defers to sane =E2=80=98SSLLabs A+=E2=80=99 level SSl = defaults. What I=E2=80=99d like to understand is - What is the value of doing the exchange over HTTPS (as this is = made the default as opposed to the current 80) when one does not check = the certificate nor retains the ACME Servers its view of that cert in = the further exchange (or uses the RSA key of the challenge to self sign) = ? - Would there be any good reason to not allow the specification of = a port number ? The reason for the first question is that keeping the process simple is = desirable from an implementers point of view - as you want it relatively = robust because some of the backend server config processes need to hark = back to pre-chroot and pre-fork/pre-setuid() as to get secure = persistence of state and (private) keys (which you want be a = social-internet citizen that does not willy nilly overload the lets = encrypt infra every startup). The reason for the latter question is that it 1) allows for non-root > = 1024 settings and 2) may be more =E2=80=98robust=E2=80=99 to allow the = server to open a relatively random high ephemeral port for a short time = during startup that does not give a false sense of having the actual = virtual host yet up; or a HTTPS only virtualhost shortly seeming to be = misconfigured and appearing on port 80. Thanks, Dw. * Well not =E2=80=98solving=E2=80=99 it - as the cert seen by the ACME = server or the session key negotiated are not mixed into the response as = to allow the Client to verify that there was no MITM during this = exchange =E2=80=94 as this is sort of deferred to later - when you find = out that the cert signed is not one you have a private key for. Or by = for exampling insisting that this certificate that is =E2=80=98ignored=E2=80= =99 is in fact one self-signed by the same RSA key used in the token = dance (which would be probably easiest for implementors if HTTPS was a = strong default/guidance/best-practice). From nobody Sun Jan 15 06:03:38 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F86D129432 for ; Sun, 15 Jan 2017 06:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 HdgrZeJ9D9WV for ; Sun, 15 Jan 2017 06:03:34 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 62C49129565 for ; Sun, 15 Jan 2017 06:03:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id B10EB156FF; Sun, 15 Jan 2017 16:03:32 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id JcveZ97hPpXi; Sun, 15 Jan 2017 16:03:32 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id EE6E2C4; Sun, 15 Jan 2017 16:03:31 +0200 (EET) Date: Sun, 15 Jan 2017 16:03:30 +0200 From: Ilari Liusvaara To: Dirk-Willem van Gulik Message-ID: <20170115140330.GA26429@LK-Perkele-V2.elisa-laajakaista.fi> References: <9099A621-D460-47B6-9172-0984CF3A0DC8@webweaving.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9099A621-D460-47B6-9172-0984CF3A0DC8@webweaving.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: acme@ietf.org Subject: Re: [Acme] Well Known CA->client poll on port 80/443 in http-acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 14:03:37 -0000 On Sun, Jan 15, 2017 at 02:50:37PM +0100, Dirk-Willem van Gulik wrote: > W.r.t. http-acme — as far as I understand; the current 0.4 draft (https://tools.ietf.org/html/draft-ietf-acme-acme-04) has the Well known fetch going to port 80: > > Section 7.2, page 47 > > 3. Dereference the URI using an HTTP GET request. > > This request MUST be sent to TCP port 80 on the server. > > The new draft: (https://letsencrypt.github.io/acme-spec/ also numbered > '04') in section 7.1 ‘Simple HTTP’, does a 180 degree change on this > ‘default’: to an httpS default with an option to explicitly move it to > HTTP with: > > "tls": false / false That's not a new version. It is pre-WG version, published about 1.5 years ago. The reason HTTPS support for HTTP authentication was removed was that many webservers handle HTTPS in odd manner, making alphabetically first HTTPS vhost the default, which would let one get certificates for vhosts one should not. Currently in acme spec, the only ways to do verification without port 80 are TLS-SNI-02 (uses port 443) and DNS-01 (no connections at all, relies on DNS exclusively). -Ilari From nobody Sun Jan 15 06:12:52 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C70512957F for ; Sun, 15 Jan 2017 06:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 20tGUlZQm0Ow for ; Sun, 15 Jan 2017 06:12:49 -0800 (PST) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A238012957B for ; Sun, 15 Jan 2017 06:12:49 -0800 (PST) Received: from beeb.leiden.webweaving.org (5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v0FEBWLn044504 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 15 Jan 2017 15:11:32 +0100 (CET) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6] claimed to be beeb.leiden.webweaving.org From: Dirk-Willem van Gulik Message-Id: <6AEBC4C9-FA1B-4672-AE58-15C165722B30@webweaving.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_30AD87F4-E28B-45B1-90E0-4C934C368C48" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 15 Jan 2017 15:11:32 +0100 In-Reply-To: <20170115140330.GA26429@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara References: <9099A621-D460-47B6-9172-0984CF3A0DC8@webweaving.org> <20170115140330.GA26429@LK-Perkele-V2.elisa-laajakaista.fi> X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Sun, 15 Jan 2017 15:11:33 +0100 (CET) Archived-At: Cc: acme@ietf.org Subject: Re: [Acme] Well Known CA->client poll on port 80/443 in http-acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 14:12:51 -0000 --Apple-Mail=_30AD87F4-E28B-45B1-90E0-4C934C368C48 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15 Jan 2017, at 15:03, Ilari Liusvaara = wrote: >=20 > On Sun, Jan 15, 2017 at 02:50:37PM +0100, Dirk-Willem van Gulik wrote: >> =E2=80=A6. >=20 > That's not a new version. It is pre-WG version, published about 1.5 > years ago. Ok - so I=E2=80=99ll ignore git - and will take the IETF latest as = leading. > The reason HTTPS support for HTTP authentication was removed was that > many webservers handle HTTPS in odd manner, making alphabetically > first HTTPS vhost the default, which would let one get certificates > for vhosts one should not. Ok. > Currently in acme spec, the only ways to do verification without port > 80 are TLS-SNI-02 (uses port 443) and DNS-01 (no connections at all, > relies on DNS exclusively). Ok - and is there any reason why allowing one to specify the port would = not be an option/bad idea ? I am looking at the typical old school unix case - i.e. apache =E2=80=94 = where one starts up as root and quickly chroots/setuid()s - and where the servers are commonly deployed on port = > 1024 by end users. Thanks, Dw.= --Apple-Mail=_30AD87F4-E28B-45B1-90E0-4C934C368C48 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 15 Jan 2017, at 15:03, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:

On Sun, Jan 15, 2017 at 02:50:37PM +0100, = Dirk-Willem van Gulik wrote:
=E2=80=A6.

That's not a new = version. It is pre-WG version, published about 1.5
years = ago.

Ok - so I=E2=80=99= ll ignore git - and will take the IETF latest as leading.

The reason HTTPS support for HTTP authentication = was removed was that
many webservers handle HTTPS in odd = manner, making alphabetically
first HTTPS vhost the default, which = would let one get certificates
for vhosts one should not.

Ok.

Currently in acme spec, = the only ways to do verification without port
80 are TLS-SNI-02 = (uses port 443) and DNS-01 (no connections at all,
relies on DNS = exclusively).

Ok - = and is there any reason why allowing one to specify the port would not = be an option/bad idea ?

I am looking at the typical old school unix case - i.e. = apache =E2=80=94 where one starts up as root and quickly
chroots/setuid()s - and where the servers are commonly = deployed on port > 1024 by end users.

Thanks,

Dw.
= --Apple-Mail=_30AD87F4-E28B-45B1-90E0-4C934C368C48-- From nobody Sun Jan 15 06:29:37 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F6412959D for ; Sun, 15 Jan 2017 06:29:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 W47XBaTcT9gK for ; Sun, 15 Jan 2017 06:29:33 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id B77D412957F for ; Sun, 15 Jan 2017 06:29:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 417FC15C67; Sun, 15 Jan 2017 16:29:32 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id mmfl0x2YU6Vk; Sun, 15 Jan 2017 16:29:32 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id E680A289; Sun, 15 Jan 2017 16:29:31 +0200 (EET) Date: Sun, 15 Jan 2017 16:29:31 +0200 From: Ilari Liusvaara To: Dirk-Willem van Gulik Message-ID: <20170115142931.GB26429@LK-Perkele-V2.elisa-laajakaista.fi> References: <9099A621-D460-47B6-9172-0984CF3A0DC8@webweaving.org> <20170115140330.GA26429@LK-Perkele-V2.elisa-laajakaista.fi> <6AEBC4C9-FA1B-4672-AE58-15C165722B30@webweaving.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6AEBC4C9-FA1B-4672-AE58-15C165722B30@webweaving.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: acme@ietf.org Subject: Re: [Acme] Well Known CA->client poll on port 80/443 in http-acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 14:29:36 -0000 On Sun, Jan 15, 2017 at 03:11:32PM +0100, Dirk-Willem van Gulik wrote: > > > On 15 Jan 2017, at 15:03, Ilari Liusvaara wrote: > > > > On Sun, Jan 15, 2017 at 02:50:37PM +0100, Dirk-Willem van Gulik wrote: > >> …. > > > > That's not a new version. It is pre-WG version, published about 1.5 > > years ago. > > Ok - so I’ll ignore git - and will take the IETF latest as leading. There actually is another git repo (ietf-wg-acme/acme) that contains the WG draft work. That one is a bit newer than ietf-04 (but shouldn't have significant changes). > > Currently in acme spec, the only ways to do verification without port > > 80 are TLS-SNI-02 (uses port 443) and DNS-01 (no connections at all, > > relies on DNS exclusively). > > Ok - and is there any reason why allowing one to specify the port > would not be an option/bad idea ? The list of ports public CAs can use is pretty short (5 ports in fact). > I am looking at the typical old school unix case - i.e. apache — where > one starts up as root and quickly chroots/setuid()s - and where the > servers are commonly deployed on port > 1024 by end users. There actually are restrictions on what ports public CAs can use for authentication. These are: - 80 (HTTP) - 443 (HTTPS) - 115 (SFTP; no, not _that_ SFTP [1]) - 25 (SMTP) - 22 (SSH) These limits are exactly so that unprivileged users don't bind daemons to the ports and use those to obtain certificates (the certificates are valid for all ports). [1] This is likely a mistake (but it is still allowed). The "SFTP" is not _Secure_ File Transfer Protocol (shares port 22 with SSH) but instead _Simple_ File Transfer Protocol... Described in three-digit- number historic-status RFC, from the 80s... -Ilari From nobody Sun Jan 15 06:41:07 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5591012959D for ; Sun, 15 Jan 2017 06:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 fsFzgK_IOQZw for ; Sun, 15 Jan 2017 06:41:03 -0800 (PST) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21BFB129547 for ; Sun, 15 Jan 2017 06:41:02 -0800 (PST) Received: from beeb.leiden.webweaving.org (5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v0FEditq045445 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 15 Jan 2017 15:39:44 +0100 (CET) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED29A06.cm-7-3c.dynamic.ziggo.nl [94.210.154.6] claimed to be beeb.leiden.webweaving.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Dirk-Willem van Gulik In-Reply-To: <20170115142931.GB26429@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sun, 15 Jan 2017 15:39:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <65DAC165-2700-4DA5-A492-28B1F2E60541@webweaving.org> References: <9099A621-D460-47B6-9172-0984CF3A0DC8@webweaving.org> <20170115140330.GA26429@LK-Perkele-V2.elisa-laajakaista.fi> <6AEBC4C9-FA1B-4672-AE58-15C165722B30@webweaving.org> <20170115142931.GB26429@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Sun, 15 Jan 2017 15:39:44 +0100 (CET) Archived-At: Cc: acme@ietf.org Subject: Re: [Acme] Well Known CA->client poll on port 80/443 in http-acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 14:41:05 -0000 > On 15 Jan 2017, at 15:29, Ilari Liusvaara = wrote: >=20 > On Sun, Jan 15, 2017 at 03:11:32PM +0100, Dirk-Willem van Gulik wrote: >>=20 >>> On 15 Jan 2017, at 15:03, Ilari Liusvaara = wrote: >>>=20 >>> On Sun, Jan 15, 2017 at 02:50:37PM +0100, Dirk-Willem van Gulik = wrote: >>>> =E2=80=A6. >>>=20 >>> That's not a new version. It is pre-WG version, published about 1.5 >>> years ago. >>=20 >> Ok - so I=E2=80=99ll ignore git - and will take the IETF latest as = leading. >=20 > There actually is another git repo (ietf-wg-acme/acme) that contains = the > WG draft work. That one is a bit newer than ietf-04 (but shouldn't = have > significant changes). >=20 >>> Currently in acme spec, the only ways to do verification without = port >>> 80 are TLS-SNI-02 (uses port 443) and DNS-01 (no connections at all, >>> relies on DNS exclusively). >>=20 >> Ok - and is there any reason why allowing one to specify the port >> would not be an option/bad idea ? >=20 > The list of ports public CAs can use is pretty short (5 ports in = fact). >=20 >> I am looking at the typical old school unix case - i.e. apache =E2=80=94= where >> one starts up as root and quickly chroots/setuid()s - and where the >> servers are commonly deployed on port > 1024 by end users. >=20 > There actually are restrictions on what ports public CAs can use for > authentication. These are: >=20 > - 80 (HTTP) > - 443 (HTTPS) > - 115 (SFTP; no, not _that_ SFTP [1]) > - 25 (SMTP) > - 22 (SSH) >=20 > These limits are exactly so that unprivileged users don't bind > daemons to the ports and use those to obtain certificates (the > certificates are valid for all ports). Just to make sure I understand the reasoning: CA Policy prohibits an ACME CA Server from fetching the token = (authenticating) from a subscriber port > 1024 (or a port not an element = of [80,443,115,25,22)) because an (on common flavours of unix) an = un(der)privileged) user may run a daemon on such a port. Correct ? Just so I understand the tradeoffs made correctly when = implementing/mitigating the root-risk on the webserver side. You would not happen to know where these are documented (I=E2=80=99ve = scanned CPS, SA and policy but no cookie yet). Dw= From nobody Sun Jan 15 07:04:19 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262EB1295A7 for ; Sun, 15 Jan 2017 07:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 mdzWx1HFjtQm for ; Sun, 15 Jan 2017 07:04:10 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 642F612959D for ; Sun, 15 Jan 2017 07:04:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 9488B192AB; Sun, 15 Jan 2017 17:04:08 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id Url5KDCqXzhR; Sun, 15 Jan 2017 17:04:08 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 24C8FC4; Sun, 15 Jan 2017 17:04:08 +0200 (EET) Date: Sun, 15 Jan 2017 17:04:07 +0200 From: Ilari Liusvaara To: Dirk-Willem van Gulik Message-ID: <20170115150407.GA26702@LK-Perkele-V2.elisa-laajakaista.fi> References: <9099A621-D460-47B6-9172-0984CF3A0DC8@webweaving.org> <20170115140330.GA26429@LK-Perkele-V2.elisa-laajakaista.fi> <6AEBC4C9-FA1B-4672-AE58-15C165722B30@webweaving.org> <20170115142931.GB26429@LK-Perkele-V2.elisa-laajakaista.fi> <65DAC165-2700-4DA5-A492-28B1F2E60541@webweaving.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <65DAC165-2700-4DA5-A492-28B1F2E60541@webweaving.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: acme@ietf.org Subject: Re: [Acme] Well Known CA->client poll on port 80/443 in http-acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 15:04:17 -0000 On Sun, Jan 15, 2017 at 03:39:43PM +0100, Dirk-Willem van Gulik wrote: > > > On 15 Jan 2017, at 15:29, Ilari Liusvaara wrote: > > > > There actually are restrictions on what ports public CAs can use for > > authentication. These are: > > > > - 80 (HTTP) > > - 443 (HTTPS) > > - 115 (SFTP; no, not _that_ SFTP [1]) > > - 25 (SMTP) > > - 22 (SSH) > > > > These limits are exactly so that unprivileged users don't bind > > daemons to the ports and use those to obtain certificates (the > > certificates are valid for all ports). > > Just to make sure I understand the reasoning: > > CA Policy prohibits an ACME CA Server from fetching the token > (authenticating) from a subscriber port > 1024 (or a port not an > element of [80,443,115,25,22)) because an (on common flavours of > unix) an un(der)privileged) user may run a daemon on such a port. > > Correct ? Just so I understand the tradeoffs made correctly when > implementing/mitigating the root-risk on the webserver side. Actually, ACME as of currently can use only 80 or 443 (there is no explicit port selection anywhere). The remaining three ports might be used by non-ACME public CAs. And all those five ports are privileged to bind to (but once bound, are not privileged to accept connections from[2]). And if you are talking about abuse from root, there is not much that can be done, outside Mandatory Access Control extensions like SELinux and such. > You would not happen to know where these are documented (I’ve > scanned CPS, SA and policy but no cookie yet). CABForum Baseline Requirements.(I looked up version 1.3.9, since the 1.4 versions are AFAIK essentially withdrawn). [2] It is actually possible to bind to such port, drop privileges and then pass the descriptor to another program via exec or even local socket. The receiver can then accept connections from it, even if receiver never was privileged. I have one daemon on one VM that does just that with port 443. -Ilari From nobody Sun Jan 15 07:35:56 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9461293D6 for ; Sun, 15 Jan 2017 07:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com 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 pv-QsgKkPPlf for ; Sun, 15 Jan 2017 07:35:54 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0C3128874 for ; Sun, 15 Jan 2017 07:35:54 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 95C6116C7C4; Sun, 15 Jan 2017 15:35:53 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 7F9D416C7B7; Sun, 15 Jan 2017 15:35:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1484494553; bh=U6ohU7YpxQmjii89IfTCJ9JaNYQjfmDoZ5XQ5ArwxAc=; l=248; h=From:To:CC:Date:References:In-Reply-To:From; b=OnsIRpBNoz8063KDF4x6veIrHz6jFvI+l6TBXRN5WJO9x9vpdmpcF6jK12EHFU8Dg h/Olo713tGcnReu4o2M297aPsnUBOjbh9Z3R9DFMJ4sPGQ6xIiQY7kz+naIIqy73PF /4cB7kHKU2OY4n3CaYHWspYKG5VAOE8uMB9n4QQ4= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 65F271E090; Sun, 15 Jan 2017 15:35:53 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 15 Jan 2017 10:35:52 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Sun, 15 Jan 2017 10:35:52 -0500 From: "Salz, Rich" To: Dirk-Willem van Gulik , Ilari Liusvaara Thread-Topic: [Acme] Well Known CA->client poll on port 80/443 in http-acme Thread-Index: AQHSbzaxoaqIQafKN0Sbh4Xs7ne0yqE55bEAgAACPgD//8NkgA== Date: Sun, 15 Jan 2017 15:35:52 +0000 Message-ID: References: <9099A621-D460-47B6-9172-0984CF3A0DC8@webweaving.org> <20170115140330.GA26429@LK-Perkele-V2.elisa-laajakaista.fi> <6AEBC4C9-FA1B-4672-AE58-15C165722B30@webweaving.org> In-Reply-To: <6AEBC4C9-FA1B-4672-AE58-15C165722B30@webweaving.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.168] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Well Known CA->client poll on port 80/443 in http-acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 15:35:55 -0000 PiBPayAtIHNvIEnigJlsbCBpZ25vcmUgZ2l0IC0gYW5kIHdpbGwgdGFrZSB0aGUgSUVURiBsYXRl c3QgYXMgbGVhZGluZy4NCg0KQXJlIHlvdSBsb29raW5nIGF0IHRoZSBMZXRzRW5jcnlwdCBnaXQg cmVwbz8gIFRoZSBJRVRGIG9uZSBpcyBhdCBodHRwczovL2dpdGh1Yi5jb20vaWV0Zi13Zy1hY21l L2FjbWUNCg== From nobody Sun Jan 15 09:01:22 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A27C12960C for ; Sun, 15 Jan 2017 09:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 tNGSOfIscgpA for ; Sun, 15 Jan 2017 09:01:19 -0800 (PST) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94B91294CC for ; Sun, 15 Jan 2017 09:01:18 -0800 (PST) Received: from beeb.leiden.webweaving.org (5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v0FGximI049299 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 15 Jan 2017 18:00:00 +0100 (CET) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20] claimed to be beeb.leiden.webweaving.org From: Dirk-Willem van Gulik Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_452831EF-6D2F-4977-8457-F622091584CF" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sun, 15 Jan 2017 17:59:43 +0100 In-Reply-To: <20170115150407.GA26702@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara References: <9099A621-D460-47B6-9172-0984CF3A0DC8@webweaving.org> <20170115140330.GA26429@LK-Perkele-V2.elisa-laajakaista.fi> <6AEBC4C9-FA1B-4672-AE58-15C165722B30@webweaving.org> <20170115142931.GB26429@LK-Perkele-V2.elisa-laajakaista.fi> <65DAC165-2700-4DA5-A492-28B1F2E60541@webweaving.org> <20170115150407.GA26702@LK-Perkele-V2.elisa-laajakaista.fi> X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Sun, 15 Jan 2017 18:00:00 +0100 (CET) Archived-At: Cc: acme@ietf.org Subject: Re: [Acme] Well Known CA->client poll on port 80/443 in http-acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 17:01:20 -0000 --Apple-Mail=_452831EF-6D2F-4977-8457-F622091584CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15 Jan 2017, at 16:04, Ilari Liusvaara = wrote: >=20 > On Sun, Jan 15, 2017 at 03:39:43PM +0100, Dirk-Willem van Gulik wrote: >>=20 >>> On 15 Jan 2017, at 15:29, Ilari Liusvaara = wrote: >>>=20 >>> There actually are restrictions on what ports public CAs can use for >>> authentication. These are: >>>=20 >>> - 80 (HTTP) >>> - 443 (HTTPS) >>> - 115 (SFTP; no, not _that_ SFTP [1]) >>> - 25 (SMTP) >>> - 22 (SSH) >>>=20 >>> These limits are exactly so that unprivileged users don't bind >>> daemons to the ports and use those to obtain certificates (the >>> certificates are valid for all ports). >>=20 >> Just to make sure I understand the reasoning: >>=20 >> CA Policy prohibits an ACME CA Server from fetching the token >> (authenticating) from a subscriber port > 1024 (or a port not an >> element of [80,443,115,25,22)) because an (on common flavours of >> unix) an un(der)privileged) user may run a daemon on such a port. >>=20 >> Correct ? Just so I understand the tradeoffs made correctly when >> implementing/mitigating the root-risk on the webserver side. >=20 > Actually, ACME as of currently can use only 80 or 443 (there is > no explicit port selection anywhere). Which makes sense given the current CABForum limitation. > The remaining three ports > might be used by non-ACME public CAs. >=20 > And all those five ports are privileged to bind to (but once > bound, are not privileged to accept connections from[2]). And if > you are talking about abuse from root, there is not much that > can be done, outside Mandatory Access Control extensions like > SELinux and such. Agreed - I am more concerned about the opposite - allowing well = intending non-root users who want to spin up a server to do the right = thing. The more educated/capable group is already well served by, for example, = a trivial apache SSL config file in conjunction with shell scripts = [1,2]. >> You would not happen to know where these are documented (I=E2=80=99ve >> scanned CPS, SA and policy but no cookie yet). >=20 > CABForum Baseline Requirements.(I looked up version 1.3.9, since > the 1.4 versions are AFAIK essentially withdrawn). Lovely - thanks! > [2] It is actually possible to bind to such port, drop privileges > and then pass the descriptor to another program via exec or even > local socket. The receiver can then accept connections from it, > even if receiver never was privileged. I have one daemon on one VM > that does just that with port 443. `` We have sufficient infrastructure for that in apache and its APR utility = library. I am trying to understand enough of the considerations of ACME (such as = the choise for the the =E2=80=98Authorized Ports=E2=80=99 list as = defined in that CABForum BR) to help me make the right trade offs = between a) bringing the webserver up in a relatively insecure fashion = for a short period of time and getting the business of (re)new cert=E2=80=99= s over as robustly as possible v.s. spinning up much more surface of = things that can confuse -or- go wrong (including apache its normal = devolved setuid()/chroot() post forking & opening the < 1024 sockets), = are expensive to maintain or prone to abuse. And secondly I am trying to come to grips with the advent of = virtualisation & containerisation causing the concepts of virtual hosts = to change; rather than have 10=E2=80=99s of thousands of VHOSTs in a = single config/binary; all listening to all IP=E2=80=99s on port 80 - so = common at the turn of the century - one now increasingly sees a lot of = port mapping - where in effect each httpd runs =E2=80=98alone=E2=80=99, = in a container, with a single vhost config - albeit on a funny port.=20 Which may, or may not be, mapped to some IP:80 or through some = LB/fan-out proxy that has a FQDN->internal IP & port table. Software = defined networking seems to favour the latter. But the net effect is that that makes the listening on port 80 for a = FQDN that is elsewhere configured to be visible on just a single IP:443 = (mapped to -> internal-ip + high port) rather much out of reach. As a = listen *:80 is no longer effective. Especially for the cohort of users = for whom the scripting is already out of reach. Hence the desire to understand the design better. Thanks, Dw. 1: https://github.com/Neilpang/acme.sh = 2: https://github.com/lukas2511/dehydrated = --Apple-Mail=_452831EF-6D2F-4977-8457-F622091584CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 15 Jan 2017, at 16:04, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:

On = Sun, Jan 15, 2017 at 03:39:43PM +0100, Dirk-Willem van Gulik wrote:

On 15 Jan 2017, at 15:29, Ilari Liusvaara = <ilariliusvaara@welho.com> wrote:

There actually are restrictions on what ports public CAs can = use for
authentication. These are:

- 80 (HTTP)
- 443 (HTTPS)
- 115 = (SFTP; no, not _that_ SFTP [1])
- 25 (SMTP)
- = 22 (SSH)

These limits are exactly so that = unprivileged users don't bind
daemons to the ports and use = those to obtain certificates (the
certificates are valid = for all ports).

Just to make = sure I understand the reasoning:

CA Policy = prohibits an ACME CA Server from fetching the token
(authenticating) from a subscriber port > 1024 (or a port = not an
element of [80,443,115,25,22)) because an (on = common  flavours of
unix) an un(der)privileged) user = may run a daemon on such a port.

Correct ? = Just so I understand the tradeoffs made correctly when
implementing/mitigating the root-risk on the webserver = side.

Actually, ACME as of = currently can use only 80 or 443 (there is
no explicit = port selection anywhere).

Which makes sense given the current CABForum = limitation.

The remaining three ports
might be used by  non-ACME public CAs.

And all those five ports are privileged to bind to (but = once
bound, are not privileged to accept connections = from[2]). And if
you are talking about abuse from root, = there is not much that
can be done, outside Mandatory = Access Control extensions like
SELinux and such.

Agreed - I = am more concerned about the opposite - allowing well intending non-root = users who want to spin up a server to do the right thing.

The more educated/capable group is already well = served by, for example, a trivial apache SSL config file  in = conjunction with shell scripts [1,2].

You would not happen to know where these are = documented (I=E2=80=99ve
scanned CPS, SA and policy but no = cookie yet).

CABForum Baseline = Requirements.(I looked up version 1.3.9, since
the 1.4 = versions are AFAIK essentially withdrawn).

Lovely - = thanks!

[2] It is actually possible to bind to such = port, drop privileges
and then pass the descriptor to = another program via exec or even
local socket. The = receiver can then accept connections from it,
even if = receiver never was privileged. I have one daemon on one VM
that does just that with port 443.
``
We have sufficient infrastructure for that in apache and its = APR utility library.

I am trying to understand enough of the considerations of = ACME (such as the choise for the the =E2=80=98Authorized Ports=E2=80=99 = list as defined in that CABForum BR) to help me make the right trade = offs between a) bringing the webserver up in a relatively insecure = fashion for a short period of time and getting the business of (re)new = cert=E2=80=99s over as robustly as possible v.s. spinning up much more = surface of things that can confuse -or- go wrong (including apache its = normal devolved setuid()/chroot() post forking & opening the < = 1024 sockets), are expensive to maintain or prone to abuse.

And secondly I am trying = to come to grips with the advent of virtualisation & = containerisation causing the concepts of virtual hosts to change; rather = than have 10=E2=80=99s of thousands of VHOSTs in a single config/binary; = all listening to all IP=E2=80=99s on port 80 - so common at the turn of = the century - one now  increasingly sees a lot of port mapping - = where in effect each httpd runs =E2=80=98alone=E2=80=99, in a container, = with a single vhost config - albeit on a funny port. 

Which may, or may not = be, mapped to some IP:80 or through some LB/fan-out proxy that has a = FQDN->internal IP & port table. Software defined networking seems = to favour the latter.

But the net effect is that that makes the listening on port = 80 for a FQDN that is elsewhere configured to be visible on just a = single IP:443 (mapped to -> internal-ip + high port) rather much out = of reach. As a listen *:80 is no longer effective. Especially for the = cohort of users for whom the scripting is already out of = reach.

Hence = the desire to understand the design better.

Thanks,

Dw.

1: https://github.com/Neilpang/acme.sh
2: https://github.com/lukas2511/dehydrated

= --Apple-Mail=_452831EF-6D2F-4977-8457-F622091584CF-- From nobody Sun Jan 15 09:37:06 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C1112963A for ; Sun, 15 Jan 2017 09:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 vMWKptz42jA1 for ; Sun, 15 Jan 2017 09:37:03 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id ACAB512947E for ; Sun, 15 Jan 2017 09:37:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id BA5F1192B2; Sun, 15 Jan 2017 19:37:00 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id S53zToUUZVhn; Sun, 15 Jan 2017 19:37:00 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5F4A9C4; Sun, 15 Jan 2017 19:37:00 +0200 (EET) Date: Sun, 15 Jan 2017 19:36:59 +0200 From: Ilari Liusvaara To: Dirk-Willem van Gulik Message-ID: <20170115173659.GA27033@LK-Perkele-V2.elisa-laajakaista.fi> References: <9099A621-D460-47B6-9172-0984CF3A0DC8@webweaving.org> <20170115140330.GA26429@LK-Perkele-V2.elisa-laajakaista.fi> <6AEBC4C9-FA1B-4672-AE58-15C165722B30@webweaving.org> <20170115142931.GB26429@LK-Perkele-V2.elisa-laajakaista.fi> <65DAC165-2700-4DA5-A492-28B1F2E60541@webweaving.org> <20170115150407.GA26702@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: acme@ietf.org Subject: Re: [Acme] Well Known CA->client poll on port 80/443 in http-acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 17:37:05 -0000 On Sun, Jan 15, 2017 at 05:59:43PM +0100, Dirk-Willem van Gulik wrote: > > We have sufficient infrastructure for that in apache and its > APR utility library. > > I am trying to understand enough of the considerations of ACME > (such as the choise for the the ‘Authorized Ports’ list as defined > in that CABForum BR) to help me make the right trade offs between > a) bringing the webserver up in a relatively insecure fashion for > a short period of time and getting the business of (re)new cert’s > over as robustly as possible v.s. spinning up much more surface of > things that can confuse -or- go wrong (including apache its normal > devolved setuid()/chroot() post forking & opening the < 1024 sockets), > are expensive to maintain or prone to abuse. There's also the fact that HTTP-01 will follow redirects to https:// (just the initial request has to be http://), ignoring certificate validity. > And secondly I am trying to come to grips with the advent of > virtualisation & containerisation causing the concepts of virtual > hosts to change; rather than have 10’s of thousands of VHOSTs in a > single config/binary; all listening to all IP’s on port 80 - so common > at the turn of the century - one now increasingly sees a lot of port > mapping - where in effect each httpd runs ‘alone’, in a container, with > a single vhost config - albeit on a funny port. The funny ports are because one can't get enough IPv4 address space to give each container its own address? > Which may, or may not be, mapped to some IP:80 or through some LB/fan-out > proxy that has a FQDN->internal IP & port table. Software defined > networking seems to favour the latter. > > But the net effect is that that makes the listening on port 80 for a FQDN > that is elsewhere configured to be visible on just a single IP:443 (mapped > to -> internal-ip + high port) rather much out of reach. As a listen *:80 > is no longer effective. Especially for the cohort of users for whom the > scripting is already out of reach. Well, if the port 80 on the same external IP could be configured to serve a redirect to https for validation requests (which is just a static mapping per FQDN), then those requests would presumably be sent to the container. That is, rule of form: http://foo.example/.well-known/acme-challenge/bar -> https://foo.example/.well-known/acme-challenge/bar And the secondary requests also AFAIK have SNI on TLS level, so one can route on that too. -Ilari From nobody Sun Jan 15 09:55:31 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588681294E6 for ; Sun, 15 Jan 2017 09:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 rOEFz6mfqpJb for ; Sun, 15 Jan 2017 09:55:29 -0800 (PST) Received: from weser.webweaving.org (weser.webweaving.org [148.251.234.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59786129640 for ; Sun, 15 Jan 2017 09:55:29 -0800 (PST) Received: from beeb.leiden.webweaving.org (5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20]) (authenticated bits=0) by weser.webweaving.org (8.15.2/8.15.2) with ESMTPSA id v0FHsA6F050661 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 15 Jan 2017 18:54:12 +0100 (CET) (envelope-from dirkx@webweaving.org) X-Authentication-Warning: weser.webweaving.org: Host 5ED06D14.cm-7-1b.dynamic.ziggo.nl [94.208.109.20] claimed to be beeb.leiden.webweaving.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Dirk-Willem van Gulik In-Reply-To: <20170115173659.GA27033@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sun, 15 Jan 2017 18:54:10 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <38DABE99-99B0-41BE-8D27-EC519C30D3AE@webweaving.org> References: <9099A621-D460-47B6-9172-0984CF3A0DC8@webweaving.org> <20170115140330.GA26429@LK-Perkele-V2.elisa-laajakaista.fi> <6AEBC4C9-FA1B-4672-AE58-15C165722B30@webweaving.org> <20170115142931.GB26429@LK-Perkele-V2.elisa-laajakaista.fi> <65DAC165-2700-4DA5-A492-28B1F2E60541@webweaving.org> <20170115150407.GA26702@LK-Perkele-V2.elisa-laajakaista.fi> <20170115173659.GA27033@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3259) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (weser.webweaving.org [148.251.234.232]); Sun, 15 Jan 2017 18:54:12 +0100 (CET) Archived-At: Cc: acme@ietf.org Subject: Re: [Acme] Well Known CA->client poll on port 80/443 in http-acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 17:55:30 -0000 > On 15 Jan 2017, at 18:36, Ilari Liusvaara = wrote: >=20 > On Sun, Jan 15, 2017 at 05:59:43PM +0100, Dirk-Willem van Gulik wrote: >>=20 >> We have sufficient infrastructure for that in apache and its >> APR utility library. >>=20 >> I am trying to understand enough of the considerations of ACME >> (such as the choise for the the =E2=80=98Authorized Ports=E2=80=99 = list as defined >> in that CABForum BR) to help me make the right trade offs between >> a) bringing the webserver up in a relatively insecure fashion for >> a short period of time and getting the business of (re)new cert=E2=80=99= s >> over as robustly as possible v.s. spinning up much more surface of >> things that can confuse -or- go wrong (including apache its normal >> devolved setuid()/chroot() post forking & opening the < 1024 = sockets), >> are expensive to maintain or prone to abuse. >=20 > There's also the fact that HTTP-01 will follow redirects to https:// > (just the initial request has to be http://), ignoring certificate > validity. >=20 >> And secondly I am trying to come to grips with the advent of=20 >> virtualisation & containerisation causing the concepts of virtual >> hosts to change; rather than have 10=E2=80=99s of thousands of VHOSTs = in a >> single config/binary; all listening to all IP=E2=80=99s on port 80 - = so common >> at the turn of the century - one now increasingly sees a lot of port >> mapping - where in effect each httpd runs =E2=80=98alone=E2=80=99, in = a container, with >> a single vhost config - albeit on a funny port.=20 >=20 > The funny ports are because one can't get enough IPv4 address space > to give each container its own address? >=20 >> Which may, or may not be, mapped to some IP:80 or through some = LB/fan-out >> proxy that has a FQDN->internal IP & port table. Software defined >> networking seems to favour the latter. >>=20 >> But the net effect is that that makes the listening on port 80 for a = FQDN >> that is elsewhere configured to be visible on just a single IP:443 = (mapped >> to -> internal-ip + high port) rather much out of reach. As a listen = *:80 >> is no longer effective. Especially for the cohort of users for whom = the >> scripting is already out of reach. >=20 > Well, if the port 80 on the same external IP could be configured to = serve > a redirect to https for validation requests (which is just a static > mapping per FQDN), then those requests would presumably be sent to the > container. >=20 > That is, rule of form: = http://foo.example/.well-known/acme-challenge/bar > -> https://foo.example/.well-known/acme-challenge/bar=20 >=20 > And the secondary requests also AFAIK have SNI on TLS level, so one = can > route on that too. That is indeed the alternative =E2=80=94 surmise that as the user (no = matter how VM=E2=80=99s, containers, virtual load balancers or whatever = is configured) will want to end up visible on port 443 with a cert =E2=80=94= we focus on some blind http->https redirect which can be configured in = bulk; and always bring up an TLS+SSL on 443 with a self signed cert if = we do not yet have an acme cert (and using the same private key for = thus). Dw.= From nobody Sun Jan 15 10:29:21 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218BC1294D3 for ; Sun, 15 Jan 2017 10:29:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.199 X-Spam-Level: X-Spam-Status: No, score=-3.199 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 hFokz38altU0 for ; Sun, 15 Jan 2017 10:29:18 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA821294C9 for ; Sun, 15 Jan 2017 10:29:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 8468E14617; Sun, 15 Jan 2017 20:29:16 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id E9zu8FyvArlE; Sun, 15 Jan 2017 20:29:16 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 3AEEE21C; Sun, 15 Jan 2017 20:29:16 +0200 (EET) Date: Sun, 15 Jan 2017 20:29:15 +0200 From: Ilari Liusvaara To: Dirk-Willem van Gulik Message-ID: <20170115182915.GA27571@LK-Perkele-V2.elisa-laajakaista.fi> References: <9099A621-D460-47B6-9172-0984CF3A0DC8@webweaving.org> <20170115140330.GA26429@LK-Perkele-V2.elisa-laajakaista.fi> <6AEBC4C9-FA1B-4672-AE58-15C165722B30@webweaving.org> <20170115142931.GB26429@LK-Perkele-V2.elisa-laajakaista.fi> <65DAC165-2700-4DA5-A492-28B1F2E60541@webweaving.org> <20170115150407.GA26702@LK-Perkele-V2.elisa-laajakaista.fi> <20170115173659.GA27033@LK-Perkele-V2.elisa-laajakaista.fi> <38DABE99-99B0-41BE-8D27-EC519C30D3AE@webweaving.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <38DABE99-99B0-41BE-8D27-EC519C30D3AE@webweaving.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: acme@ietf.org Subject: Re: [Acme] Well Known CA->client poll on port 80/443 in http-acme X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 18:29:20 -0000 On Sun, Jan 15, 2017 at 06:54:10PM +0100, Dirk-Willem van Gulik wrote: > > > That is indeed the alternative — surmise that as the user (no matter > how VM’s, containers, virtual load balancers or whatever is configured) > will want to end up visible on port 443 with a cert — we focus on some > blind http->https redirect which can be configured in bulk; and always > bring up an TLS+SSL on 443 with a self signed cert if we do not yet > have an acme cert (and using the same private key for thus). Well, if the container is not visible on port 80, you presumably want a path-preserving HTTP -> HTTPS redirect for all URLs on the FQDN. Such redirect would also redirect ACME HTTP requests. Or if one wants just to redirect ACME HTTP requests, one can redirect just the paths under .well-known/acme-challenge/. No need to be discriminate: the target server will sort it out anyway. -Ilari From nobody Thu Jan 19 10:55:04 2017 Return-Path: X-Original-To: acme@ietf.org Delivered-To: acme@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8995C129534; Thu, 19 Jan 2017 10:55:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148485210255.10377.13324695382693712133.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 10:55:02 -0800 Archived-At: Cc: Kathleen.Moriarty.ietf@gmail.com, acme@ietf.org, ted.ietf@gmail.com, acme-chairs@ietf.org Subject: [Acme] acme - New Meeting Session Request for IETF 98 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 18:55:02 -0000 A new meeting session request has just been submitted by Ted Hardie, a Chair of the acme working group. --------------------------------------------------------- Working Group Name: Automated Certificate Management Environment Area Name: Security Area Session Requester: Ted Hardie Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 80 Conflicts to Avoid: First Priority: httpauth httpbis sidr rtcweb tls perc Second Priority: dprive tcpinc uta dispatch netvc cfrg ace Third Priority: maprg hrpc irtfopen opsec Special Requests: --------------------------------------------------------- From nobody Thu Jan 19 11:55:43 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684D31294C6 for ; Thu, 19 Jan 2017 11:55:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.957 X-Spam-Level: X-Spam-Status: No, score=-9.957 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 zprHCkmrokby for ; Thu, 19 Jan 2017 11:55:40 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8B0129497 for ; Thu, 19 Jan 2017 11:55:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=nOGMXMuuGNwr/TGGeJ3q77OmDlenwo5Wkx+YhW3h0FM=; b=AVy8+vFPYYWBItu5P9uv8G/vlMMKl2VV5jdvpubiZ22VKsrJSLZWtjyJetIOPfn8ocDQkK/O+STirL/JYn5o6WGcTNZCSd16NGktCVQje2zLyrf3i4O1lo1GLaCX/VxJ+DgtgC4hJN+Zwk5J2aBdWAT3W/VsRnHHVdMOEtjojR4=; Received: ; Thu, 19 Jan 2017 11:55:41 -0800 To: "acme@ietf.org" From: Jacob Hoffman-Andrews Message-ID: <760b7647-3a28-efb8-9189-3ab9c50cfe5d@eff.org> Date: Thu, 19 Jan 2017 11:55:40 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Acme] Editorial fixes in GitHub X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 19:55:42 -0000 Hi all, I did a top-to-bottom review of the spec to look for coherency (since we've changed a number of concepts), mistakes, and general consistency. I filed several pull requests on GitHub: https://github.com/ietf-wg-acme/acme/pull/231 https://github.com/ietf-wg-acme/acme/pull/232 https://github.com/ietf-wg-acme/acme/pull/233 https://github.com/ietf-wg-acme/acme/pull/234 https://github.com/ietf-wg-acme/acme/pull/235 From nobody Fri Jan 20 07:54:28 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE443129BD9 for ; Fri, 20 Jan 2017 07:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com 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 osglmCv5B0Gl for ; Fri, 20 Jan 2017 07:54:24 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id C4CF612960E for ; Fri, 20 Jan 2017 07:54:24 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 504C216C788 for ; Fri, 20 Jan 2017 15:54:24 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 3036916C9A1 for ; Fri, 20 Jan 2017 15:54:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1484927664; bh=+0uDYtWj4bmo5OI+Hr/wiXoSChpAzhsGQOSpkoYkQkU=; l=3652; h=From:To:Date:From; b=VSRNo7+NlXW7lR4b+6KDsoW4+/ANsxBwsNMaQVcx41o3lwX5Q2w5YdQjXZBeuA0uZ f1kJMU4CAkQjvoeGAAX7aqTVkk7r2UaPcGICyyCg8UPsjH7cPTKuWkUfNZLff7mo4+ npFzrnou1Sg0dBBvc7RBdJJ7uKDgYUFY3Eq2QNmk= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 13B3F98085 for ; Fri, 20 Jan 2017 15:54:24 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 20 Jan 2017 10:54:23 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 20 Jan 2017 10:54:23 -0500 From: "Salz, Rich" To: "acme@ietf.org" Thread-Topic: Recent pull requests Thread-Index: AdJzNJiHhPIrcrqRRTOpsWWF1NCfGQ== Date: Fri, 20 Jan 2017 15:54:22 +0000 Message-ID: <8e40839cb1c24af3b4f43ea923e95515@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.119] Content-Type: multipart/alternative; boundary="_000_8e40839cb1c24af3b4f43ea923e95515usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [Acme] Recent pull requests X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 15:54:27 -0000 --_000_8e40839cb1c24af3b4f43ea923e95515usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, Please resolve/merge 231 and 232 and publish a new draft - those are truly = strictly editorial. We'll treat 234 and 235 as WGLC comments. If you want to pull some of the c= hanges in 235 out into a separate PR that (a) has agreement between you, an= d (b) *is* strictly editorial, feel free. (For example, saying a server MA= Y follow redirects is not one of those. :) /r$ -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz --_000_8e40839cb1c24af3b4f43ea923e95515usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authors,

 

Please resolve/merge 231 and 232 and publish a new d= raft – those are truly strictly editorial.

 

We’ll treat 234 and 235 as WGLC comments. If y= ou want to pull some of the changes in 235 out into a separate PR that (a) = has agreement between you, and (b) *is* strictly editorial, feel fre= e.  (For example, saying a server MAY follow redirects is not one of those. :)

 

        &nbs= p;       /r$

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_8e40839cb1c24af3b4f43ea923e95515usma1exdag1mb1msgcorpak_-- From andriy.mahats@buypass.no Fri Jan 20 08:08:38 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C50129AB7 for ; Fri, 20 Jan 2017 08:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 leag_KIypUOc for ; Fri, 20 Jan 2017 08:08:36 -0800 (PST) Received: from mr10.infostorm.no (mr10.infostorm.no [217.18.206.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B59312952D for ; Fri, 20 Jan 2017 08:08:36 -0800 (PST) Received: from Buyp-gvk-ex01.intra.buypass.no (unknown [146.192.247.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mr10.infostorm.no (Postfix) with ESMTP id 499CB137DC6 for ; Fri, 20 Jan 2017 17:08:32 +0100 (CET) Received: from BUYP-GVK-EX01.intra.buypass.no (10.11.2.9) by Buyp-gvk-ex01.intra.buypass.no (10.11.2.9) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 20 Jan 2017 17:08:31 +0100 Received: from BUYP-GVK-EX01.intra.buypass.no ([10.11.2.241]) by Buyp-gvk-ex01.intra.buypass.no ([10.11.2.241]) with mapi id 15.00.0995.032; Fri, 20 Jan 2017 17:08:31 +0100 From: Andriy Mahats To: "acme@ietf.org" Thread-Topic: ACME resources relations Thread-Index: AdJzM3QHeFQ872lYS1ShtddeaxOqYw== Date: Fri, 20 Jan 2017 16:08:31 +0000 Message-ID: <1bfcd722703f4236a32fc7458084ff06@Buyp-gvk-ex01.intra.buypass.no> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.11.51.34] Content-Type: multipart/alternative; boundary="_000_1bfcd722703f4236a32fc7458084ff06Buypgvkex01intrabuypass_" MIME-Version: 1.0 X-mr10-MailScanner-Information: Please contact the ISP for more information X-mr10-MailScanner-ID: 499CB137DC6.AB347 X-mr10-MailScanner: Found to be clean X-mr10-MailScanner-From: andriy.mahats@buypass.no Archived-At: Subject: [Acme] ACME resources relations X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 15:26:49 -0000 --_000_1bfcd722703f4236a32fc7458084ff06Buypgvkex01intrabuypass_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all! At the resource diagram in 6.1 Resources section, there is an authz resource related to order by "up" relation. My question is for following case: The client orders a certificate and at the time of ordering it satisfied some of authorizations (let's say = 2 of 3) in previous transactions (possibly using pre-authorization: new-authz). When client queries such previously satisfied authorization, what order resource shall pointed using "up" relation, since that authorization can be used for many orders? I've created issue in GitHub for this. You can find it here: https://github= .com/ietf-wg-acme/acme/issues/236 Sincerely, Andriy --_000_1bfcd722703f4236a32fc7458084ff06Buypgvkex01intrabuypass_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all!

 

At the resource diagram in 6= .1 Resources section,

there is an authz resource rela= ted to order by “up” relation.

 

My question is for following ca= se:

 

The client orders a certificate=

and at the time of ordering it = satisfied some of authorizations (let’s say 2 of 3)=

in previous transactions (possi= bly using pre-authorization: new-authz).

 

When client queries such previo= usly satisfied authorization,

what order resource shall point= ed using “up” relation,

since that authorization can be= used for many orders?

 

I’ve created issue in Git= Hub for this. You can find it here: https://github.= com/ietf-wg-acme/acme/issues/236

 

 

Sincerely,

Andriy

--_000_1bfcd722703f4236a32fc7458084ff06Buypgvkex01intrabuypass_-- From nobody Mon Jan 23 14:46:49 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53ACE1293DA for ; Mon, 23 Jan 2017 14:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.201 X-Spam-Level: X-Spam-Status: No, score=-10.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 nlrZ7jl-rqo3 for ; Mon, 23 Jan 2017 14:46:46 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6FE120727 for ; Mon, 23 Jan 2017 14:46:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=x780S44qK3mMkkzgmFLhn4A2ullvMsRZWVAmyCNDC98=; b=2EVXibflo6vdOsHmlQcRZGcQxi4Dk72Eq88oPbO+j0CdOTDdnILllAHQkhOJgzqSC7GlvMp5q1kz3hYVZZzug2n21R5Scb+0Zwtjvy1Z4107Sw+0TvFd43N7ayL5IgARvRANK9sLiQ8bwLWVNIcGVvnjFI7+AB7AufOdZsEprVs=; Received: ; Mon, 23 Jan 2017 14:46:47 -0800 To: "acme@ietf.org" References: <760b7647-3a28-efb8-9189-3ab9c50cfe5d@eff.org> From: Jacob Hoffman-Andrews Message-ID: Date: Mon, 23 Jan 2017 14:46:45 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <760b7647-3a28-efb8-9189-3ab9c50cfe5d@eff.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Editorial fixes in GitHub X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 22:46:48 -0000 In review, Rich pointed out that some of these are more substantive and should be reviewed as such, so I broke them out into their own PRs: Remove SCT link relation. https://github.com/ietf-wg-acme/acme/pull/234 Specify multi-viewpoint validation. https://github.com/ietf-wg-acme/acme/pull/239 Specify server MAY follow HTTP redirects. https://github.com/ietf-wg-acme/acme/pull/238 Note: the last one is more of a clarification of current behavior, since HTTP already says "MAY" for redirects. But a lot of ACME implementers have been surprised to hear that redirects are followed, so I think it's important to clarify. On 01/19/2017 11:55 AM, Jacob Hoffman-Andrews wrote: > Hi all, > > I did a top-to-bottom review of the spec to look for coherency (since > we've changed a number of concepts), mistakes, and general consistency. > I filed several pull requests on GitHub: > > https://github.com/ietf-wg-acme/acme/pull/231 > https://github.com/ietf-wg-acme/acme/pull/232 > https://github.com/ietf-wg-acme/acme/pull/233 > https://github.com/ietf-wg-acme/acme/pull/234 > https://github.com/ietf-wg-acme/acme/pull/235 > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > From nobody Tue Jan 24 07:07:24 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAF3129A2D for ; Tue, 24 Jan 2017 07:07:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org 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 Nix9ZEOgKUoA for ; Tue, 24 Jan 2017 07:07:19 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DC151294D5 for ; Tue, 24 Jan 2017 07:07:18 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id z134so112497454lff.3 for ; Tue, 24 Jan 2017 07:07:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=NobfRM5tmuJM/qsKaGHWsonGJdK1xI1ABSU2/HHvVrA=; b=Y1vFUm95z7DiL6u152Qn6hXoqs1TuWmZ766EieNH8UAEhSBfw7jxjKcfIeK9qfGKnr VV4k+hSqQCMU01DHLNGKjBPRLqxkgnqgGxJi1cafF+1o4Pj8NlzkommotVWOxNLY4APl 1g7Ta4GbZkujEa3/ANXhqWJERnsHq9PD8vR9c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=NobfRM5tmuJM/qsKaGHWsonGJdK1xI1ABSU2/HHvVrA=; b=EFuFflYWYFMWOJ1d9mot3p7OfLgjglKYDjPoqnVkFekhZ2svue6pUXsQS45RTkHbGm euGGpDpEJWivr4BemQ+1o+gsM9pVQmmYVgJtDq2/7E8YVnA7XvMflfBPvZ+69zQOwDRR MePgXODwWghfJHNCFWZR5+uuyqLkgLuQSxc8xsLWBzbTAaSPHSti2/qTr3ueSHTiUf0L OKksQrLZdundnRSCc2N2yWVQgmSQ4vVvA18t8mwbUNMFArBAI0T7Pwqhr2LgBW/WS0sb A+qc+3Gq2VsM4ryBB7aNXmYxZmk5B+4GLeE8+JGGPai3ee7C5pi1HEti5NX6ZEaCmDN0 HXjg== X-Gm-Message-State: AIkVDXLhs9FmJTGERyjhc3kIE992GfDo1TLnIVSvlEER7T4E0Qqltm+r6xV0xcfspC66HkC+A0jQuCEUZ0W+S1Jx X-Received: by 10.25.67.19 with SMTP id q19mr11378999lfa.9.1485270436364; Tue, 24 Jan 2017 07:07:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.205.203 with HTTP; Tue, 24 Jan 2017 07:07:15 -0800 (PST) In-Reply-To: References: <760b7647-3a28-efb8-9189-3ab9c50cfe5d@eff.org> From: Daniel McCarney Date: Tue, 24 Jan 2017 10:07:15 -0500 Message-ID: To: Jacob Hoffman-Andrews Content-Type: multipart/alternative; boundary=f403045ea4eac160f30546d87822 Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Editorial fixes in GitHub X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: cpu@letsencrypt.org List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 15:07:22 -0000 --f403045ea4eac160f30546d87822 Content-Type: text/plain; charset=UTF-8 I've reviewed each and left comments or positive +1's in the form of approved Github reviews. I'm in favour of removing the SCT link relation. It's unnecessary and as Richard pointed out, easy to add back if it turns out the other SCT delivery mechanisms aren't sufficient for a concrete use-case. On Mon, Jan 23, 2017 at 5:46 PM, Jacob Hoffman-Andrews wrote: > In review, Rich pointed out that some of these are more substantive and > should be reviewed as such, so I broke them out into their own PRs: > > Remove SCT link relation. https://github.com/ietf-wg-acme/acme/pull/234 > Specify multi-viewpoint validation. > https://github.com/ietf-wg-acme/acme/pull/239 > Specify server MAY follow HTTP redirects. > https://github.com/ietf-wg-acme/acme/pull/238 > > Note: the last one is more of a clarification of current behavior, since > HTTP already says "MAY" for redirects. But a lot of ACME implementers > have been surprised to hear that redirects are followed, so I think it's > important to clarify. > > On 01/19/2017 11:55 AM, Jacob Hoffman-Andrews wrote: > > Hi all, > > > > I did a top-to-bottom review of the spec to look for coherency (since > > we've changed a number of concepts), mistakes, and general consistency. > > I filed several pull requests on GitHub: > > > > https://github.com/ietf-wg-acme/acme/pull/231 > > https://github.com/ietf-wg-acme/acme/pull/232 > > https://github.com/ietf-wg-acme/acme/pull/233 > > https://github.com/ietf-wg-acme/acme/pull/234 > > https://github.com/ietf-wg-acme/acme/pull/235 > > > > _______________________________________________ > > Acme mailing list > > Acme@ietf.org > > https://www.ietf.org/mailman/listinfo/acme > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --f403045ea4eac160f30546d87822 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've reviewed each and left comments or positive = +1's in the form of approved
Github reviews.

I'm in favour of removing the SCT link relation. It's unne= cessary and as
Richard pointed out, easy to add back if it turns = out the other SCT delivery
mechanisms aren't sufficient for a= concrete use-case.


On Mon, Jan 23, 2017 at 5:46 PM, Jacob Hoffman-Andre= ws <= jsha@eff.org> wrote:
In review, Rich pointed out that some of these are more substa= ntive and
should be reviewed as such, so I broke them out into their own PRs:

Remove SCT link relation. https://github.com/ietf-wg-acme/acme/pull/234
Specify multi-viewpoint validation.
https://github.com/ietf-wg-acme/acme/pull/239<= br> Specify server MAY follow HTTP redirects.
https://github.com/ietf-wg-acme/acme/pull/238<= br>
Note: the last one is more of a clarification of current behavior, since HTTP already says "MAY" for redirects. But a lot of ACME implemen= ters
have been surprised to hear that redirects are followed, so I think it'= s
important to clarify.

On 01/19/2017 11:55 AM, Jacob Hoffman-Andrews wrote:
> Hi all,
>
> I did a top-to-bottom review of the spec to look for coherency (since<= br> > we've changed a number of concepts), mistakes, and general consist= ency.
> I filed several pull requests on GitHub:
>
> https://github.com/ietf-wg-acme/acme/pull/231=
> https://github.com/ietf-wg-acme/acme/pull/232=
> https://github.com/ietf-wg-acme/acme/pull/233=
> https://github.com/ietf-wg-acme/acme/pull/234=
> https://github.com/ietf-wg-acme/acme/pull/235=
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme >

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

--f403045ea4eac160f30546d87822-- From nobody Wed Jan 25 05:29:44 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70379129929 for ; Wed, 25 Jan 2017 05:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.9 X-Spam-Level: X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com 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 lk6GbrSUVy_X for ; Wed, 25 Jan 2017 05:29:42 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 179D41298D3 for ; Wed, 25 Jan 2017 05:29:42 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6095343341B; Wed, 25 Jan 2017 13:29:41 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 4A257433408; Wed, 25 Jan 2017 13:29:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1485350981; bh=l2wA1raJA0bKBMq7EXWCBit5zuW7JovNluLVC0N4f20=; l=658; h=From:To:Date:References:In-Reply-To:From; b=LC6uqqEpXbHfYVfZg0Zb939vhuxEALUPVTt/Vk5E19VYnUDnpZvSJoXjkTmaA2Vz6 so6H88rXLhdDp0htbBw9Wt92/AkFNUI0g0Q4YGULe9HR++MP/7OW3scM95juN6AZWl RjtSMZ6JfF8w+/6YAHGi4wyvWDTh9GiBc4UHcKzY= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 46E7F1FC90; Wed, 25 Jan 2017 13:29:41 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 25 Jan 2017 08:29:40 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 25 Jan 2017 08:29:41 -0500 From: "Salz, Rich" To: Jacob Hoffman-Andrews , "acme@ietf.org" Thread-Topic: [Acme] Editorial fixes in GitHub Thread-Index: AQHSco4HmFSjEhW8wEigU+x4REBE96FHA9qAgAI07jA= Date: Wed, 25 Jan 2017 13:29:40 +0000 Message-ID: <31d94d1198ac4b1280e562430d0e1bb1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <760b7647-3a28-efb8-9189-3ab9c50cfe5d@eff.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.141] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Acme] Editorial fixes in GitHub X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 13:29:43 -0000 WG members. We'd like to get into last call very soon. Please look at the issues that Jacob lists below and post commentary here. > Remove SCT link relation. https://github.com/ietf-wg-acme/acme/pull/234 > Specify multi-viewpoint validation. https://github.com/ietf-wg-acme/acme/= pull/239 > Specify server MAY follow HTTP redirects. https://github.com/ietf-wg-acme= /acme/pull/238 >=20 > Note: the last one is more of a clarification of current behavior, since = HTTP > already says "MAY" for redirects. But a lot of ACME implementers have bee= n > surprised to hear that redirects are followed, so I think it's important = to > clarify. From nobody Wed Jan 25 05:32:52 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F4B12994F for ; Wed, 25 Jan 2017 05:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3HO-wjYC_uZg for ; Wed, 25 Jan 2017 05:32:47 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F10231298C1 for ; Wed, 25 Jan 2017 05:32:46 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id j13so13316901iod.3 for ; Wed, 25 Jan 2017 05:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to; bh=R14yBekicwS3VawUlr/qRgG5lWmCf9ZANGipNJidUtQ=; b=DJQWZvAe5vAU7XDKKsTMpd2ipU1Rz4gsSOwWljP87vrTj18SQbLdsMapJR9iBr4gxK 4tuOH2OguTK1mBFYlMazBSfi6cZgOCvd2/H7htwoLC3CV7A9JtdT161wIfZm8eVnsrhv a4BDUBk3DMlwJDObE+tWo+qxIYWN4tj0mHWvzd53Go4GJqAW0A3o4yKen47U3EV3Hbfx Wxhqyc4yOKnsqXMnMHcKDNMLiiwG9Q9/WP+p9u9fNWRdmqJImv+6m5xyb11HuHbunluX RAeTM71L3I113giMoU1L86rr96YgJCYSM7EpSkbD73It0PiYcEo0/ajdP/KFLvTszoxb jODw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to; bh=R14yBekicwS3VawUlr/qRgG5lWmCf9ZANGipNJidUtQ=; b=FKotCXbBelAYBcd/NVvfVyHkUCrhu7BW9/pNk7NZUhrQ0quBJwWzisOkeIq5T+cWI1 SUiAPs96HKWiyPKRCSmYGS1FwiHT5U2YtOxH2eH3gfxcBioMw0mfzHWXfVJh0IyzjyZN DtOMzp6dLGCcPGPN2MpYvGnCFSF5YlVvvzkXViWgz8k+8Aea6SJAcpS9cvnup/aTQaTy zoO1aeGGn0eMNuW1kTb+r4DaXyOl78eBNEOSZgfbQPCobcqbuVktcOV5wfdFkdD+6QYk YNs/AGwZ1g+w0WQelzJwp9s8PhHab9xBGb+InDK0LeZD4St6dr+z6bcaQQ5RiPPNO/W7 XVHg== X-Gm-Message-State: AIkVDXJFULscKpEs9nfb1UirTBM3g7fo/0PwdsNVSvNCNzuCl9A/IqO+V/RFvHleQKEhPQ== X-Received: by 10.107.20.137 with SMTP id 131mr33682132iou.187.1485351166210; Wed, 25 Jan 2017 05:32:46 -0800 (PST) Received: from [127.0.0.1] (135-23-187-91.cpe.pppoe.ca. [135.23.187.91]) by smtp.gmail.com with ESMTPSA id l3sm196361ioa.31.2017.01.25.05.32.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Jan 2017 05:32:45 -0800 (PST) Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20170125133245.4894801.83094.2019@gmail.com> Date: Wed, 25 Jan 2017 08:32:45 -0500 From: Josh Soref In-Reply-To: <31d94d1198ac4b1280e562430d0e1bb1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <760b7647-3a28-efb8-9189-3ab9c50cfe5d@eff.org> <31d94d1198ac4b1280e562430d0e1bb1@usma1ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" , Jacob Hoffman-Andrews , acme@ietf.org Archived-At: Subject: Re: [Acme] Editorial fixes in GitHub X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 13:32:48 -0000 Please don't. I just started and haven't had time to explain the problems c= ertbot and boulder are experiencing.=A0 But, on the spot: The error handling approach doesn't scale well, doesn't lead to good errors= for end users, and makes it virtually impossible for clients (like certbot= ) to provide localized error messages. From nobody Wed Jan 25 08:28:42 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7A0129A22 for ; Wed, 25 Jan 2017 08:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kelunik.com 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 pddeiIwx_ETB for ; Wed, 25 Jan 2017 08:28:39 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B2C9129A2C for ; Wed, 25 Jan 2017 08:28:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1485361716; l=1397; s=domk; d=kelunik.com; h=Content-Type:Cc:To:Subject:Date:From:References:In-Reply-To: MIME-Version; bh=bR9gH7r0nJ+dpM+B/5D9afz1SuJUx7sld0MP6vG0RkQ=; b=VwmPcr/D+vh4SG+tIQFyHtzjlpro3aqRqkL0G98+ymo0Czy839rLhNsH5sIfh9GxvU 59ew2fxBjUHD9cvdtIrb6KXVLW+fYSMoM3zL7Xtp3ST5m3OtGLCwPI3U1lWfQ6YuBLTV 2JZGkT9gqcGBrELWWlkMvVay8wIm4Ll4lVgPI= X-RZG-AUTH: :IWkkfkWkbvHsXQGmRYmUo9mls2vWuiu+7SLDup6E67mzuoNJBqD/tMc= X-RZG-CLASS-ID: mo00 Received: from mail-qt0-f174.google.com ([209.85.216.174]) by smtp.strato.de (RZmta 39.11 AUTH) with ESMTPSA id N06c98t0PGSZZVK (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp384r1 with 384 ECDH bits, eq. 7680 bits RSA)) (Client did not present a certificate) for ; Wed, 25 Jan 2017 17:28:35 +0100 (CET) Received: by mail-qt0-f174.google.com with SMTP id l7so25207194qtd.1 for ; Wed, 25 Jan 2017 08:28:35 -0800 (PST) X-Gm-Message-State: AIkVDXIV1Cgw0UeSTqjX+QlV3o9QNBqqtMMXmRooALzDEskI3KOkZPBY9qhXPLBA66ANPR5hfyrYFrC+zwPVfA== X-Received: by 10.233.237.136 with SMTP id c130mr36961517qkg.160.1485361715164; Wed, 25 Jan 2017 08:28:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.144.132 with HTTP; Wed, 25 Jan 2017 08:28:34 -0800 (PST) In-Reply-To: <31d94d1198ac4b1280e562430d0e1bb1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <760b7647-3a28-efb8-9189-3ab9c50cfe5d@eff.org> <31d94d1198ac4b1280e562430d0e1bb1@usma1ex-dag1mb1.msg.corp.akamai.com> From: Niklas Keller Date: Wed, 25 Jan 2017 17:28:34 +0100 X-Gmail-Original-Message-ID: Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=94eb2c09830e6541b00546edb987 Archived-At: Cc: "acme@ietf.org" , Jacob Hoffman-Andrews Subject: Re: [Acme] Editorial fixes in GitHub X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 16:28:41 -0000 --94eb2c09830e6541b00546edb987 Content-Type: text/plain; charset=UTF-8 I already posted a comment on GitHub, but didn't get a response there, so I'm posting here again. > Standardize on new-account rather than new-acct; previously there was a mix. "authz" and "new-authz" seem to be the only abbreviated resources now. I guess we should change that one to new-authorization then? Feels inconsistent in the current way. https://github.com/ietf-wg-acme/acme/pull/232#issuecomment-273894220 Regards, Niklas --94eb2c09830e6541b00546edb987 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I already posted a comment on GitHub, but didn't get a= response there, so I'm posting here again.

>= ; Standardize on new-account rather than new-acct; previously there was a m= ix.

"authz" and "new-authz" se= em to be the only abbreviated resources now. I guess we should change that = one to new-authorization then? Feels inconsistent in the current way.
=


Regards, Niklas<= /div>
--94eb2c09830e6541b00546edb987-- From nobody Wed Jan 25 09:57:51 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F3D129AB5 for ; Wed, 25 Jan 2017 09:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 A95t4nT5ROce for ; Wed, 25 Jan 2017 09:57:48 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 2502D129AA2 for ; Wed, 25 Jan 2017 09:57:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id DD0921F1AC; Wed, 25 Jan 2017 19:57:45 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id lOH1G756oqh3; Wed, 25 Jan 2017 19:57:45 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 815882315; Wed, 25 Jan 2017 19:57:45 +0200 (EET) Date: Wed, 25 Jan 2017 19:57:43 +0200 From: Ilari Liusvaara To: Josh Soref Message-ID: <20170125175742.GA10811@LK-Perkele-V2.elisa-laajakaista.fi> References: <760b7647-3a28-efb8-9189-3ab9c50cfe5d@eff.org> <31d94d1198ac4b1280e562430d0e1bb1@usma1ex-dag1mb1.msg.corp.akamai.com> <20170125133245.4894801.83094.2019@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20170125133245.4894801.83094.2019@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "Salz, Rich" , acme@ietf.org, Jacob Hoffman-Andrews Subject: Re: [Acme] Editorial fixes in GitHub X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 17:57:50 -0000 On Wed, Jan 25, 2017 at 08:32:45AM -0500, Josh Soref wrote: > Please don't. I just started and haven't had time to explain the > problems certbot and boulder are experiencing.  > > But, on the spot: > The error handling approach doesn't scale well, doesn't lead to > good errors for end users, and makes it virtually impossible for > clients (like certbot) to provide localized error messages. The primary task of those error message is for users to troubleshoot. >From LE community forum threads, the following seem to be the most frequent validation errors (in no practicular order) - Rate limiting errors (certs per FQDNset) - Rate limiting errors (certs per domain). - Bad DNS names requested - DNS names classed as high-risk. - DNS names blocked by GSB. - NXDOMAIN from DNS. - Horked DNS server doesn't understand 0x20 hack. - Horked DNS server barfs on CAA records. - Various temporary DNS server horkage (rarely DNSSEC). - Only RFC1918 IP in DNS (for HTTP-01/TLS-SNI-01). - No IPs at all (no A nor AAAA) in DNS (for HTTP-01/TLS-SNI-01) - Wrong IP in DNS. - Connect failure to 80 or 443 port (either firewall or not listening at all). - Port 443 responding with HTTP (yes, really). - HTTP-01 responds with 4XX error. - HTTP-01 responds with spew of HTML with 200 code - HTTP-01 redirects to unexpected place. - TLS-SNI-01 sends some default cert. - TLS-SNI-01 sends fatal alert. - DNS-01 propagation failure. Of course, most have variety of causes. -Ilari From nobody Wed Jan 25 10:00:56 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7192F129AAE for ; Wed, 25 Jan 2017 10:00:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.854 X-Spam-Level: X-Spam-Status: No, score=-8.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 jjNEoGosmc2W for ; Wed, 25 Jan 2017 10:00:54 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0535C129A9F for ; Wed, 25 Jan 2017 10:00:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=knV93/uIdwzhmDY2A2Nw4TgFIpe7xKbNCs1YA4jdBbg=; b=GEi+YXzMFgYsDkrvopXHo5I5OrQJzTkbRrwzwiRFsUMdAxDr9jClntUGkwX9ME01ZT4+atnuZ7w7eO646Au/qNSCA0YkgyMIKMpdgNSoOrSvr9PgC92sSHDwkhJTMt5nrbJDjbu1tmPO5gyayVYFEAtS3nst7cXGKM0s4oi3+mw=; Received: ; Wed, 25 Jan 2017 10:00:54 -0800 To: Niklas Keller , "Salz, Rich" References: <760b7647-3a28-efb8-9189-3ab9c50cfe5d@eff.org> <31d94d1198ac4b1280e562430d0e1bb1@usma1ex-dag1mb1.msg.corp.akamai.com> From: Jacob Hoffman-Andrews Message-ID: <0030ba0f-58e4-829c-676f-92801b60c18c@eff.org> Date: Wed, 25 Jan 2017 10:00:52 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "acme@ietf.org" Subject: Re: [Acme] Editorial fixes in GitHub X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 18:00:55 -0000 On 01/25/2017 08:28 AM, Niklas Keller wrote: > I already posted a comment on GitHub, but didn't get a response there, > so I'm posting here again. > > > Standardize on new-account rather than new-acct; previously there > was a mix. > > "authz" and "new-authz" seem to be the only abbreviated resources now. > I guess we should change that one to new-authorization then? Feels > inconsistent in the current way. > > https://github.com/ietf-wg-acme/acme/pull/232#issuecomment-273894220 Yep, agreed. Also, we have a number of "asdf" tokens still in there that I'd like to change to something a little more formal. I think this change would conflict with some of my outstanding purely-editorial PRs, so I'm waiting on merging them. From nobody Wed Jan 25 11:17:51 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5B4129B14 for ; Wed, 25 Jan 2017 11:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org 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 47XYwnPh6c3t for ; Wed, 25 Jan 2017 11:17:46 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5FA129B12 for ; Wed, 25 Jan 2017 11:17:46 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id 189so60240007pfu.3 for ; Wed, 25 Jan 2017 11:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=j1xM8WWAXKxFD4hoc2TzUOEvDqcJ6tglkv6jkCiUUPE=; b=KvJXvnEj6uhBMmvVdaFw/CSO9BM5jzwjjBXj6xoHICSXJvuGhRCxWR6z0Vw+bYqV4b 5tmxvT+Ip1bEdWs2izQ6ekhEbDk8wz6ylyf2MFgkMU827Ua5kV3cqHmFOoGRxmZQNRqD L4GHgvWV26cIT1BSOo4GIHRUdaw42nxzLexKM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=j1xM8WWAXKxFD4hoc2TzUOEvDqcJ6tglkv6jkCiUUPE=; b=WIrb6wNXV0auZqwJ6jiWfeV1NZrBhc9DtQ4ssSyXQ61ttT3Bs+hW3IdZ8fKlu69kjF zn/y0GD7mPLHMGVghVNHXEetAIxZqkwH7/Bhq8/BJ6kV4pT8u07iZ20OgI8PIRH/ITqA JLO//MHuvLc/UrbNSQFOPpU7a9gEAbE6eQ4SQ0d+USftMe+mWFcyx6sfTLd7mfWOoYrA Klh6ZKPE7uYyv6/tW7JzW3++vrWnHdlI8wqJwnQ206X7TvESIobIKumOQhU0Z6/o3qft TMx6LwLk03PM9p9+U6K6TLf8i5Q/RgkzY/qDr0VZYY8jPyA97dJzufZjAv1XRIxTRXTy nJTQ== X-Gm-Message-State: AIkVDXK6c0EBc+oVITiHU64NqcoMQJ0GDDKB6QCAI6o2IwDCw0e6UapYHH/3dPity+vv+qow X-Received: by 10.98.70.12 with SMTP id t12mr48832854pfa.47.1485371865290; Wed, 25 Jan 2017 11:17:45 -0800 (PST) Received: from [192.168.42.65] (50-0-146-254.dsl.dynamic.fusionbroadband.com. [50.0.146.254]) by smtp.gmail.com with ESMTPSA id h17sm2928038pfh.62.2017.01.25.11.17.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 11:17:44 -0800 (PST) To: acme@ietf.org References: <760b7647-3a28-efb8-9189-3ab9c50cfe5d@eff.org> From: Roland Bracewell Shoemaker Message-ID: <18f5223c-effa-400f-5b06-e1ad07fb03db@letsencrypt.org> Date: Wed, 25 Jan 2017 11:17:43 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] Editorial fixes in GitHub X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 19:17:50 -0000 On 01/24/2017 07:07 AM, Daniel McCarney wrote: > I've reviewed each and left comments or positive +1's in the form of > approved > Github reviews. > > I'm in favour of removing the SCT link relation. It's unnecessary and as > Richard pointed out, easy to add back if it turns out the other SCT delivery > mechanisms aren't sufficient for a concrete use-case. > I'm fine losing this as LE doesn't plan on implementing it but I think there is a valid argument to keep it if any other CA plans on implementing ACME and CT but not embedding SCTs. That said if it does stay the language definitely needs to be reworked as it currently implies a certificate would only have a single SCT and provides no guidance to how a list of SCTs should be presented to the client/user from the endpoint. > > On Mon, Jan 23, 2017 at 5:46 PM, Jacob Hoffman-Andrews > wrote: > > In review, Rich pointed out that some of these are more substantive and > should be reviewed as such, so I broke them out into their own PRs: > > Remove SCT link relation. > https://github.com/ietf-wg-acme/acme/pull/234 > > Specify multi-viewpoint validation. > https://github.com/ietf-wg-acme/acme/pull/239 > > Specify server MAY follow HTTP redirects. > https://github.com/ietf-wg-acme/acme/pull/238 > > > Note: the last one is more of a clarification of current behavior, since > HTTP already says "MAY" for redirects. But a lot of ACME implementers > have been surprised to hear that redirects are followed, so I think it's > important to clarify. > > On 01/19/2017 11:55 AM, Jacob Hoffman-Andrews wrote: > > Hi all, > > > > I did a top-to-bottom review of the spec to look for coherency (since > > we've changed a number of concepts), mistakes, and general > consistency. > > I filed several pull requests on GitHub: > > > > https://github.com/ietf-wg-acme/acme/pull/231 > > > https://github.com/ietf-wg-acme/acme/pull/232 > > > https://github.com/ietf-wg-acme/acme/pull/233 > > > https://github.com/ietf-wg-acme/acme/pull/234 > > > https://github.com/ietf-wg-acme/acme/pull/235 > > > > > _______________________________________________ > > Acme mailing list > > Acme@ietf.org > > https://www.ietf.org/mailman/listinfo/acme > > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > From nobody Mon Jan 30 13:03:35 2017 Return-Path: X-Original-To: acme@ietfa.amsl.com Delivered-To: acme@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278FB12960F for ; Mon, 30 Jan 2017 13:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.2 X-Spam-Level: X-Spam-Status: No, score=-10.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org 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 d858TSN_G0Or for ; Mon, 30 Jan 2017 13:03:30 -0800 (PST) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1551295FE for ; Mon, 30 Jan 2017 13:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=dj+2JgTuvdP11W4XpXT951PvDSMbV6+5xD5Vii0A9RE=; b=0Q2dEXS0S24tShkvaLUpqz1vLRbrnKQ45Jz16fP/0ehv5PDa0l4y6iihwvKJ8V/M7snCVBrQQQ25BPhAEKthAhCVHMB4h9/bQoca4D92BNu9dyKDyn8BWqvlJbH1XyfGiZ/uWj+2F8hGmr6iAAdEAMjCEmCJMg57wLutSmchtN0=; Received: ; Mon, 30 Jan 2017 13:03:30 -0800 To: "acme@ietf.org" From: Jacob Hoffman-Andrews Message-ID: <0964d671-972a-1101-93ed-d9f64ece8e2a@eff.org> Date: Mon, 30 Jan 2017 13:03:28 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Acme] Invalidation of authz after an account compromise X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 21:03:32 -0000 We've discussed in the past how a domain owner should recover from a host compromise. I believe we came to a rough consensus that solving a DV challenge should be sufficient authorization to invalidate extant authorization on other accounts, and that we can consider each newly validated authz to invalidate previous authzs for the same identifier. I've written this up as a PR: https://github.com/ietf-wg-acme/acme/pull/240 diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md index d2b1ca1..9ab10f2 100644 --- a/draft-ietf-acme-acme.md +++ b/draft-ietf-acme-acme.md @@ -1643,6 +1643,9 @@ for the identifier. If the final state is "valid", the server MUST add an "expires" field to the authorization. When finalizing an authorization,= the server MAY remove challenges other than the one that was completed. = The server SHOULD NOT remove challenges with status "invalid". +If the final state is "valid", the server SHOULD invalidate any other +currently-valid authorizations for the same identifier. See +{{security-considerations}} for reasoning. =20 Usually, the validation process will take some time, so the client will need to poll the authorization resource to see when it is finalized. For challenges @@ -2688,6 +2691,23 @@ within their trusted network and use these resolvers both for both CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.). =20 +## Recovery From Host Compromise + +If a host is compromised, once the owner regains exclusive control of the host, +they will want to take steps to revoke any certificates the attacker may have +issued, and to ensure that the attacker cannot issue new certificates for the +affected hostnames. + +If the attacker gained access to the private key for an ACME account, but has +not yet changed the ACME account keypair, the proper owner can use the k= ey +rotation functionality to regain exclusive control of their ACME account= =2E + +If the attacker did change the ACME account keypair, or if the attacker created +their own ACME account and authorized the hostname, the proper owner, af= ter +regaining control of the host, can authorize that hostname on their own account +(which should invalidate previous authorizations for that hostname), and can use +that authorization to revoke any certificates the attacker may have issu= ed. + # Acknowledgements =20 In addition to the editors listed on the front page, this document has benefited