From nobody Thu May 4 00:04:57 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 9E611129B7E for ; Thu, 4 May 2017 00:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_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 dzumH-REh_pg for ; Thu, 4 May 2017 00:04:54 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 7A09B126C89 for ; Thu, 4 May 2017 00:04:53 -0700 (PDT) Received: from [192.168.123.151] (unknown [76.90.60.238]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id B871B22E257 for ; Thu, 4 May 2017 03:04:46 -0400 (EDT) From: Sean Leonard Content-Type: multipart/alternative; boundary="Apple-Mail=_7718BEA2-2E03-447C-8E3C-9DE31A87F4D4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 4 May 2017 00:04:45 -0700 References: <083b73a4-a199-dc57-e078-bf1bf9c10bd2@seantek.com> <9f046557-fe26-faad-30b3-7f721851cb5b@seantek.com> To: ACME WG In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] "Slide 21" follow-up (textual encoding question) PART 2 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 May 2017 07:04:57 -0000 --Apple-Mail=_7718BEA2-2E03-447C-8E3C-9DE31A87F4D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Since the best thing to get adoption probably involves =E2=80=9CSend = Text=E2=80=9D, I will try to send a proposed textual change to = draft-ietf-acme-acme-06 over the next few days (most likely by Monday = May 8). Therefore I would ask that we get a bit of a time extension for = folks to think about it (and also for me, to write the text). Kind regards, Sean > On Apr 19, 2017, at 9:44 PM, Logan Widick = wrote: >=20 >=20 >=20 > On Apr 3, 2017 16:07, "Sean Leonard" > wrote: > On 4/3/2017 5:54 AM, Logan Widick wrote: >> I think that having separate URIs to reduce bloat is a good idea. I = understand that the client needs to send the CSR as a field in the = new-order request payload for security. However, in the server response, = could the CSR be a URI that would allow the client to retrieve the CSR = that the client submitted in DER format? So, could new-order requests = look like: >> [=E2=80=A6] >=20 >=20 > Finally, here is how you convert from p7s to textual certificates: > openssl pkcs7 -inform DER -in yourfile.p7s -print_certs >=20 > The advantage of the command-line/OpenSSL recipe above, is that you = are guaranteed that the output will only be -----BEGIN CERTIFICATE----- = things. Non-certificates shall not pass. >=20 > That already standardized type would be better.=20 >=20 >>=20 >> On Apr 3, 2017 06:29, "Niklas Keller" > wrote: >> One potential issue I can see with embedding certificates with the = currently proposed format directly into orders are alternative chains. = Chains usually do not change between orders, so they could be kept with = separate URIs for cachability and less bloat in the order response. >>=20 >> e.g. >>=20 >> "certificate": base64url(derEncodedCertificate), >> "chains": [ >> "https://.../chain" , >> "https://.../alternate-chain" >> ] >>=20 >> Regards, Niklas --Apple-Mail=_7718BEA2-2E03-447C-8E3C-9DE31A87F4D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Since the best thing to get adoption probably involves = =E2=80=9CSend Text=E2=80=9D, I will try to send a proposed textual = change to draft-ietf-acme-acme-06 over the next few days (most likely by = Monday May 8). Therefore I would ask that we get a bit of a time = extension for folks to think about it (and also for me, to write the = text).

Kind = regards,

Sean

On Apr 19, 2017, at 9:44 PM, Logan Widick = <logan.widick@gmail.com> wrote:



On Apr 3, 2017 16:07, "Sean = Leonard" <dev+ietf@seantek.com> wrote:
=20 =20 =20
On 4/3/2017 5:54 = AM, Logan Widick wrote:
I think that having separate URIs to reduce = bloat is a good idea. I understand that the client needs to send the CSR as a field in the new-order request payload for security. However, in the server response, could the CSR be a URI that would allow the client to retrieve the CSR that the client submitted in DER format? So, could new-order requests look = like:
<= /div>

[=E2=80=A6]
=

Finally, here is how you convert from p7s to textual = certificates:
  openssl pkcs7 -inform DER -in yourfile.p7s = -print_certs

The advantage of the command-line/OpenSSL recipe above, is that you are guaranteed that the output will only be -----BEGIN CERTIFICATE----- things. Non-certificates shall not = pass.
That already standardized = type would be better. 


On Apr 3, 2017 = 06:29, "Niklas Keller" <me@kelunik.com> wrote:
One potential issue I can = see with embedding certificates with the currently proposed format directly into orders are alternative chains. Chains usually do not change between orders, so they could be kept with separate URIs for cachability and less bloat in the order response.

e.g.

"certificate": = base64url(derEncodedCertificate),
"chains": [
   "https://.../chain",
   "https://.../alternate-chain"
]

Regards, Niklas
=

= --Apple-Mail=_7718BEA2-2E03-447C-8E3C-9DE31A87F4D4-- From nobody Mon May 8 15:21: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 3A7D9127078 for ; Mon, 8 May 2017 15:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=onevmw.onmicrosoft.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 3mVrxouOc8sm for ; Mon, 8 May 2017 15:21:49 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0089.outbound.protection.outlook.com [104.47.41.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE011204DA for ; Mon, 8 May 2017 15:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nQJHwrnARWn4sKAVejssZsqBEIrulAm2Ib+vplZSWDc=; b=XpyRWpINgAVTbmL+x7wz0cOShqwnqfO1/7mNnFaAjzmWpwU9gKLPXa5Ojxb0GYbX0HIP84uPjqLFByE3ebnVDZgB5Qw22XUGtARaVpTmYObS15GQRzlvxihZm/rbftha8Fw9VBUbVc2qtsZYjvQ55uVmH1jMuyzUuar8YcHv0cE= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3048.namprd05.prod.outlook.com (10.172.156.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Mon, 8 May 2017 22:21:48 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.1084.015; Mon, 8 May 2017 22:21:48 +0000 From: Zach Shepherd To: "acme@ietf.org" Thread-Topic: Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token Thread-Index: AQHSyEjYBSJMcNvrJ0+rg/Q+1mjkwA== Date: Mon, 8 May 2017 22:21:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [76.14.92.26] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR05MB3048; 7:+v77W2ZFUKWYQNpUu5p3amkhC1v4TdbtfFDG1myxo+ZVys2OF6TKf66XFWokxsAYF3H5Kgsknn2+qsaU3do+bNsDgeOcRzfBwo7wiolprccJ9lcZ0Rru6WW0k1AAXn7CA3oDiNcniueSsKz3GI+jKA4w5YU10Ze4P0XPKDsD/SmZitO1BaiPswiKdioLsa5Mx/uqwTKdSYAvIDCPLErVDAax07ozsstJanvZh1D7jcUVcWV3Ev3mtwbXja6yxksdyX4QybqT47DKmjpG4M31EMUzOawt4ECkaMdxya+pA+4EF9lcHq0M/k2bfVDXoYQM6zlmg/64xVfrcJxk8u6a2A==; 20:7Vr6P3Gu976D4rzWPuz2URd1Dq8jsiB1OMaPpMkOhkCMRdyF13lLfKWkMlfvBJRIHeyIYOLaTT9dAMUEr3E7ExiNGZSB+wDvNX3I2JBrvQ3fA+wjNxHExbNTh+G6d6DLE+G9ALVGf1H+qXh3/gL51U+rbT0bSG2b89giLzuCXtA= x-ms-office365-filtering-correlation-id: b76e3b8c-82f4-4382-f5a5-08d496609e47 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY4PR05MB3048; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(265273979862326); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148); SRVR:CY4PR05MB3048; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3048; x-forefront-prvs: 0301360BF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39450400003)(39840400002)(39410400002)(39850400002)(39400400002)(236005)(6916009)(6306002)(54896002)(55016002)(2900100001)(9686003)(53936002)(6606003)(54356999)(606005)(74316002)(3846002)(5640700003)(6116002)(19627405001)(2351001)(102836003)(3280700002)(25786009)(38730400002)(99286003)(110136004)(5660300001)(3660700001)(2906002)(33656002)(50986999)(77096006)(6506006)(7696004)(478600001)(2501003)(86362001)(7906003)(189998001)(53336002)(8676002)(1730700003)(81166006)(7736002)(8936002)(122556002)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3048; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB30458AD573BD26D3C38969BDC0EE0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 May 2017 22:21:48.0703 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3048 Archived-At: Subject: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 22:21:51 -0000 --_000_CY4PR05MB30458AD573BD26D3C38969BDC0EE0CY4PR05MB3045namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The following feedback is based on cd7c5e9 (current HEAD of master). Section 8.3 states that the token value for HTTP validation "MUST have at l= east 128 bits of entropy." Section 11.3 explains that one goal of this is that "the entropy requiremen= t prevents ACME clients from implementing a =93naive=94 validation server t= hat automatically replies to challenges without participating in the creati= on of the intial authorization request." However, because of the way the token is used in the validation process, as= a part of the request, this goal is not met. It is possible to configure a= webserver to respond to all requests under .well-known/acme-challenge with= the ASCII representation of the key authorization. (See, e.g., https://git= hub.com/Neilpang/acme.sh/wiki/Stateless-Mode.) Essentially, the server informs the client of the token during the validati= on process, removing any need for the client to have known it. If this is acceptable, the entropy requirement should be removed. If this i= s unacceptable, the challenge and validation should be revised. Regards, Zach Shepherd --_000_CY4PR05MB30458AD573BD26D3C38969BDC0EE0CY4PR05MB3045namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

The following feedback is based on cd7c5e9 (current HEAD of master).
Section 8.3 states that the token value for HTTP validation "MUST have= at least 128 bits of entropy."

Section 11.3 explains that one goal of this is that "the entropy requi= rement prevents ACME clients from implementing a =93naive=94 validation ser= ver that automatically replies to challenges without participating in the c= reation of the intial authorization request."

However, because of the way the token is used in the validation process, as= a part of the request, this goal is not met. It is possible to configure a= webserver to respond to all requests under .well-known/acme-challenge with= the ASCII representation of the key authorization. (See, e.g., https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.)

Essentially, the server informs the client of the token during the validati= on process, removing any need for the client to have known it.

If this is acceptable, the entropy requirement should be removed. If this i= s unacceptable, the challenge and validation should be revised.

Regards,
Zach Shepherd

--_000_CY4PR05MB30458AD573BD26D3C38969BDC0EE0CY4PR05MB3045namp_-- From nobody Mon May 8 16:37:55 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 D9ABD129329 for ; Mon, 8 May 2017 16:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 qeN9m_6aeRsV for ; Mon, 8 May 2017 16:37:51 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::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 9196D128B88 for ; Mon, 8 May 2017 16:37:51 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id u187so34510087pgb.0 for ; Mon, 08 May 2017 16:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QRoqXOvfJFqMlwJ+K8N0r8AGWm7c3rBiQ90NlllhoW8=; b=CD0zxEIzVJuExoseqhYPY5jZGi+lrwH/zR9JjuMrssYCeKQM1hirrR0b2+ihZKTbIB Bth7w9T3nNaeWmWgu8qrgiLm35r9M99Naf2NDu54CXok1rZJC9spB4BCX1nExJBFkPc0 YaNsDjCnEYNXqYLSjQ7sqVIg3OlifEWbKsvRjjHvE2F84DAOQ6vRVVtkVXPJL7Ma3lRu JBmXSz5D4VoPAlLf5EhYgWnXLmE5CmnlOafApaGz9r9jBxwa35z+VahyDD+V0S9tEALO e8kWj24Hb3VOtzzsdhSjchQveivMoStnFpxBOaH++/TRVse4Bx7om/2VE9SiEx+YyrCY MGPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QRoqXOvfJFqMlwJ+K8N0r8AGWm7c3rBiQ90NlllhoW8=; b=ZoBcZF/O9gU3LHR/8xVt31irjqZJI88FDJg34Nbv/1xhw5i6RIL4ilZgaw2KDc+snL q3aWz6RauoBVsInQvVutwTj/I8/Q0RpPzCSvat1kvG5usqEhSTUpuHOVq1LtJ/CrAAf1 kVk18kCTKspCHPuU0hKSVFd+7FuO9UrPf57EEFNxRU/xiKyO2SrS8Rg18ZtzsH1yyEK8 GYIXxrf+inQgTRg7Tdau53cHQQz5Q/e1bScOSGLH2O0AL8zpnKTAifWNUG5pr+eu6tTS C49N31KhgM31lEFMwDnSX701W0g1iy2BMLD1PggZ5hYv+8ydTA/zMd/iCkyU/b8XGB+r nWhA== X-Gm-Message-State: AN3rC/5nKoNwh4UwLapXIoeTzEeZK5z3RAU5JdKmnGWqb7o6eG0LxsOh /bCYMzG34CFeYGCq5GDAUn0kdDDDBw== X-Received: by 10.98.201.15 with SMTP id k15mr27368420pfg.14.1494286671078; Mon, 08 May 2017 16:37:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Mon, 8 May 2017 16:37:50 -0700 (PDT) In-Reply-To: References: From: Logan Widick Date: Mon, 8 May 2017 18:37:50 -0500 Message-ID: To: Zach Shepherd Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c1877e038ecef054f0bba58 Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 May 2017 23:37:54 -0000 --94eb2c1877e038ecef054f0bba58 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think that this may require revising the challenge. Would a "two-token" challenge pattern help mitigate the risk of stateless clients for the HTTP challenge and for future challenges that may otherwise have similar issues? For example, assume that the challenge has two tokens, which I will call "tokenA" and "tokenB", TokenA would be used to make request parameters, and tokenB would be used only for responses. The key authorization would include both tokens to ensure that the tokens were received correctly. For example, the key authorization could be tokenA || tokenB || account key thumbprint. The ACME server could perform HTTP validation by sending a request to "http://example.com/.well-known/acme-challenge/tokenA" and get back the revised key authorization (or anything else with tokenB in it). Since tokenB was not sent with the request, the server would have to have known tokenB somehow. One possible drawback of this approach is the increased storage required for the extra token. An alternate approach may be to require that a request parameter sent during validation for any type of challenge (now existing or later developed) must include a hash of something containing the challenge token rather than something containing the token itself. For example, the HTTP challenge could be revised by having the validation go to " http://example.com/.well-known/acme-challenge/SHA256_hash_of_the_token" instead of "http://example.com/.well-known/acme-challenge/token". The TLS-SNI challenge uses this "hashed token for requests" pattern already. In the TLS-SNI challenge, SAN A (the one requested in the TLS SNI extension during challenge verification) is constructed by hashing the token, while the response is constructed with the (hash of) the key authorization. One possible drawback of having challenges to use this "hashed token for requests" pattern is that hashing would become such an integral part of the challenge process that if a hash algorithm is compromised, new versions of all challenges will need to be released. In both ideas above, I suggested applying the same general "pattern" (of what should be used for making validation requests and what should be used for making validation responses) to all challenges. Although this statelessness issue solely affects the HTTP challenge at this time, adding text in the specification (probably in a "security considerations" subsection) to require or recommend all challenges to use the same pattern (or choose from a list of multiple approved patterns) would prevent future challenges from having similar issues. On a different note, would requiring the provisioned challenge resource (in this case, the response to the "http://example.com/.well-know n/acme-challenge/some_token_or_hash_of_the_token" request) to be digitally signed by the account JWK and/or the CSR key (most likely by having the response be a JWS containing the key authorization rather than the key authorization itself) improve security, worsen security, or have no impact on security? If it would improve security, would this be feasible for each type of challenge? Sincerely, Logan Widick On Mon, May 8, 2017 at 5:21 PM, Zach Shepherd wrote: > The following feedback is based on cd7c5e9 (current HEAD of master). > > Section 8.3 states that the token value for HTTP validation "MUST have at > least 128 bits of entropy." > > Section 11.3 explains that one goal of this is that "the entropy > requirement prevents ACME clients from implementing a =E2=80=9Cnaive=E2= =80=9D validation > server that automatically replies to challenges without participating in > the creation of the intial authorization request." > > However, because of the way the token is used in the validation process, > as a part of the request, this goal is not met. It is possible to configu= re > a webserver to respond to all requests under .well-known/acme-challenge > with the ASCII representation of the key authorization. (See, e.g., > https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.) > > Essentially, the server informs the client of the token during the > validation process, removing any need for the client to have known it. > > If this is acceptable, the entropy requirement should be removed. If this > is unacceptable, the challenge and validation should be revised. > > Regards, > Zach Shepherd > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --94eb2c1877e038ecef054f0bba58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that this may require revising the challenge.=C2= =A0

Would a "two-token" challenge pattern help= mitigate the risk of stateless clients for the HTTP challenge and for futu= re challenges that may otherwise have similar issues? For example, assume t= hat the challenge has two tokens, which I will call "tokenA" and = "tokenB", TokenA would be used to make request parameters, and to= kenB would be used only for responses. The key authorization would include = both tokens to ensure that the tokens were received correctly. For example,= the key authorization could be tokenA || tokenB || account key thumbprint.= The ACME server could perform HTTP validation by sending a request to &quo= t;http://example.com/.well-known/acme-challenge/tokenA" and get back the revised key authoriza= tion (or anything else with tokenB in it). Since tokenB was not sent with t= he request, the server would have to have known tokenB somehow. One possibl= e drawback of this approach is the increased storage required for the extra= token.=C2=A0

An alternate approach may be to requ= ire that a request parameter sent during validation for any type of challen= ge (now existing or later developed) must include a hash of something conta= ining the challenge token rather than something containing the token itself= . For example, the HTTP challenge could be revised by having the validation= go to "http://example.com/.= well-known/acme-challenge/SHA256_hash_of_the_token" inst= ead of "http://example.com/.= well-known/acme-challenge/token". The TLS-SNI challenge uses = this "hashed token for requests" pattern already. In the TLS-SNI = challenge, SAN A (the one requested in the TLS SNI extension during challen= ge verification) is constructed by hashing the token, while the response is= constructed with the (hash of) the key authorization. One possible drawbac= k of having challenges to use this "hashed token for requests" pa= ttern is that hashing would become such an integral part of the challenge p= rocess that if a hash algorithm is compromised, new versions of all challen= ges will need to be released.=C2=A0

In both ideas = above, I suggested applying the same general "pattern" (of what s= hould be used for making validation requests and what should be used for ma= king validation responses) to all challenges. Although this statelessness i= ssue solely affects the HTTP challenge at this time, adding text in the spe= cification (probably in a "security considerations" subsection) t= o require or recommend all challenges to use the same pattern (or choose fr= om a list of multiple approved patterns) would prevent future challenges fr= om having similar issues.=C2=A0

On a different not= e, would requiring the provisioned challenge resource (in this case, the re= sponse to the "http://exampl= e.com/.well-known/acme-challenge/some_token_or_hash_of_the_to= ken" request) to be digitally signed by the account JWK and/or the CSR= key (most likely by having the response be a JWS containing the key author= ization rather than the key authorization itself) improve security, worsen = security, or have no impact on security? If it would improve security, woul= d this be feasible for each type of challenge?=C2=A0

Sincerely,=C2=A0
Logan Widick

On Mon, May 8, 2017 at 5:21 PM, Zach S= hepherd <shepherdz@vmware.com> wrote:

The following feedback is based on cd7c5e9 (current HEAD of master).
Section 8.3 states that the token value for HTTP validation "MUST have= at least 128 bits of entropy."

Section 11.3 explains that one goal of this is that "the entropy requi= rement prevents ACME clients from implementing a =E2=80=9Cnaive=E2=80=9D va= lidation server that automatically replies to challenges without participat= ing in the creation of the intial authorization request."

However, because of the way the token is used in the validation process, as= a part of the request, this goal is not met. It is possible to configure a= webserver to respond to all requests under .well-known/acme-challenge with= the ASCII representation of the key authorization. (See, e.g., https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.)

Essentially, the server informs the client of the token during the validati= on process, removing any need for the client to have known it.

If this is acceptable, the entropy requirement should be removed. If this i= s unacceptable, the challenge and validation should be revised.

Regards,
Zach Shepherd


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


--94eb2c1877e038ecef054f0bba58-- From nobody Mon May 8 23:05:10 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 F3998129ADA for ; Mon, 8 May 2017 23:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 uAtMN8Ua1h5x for ; Mon, 8 May 2017 23:05:05 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEA81242EA for ; Mon, 8 May 2017 23:05:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 16C8B5FD6B; Tue, 9 May 2017 09:05:04 +0300 (EEST) 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 E31aOMc03-c4; Tue, 9 May 2017 09:05:03 +0300 (EEST) 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 9DAD821C; Tue, 9 May 2017 09:05:03 +0300 (EEST) Date: Tue, 9 May 2017 09:05:03 +0300 From: Ilari Liusvaara To: Logan Widick Cc: Zach Shepherd , "acme@ietf.org" Message-ID: <20170509060503.GA8599@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 06:05:08 -0000 On Mon, May 08, 2017 at 06:37:50PM -0500, Logan Widick wrote: > I think that this may require revising the challenge. > > Would a "two-token" challenge pattern help mitigate the risk of stateless > clients for the HTTP challenge and for future challenges that may otherwise > have similar issues? For example, assume that the challenge has two tokens, > which I will call "tokenA" and "tokenB", TokenA would be used to make > request parameters, and tokenB would be used only for responses. The key > authorization would include both tokens to ensure that the tokens were > received correctly. For example, the key authorization could be tokenA || > tokenB || account key thumbprint. The ACME server could perform HTTP > validation by sending a request to > "http://example.com/.well-known/acme-challenge/tokenA" > and get back the revised key authorization (or anything else with tokenB in > it). Since tokenB was not sent with the request, the server would have to > have known tokenB somehow. One possible drawback of this approach is the > increased storage required for the extra token. The way TLS-SNI-02 does it is to derive the challenge and response tokens out of the master random value. TLS-SNI-01 had a similar problem, but in that case, the problem was compounded by: - TLS-SNI not even weakly binding the hostname to validate into validation (-02 does not fix this), and - TLS-SNI-01 not binding the account key into validation (and even in -02, this is not verifiably done). (For these problems, I consider TLS-SNI-01/-02 to validate the underlying IP, not the domain itself... In CABForum BRs, this is known as method 8 validation. Method 10 was intended to cover TLS-SNI, but the definition looks just screwed up). Whereas HTTP-01 does (weakly) bind both the hostname and the account key into validation in verifiable way. This renders "stateless mode" quite a bit harder to exploit. And if one moved to challenge-response token scheme, most likely the response would not contain challenge at all. So the storage amount would remain the same, unless implementation backed things with database table. Some extra storage is unlikely to be an issue for such implementation. > On a different note, would requiring the provisioned challenge resource (in > this case, the response to the "http://example.com/.well-know > n/acme-challenge/some_token_or_hash_of_the_token" request) to be digitally > signed by the account JWK and/or the CSR key (most likely by having the > response be a JWS containing the key authorization rather than the key > authorization itself) improve security, worsen security, or have no impact > on security? If it would improve security, would this be feasible for each > type of challenge? I don't think having it signed by account key would affect security. Rendering responses unpredictable to the CA and strongly binding the hostname could have some benefits tho. Also note that you can't assume that signature binds the key it was done using: For that, you need to include the public key in data to be signed. Yes, some signatures like Ed25519 do such binding anyway, but IIRC ECDSA doesn't. Signing with CSR key would have negative impact (cross-protocol attack possibility! Not to mention it would really interfere with properly protecting the TLS key). There actually was a message that was signed with TLS key in past versions, but it was removed because of cross-protocol attack possibilities and such problems. -Ilari From nobody Tue May 9 09:13:48 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 7095F1294E0 for ; Tue, 9 May 2017 09:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.088 X-Spam-Level: X-Spam-Status: No, score=0.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, 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=onevmw.onmicrosoft.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 eN07TGnZfxVl for ; Tue, 9 May 2017 09:13:39 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0066.outbound.protection.outlook.com [104.47.37.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2159A1294CC for ; Tue, 9 May 2017 09:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7cWUsSdrPD2wYc7kh886Wo5BBXHgg/UGEuwKjIyk2U4=; b=kZGqbfONVnl7mHi6Sug6AOcXBQrQtca92SLcjZEi3QhFQ/OBPSsMryMj32WihRUVEwkzTK5J5+V4skkrLQNkJb1Do6oMTxEcn07OVBIwr+RbAyEAHA9mCdh6/oM3+FtMk41xZJGYzdK82Mx4tYfnWIAe+x16mnh+RnYvh4SLEHk= Received: from DM5PR05MB3052.namprd05.prod.outlook.com (10.173.218.138) by DM5PR05MB3052.namprd05.prod.outlook.com (10.173.218.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Tue, 9 May 2017 16:13:37 +0000 Received: from DM5PR05MB3052.namprd05.prod.outlook.com ([10.173.218.138]) by DM5PR05MB3052.namprd05.prod.outlook.com ([10.173.218.138]) with mapi id 15.01.1084.015; Tue, 9 May 2017 16:13:37 +0000 From: Zach Shepherd To: Logan Widick CC: "acme@ietf.org" Thread-Topic: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token Thread-Index: AQHSyEjYBSJMcNvrJ0+rg/Q+1mjkwKHrF6MAgAEPxHk= Date: Tue, 9 May 2017 16:13:37 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [76.14.92.26] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB3052; 7:a+UZ3c1tfgPK0LzgTg5xTgKc0fPW+28xGp7QMe2kRtPg4Ll1lNhrVbQeqz+1/NKYFV+rrisLrslgi67CWXcJUUgofQ+Nf2WfSfpO20ujWh25M/gFCC1XfSUiG14ZAgu2L0PzTAf2zfUlMYwMQMVOK+1qngnsJmgPqVEBRntDmjXf79YFcDR6seLjf/enOV4iVjCsM40v7mGw6hOoampzd+s+07nT8KdJL4Ws8fTX51xT4AaBC8CVNxODOoll2Z3BCwuk1dnqdd787SgagJnbLXxuMCFc/MFCt9jIdkoc2qU3E5WhpO1vVr3NoCpAjLD7akWVAJpLTusn166N+8qJ3g==; 20:9Ub9A0ks3e+o4fXOWoWrAPxG1dXfO1BEN/sZJnWMv5hUJnkMLGAqKF2qfUl2VMZ7GcXz+ZrXBTN1oRXSRX1msGWt5zP1gUE+oqo5JwMZ2pnOjwxR1HJhsmaXGtKZk4atlWmUZ+I3ot73OWzZcEa5dbTNjXH5Pjj93AYwc7gZbKM= x-ms-office365-filtering-correlation-id: bc0118a9-1bf7-4d2a-f71c-08d496f65996 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:DM5PR05MB3052; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(158342451672863)(10436049006162)(166708455590820)(192374486261705)(265273979862326); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:DM5PR05MB3052; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3052; x-forefront-prvs: 0302D4F392 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400002)(39410400002)(39400400002)(39840400002)(39450400003)(51444003)(377454003)(24454002)(6606003)(8676002)(9686003)(2950100002)(99286003)(39060400002)(2906002)(3660700001)(55016002)(4326008)(236005)(6306002)(3846002)(53936002)(102836003)(6116002)(77096006)(6436002)(5660300001)(54896002)(86362001)(189998001)(81166006)(6916009)(7696004)(6506006)(8936002)(7736002)(478600001)(606005)(54356999)(122556002)(2900100001)(38730400002)(110136004)(7906003)(3280700002)(106356001)(6246003)(53376002)(33656002)(66066001)(53546009)(74316002)(25786009)(229853002)(19627405001)(50986999)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR05MB3052; H:DM5PR05MB3052.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR05MB3052FCDE23E7B9EB462C467FC0EF0DM5PR05MB3052namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2017 16:13:37.3007 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3052 Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 16:13:42 -0000 --_000_DM5PR05MB3052FCDE23E7B9EB462C467FC0EF0DM5PR05MB3052namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I like the "hashed token for requests" pattern, assuming that the [unhashed= ] token would be present as a part of the response. I think the drawback of hash algorithm compromise can be mitigated by the c= hoice of hash algorithm; compromise of SHA-256 would already have substanti= al impact on ACME such that the net impact of further use of it would be re= latively insignificant. Regards, Zach ________________________________ From: Logan Widick Sent: Monday, May 8, 2017 4:37 PM To: Zach Shepherd Cc: acme@ietf.org Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of= entropy for the http-01 token I think that this may require revising the challenge. Would a "two-token" challenge pattern help mitigate the risk of stateless c= lients for the HTTP challenge and for future challenges that may otherwise = have similar issues? For example, assume that the challenge has two tokens,= which I will call "tokenA" and "tokenB", TokenA would be used to make requ= est parameters, and tokenB would be used only for responses. The key author= ization would include both tokens to ensure that the tokens were received c= orrectly. For example, the key authorization could be tokenA || tokenB || a= ccount key thumbprint. The ACME server could perform HTTP validation by sen= ding a request to "http://example.com/.well-known/acme-challenge/tokenA" and get back the revised key author= ization (or anything else with tokenB in it). Since tokenB was not sent wit= h the request, the server would have to have known tokenB somehow. One poss= ible drawback of this approach is the increased storage required for the ex= tra token. An alternate approach may be to require that a request parameter sent durin= g validation for any type of challenge (now existing or later developed) mu= st include a hash of something containing the challenge token rather than s= omething containing the token itself. For example, the HTTP challenge could= be revised by having the validation go to "http://example.com/.well-known/acme-challenge/SHA256_hash_of_the= _token" instead of "http://example.com/.well-known/acme-challenge/token". The TLS-SNI challenge uses this "h= ashed token for requests" pattern already. In the TLS-SNI challenge, SAN A = (the one requested in the TLS SNI extension during challenge verification) = is constructed by hashing the token, while the response is constructed with= the (hash of) the key authorization. One possible drawback of having chall= enges to use this "hashed token for requests" pattern is that hashing would= become such an integral part of the challenge process that if a hash algor= ithm is compromised, new versions of all challenges will need to be release= d. In both ideas above, I suggested applying the same general "pattern" (of wh= at should be used for making validation requests and what should be used fo= r making validation responses) to all challenges. Although this statelessne= ss issue solely affects the HTTP challenge at this time, adding text in the= specification (probably in a "security considerations" subsection) to requ= ire or recommend all challenges to use the same pattern (or choose from a l= ist of multiple approved patterns) would prevent future challenges from hav= ing similar issues. On a different note, would requiring the provisioned challenge resource (in= this case, the response to the "http://example.com/.well-known/acme-challenge/some_token_or_hash_of_the_tok= en" request) to be digitally signed by the account JWK and/or the CSR key (= most likely by having the response be a JWS containing the key authorizatio= n rather than the key authorization itself) improve security, worsen securi= ty, or have no impact on security? If it would improve security, would this= be feasible for each type of challenge? Sincerely, Logan Widick On Mon, May 8, 2017 at 5:21 PM, Zach Shepherd > wrote: The following feedback is based on cd7c5e9 (current HEAD of master). Section 8.3 states that the token value for HTTP validation "MUST have at l= east 128 bits of entropy." Section 11.3 explains that one goal of this is that "the entropy requiremen= t prevents ACME clients from implementing a =93naive=94 validation server t= hat automatically replies to challenges without participating in the creati= on of the intial authorization request." However, because of the way the token is used in the validation process, as= a part of the request, this goal is not met. It is possible to configure a= webserver to respond to all requests under .well-known/acme-challenge with= the ASCII representation of the key authorization. (See, e.g., https://git= hub.com/Neilpang/acme.sh/wiki/Stateless-Mode.) Essentially, the server informs the client of the token during the validati= on process, removing any need for the client to have known it. If this is acceptable, the entropy requirement should be removed. If this i= s unacceptable, the challenge and validation should be revised. Regards, Zach Shepherd _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme --_000_DM5PR05MB3052FCDE23E7B9EB462C467FC0EF0DM5PR05MB3052namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I like the "hashed token for requests" pattern, assuming that = the [unhashed] token would be present as a part of the response.


I think the drawback of hash algorithm compromise can be mitigated by th= e choice of hash algorithm; compromise of SHA-256 would already have substa= ntial impact on ACME such that the net impact of further use of it would be= relatively insignificant.


Regards,

Zach


From: Logan Widick <lo= gan.widick@gmail.com>
Sent: Monday, May 8, 2017 4:37 PM
To: Zach Shepherd
Cc: acme@ietf.org
Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 = bits of entropy for the http-01 token
 
I think that this may require revising the challenge. = ;

Would a "two-token" challenge pattern help mitigate the risk= of stateless clients for the HTTP challenge and for future challenges that= may otherwise have similar issues? For example, assume that the challenge = has two tokens, which I will call "tokenA" and "tokenB", TokenA would be used to make request parameters, a= nd tokenB would be used only for responses. The key authorization would inc= lude both tokens to ensure that the tokens were received correctly. For exa= mple, the key authorization could be tokenA || tokenB || account key thumbprint. The ACME server could perform HTTP va= lidation by sending a request to "http://example.com/.well-know= n/acme-challenge/tokenA" and get back the revised key authorization (or anything else with tokenB i= n it). Since tokenB was not sent with the request, the server would have to= have known tokenB somehow. One possible drawback of this approach is the i= ncreased storage required for the extra token. 

An alternate approach may be to require that a request parameter sent = during validation for any type of challenge (now existing or later develope= d) must include a hash of something containing the challenge token rather t= han something containing the token itself. For example, the HTTP challenge could be revised by having the val= idation go to "http://example.com/.well-known/acme-challe= nge/SHA256_hash_of_the_token" instead of "http://example.com/.well-known/acme-challenge/= token". The TLS-SNI challenge uses this "hashed token for requests" patt= ern already. In the TLS-SNI challenge, SAN A (the one requested in the TLS = SNI extension during challenge verification) is constructed by hashing the = token, while the response is constructed with the (hash of) the key authorization. One possible drawback of having chall= enges to use this "hashed token for requests" pattern is that has= hing would become such an integral part of the challenge process that if a = hash algorithm is compromised, new versions of all challenges will need to be released. 

In both ideas above, I suggested applying the same general "patte= rn" (of what should be used for making validation requests and what sh= ould be used for making validation responses) to all challenges. Although t= his statelessness issue solely affects the HTTP challenge at this time, adding text in the specification (probably in= a "security considerations" subsection) to require or recommend = all challenges to use the same pattern (or choose from a list of multiple a= pproved patterns) would prevent future challenges from having similar issues. 


Sincerely, 
Logan Widick

On Mon, May 8, 2017 at 5:21 PM, Zach Shepherd <shepherdz@vmw= are.com> wrote:

The following feedback is based on cd7c5e9 (current HEAD of master).
Section 8.3 states that the token value for HTTP validation "MUST have= at least 128 bits of entropy."

Section 11.3 explains that one goal of this is that "the entropy requi= rement prevents ACME clients from implementing a =93naive=94 validation ser= ver that automatically replies to challenges without participating in the c= reation of the intial authorization request."

However, because of the way the token is used in the validation process, as= a part of the request, this goal is not met. It is possible to configure a= webserver to respond to all requests under .well-known/acme-challenge with= the ASCII representation of the key authorization. (See, e.g., https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.)

Essentially, the server informs the client of the token during the validati= on process, removing any need for the client to have known it.

If this is acceptable, the entropy requirement should be removed. If this i= s unacceptable, the challenge and validation should be revised.

Regards,
Zach Shepherd


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mail= man/listinfo/acme


--_000_DM5PR05MB3052FCDE23E7B9EB462C467FC0EF0DM5PR05MB3052namp_-- From nobody Tue May 9 13:29:04 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 02C2712EB11 for ; Tue, 9 May 2017 13:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 rnsxl1N92SY9 for ; Tue, 9 May 2017 13:29:00 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 B8F54128D2E for ; Tue, 9 May 2017 13:29:00 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v49KC2oG014043 for ; Tue, 9 May 2017 21:28:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=xLlOzSWf3GPa8DZKwZeTW4/+ecXMUswBWVlan1Dm1fM=; b=BNrTEBgJkyjHBe2ffsl9FgCHSwxr5Uwc+YiDQzMEaPao2G2LhVoOs9A+Fgruw/nNGbJZ q1nt9KAZhbBuV19vVd2WREKx9P6MqsrW+pfYDEBnqyMfbWCqK9blUogPodjSx1m4l1jN MFK+yQ/YCfMQvP3ZVYMwngeJ+NpznWhtrJeBPrYOnRuONV4Sep3u2si5jWkPevqLNadz wzse38ZsaBPvUhHgz2tvrAC7XvTOxG4VQK9JvLBLLG8I3Z0OGcP29vc+yY4Ic020IKhq +EGM8bQhGM3gifBBSbFahx4TRMdXdQ3RtYCbGkM5RCFjHwog5xa5Hwb56jaTH/rYUPIA 6g== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2aaymjprq8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 09 May 2017 21:28:58 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v49KMqjK000466 for ; Tue, 9 May 2017 16:28:58 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2a99tunxhk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 09 May 2017 16:28:57 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 9 May 2017 16:28:56 -0400 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.1263.000; Tue, 9 May 2017 16:28:57 -0400 From: "Salz, Rich" To: ACME WG Thread-Topic: ACME interm meeting poll Thread-Index: AdLJAssKtJISGs1HQFePQCpVZ1P8Fw== Date: Tue, 9 May 2017 20:28:57 +0000 Message-ID: <37f92587e2f245829383f65b3ef38a30@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.36.228] Content-Type: multipart/alternative; boundary="_000_37f92587e2f245829383f65b3ef38a30usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-09_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705090115 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-09_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705090114 Archived-At: Subject: [Acme] ACME interm meeting poll X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 20:29:03 -0000 --_000_37f92587e2f245829383f65b3ef38a30usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable We are trying to decide if we should meet in Prague. To help make the deci= sion, we are holding a Doodle poll for a one-hour virtual interim. Please = go here and vote: http://doodle.com/poll/u56c5xwr7nb23wqe The main ACME draft is essentially done, and should enter a second WGLC soo= n. That alone would not justify a meeting. In the early message thread that was labeled =93Futures=94 the following po= ssible work items came up: Hugo=92s CAA draft (already adopted, short, might be ready = for WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01 The following drafts are possible calls for adoption: Yaron Sheffer et al draft on STAR -- https://tools.ietf.org= /html/draft-sheffer-acme-star-lurk-00 Mary Barnes on an ACME challenge for ATIS/SIP -- https://to= ols.ietf.org/html/draft-barnes-acme-service-provider-00 Roland Shoemaker on an ACME challenge for validating IP add= resses -- https://tools.ietf.org/html/draft-shoemaker-acme-ip-00 In addition, Alexey is interested in helping with an ACME challenge for ema= il certificates. Is anyone else interested in helping to draft drafting? We would like to know if people are interested in adopting, advancing, work= ing-on these drafts within the ACME WG. And if anyone will commit to workin= g on any of them. If so, then we will discuss them in Prague, and have a r= e-chartering discussion to cover this new work. Please see the Doodle poll and mark your availability. For the good of the order, /r$ --_000_37f92587e2f245829383f65b3ef38a30usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

We are trying to decide if we should meet in Prague.=   To help make the decision, we are holding a Doodle poll for a one-ho= ur virtual interim.  Please go here and vote:

http://doodle.com/poll/u56c5xwr7nb23= wqe

 

The main ACME draft is essentially done, and should = enter a second WGLC soon.  That alone would not justify a meeting.

 

In the early message thread that was labeled =93Futu= res=94 the following possible work items came up:

        &nbs= p;       Hugo=92s CAA draft (already adopted,= short, might be ready for WGLC) -- https://tool= s.ietf.org/html/draft-ietf-acme-caa-01

 

The following drafts are possible calls for adoption= :

        &nbs= p;       Yaron Sheffer et al draft on STAR --= https://tools.ietf.org/html/draft-sheffer-acme-star-lurk-00

        &nbs= p;       Mary Barnes on an ACME challenge for= ATIS/SIP -- https://tools.ietf.org/html/draft-barnes-acme-service-provider-00

        &nbs= p;       Roland Shoemaker on an ACME challeng= e for validating IP addresses -- https://= tools.ietf.org/html/draft-shoemaker-acme-ip-00

 

In addition, Alexey is interested in helping with an= ACME challenge for email certificates. Is anyone else interested in helpin= g to draft drafting?

 

We would like to know if people are interested in ad= opting, advancing, working-on these drafts within the ACME WG. And if anyon= e will commit to working on any of them.  If so, then we will discuss = them in Prague, and have a re-chartering discussion to cover this new work.

 

Please see the Doodle poll and mark your availabilit= y.

 

For the good of the order,

        &nbs= p;       /r$

 

--_000_37f92587e2f245829383f65b3ef38a30usma1exdag1mb1msgcorpak_-- From nobody Tue May 9 14:44:11 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 030E2127058 for ; Tue, 9 May 2017 14:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 0CbXyv0kro8L for ; Tue, 9 May 2017 14:44:08 -0700 (PDT) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::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 33FF21200F1 for ; Tue, 9 May 2017 14:44:08 -0700 (PDT) Received: by mail-wr0-x236.google.com with SMTP id l9so17845762wre.1 for ; Tue, 09 May 2017 14:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/d+7sogagSm258ZLf7BOjYGQkcTV5ZRX4vG7MELRqyw=; b=lVOclWXh/Ji5HsZ2Cz+2jZMGo2q1QSo4PgHnHor0zlGXzixcw2Hrw+5G9lYO4oB1hy FfjAfWOEPmSnA6tFNcbKQiBYshKQSjQWKzDGVq0Q+y69ce55+pclofz6XXVHhxVmmFyO AuIh2bk3mdK9I6kyh3p/OGp6m0uJcto23fuaLFQX0Rt3BXG+vbgSl75aJtZqk4b4OT4Z E8F8zcIMqxHnCN2FH8S1emyB8ONY8MHu+Y80cGEwbkB/WaKeYbG9Y5/DBW1JBzoJDzev J3vaBf7YNOsrl2M4C2GfVuwFJ7p38EexoctMzE8zvktiL+Cf/h3GOv3EfKLs1YbSOOVM ZJ7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/d+7sogagSm258ZLf7BOjYGQkcTV5ZRX4vG7MELRqyw=; b=lVvOHZt7k5PYKKY7XKOvfj/Rh6Iewc1x//ITalARBtPkzfNtZmERJs33zPd4mA5u6b bM5r949DHVAqOOwu8o88dHeeKJVoGFhZRUWcAO4cfPvTwE5VGanvRK/+I4xdqL4PqjLV flq8U2WpWIDtMqImT8MZD9QsQQt7ImxDnTA5oucC1KKS0ruEGG3WteYL/Xwtutk/5QkT aQiQkzpw9mCs/MEfF8RawfFa8MtGqgZDeltQaeuCeG3YA1D1knVy6xB8B0EA6Wos+1GO X0Hsx9+BNmbiZKpfNvd/7hzIiKMqBqZz9KCVApIj66C6z3lpfethq6lSIuegexP2E4lB Khog== X-Gm-Message-State: AODbwcA4G5WCOPXSxG2ogUgvmtQAu3jPHfNMZexAIHxInjOohgA6555q uAGc/q9c13KTBw== X-Received: by 10.80.138.34 with SMTP id i31mr1570858edi.145.1494366246737; Tue, 09 May 2017 14:44:06 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id l4sm1083806edd.69.2017.05.09.14.44.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 14:44:05 -0700 (PDT) From: Yoav Nir Message-Id: <64C79811-4994-41A1-A3DC-459D62D80D23@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F667E570-186A-4B86-ABFF-5EA307983D23"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 10 May 2017 00:44:02 +0300 In-Reply-To: <37f92587e2f245829383f65b3ef38a30@usma1ex-dag1mb1.msg.corp.akamai.com> Cc: ACME WG To: Rich Salz References: <37f92587e2f245829383f65b3ef38a30@usma1ex-dag1mb1.msg.corp.akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] ACME interm meeting poll X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 May 2017 21:44:10 -0000 --Apple-Mail=_F667E570-186A-4B86-ABFF-5EA307983D23 Content-Type: multipart/alternative; boundary="Apple-Mail=_D5A30E30-2C08-4E4B-A91F-C6F7EFFDEF57" --Apple-Mail=_D5A30E30-2C08-4E4B-A91F-C6F7EFFDEF57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 9 May 2017, at 23:28, Salz, Rich wrote: > In addition, Alexey is interested in helping with an ACME challenge = for email certificates. Is anyone else interested in helping to draft = drafting? Has there been anything about this on the list? Anyway, I=E2=80=99d be = happy to help with that. >=20 > We would like to know if people are interested in adopting, advancing, = working-on these drafts within the ACME WG. And if anyone will commit to = working on any of them. If so, then we will discuss them in Prague, and = have a re-chartering discussion to cover this new work. >=20 > Please see the Doodle poll and mark your availability. >=20 > For the good of the order, Had to look that one up. Learn something new every day=E2=80=A6 Yoav --Apple-Mail=_D5A30E30-2C08-4E4B-A91F-C6F7EFFDEF57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 9 May 2017, at 23:28, Salz, Rich <rsalz@akamai.com> = wrote:

<snip />

In addition, Alexey is = interested in helping with an ACME challenge for email certificates. Is = anyone else interested in helping to draft = drafting?

Has there = been anything about this on the list?  Anyway, I=E2=80=99d be happy = to help with that.

 
We would like to know if people are = interested in adopting, advancing, working-on these drafts within the = ACME WG. And if anyone will commit to working on any of them.  If = so, then we will discuss them in Prague, and have a re-chartering = discussion to cover this new work.
 
Please see the Doodle poll and mark = your availability.
 
For the good of the order,

Had to look that one up.  Learn something = new every day=E2=80=A6

Yoav
= --Apple-Mail=_D5A30E30-2C08-4E4B-A91F-C6F7EFFDEF57-- --Apple-Mail=_F667E570-186A-4B86-ABFF-5EA307983D23 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZEjgjAAoJELhJCxUKWMyZjuUIAIyvhquse6Xz9Rav5B7ZlYWK YtB3Vj2wVqlnXb+5vZozwqIW9vFxQ17AmT5VJWhwu9/vN8NzFd60AKEuquRJ9Sad nEidHhFhneagky0F8ffB1RxJ3eSJQnTtby9Rk3GGNX/xFPrP+/g9xiY5UwkE7ved RznoDf5fDjFvWYpeFArYpZpXHOtTq2NP+TKKw3KoTNgKrIDUFwhbUpvem5L27cM9 ntFZfTuWVXAobCO+US7dblneiR2lTCi/OsW8e2T8evxkuL/8rZF5M7TtPfRmK5Yo R/ImrawRJBzpTexg+3M2Orl2wcNKI4vpNtZkbMfzyVxX4ArwSNGi8M0NeF6Wms4= =GVUO -----END PGP SIGNATURE----- --Apple-Mail=_F667E570-186A-4B86-ABFF-5EA307983D23-- From nobody Wed May 10 02:34:50 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 6FE081252BA for ; Wed, 10 May 2017 02:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-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=isode.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 UGl23SYeOb1U for ; Wed, 10 May 2017 02:34:47 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 59E71129412 for ; Wed, 10 May 2017 02:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1494408868; d=isode.com; s=june2016; i=@isode.com; bh=JMepKifTuPP0KHsZC5v+hSaCe4A7eQGR1rh1hAs6/5w=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=qzpsAbhoYLJIdibhext2V2AqNJGFinzDNmKCyPEfB9+UvAIRnEDV1x3QFujpKGZNi05f+7 lWrM0XPqOtnc6DyFh92j+U92MHywM9FaxnsDtohJmgngG2bDAtw8jvdyaoOf5U4AZlkNF+ yqK0DiXGkgk/WZxUmO6IqqFeQuw65KM=; Received: from [10.215.126.138] ((unknown) [85.255.237.225]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 10 May 2017 10:34:28 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING From: Alexey Melnikov X-Mailer: iPhone Mail (13G35) In-Reply-To: <64C79811-4994-41A1-A3DC-459D62D80D23@gmail.com> Date: Wed, 10 May 2017 10:50:56 +0100 Cc: Rich Salz , ACME WG Message-Id: <8BFA8BA2-3F69-41F5-A54F-10699DB81210@isode.com> References: <37f92587e2f245829383f65b3ef38a30@usma1ex-dag1mb1.msg.corp.akamai.com> <64C79811-4994-41A1-A3DC-459D62D80D23@gmail.com> To: Yoav Nir MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-0F02C3B7-4C19-455A-859C-8C40848FD2DA Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Acme] ACME interm meeting poll X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 09:34:48 -0000 --Apple-Mail-0F02C3B7-4C19-455A-859C-8C40848FD2DA Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Hi Yoav, > On 9 May 2017, at 22:44, Yoav Nir wrote: >=20 >=20 >> On 9 May 2017, at 23:28, Salz, Rich wrote: >=20 > >=20 >> In addition, Alexey is interested in helping with an ACME challenge for e= mail certificates. Is anyone else interested in helping to draft drafting? >=20 > Has there been anything about this on the list? Anyway, I=92d be happy to= help with that. No, just a few private discussions so far. >=20 >>=20 >> We would like to know if people are interested in adopting, advancing, wo= rking-on these drafts within the ACME WG. And if anyone will commit to worki= ng on any of them. If so, then we will discuss them in Prague, and have a r= e-chartering discussion to cover this new work. >> =20 >> Please see the Doodle poll and mark your availability. >> =20 >> For the good of the order, >=20 > Had to look that one up. Learn something new every day=85 >=20 > Yoav > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme --Apple-Mail-0F02C3B7-4C19-455A-859C-8C40848FD2DA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Yoav,

On 9 May 2017, a= t 22:44, Yoav Nir <ynir.ietf@gmail= .com> wrote:


<= div>
On 9 May 2017, at 2= 3:28, Salz, Rich <rsalz@ak= amai.com> wrote:

<s= nip />

In addition, Alexey is interested i= n helping with an ACME challenge for email certificates. Is anyone else inte= rested in helping to draft drafting?

Has there been anything about this on the list?  Anyway, I=E2=80= =99d be happy to help with that.

No, j= ust a few private discussions so far.


We would like to know if people are interested= in adopting, advancing, working-on these drafts within the ACME WG. And if a= nyone will commit to working on any of them.  If so, then we will discu= ss them in Prague, and have a re-chartering discussion to cover this new wor= k.
&nb= sp;
Please see the Doodle poll and mar= k your availability.
<= o:p class=3D""> 
For the good of t= he order,

Had to loo= k that one up.  Learn something new every day=E2=80=A6
<= br class=3D"">
Yoav
_______________________________________________
= Acme mailing list
Acm= e@ietf.org
https://www.ietf.org/mailman/listinfo/acme
= --Apple-Mail-0F02C3B7-4C19-455A-859C-8C40848FD2DA-- From nobody Wed May 10 08:56: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 9A72E129C3F for ; Wed, 10 May 2017 08:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=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 UZnX8_-0YMvV for ; Wed, 10 May 2017 08:56:03 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914C9129C3E for ; Wed, 10 May 2017 08:56:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0B3A7300541 for ; Wed, 10 May 2017 11:56:02 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yH6Ga0K-5gNM for ; Wed, 10 May 2017 11:56:01 -0400 (EDT) Received: from [5.5.33.188] (vpn.snozzages.com [204.42.252.17]) by mail.smeinc.net (Postfix) with ESMTPSA id D47C03004D7 for ; Wed, 10 May 2017 11:56:00 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_EA251D16-9357-445D-BC10-FBC5EEAD02F5" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 10 May 2017 11:56:00 -0400 References: <37f92587e2f245829383f65b3ef38a30@usma1ex-dag1mb1.msg.corp.akamai.com> <64C79811-4994-41A1-A3DC-459D62D80D23@gmail.com> To: IETF ACME In-Reply-To: <64C79811-4994-41A1-A3DC-459D62D80D23@gmail.com> Message-Id: <332B1400-2636-42FA-BD29-E207EF1CDF46@vigilsec.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] ACME interm meeting poll X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 15:56:04 -0000 --Apple-Mail=_EA251D16-9357-445D-BC10-FBC5EEAD02F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> In addition, Alexey is interested in helping with an ACME challenge = for email certificates. Is anyone else interested in helping to draft = drafting? >=20 > Has there been anything about this on the list? Anyway, I=E2=80=99d = be happy to help with that. I=E2=80=99m interested in that as well, especially after the LAMPS = document on EAI addresses in certificates is finished. Russ --Apple-Mail=_EA251D16-9357-445D-BC10-FBC5EEAD02F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

In addition, Alexey is interested in helping with an ACME = challenge for email certificates. Is anyone else interested in helping = to draft drafting?

Has there been anything about this on the list? =  Anyway, I=E2=80=99d be happy to help with = that.

I=E2=80=99m = interested in that as well, especially after the LAMPS document on EAI = addresses in certificates is finished.

Russ

= --Apple-Mail=_EA251D16-9357-445D-BC10-FBC5EEAD02F5-- From nobody Wed May 10 10:46:03 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 BDC5712DDD2 for ; Wed, 10 May 2017 10:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neustar.biz 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 VFx29rSkTR5h for ; Wed, 10 May 2017 10:45:59 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0a-0018ba01.pphosted.com [67.231.149.94]) (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 947B4129C1E for ; Wed, 10 May 2017 10:45:59 -0700 (PDT) Received: from pps.filterd (m0078666.ppops.net [127.0.0.1]) by mx0a-0018ba01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v4AHj7aI007776; Wed, 10 May 2017 13:45:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; h=from : to : subject : date : message-id : content-type : mime-version; s=neustar-biz; bh=61yNMMvsXCc09QB6yJpgn6q54sCEhgUF0TFsidc/vnU=; b=bxZWhpvOhrI6Tu7DsebPfTczRDbByUEMcax2t2tNgqGmmgmE3JmcuESgxkcn2ubaPOLg WkLiD9Ww9NMV2hR7zlSjYsVCWZQQNcSP2epi5ZU+t1uefvcOFreHXtNv61SzseKwE5Dm JXmk8HyiCpIoV4nMjqd3vRM/AEJ/UBRYPDy7ui78Eae2ODGq6xbJmORFR4KAmER6P7k6 XJRU1gXacUO8RwwemzGlL0ZtwmWf0kuBZ26D3D8ynG4njxSdyH+ZIv9MvFMqVWdW7eqI hwup43HsWKIJZJjPPB2oA39OsZDv34fMpnVxJVLwxR93DTlIJIV9wIIzD+v76hwIunQg kA== Received: from stntexhc11.cis.neustar.com ([156.154.17.216]) by mx0a-0018ba01.pphosted.com with ESMTP id 2a9akr7yvm-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 10 May 2017 13:45:56 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.33]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Wed, 10 May 2017 13:45:55 -0400 From: "Peterson, Jon" To: "Salz, Rich" , ACME WG Thread-Topic: [Acme] ACME interm meeting poll Thread-Index: AQHSybVFtJISGs1HQFePQCpVZ1P8Fw== Date: Wed, 10 May 2017 17:45:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.234] Content-Type: multipart/alternative; boundary="_000_D538C03D1D9985jonpetersonneustarbiz_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-05-10_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705100121 Archived-At: Subject: Re: [Acme] ACME interm meeting poll X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 May 2017 17:46:02 -0000 --_000_D538C03D1D9985jonpetersonneustarbiz_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable To the degree that barnes-acme-service-provider-00 belongs here, probably p= eterson-acme-telephone does as well. I mean, certs in STIR kind of have two= special ways of identifying their scope, and these two drafts are reflecti= ons of those two ways. Anyway, happy to discuss in the interim/call. Jon Peterson Neustar, Inc. From: Acme > on behalf = of "Salz, Rich" > Date: Tuesday, May 9, 2017 at 4:28 PM To: ACME WG > Subject: [Acme] ACME interm meeting poll We are trying to decide if we should meet in Prague. To help make the deci= sion, we are holding a Doodle poll for a one-hour virtual interim. Please = go here and vote: http://doodle.com/poll/u56c5xwr7nb23wqe The main ACME draft is essentially done, and should enter a second WGLC soo= n. That alone would not justify a meeting. In the early message thread that was labeled =93Futures=94 the following po= ssible work items came up: Hugo=92s CAA draft (already adopted, short, might be ready = for WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01 The following drafts are possible calls for adoption: Yaron Sheffer et al draft on STAR -- https://tools.ietf.org= /html/draft-sheffer-acme-star-lurk-00 Mary Barnes on an ACME challenge for ATIS/SIP -- https://to= ols.ietf.org/html/draft-barnes-acme-service-provider-00 Roland Shoemaker on an ACME challenge for validating IP add= resses -- https://tools.ietf.org/html/draft-shoemaker-acme-ip-00 In addition, Alexey is interested in helping with an ACME challenge for ema= il certificates. Is anyone else interested in helping to draft drafting? We would like to know if people are interested in adopting, advancing, work= ing-on these drafts within the ACME WG. And if anyone will commit to workin= g on any of them. If so, then we will discuss them in Prague, and have a r= e-chartering discussion to cover this new work. Please see the Doodle poll and mark your availability. For the good of the order, /r$ --_000_D538C03D1D9985jonpetersonneustarbiz_ Content-Type: text/html; charset="Windows-1252" Content-ID: <433217B7B3E360419A6732833C4163FF@neustar.biz> Content-Transfer-Encoding: quoted-printable

To the degree that barnes-acme-service-provider-00 belongs here, proba= bly peterson-acme-telephone does as well. I mean, certs in STIR kind of hav= e two special ways of identifying their scope, and these two drafts are ref= lections of those two ways.  Anyway, happy to discuss in the interim/call.

Jon Peterson
Neustar, Inc.

From: Acme <acme-bounces@ietf.org> on behalf of "Salz,= Rich" <rsalz@akamai.com>= ;
Date: Tuesday, May 9, 2017 at 4:28 = PM
To: ACME WG <acme@ietf.org>
Subject: [Acme] ACME interm meeting= poll

We are trying to decide if we should meet in Prague.=   To help make the decision, we are holding a Doodle poll for a one-ho= ur virtual interim.  Please go here and vote:

http://doodle.com/poll/u56c5xwr7nb23= wqe

 

The main ACME draft is essentially done, and should = enter a second WGLC soon.  That alone would not justify a meeting.

 

In the early message thread that was labeled =93Futu= res=94 the following possible work items came up:

        &nbs= p;       Hugo=92s CAA draft (already adopted,= short, might be ready for WGLC) -- https://tool= s.ietf.org/html/draft-ietf-acme-caa-01

 

The following drafts are possible calls for adoption= :

        &nbs= p;       Yaron Sheffer et al draft on STAR --= https://tools.ietf.org/html/draft-sheffer-acme-star-lurk-00

        &nbs= p;       Mary Barnes on an ACME challenge for= ATIS/SIP -- https://tools.ietf.org/html/draft-barnes-acme-service-provider-00

        &nbs= p;       Roland Shoemaker on an ACME challeng= e for validating IP addresses -- https://= tools.ietf.org/html/draft-shoemaker-acme-ip-00

 

In addition, Alexey is interested in helping with an= ACME challenge for email certificates. Is anyone else interested in helpin= g to draft drafting?

 

We would like to know if people are interested in ad= opting, advancing, working-on these drafts within the ACME WG. And if anyon= e will commit to working on any of them.  If so, then we will discuss = them in Prague, and have a re-chartering discussion to cover this new work.

 

Please see the Doodle poll and mark your availabilit= y.

 

For the good of the order,

        &nbs= p;       /r$

 

 --_000_D538C03D1D9985jonpetersonneustarbiz_-- From nobody Wed May 10 20:00: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 AA94612DFE0 for ; Wed, 10 May 2017 20:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.712 X-Spam-Level: X-Spam-Status: No, score=-2.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=onevmw.onmicrosoft.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 VbV89Pd9NAEc for ; Wed, 10 May 2017 20:00:33 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0044.outbound.protection.outlook.com [104.47.40.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF2671293E9 for ; Wed, 10 May 2017 20:00:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gn/5y7lLYrifIHTZs1DrkxpqYrSZSkdrbDepwVxJz6s=; b=XyBcm3SSSjAd/ibiw4tdfk6KHjsnS9vZGtqbgJKjWkcS0xmKQ1HdnsDL1LYmgbBvMXwVvhxkKR0OnakyrmFZFBP763xFFGRLJ2WT93zJencH9OR6uhCZ31ZqMmjEpK0V7ByNs5ORNid20Wc7ZNBQARaT3k7kOfBCqN0X9gzuCs8= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3046.namprd05.prod.outlook.com (10.172.155.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Thu, 11 May 2017 03:00:30 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.1084.017; Thu, 11 May 2017 03:00:30 +0000 From: Zach Shepherd To: Logan Widick CC: "acme@ietf.org" Thread-Topic: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token Thread-Index: AQHSyEjYBSJMcNvrJ0+rg/Q+1mjkwKHrF6MAgAEPxHmAAkzXiA== Date: Thu, 11 May 2017 03:00:30 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=vmware.com; x-originating-ip: [25.173.177.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR05MB3046; 7:fbGjfQr5SRTGw/xuh/ylmspoKA1Jlyls8LAXI4IAvbbHeCGOTCBGfaLUGduyymiIuys4ABlo7umvMbg36+EWs0yifTuevs+xRu9h9ozF5NT0YRsSa6OT+9r3QA0tvKtyfV543yTHDIUkPf/4uSMkP1CopOKGgZR54GfuOplTdidHcjDAq+UUdqNsYnQrXl3TnV20WJaWn/h+4Hi5HhJ862XOzNTkYaV2Zk699ezRL28GiQsPSJbRTNsIVwHPKBM9pxYMR6hn8NFx0O57NNGLqDkCVjQv6RkjkKBAmuv1n/6u6TJMLkKzQc04k53PgzWy2XJqiDUXtB9XkC2IVL7hpw==; 20:y1Z3RDlKF7fY9wxzK6j46RLwNhsXdDkcJY7ev2xyUJzA1iAvZMen1MJKdPpQmmsciTpNQR+G3tQEt10bX2T/nzG8rCAN7smLsSA5YQ6vyRJsWNy4YiHvK8s6DHTUhYwWFq1E6blfBKMYBOG26eStMJnErQcm4v/UJZ4nDSVnJMg= x-ms-office365-filtering-correlation-id: 64a69124-cd3f-413f-a3a3-08d49819e23a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR05MB3046; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(61668805478150)(158342451672863)(10436049006162)(166708455590820)(192374486261705)(265273979862326); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(6072148); SRVR:CY4PR05MB3046; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3046; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39410400002)(39400400002)(39850400002)(39450400003)(39840400002)(24454002)(51444003)(377454003)(76176999)(54356999)(81166006)(66066001)(50986999)(5660300001)(2900100001)(33656002)(6916009)(7696004)(38730400002)(53376002)(8676002)(6306002)(53936002)(3660700001)(3280700002)(189998001)(236005)(99286003)(54896002)(606005)(122556002)(9686003)(6246003)(2950100002)(6436002)(19627405001)(110136004)(6506006)(229853002)(7906003)(39060400002)(4326008)(7736002)(6116002)(2906002)(77096006)(102836003)(3846002)(86362001)(53546009)(25786009)(478600001)(8936002)(74316002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3046; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB30453064B16D99820574F839C0ED0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2017 03:00:30.0108 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3046 Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 03:00:37 -0000 --_000_CY4PR05MB30453064B16D99820574F839C0ED0CY4PR05MB3045namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable To make things more concrete, here is a PR that introduces a new version of= the HTTP challenge: https://github.com/ietf-wg-acme/acme/pull/312 Regards, Zach ________________________________ From: Zach Shepherd Sent: Tuesday, May 9, 2017 9:13:37 AM To: Logan Widick Cc: acme@ietf.org Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of= entropy for the http-01 token I like the "hashed token for requests" pattern, assuming that the [unhashed= ] token would be present as a part of the response. I think the drawback of hash algorithm compromise can be mitigated by the c= hoice of hash algorithm; compromise of SHA-256 would already have substanti= al impact on ACME such that the net impact of further use of it would be re= latively insignificant. Regards, Zach ________________________________ From: Logan Widick Sent: Monday, May 8, 2017 4:37 PM To: Zach Shepherd Cc: acme@ietf.org Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of= entropy for the http-01 token I think that this may require revising the challenge. Would a "two-token" challenge pattern help mitigate the risk of stateless c= lients for the HTTP challenge and for future challenges that may otherwise = have similar issues? For example, assume that the challenge has two tokens,= which I will call "tokenA" and "tokenB", TokenA would be used to make requ= est parameters, and tokenB would be used only for responses. The key author= ization would include both tokens to ensure that the tokens were received c= orrectly. For example, the key authorization could be tokenA || tokenB || a= ccount key thumbprint. The ACME server could perform HTTP validation by sen= ding a request to "http://example.com/.well-known/acme-challenge/tokenA" and get back the revised key author= ization (or anything else with tokenB in it). Since tokenB was not sent wit= h the request, the server would have to have known tokenB somehow. One poss= ible drawback of this approach is the increased storage required for the ex= tra token. An alternate approach may be to require that a request parameter sent durin= g validation for any type of challenge (now existing or later developed) mu= st include a hash of something containing the challenge token rather than s= omething containing the token itself. For example, the HTTP challenge could= be revised by having the validation go to "http://example.com/.well-known/acme-challenge/SHA256_hash_of_the= _token" instead of "http://example.com/.well-known/acme-challenge/token". The TLS-SNI challenge uses this "h= ashed token for requests" pattern already. In the TLS-SNI challenge, SAN A = (the one requested in the TLS SNI extension during challenge verification) = is constructed by hashing the token, while the response is constructed with= the (hash of) the key authorization. One possible drawback of having chall= enges to use this "hashed token for requests" pattern is that hashing would= become such an integral part of the challenge process that if a hash algor= ithm is compromised, new versions of all challenges will need to be release= d. In both ideas above, I suggested applying the same general "pattern" (of wh= at should be used for making validation requests and what should be used fo= r making validation responses) to all challenges. Although this statelessne= ss issue solely affects the HTTP challenge at this time, adding text in the= specification (probably in a "security considerations" subsection) to requ= ire or recommend all challenges to use the same pattern (or choose from a l= ist of multiple approved patterns) would prevent future challenges from hav= ing similar issues. On a different note, would requiring the provisioned challenge resource (in= this case, the response to the "http://example.com/.well-known/acme-challenge/some_token_or_hash_of_the_tok= en" request) to be digitally signed by the account JWK and/or the CSR key (= most likely by having the response be a JWS containing the key authorizatio= n rather than the key authorization itself) improve security, worsen securi= ty, or have no impact on security? If it would improve security, would this= be feasible for each type of challenge? Sincerely, Logan Widick On Mon, May 8, 2017 at 5:21 PM, Zach Shepherd > wrote: The following feedback is based on cd7c5e9 (current HEAD of master). Section 8.3 states that the token value for HTTP validation "MUST have at l= east 128 bits of entropy." Section 11.3 explains that one goal of this is that "the entropy requiremen= t prevents ACME clients from implementing a =93naive=94 validation server t= hat automatically replies to challenges without participating in the creati= on of the intial authorization request." However, because of the way the token is used in the validation process, as= a part of the request, this goal is not met. It is possible to configure a= webserver to respond to all requests under .well-known/acme-challenge with= the ASCII representation of the key authorization. (See, e.g., https://git= hub.com/Neilpang/acme.sh/wiki/Stateless-Mode.) Essentially, the server informs the client of the token during the validati= on process, removing any need for the client to have known it. If this is acceptable, the entropy requirement should be removed. If this i= s unacceptable, the challenge and validation should be revised. Regards, Zach Shepherd _______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme --_000_CY4PR05MB30453064B16D99820574F839C0ED0CY4PR05MB3045namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

To make things more concrete, here is a PR that introduces a new version= of the HTTP challenge: https://github.com/ietf-wg-acme/acme/pull/312


Regards,

Zach

From: Zach Shepherd
Sent: Tuesday, May 9, 2017 9:13:37 AM
To: Logan Widick
Cc: acme@ietf.org
Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 = bits of entropy for the http-01 token
 

I like the "hashed token for requests" pattern, assuming that = the [unhashed] token would be present as a part of the response.


I think the drawback of hash algorithm compromise can be mitigated by th= e choice of hash algorithm; compromise of SHA-256 would already have substa= ntial impact on ACME such that the net impact of further use of it would be= relatively insignificant.


Regards,

Zach


From: Logan Widick <lo= gan.widick@gmail.com>
Sent: Monday, May 8, 2017 4:37 PM
To: Zach Shepherd
Cc: acme@ietf.org
Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 = bits of entropy for the http-01 token
 
I think that this may require revising the challenge. = ;

Would a "two-token" challenge pattern help mitigate the risk= of stateless clients for the HTTP challenge and for future challenges that= may otherwise have similar issues? For example, assume that the challenge = has two tokens, which I will call "tokenA" and "tokenB", TokenA would be used to make request parameters, a= nd tokenB would be used only for responses. The key authorization would inc= lude both tokens to ensure that the tokens were received correctly. For exa= mple, the key authorization could be tokenA || tokenB || account key thumbprint. The ACME server could perform HTTP va= lidation by sending a request to "http://example.com/.well-know= n/acme-challenge/tokenA" and get back the revised key authorization (or anything else with tokenB i= n it). Since tokenB was not sent with the request, the server would have to= have known tokenB somehow. One possible drawback of this approach is the i= ncreased storage required for the extra token. 

An alternate approach may be to require that a request parameter sent = during validation for any type of challenge (now existing or later develope= d) must include a hash of something containing the challenge token rather t= han something containing the token itself. For example, the HTTP challenge could be revised by having the val= idation go to "http://example.com/.well-known/acme-challe= nge/SHA256_hash_of_the_token" instead of "http://example.com/.well-known/acme-challenge/= token". The TLS-SNI challenge uses this "hashed token for requests" patt= ern already. In the TLS-SNI challenge, SAN A (the one requested in the TLS = SNI extension during challenge verification) is constructed by hashing the = token, while the response is constructed with the (hash of) the key authorization. One possible drawback of having chall= enges to use this "hashed token for requests" pattern is that has= hing would become such an integral part of the challenge process that if a = hash algorithm is compromised, new versions of all challenges will need to be released. 

In both ideas above, I suggested applying the same general "patte= rn" (of what should be used for making validation requests and what sh= ould be used for making validation responses) to all challenges. Although t= his statelessness issue solely affects the HTTP challenge at this time, adding text in the specification (probably in= a "security considerations" subsection) to require or recommend = all challenges to use the same pattern (or choose from a list of multiple a= pproved patterns) would prevent future challenges from having similar issues. 


Sincerely, 
Logan Widick

On Mon, May 8, 2017 at 5:21 PM, Zach Shepherd <shepherdz@vmw= are.com> wrote:

The following feedback is based on cd7c5e9 (current HEAD of master).
Section 8.3 states that the token value for HTTP validation "MUST have= at least 128 bits of entropy."

Section 11.3 explains that one goal of this is that "the entropy requi= rement prevents ACME clients from implementing a =93naive=94 validation ser= ver that automatically replies to challenges without participating in the c= reation of the intial authorization request."

However, because of the way the token is used in the validation process, as= a part of the request, this goal is not met. It is possible to configure a= webserver to respond to all requests under .well-known/acme-challenge with= the ASCII representation of the key authorization. (See, e.g., https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.)

Essentially, the server informs the client of the token during the validati= on process, removing any need for the client to have known it.

If this is acceptable, the entropy requirement should be removed. If this i= s unacceptable, the challenge and validation should be revised.

Regards,
Zach Shepherd


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mail= man/listinfo/acme


--_000_CY4PR05MB30453064B16D99820574F839C0ED0CY4PR05MB3045namp_-- From nobody Wed May 10 20:12:45 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 C7C591293E9 for ; Wed, 10 May 2017 20:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 pVlDdJrAYUzV for ; Wed, 10 May 2017 20:12:41 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 8F3DB1286B1 for ; Wed, 10 May 2017 20:12:41 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id y201so12403746qka.0 for ; Wed, 10 May 2017 20:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5qSYsA5E6rxPDN86TC8MdZJKIgNCbEasKfmrNYNhLlI=; b=jP+RV83r6O/7cfGYwCXkAoEoX95IuqXtMsuUmzDMkBM9EZ6GUDhJRvz407d43345md 4yaBHuLwkMn+lnPIyAYig8I0Bf3HSOKUlFiXYOz0/JTozxrtTKfgTWX8EOLyFKOFxBov Oz2lrKkMqjyYssWoXZECoUibZuIFRhj02aL70T2RDlFYXD7hJu9budtIoHDiMJM/Wfm+ VHDMztSCLUYYKpRGg9LX+JPl6uPlO26Ue6/zk1FFdMmwyx70y+2UZguuHYJ2BKnZAY+s 64dX2RimDt1Gpf56wWN4EEUq+jjbvcfyz4d7q0y7vJRNYYF+6fP1MWa3+ACftNegEPtw GY6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5qSYsA5E6rxPDN86TC8MdZJKIgNCbEasKfmrNYNhLlI=; b=aSMqKMfF0zKq4KRFHI0Mf4jT1JgpUsE7LqjKTjqNGg7r0DtDnfJ9+kGVs/OvuINtwb GQwn4BG10QyT+DTbfzwSYnpGb4Y1FP0Ryrwmb4T+rRWhmuE5HyGzifwL0h/5P1T12CWA XkPRrkvPtjGZo61mDDes/ENttEpKu3Z41qOyso4qxEVJRhb3Xl6p+fGB4lJEKJh4eXsO u4p9aJw4wAg7EbZLmXsJAbdXE1HF+g2bcW5tckYOGpEx9kExyc8Ck5vXeLCqCESWdqB8 bAukLU3RKxx2HR3UIqA6CDvCXq3vqzEGXLm2SfTb1CJ+awZzXp/uaj78or/g3fKb4/Rf nGzg== X-Gm-Message-State: AODbwcCNKQ+JBHBOs4rVA3PbIGxfOSAjHF/gYYIi/o9ZziTowki8RPaG fzTKlf+zianwZ3tYbPPxpSDUEltTaw== X-Received: by 10.55.167.6 with SMTP id q6mr8167744qke.134.1494472360780; Wed, 10 May 2017 20:12:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.52.194 with HTTP; Wed, 10 May 2017 20:12:40 -0700 (PDT) In-Reply-To: References: From: Jehiah Czebotar Date: Wed, 10 May 2017 23:12:40 -0400 Message-ID: To: Zach Shepherd Cc: Logan Widick , "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a114fca6830ea26054f36f68d Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 03:12:45 -0000 --001a114fca6830ea26054f36f68d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm not convinced of a need to change the http-01 validation method here. > However, because of the way the token is used in the validation process, as a part of the request, this goal is not met. It is possible to configure a webserver to respond to all requests under .well-known/acme-challenge with the ASCII representation of the key authorization. (See, e.g., https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.) As Ilari addressed, this assumption isn't correct. The token (provided in the request) alone isn't sufficient to implement a stateless response for http-01. -- Jehiah On Wed, May 10, 2017 at 11:00 PM, Zach Shepherd wrote: > To make things more concrete, here is a PR that introduces a new version > of the HTTP challenge: https://github.com/ietf-wg-acme/acme/pull/312 > > > Regards, > > Zach > ------------------------------ > *From:* Zach Shepherd > *Sent:* Tuesday, May 9, 2017 9:13:37 AM > *To:* Logan Widick > > *Cc:* acme@ietf.org > *Subject:* Re: [Acme] Bypassing the intended purpose of requiring 128 > bits of entropy for the http-01 token > > > I like the "hashed token for requests" pattern, assuming that the > [unhashed] token would be present as a part of the response. > > > I think the drawback of hash algorithm compromise can be mitigated by the > choice of hash algorithm; compromise of SHA-256 would already have > substantial impact on ACME such that the net impact of further use of it > would be relatively insignificant. > > > Regards, > > Zach > > ------------------------------ > *From:* Logan Widick > *Sent:* Monday, May 8, 2017 4:37 PM > *To:* Zach Shepherd > *Cc:* acme@ietf.org > *Subject:* Re: [Acme] Bypassing the intended purpose of requiring 128 > bits of entropy for the http-01 token > > I think that this may require revising the challenge. > > Would a "two-token" challenge pattern help mitigate the risk of stateless > clients for the HTTP challenge and for future challenges that may otherwi= se > have similar issues? For example, assume that the challenge has two token= s, > which I will call "tokenA" and "tokenB", TokenA would be used to make > request parameters, and tokenB would be used only for responses. The key > authorization would include both tokens to ensure that the tokens were > received correctly. For example, the key authorization could be tokenA || > tokenB || account key thumbprint. The ACME server could perform HTTP > validation by sending a request to "http://example.com/.well-know > n/acme-challenge/tokenA" > and get back the revised key authorization (or anything else with tokenB = in > it). Since tokenB was not sent with the request, the server would have to > have known tokenB somehow. One possible drawback of this approach is the > increased storage required for the extra token. > > An alternate approach may be to require that a request parameter sent > during validation for any type of challenge (now existing or later > developed) must include a hash of something containing the challenge toke= n > rather than something containing the token itself. For example, the HTTP > challenge could be revised by having the validation go to " > http://example.com/.well-know > > n/acme-challenge/SHA256_hash_of_the_token" instead of " > http://example.com/.well-know > n/acme-challenge/token". > The TLS-SNI challenge uses this "hashed token for requests" pattern > already. In the TLS-SNI challenge, SAN A (the one requested in the TLS SN= I > extension during challenge verification) is constructed by hashing the > token, while the response is constructed with the (hash of) the key > authorization. One possible drawback of having challenges to use this > "hashed token for requests" pattern is that hashing would become such an > integral part of the challenge process that if a hash algorithm is > compromised, new versions of all challenges will need to be released. > > In both ideas above, I suggested applying the same general "pattern" (of > what should be used for making validation requests and what should be use= d > for making validation responses) to all challenges. Although this > statelessness issue solely affects the HTTP challenge at this time, addin= g > text in the specification (probably in a "security considerations" > subsection) to require or recommend all challenges to use the same patter= n > (or choose from a list of multiple approved patterns) would prevent futur= e > challenges from having similar issues. > > On a different note, would requiring the provisioned challenge resource > (in this case, the response to the "http://example.com/.well-know > > n/acme-challenge/some_token_or_hash_of_the_token" request) to be > digitally signed by the account JWK and/or the CSR key (most likely by > having the response be a JWS containing the key authorization rather than > the key authorization itself) improve security, worsen security, or have = no > impact on security? If it would improve security, would this be feasible > for each type of challenge? > > Sincerely, > Logan Widick > > On Mon, May 8, 2017 at 5:21 PM, Zach Shepherd > wrote: > >> The following feedback is based on cd7c5e9 (current HEAD of master). >> >> Section 8.3 states that the token value for HTTP validation "MUST have a= t >> least 128 bits of entropy." >> >> Section 11.3 explains that one goal of this is that "the entropy >> requirement prevents ACME clients from implementing a =E2=80=9Cnaive=E2= =80=9D validation >> server that automatically replies to challenges without participating in >> the creation of the intial authorization request." >> >> However, because of the way the token is used in the validation process, >> as a part of the request, this goal is not met. It is possible to config= ure >> a webserver to respond to all requests under .well-known/acme-challenge >> with the ASCII representation of the key authorization. (See, e.g., >> https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode >> >> .) >> >> Essentially, the server informs the client of the token during the >> validation process, removing any need for the client to have known it. >> >> If this is acceptable, the entropy requirement should be removed. If thi= s >> is unacceptable, the challenge and validation should be revised. >> >> Regards, >> Zach Shepherd >> >> >> _______________________________________________ >> 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 > > --=20 Jehiah --001a114fca6830ea26054f36f68d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not convinced of a need to change the http-01 vali= dation method here.

> However, because of the way the token is us= ed in the validation process, as a part of the request, this goal is not me= t. It is possible to configure a webserver to respond to all requests under= .well-known/acme-challenge with the ASCII representation of the key author= ization. (See, e.g., https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.)=

As Ilari addressed, this assumption isn't correct. The token (p= rovided in the request) alone isn't sufficient to implement a stateless= response for http-01.

--
Jehiah

On Wed, May 10, 2017 at 11:= 00 PM, Zach Shepherd <shepherdz@vmware.com> wrote:

To make things more concrete, here is a PR that introduces a new version= of the HTTP challenge: https://github.com/ietf-wg-acme/acme/pull/312


Regards,

Zach

From: = Zach Shepherd
Sent: Tuesday, May 9, 2017 9:13:37 AM
To: Logan Widick

Cc: acme@ietf.org=
Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 = bits of entropy for the http-01 token
=C2=A0

I like the "hashed token for requests" pattern, assuming that = the [unhashed] token would be present as a part of=C2=A0the response.


I think the drawback of hash algorithm compromise can be mitigated by th= e choice of hash algorithm; compromise of SHA-256 would already have substa= ntial impact on ACME such that the net impact of further use of it would be= relatively insignificant.


Regards,

Zach


From: = Logan Widick <logan.widick@gmail.com>
Sent: Monday, May 8, 2017 4:37 PM
To: Zach Shepherd
Cc: acme@ietf.org=
Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 = bits of entropy for the http-01 token
=C2=A0
I think that this may require revising the challenge.=C2= =A0

Would a "two-token" challenge pattern help mitigate the risk= of stateless clients for the HTTP challenge and for future challenges that= may otherwise have similar issues? For example, assume that the challenge = has two tokens, which I will call "tokenA" and "tokenB", TokenA would be used to make request parameters, a= nd tokenB would be used only for responses. The key authorization would inc= lude both tokens to ensure that the tokens were received correctly. For exa= mple, the key authorization could be tokenA || tokenB || account key thumbprint. The ACME server could perform HTTP va= lidation by sending a request to "http://example.= com/.well-known/acme-challenge/tokenA" and get back the revised key authorization (or anything else with tokenB i= n it). Since tokenB was not sent with the request, the server would have to= have known tokenB somehow. One possible drawback of this approach is the i= ncreased storage required for the extra token.=C2=A0

An alternate approach may be to require that a request parameter sent = during validation for any type of challenge (now existing or later develope= d) must include a hash of something containing the challenge token rather t= han something containing the token itself. For example, the HTTP challenge could be revised by having the val= idation go to "http://example.com/.well-know= n/acme-challenge/SHA256_hash_of_the_token" instead of "http://example.com/.well-known/acme-challenge/token". The TLS-SNI challenge uses this "hashed token for requests" patt= ern already. In the TLS-SNI challenge, SAN A (the one requested in the TLS = SNI extension during challenge verification) is constructed by hashing the = token, while the response is constructed with the (hash of) the key authorization. One possible drawback of having chall= enges to use this "hashed token for requests" pattern is that has= hing would become such an integral part of the challenge process that if a = hash algorithm is compromised, new versions of all challenges will need to be released.=C2=A0

In both ideas above, I suggested applying the same general "patte= rn" (of what should be used for making validation requests and what sh= ould be used for making validation responses) to all challenges. Although t= his statelessness issue solely affects the HTTP challenge at this time, adding text in the specification (probably in= a "security considerations" subsection) to require or recommend = all challenges to use the same pattern (or choose from a list of multiple a= pproved patterns) would prevent future challenges from having similar issues.=C2=A0

On a different note, would requiring the provisioned challenge resourc= e (in this case, the response to the "http://examp= le.com/.well-known/acme-challenge/some_token_or_hash_of_the_t= oken" request) to be digitally signed by the account JWK and/or the CSR key (mos= t likely by having the response be a JWS containing the key authorization r= ather than the key authorization itself) improve security, worsen security,= or have no impact on security? If it would improve security, would this be feasible for each type of chal= lenge?=C2=A0

Sincerely,=C2=A0
Logan Widick

On Mon, May 8, 2017 at 5:21 PM, Zach Shepherd <shepherdz@vmw= are.com> wrote:

The following feedback is based on cd7c5e9 (current HEAD of master).
Section 8.3 states that the token value for HTTP validation "MUST have= at least 128 bits of entropy."

Section 11.3 explains that one goal of this is that "the entropy requi= rement prevents ACME clients from implementing a =E2=80=9Cnaive=E2=80=9D va= lidation server that automatically replies to challenges without participat= ing in the creation of the intial authorization request."

However, because of the way the token is used in the validation process, as= a part of the request, this goal is not met. It is possible to configure a= webserver to respond to all requests under .well-known/acme-challenge with= the ASCII representation of the key authorization. (See, e.g., https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.)

Essentially, the server informs the client of the token during the validati= on process, removing any need for the client to have known it.

If this is acceptable, the entropy requirement should be removed. If this i= s unacceptable, the challenge and validation should be revised.

Regards,
Zach Shepherd


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mail= man/listinfo/acme



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




--
Jehiah
--001a114fca6830ea26054f36f68d-- From nobody Wed May 10 20:18:47 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 E9285128796 for ; Wed, 10 May 2017 20:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, 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 p7J10IOZ603w for ; Wed, 10 May 2017 20:18:43 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 9516B127286 for ; Wed, 10 May 2017 20:18:43 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id n4so7706326qte.2 for ; Wed, 10 May 2017 20:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o3WwoGwN3fbdyKA1OvM84R9fvec6weOWShI5P324gEE=; b=mVeOcfhYLQ37eEUfQ/jsVjmXRjDd25Zzz51x417TNAckkYw1XhN/7Wlvp3BvWEhSBM i0tWEhACLGzpoVpm/c+YeU2UJ9FM9fIMXQI0I8Zw44gGLpuM8yLg4F3cNXg0NQYDvMCC FgoR3YV9D+RIHpHfbU0vIPWGT95qxexrpPkv7WoahXRD8T2NSTg87AmXj1fCEqsPv99G iYiS6W3L3khR69w+WzZTujz5hkdcKbSOx/rOWweiLuBC4ZchzL5XSCav670idzf8u0zI 6GZYGl1GWxijmOisojG0sEz/Ds1JE3xvoT4PNtI9azxDhjR8Ri7P7CmYjWOIGS+U2v47 kcvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o3WwoGwN3fbdyKA1OvM84R9fvec6weOWShI5P324gEE=; b=CnQUIFfQPJ/XPNgRd9SHlZtXWZydCTNenZT+q2kB8YqlvHUbGwLY4exFBW6ErqGdpJ JnDyzhcRUIrW6Bh/0qSOW1z4Pysy/zDEFpBfJahSf1OFxBb/a7B24C6scwkHlFVY6dy8 STE7DBQCuEMyIs+PYVYynwwRYy2UTdnQlHw4xPzX9943yFkPGaY/yQm0hFqvPuEymLJS obX/9DIe/xi66G2Sjc534YYJmyXc0Y4kQTlYSfOEoxcOoRef66sp3FsTeeNBO0W6lqHU NSQbvTp4KE5Q144eVEWNPgfhqKyJVdBdjZXj1zEVCbjk6To3mD17j3z5XBist9O2yvue MI7Q== X-Gm-Message-State: AODbwcD6r4FdoXbsQ3CBWRfQUTKCW57tSEnd3th5tW6RMOtjx1UpIfqi 4uwO0xp4fWF3Op7l8y31jWEK5YYDHw== X-Received: by 10.200.38.76 with SMTP id v12mr1911569qtv.257.1494472722806; Wed, 10 May 2017 20:18:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.52.194 with HTTP; Wed, 10 May 2017 20:18:42 -0700 (PDT) In-Reply-To: References: From: Jehiah Czebotar Date: Wed, 10 May 2017 23:18:42 -0400 Message-ID: To: Zach Shepherd Cc: Logan Widick , "acme@ietf.org" Content-Type: multipart/alternative; boundary=001a11404c78c4fc55054f370b58 Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 03:18:46 -0000 --001a11404c78c4fc55054f370b58 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable ok nevermind, my brain is slowly working (sorry Zach); this is different from the problems in tls-sni-01 where you could respond with a stateless response to all requests from any account (which confused me at first as i thought you were reporting the same type of stateless issue). The issue here is you can provide a stateless response to all response for given account(s). I don't know if that's desirable but as it still requires some amount of authorization that seems like it might still be ok and at least isn't a security issue. --=20 Jehiah On Wed, May 10, 2017 at 11:12 PM, Jehiah Czebotar wrote: > I'm not convinced of a need to change the http-01 validation method here. > > > However, because of the way the token is used in the validation process= , > as a part of the request, this goal is not met. It is possible to configu= re > a webserver to respond to all requests under .well-known/acme-challenge > with the ASCII representation of the key authorization. (See, e.g., > https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.) > > As Ilari addressed, this assumption isn't correct. The token (provided in > the request) alone isn't sufficient to implement a stateless response for > http-01. > > -- > Jehiah > > On Wed, May 10, 2017 at 11:00 PM, Zach Shepherd > wrote: > >> To make things more concrete, here is a PR that introduces a new version >> of the HTTP challenge: https://github.com/ietf-wg-acme/acme/pull/312 >> >> >> Regards, >> >> Zach >> ------------------------------ >> *From:* Zach Shepherd >> *Sent:* Tuesday, May 9, 2017 9:13:37 AM >> *To:* Logan Widick >> >> *Cc:* acme@ietf.org >> *Subject:* Re: [Acme] Bypassing the intended purpose of requiring 128 >> bits of entropy for the http-01 token >> >> >> I like the "hashed token for requests" pattern, assuming that the >> [unhashed] token would be present as a part of the response. >> >> >> I think the drawback of hash algorithm compromise can be mitigated by th= e >> choice of hash algorithm; compromise of SHA-256 would already have >> substantial impact on ACME such that the net impact of further use of it >> would be relatively insignificant. >> >> >> Regards, >> >> Zach >> >> ------------------------------ >> *From:* Logan Widick >> *Sent:* Monday, May 8, 2017 4:37 PM >> *To:* Zach Shepherd >> *Cc:* acme@ietf.org >> *Subject:* Re: [Acme] Bypassing the intended purpose of requiring 128 >> bits of entropy for the http-01 token >> >> I think that this may require revising the challenge. >> >> Would a "two-token" challenge pattern help mitigate the risk of stateles= s >> clients for the HTTP challenge and for future challenges that may otherw= ise >> have similar issues? For example, assume that the challenge has two toke= ns, >> which I will call "tokenA" and "tokenB", TokenA would be used to make >> request parameters, and tokenB would be used only for responses. The key >> authorization would include both tokens to ensure that the tokens were >> received correctly. For example, the key authorization could be tokenA |= | >> tokenB || account key thumbprint. The ACME server could perform HTTP >> validation by sending a request to "http://example.com/.well-know >> n/acme-challenge/tokenA" >> and get back the revised key authorization (or anything else with tokenB= in >> it). Since tokenB was not sent with the request, the server would have t= o >> have known tokenB somehow. One possible drawback of this approach is the >> increased storage required for the extra token. >> >> An alternate approach may be to require that a request parameter sent >> during validation for any type of challenge (now existing or later >> developed) must include a hash of something containing the challenge tok= en >> rather than something containing the token itself. For example, the HTTP >> challenge could be revised by having the validation go to " >> http://example.com/.well-know >> >> n/acme-challenge/SHA256_hash_of_the_token" instead of " >> http://example.com/.well-know >> n/acme-challenge/token". >> The TLS-SNI challenge uses this "hashed token for requests" pattern >> already. In the TLS-SNI challenge, SAN A (the one requested in the TLS S= NI >> extension during challenge verification) is constructed by hashing the >> token, while the response is constructed with the (hash of) the key >> authorization. One possible drawback of having challenges to use this >> "hashed token for requests" pattern is that hashing would become such an >> integral part of the challenge process that if a hash algorithm is >> compromised, new versions of all challenges will need to be released. >> >> In both ideas above, I suggested applying the same general "pattern" (of >> what should be used for making validation requests and what should be us= ed >> for making validation responses) to all challenges. Although this >> statelessness issue solely affects the HTTP challenge at this time, addi= ng >> text in the specification (probably in a "security considerations" >> subsection) to require or recommend all challenges to use the same patte= rn >> (or choose from a list of multiple approved patterns) would prevent futu= re >> challenges from having similar issues. >> >> On a different note, would requiring the provisioned challenge resource >> (in this case, the response to the "http://example.com/.well-know >> >> n/acme-challenge/some_token_or_hash_of_the_token" request) to be >> digitally signed by the account JWK and/or the CSR key (most likely by >> having the response be a JWS containing the key authorization rather tha= n >> the key authorization itself) improve security, worsen security, or have= no >> impact on security? If it would improve security, would this be feasible >> for each type of challenge? >> >> Sincerely, >> Logan Widick >> >> On Mon, May 8, 2017 at 5:21 PM, Zach Shepherd >> wrote: >> >>> The following feedback is based on cd7c5e9 (current HEAD of master). >>> >>> Section 8.3 states that the token value for HTTP validation "MUST have >>> at least 128 bits of entropy." >>> >>> Section 11.3 explains that one goal of this is that "the entropy >>> requirement prevents ACME clients from implementing a =E2=80=9Cnaive=E2= =80=9D validation >>> server that automatically replies to challenges without participating i= n >>> the creation of the intial authorization request." >>> >>> However, because of the way the token is used in the validation process= , >>> as a part of the request, this goal is not met. It is possible to confi= gure >>> a webserver to respond to all requests under .well-known/acme-challenge >>> with the ASCII representation of the key authorization. (See, e.g., >>> https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode >>> >>> .) >>> >>> Essentially, the server informs the client of the token during the >>> validation process, removing any need for the client to have known it. >>> >>> If this is acceptable, the entropy requirement should be removed. If >>> this is unacceptable, the challenge and validation should be revised. >>> >>> Regards, >>> Zach Shepherd >>> >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > Jehiah > --001a11404c78c4fc55054f370b58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
ok nevermind, my brain is slowly working (sorry Zach); thi= s is different from the problems in tls-sni-01 where you could respond with= a stateless response to all requests from any account (which confused me a= t first as i thought you were reporting the same type of stateless issue).<= div>
The issue here is you can provide a stateless response t= o all response for given account(s). I don't know if that's desirab= le but as it still requires some amount of authorization that seems like it= might still be ok and at least isn't a security issue.

<= /div>
--=C2=A0
Jehiah

On Wed, May 10, 2017 = at 11:12 PM, Jehiah Czebotar <jehiah@gmail.com> wrote:
I'm not= convinced of a need to change the http-01 validation method here.

> However, because of the way the token is used in= the validation process, as a part of the request, this goal is not met. It= is possible to configure a webserver to respond to all requests under .wel= l-known/acme-challenge with the ASCII representation of the key authorizati= on. (See, e.g., https://github.com/Neilpang/acme.sh/wiki/St= ateless-Mode.)

As Ilari addressed, this assumption isn= 9;t correct. The token (provided in the request) alone isn't sufficient= to implement a stateless response for http-01.

--
=
Jehiah

=
On Wed, May 10, 2017 at 11:00 PM, Zach Shepherd = <shepherdz@vmware.com> wrote:

To make things more concrete, here is a PR that introduces a new version= of the HTTP challenge: https://github.com/ietf-wg-acme/acme/pull/312


Regards,

Zach

From: Zach Shepherd
Sent: Tuesday, May 9, 2017 9:13:37 AM
To: Logan Widick
<= br> Cc: acme@ietf.org=
Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 = bits of entropy for the http-01 token
=C2=A0

I like the "hashed token for requests" pattern, assuming that = the [unhashed] token would be present as a part of=C2=A0the response.


I think the drawback of hash algorithm compromise can be mitigated by th= e choice of hash algorithm; compromise of SHA-256 would already have substa= ntial impact on ACME such that the net impact of further use of it would be= relatively insignificant.


Regards,

Zach


From: Logan Widick <logan.widick@gmail.com>
Sent: Monday, May 8, 2017 4:37 PM
To: Zach Shepherd
Cc: acme@ietf.org=
Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 = bits of entropy for the http-01 token
=C2=A0
I think that this may require revising the challenge.=C2= =A0

Would a "two-token" challenge pattern help mitigate the risk= of stateless clients for the HTTP challenge and for future challenges that= may otherwise have similar issues? For example, assume that the challenge = has two tokens, which I will call "tokenA" and "tokenB", TokenA would be used to make request parameters, a= nd tokenB would be used only for responses. The key authorization would inc= lude both tokens to ensure that the tokens were received correctly. For exa= mple, the key authorization could be tokenA || tokenB || account key thumbprint. The ACME server could perform HTTP va= lidation by sending a request to "http://example.= com/.well-known/acme-challenge/tokenA" and get back the revised key authorization (or anything else with tokenB i= n it). Since tokenB was not sent with the request, the server would have to= have known tokenB somehow. One possible drawback of this approach is the i= ncreased storage required for the extra token.=C2=A0

An alternate approach may be to require that a request parameter sent = during validation for any type of challenge (now existing or later develope= d) must include a hash of something containing the challenge token rather t= han something containing the token itself. For example, the HTTP challenge could be revised by having the val= idation go to "http://example.com/.well-know= n/acme-challenge/SHA256_hash_of_the_token" instead of "http://example.com/.well-known/acme-challenge/token". The TLS-SNI challenge uses this "hashed token for requests" patt= ern already. In the TLS-SNI challenge, SAN A (the one requested in the TLS = SNI extension during challenge verification) is constructed by hashing the = token, while the response is constructed with the (hash of) the key authorization. One possible drawback of having chall= enges to use this "hashed token for requests" pattern is that has= hing would become such an integral part of the challenge process that if a = hash algorithm is compromised, new versions of all challenges will need to be released.=C2=A0

In both ideas above, I suggested applying the same general "patte= rn" (of what should be used for making validation requests and what sh= ould be used for making validation responses) to all challenges. Although t= his statelessness issue solely affects the HTTP challenge at this time, adding text in the specification (probably in= a "security considerations" subsection) to require or recommend = all challenges to use the same pattern (or choose from a list of multiple a= pproved patterns) would prevent future challenges from having similar issues.=C2=A0

On a different note, would requiring the provisioned challenge resourc= e (in this case, the response to the "http://examp= le.com/.well-known/acme-challenge/some_token_or_hash_of_the_t= oken" request) to be digitally signed by the account JWK and/or the CSR key (mos= t likely by having the response be a JWS containing the key authorization r= ather than the key authorization itself) improve security, worsen security,= or have no impact on security? If it would improve security, would this be feasible for each type of chal= lenge?=C2=A0

Sincerely,=C2=A0
Logan Widick

On Mon, May 8, 2017 at 5:21 PM, Zach Shepherd <shepherdz@vmw= are.com> wrote:

The following feedback is based on cd7c5e9 (current HEAD of master).
Section 8.3 states that the token value for HTTP validation "MUST have= at least 128 bits of entropy."

Section 11.3 explains that one goal of this is that "the entropy requi= rement prevents ACME clients from implementing a =E2=80=9Cnaive=E2=80=9D va= lidation server that automatically replies to challenges without participat= ing in the creation of the intial authorization request."

However, because of the way the token is used in the validation process, as= a part of the request, this goal is not met. It is possible to configure a= webserver to respond to all requests under .well-known/acme-challenge with= the ASCII representation of the key authorization. (See, e.g., https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.)

Essentially, the server informs the client of the token during the validati= on process, removing any need for the client to have known it.

If this is acceptable, the entropy requirement should be removed. If this i= s unacceptable, the challenge and validation should be revised.

Regards,
Zach Shepherd


_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mail= man/listinfo/acme



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




--
Jehiah




--001a11404c78c4fc55054f370b58-- From nobody Thu May 11 14:10: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 9620512EC9B for ; Thu, 11 May 2017 14:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.103 X-Spam-Level: X-Spam-Status: No, score=-5.103 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 I_UqJx_WFHMT for ; Thu, 11 May 2017 14:10:00 -0700 (PDT) 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 CADC1131479 for ; Thu, 11 May 2017 14:03:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=uzsh2itzJrprCZpy0ZDUQHsSiriBOmhetIEQecQddE0=; b=FzXJzmTo6C+LBUKu48NH8aaklT6oPXgLZajpZ3YbhfcPNy1Kd4F3q6taqlH6L+O9NCXGtBJrrrXazzb2kWye3w7whSX2uLr+AQiu++FosI3uXoHoPr0aE/O1CYL9FUH+iyakuggBKFGJfUEA4E7ozOKSvNe52KHhRfG9wpunofk=; Received: ; Thu, 11 May 2017 14:03:55 -0700 To: Zach Shepherd , "acme@ietf.org" References: From: Jacob Hoffman-Andrews Message-ID: <49f045b4-2ef3-3e36-5b2e-f5d75c4d33b1@eff.org> Date: Thu, 11 May 2017 14:03:55 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E2500DF09B92BC66AC181262" Received-SPF: skipped for local relay Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 21:10:05 -0000 This is a multi-part message in MIME format. --------------E2500DF09B92BC66AC181262 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks for the detailed look at this. On 05/08/2017 03:21 PM, Zach Shepherd wrote: > The following feedback is based on cd7c5e9 (current HEAD of master). > > Section 8.3 states that the token value for HTTP validation "MUST have > at least 128 bits of entropy." > > Section 11.3 explains that one goal of this is that "the entropy > requirement prevents ACME clients from implementing a =93naive=94 > validation server that automatically replies to challenges without > participating in the creation of the intial authorization request." > > However, because of the way the token is used in the validation > process, as a part of the request, this goal is not met. It is > possible to configure a webserver to respond to all requests under > .well-known/acme-challenge with the ASCII representation of the key > authorization. (See, e.g., > https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode > .) I think this type of "stateless" validation server, as opposed to the "naive" validation server described in ACME, is fine. Though I am of course open to being convinced otherwise. You're right that the second part of the token entropy requirement isn't quite correct. Specifically, the thing we want to avoid is that by setting up some ACME software on a server, someone accidentally allows a third party to come along and get a certificate for that server without actually controlling it, by exploiting that ACME software's willingness to automatically reply to challenges. This is why we include the account key thumbprint as part of the keyAuthorization. An attacker cannot get a certificate for a "stateless" validation server setup like the one you described because the account key thumbprint that server is echoing belongs to the actual administrator of the server, not the attacker. In practice we have seen this happen in non-malicious ways: recently I answered a question on Let's Encrypt's forum from someone who had a "stateless" validation server set up. They were actually getting validation failures, because they started trying to validate using a different client with a different account key, but the old stateless setup was taking precedence: https://community.letsencrypt.org/t/letsencrypt-vesta-client-error-the-ke= y-authorization-file-from-the-server-did-not-match/32822/12?u=3Djsha. --------------E2500DF09B92BC66AC181262 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Thanks for the detailed look at this.

On 05/08/2017 03:21 PM, Zach Shepherd wrote:
The following feedback is based on cd7c5e9 (current HEAD of master).

Section 8.3 states that the token value for HTTP validation "MUST have at least 128 bits of entropy."

Section 11.3 explains that one goal of this is that "the entropy requirement prevents ACME clients from implementing a naive validation server that automatically replies to challenges without participating in the creation of the intial authorization request."

However, because of the way the token is used in the validation process, as a part of the request, this goal is not met. It is possible to configure a webserver to respond to all requests under .well-known/acme-challenge with the ASCII representation of the key authorization. (See, e.g., https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.)
I think this type of "stateless" validation server, as opposed to the "naive" validation server described in ACME, is fine. Though I am of course open to being convinced otherwise.

You're right that the second part of the token entropy requirement isn't quite correct. Specifically, the thing we want to avoid is that by setting up some ACME software on a server, someone accidentally allows a third party to come along and get a certificate for that server without actually controlling it, by exploiting that ACME software's willingness to automatically reply to challenges. This is why we include the account key thumbprint as part of the keyAuthorization. An attacker cannot get a certificate for a "stateless" validation server setup like the one you described because the account key thumbprint that server is echoing belongs to the actual administrator of the server, not the attacker.

In practice we have seen this happen in non-malicious ways: recently I answered a question on Let's Encrypt's forum from someone who had a "stateless" validation server set up. They were actually getting validation failures, because they started trying to validate using a different client with a different account key, but the old stateless setup was taking precedence: https://community.letsencrypt.org/t/letsencrypt-vesta-client-error-the-key-authorization-file-from-the-server-did-not-match/32822/12?u=jsha.
--------------E2500DF09B92BC66AC181262-- From nobody Thu May 11 16:50:27 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 6DA49129AFE for ; Thu, 11 May 2017 16:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.712 X-Spam-Level: X-Spam-Status: No, score=-2.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=onevmw.onmicrosoft.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 pxW1jN0dQIwu for ; Thu, 11 May 2017 16:50:22 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0045.outbound.protection.outlook.com [104.47.41.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26508129B8D for ; Thu, 11 May 2017 16:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=j//afVurB6iIKnpefV6kFABmajzc2C1SoUXLNHwyjJs=; b=Jj4CK4YAZud1ewSSHzXc/RHk/FfBd2drZevGLxkVgOoMvR1/z2TOdBOdHjXKJwiId0ELyCSSoAg34OkpPyqGznWg22miHn/fyj9wX1JJYqlvjOdDXXCTZweD78FdnWhyT8j9fTD09iOeVkdpOs0wy4E7nz1sNYPKLdrHaYh8suk= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3047.namprd05.prod.outlook.com (10.172.156.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Thu, 11 May 2017 23:46:10 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.1084.020; Thu, 11 May 2017 23:46:10 +0000 From: Zach Shepherd To: Jacob Hoffman-Andrews , "acme@ietf.org" Thread-Topic: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token Thread-Index: AQHSyEjYBSJMcNvrJ0+rg/Q+1mjkwKHvo6GAgAAqwoc= Date: Thu, 11 May 2017 23:46:10 +0000 Message-ID: References: , <49f045b4-2ef3-3e36-5b2e-f5d75c4d33b1@eff.org> In-Reply-To: <49f045b4-2ef3-3e36-5b2e-f5d75c4d33b1@eff.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: eff.org; dkim=none (message not signed) header.d=none;eff.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [25.173.177.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR05MB3047; 7:oNlYjP103nIuMAQlq/o6k/T0Zqd2e+BGFHJt+8ihVseOXwL/b5EKtCVS/ZSwRRAeuD6XyVexff5IBemiM15TrLBRxfzI6uqz7jry8g7hr0MSKnfez7qnFhuUh5lzn0+HwyE0A3eMuuyFgLuYb9Ndi6c7EVfQZXMjNlDfsarp7T/DzPtuZdWF0tiiTDBiER4dhK2NKS4vw2yb1SKN1eUvtZcD0jwUCQdtAtDspm+BDrdC6iM+eg6HgYlqybArRSz2y0w0ovGyV8N/Zsovr2Hvy1IwzE0RZ7iGCfilGa8sWtPJw5V8gX2MmQFkkiEES3uea/+6zCb+A76E7Y7voxmmxg==; 20:XF/jxK4rZidNZmjvANfs4K9+q9/szwOK/bweWdaSJ1M5akhHSy5ItizOHJpKCeRWjKAlkE/UFZs961EEMoIFgoMp4XNFFByeLSch4UB9iLKd5vpP6Jg8nQ3HSel4KpL+XPT0gcj9it2qSwxLM3IU4q/jps0PoEKDNGNe7rG8g+Q= x-ms-office365-filtering-correlation-id: 0f9f5a42-2a94-472e-ca82-08d498c7e6e8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR05MB3047; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(166708455590820)(265273979862326); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700036)(100105000095)(100000701036)(100105300095)(100000702036)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(100000703036)(100105400095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(20161123564025)(20161123555025)(6072148)(100000704036)(100105200095)(100000705036)(100105500095); SRVR:CY4PR05MB3047; BCL:0; PCL:0; RULEID:(100000800036)(100110000095)(100000801036)(100110300095)(100000802036)(100110100095)(100000803036)(100110400095)(100000804036)(100110200095)(100000805036)(100110500095); SRVR:CY4PR05MB3047; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39450400003)(39400400002)(39410400002)(39850400002)(39840400002)(24454002)(51914003)(377454003)(77096006)(7696004)(74316002)(50986999)(76176999)(54356999)(189998001)(2906002)(19627405001)(8936002)(122556002)(81166006)(33656002)(8676002)(2501003)(5660300001)(6436002)(3846002)(102836003)(6116002)(7736002)(25786009)(53546009)(606005)(55016002)(99286003)(229853002)(2900100001)(54896002)(6306002)(9686003)(236005)(478600001)(53936002)(3660700001)(6246003)(66066001)(3280700002)(38730400002)(14971765001)(86362001)(2950100002)(7906003)(6606003)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3047; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB3045D3923BCBCD8ACFA20007C0ED0CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2017 23:46:10.4861 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3047 Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 May 2017 23:50:25 -0000 --_000_CY4PR05MB3045D3923BCBCD8ACFA20007C0ED0CY4PR05MB3045namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If this sort of "stateless" server is acceptable, why do we require 128 bit= s of entropy for the token? I'm not sure whether or not a "stateless" server like this is fine, but I d= o think requiring use of a high-entropy token which can essentially be igno= red is inconsistent. It seems like it is either not serving its intended pu= rpose (in which case we should revise the HTTP challenge to ensure the seve= r doesn't "give away" the token during the validation) or it's not actually= necessary (in which case we should consider revising the HTTP challenge, a= nd perhaps others*, to get rid of the requirements for the token). Regards, Zach * - If stateless http clients are acceptable, why not stateless DNS clients= ? I think allowing administrators to set a single TXT record containing the= account key thumbprint and have it be re-used for multiple challenges woul= d make it much more feasible to use the DNS challenge in environments where= DNS management access is tightly controlled. ________________________________ From: Jacob Hoffman-Andrews Sent: Thursday, May 11, 2017 2:03 PM To: Zach Shepherd; acme@ietf.org Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of= entropy for the http-01 token Thanks for the detailed look at this. On 05/08/2017 03:21 PM, Zach Shepherd wrote: The following feedback is based on cd7c5e9 (current HEAD of master). Section 8.3 states that the token value for HTTP validation "MUST have at l= east 128 bits of entropy." Section 11.3 explains that one goal of this is that "the entropy requiremen= t prevents ACME clients from implementing a =93naive=94 validation server t= hat automatically replies to challenges without participating in the creati= on of the intial authorization request." However, because of the way the token is used in the validation process, as= a part of the request, this goal is not met. It is possible to configure a= webserver to respond to all requests under .well-known/acme-challenge with= the ASCII representation of the key authorization. (See, e.g., https://git= hub.com/Neilpang/acme.sh/wiki/Stateless-Mode.) I think this type of "stateless" validation server, as opposed to the "naiv= e" validation server described in ACME, is fine. Though I am of course open= to being convinced otherwise. You're right that the second part of the token entropy requirement isn't qu= ite correct. Specifically, the thing we want to avoid is that by setting up= some ACME software on a server, someone accidentally allows a third party = to come along and get a certificate for that server without actually contro= lling it, by exploiting that ACME software's willingness to automatically r= eply to challenges. This is why we include the account key thumbprint as pa= rt of the keyAuthorization. An attacker cannot get a certificate for a "sta= teless" validation server setup like the one you described because the acco= unt key thumbprint that server is echoing belongs to the actual administrat= or of the server, not the attacker. In practice we have seen this happen in non-malicious ways: recently I answ= ered a question on Let's Encrypt's forum from someone who had a "stateless"= validation server set up. They were actually getting validation failures, = because they started trying to validate using a different client with a dif= ferent account key, but the old stateless setup was taking precedence: http= s://community.letsencrypt.org/t/letsencrypt-vesta-client-error-the-key-auth= orization-file-from-the-server-did-not-match/32822/12?u=3Djsha. --_000_CY4PR05MB3045D3923BCBCD8ACFA20007C0ED0CY4PR05MB3045namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

If this sort of "stateless" server is acceptable, why do we re= quire 128 bits of entropy for the token?


I'm not sure whether or not a "stateless" server like this is = fine, but I do think requiring use of a high-entropy token which can essent= ially be ignored is inconsistent. It seems like it is either not serving it= s intended purpose (in which case we should revise the HTTP challenge to ensure the sever doesn't "give away"= ; the token during the validation) or it's not actually necessary (in which= case we should consider revising the HTTP challenge, and perhaps others*, = to get rid of the requirements for the token).


Regards,

Zach

* - If stateless http clients are acceptable, why not stateless DNS clie= nts? I think allowing administrators to set a single TXT record containing = the account key thumbprint and have it be re-used for multiple challenges w= ould make it much more feasible to use the DNS challenge in environments where DNS management access is ti= ghtly controlled.


From: Jacob Hoffman-Andre= ws <jsha@eff.org>
Sent: Thursday, May 11, 2017 2:03 PM
To: Zach Shepherd; acme@ietf.org
Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 = bits of entropy for the http-01 token
 
Thanks for the detailed look at this.

On 05/08/2017 03:21 PM, Zach Shepherd wrote:
The following feedback is based on cd7c5e9 (current HEAD of master).
Section 8.3 states that the token value for HTTP validation "MUST have= at least 128 bits of entropy."

Section 11.3 explains that one goal of this is that "the entropy requi= rement prevents ACME clients from implementing a =93naive=94 validation ser= ver that automatically replies to challenges without participating in the c= reation of the intial authorization request."

However, because of the way the token is used in the validation process, as= a part of the request, this goal is not met. It is possible to configure a= webserver to respond to all requests under .well-known/acme-challenge with= the ASCII representation of the key authorization. (See, e.g., https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode.)
I think this type of "stateless" validation server, as opposed to= the "naive" validation server described in ACME, is fine. Though= I am of course open to being convinced otherwise.

You're right that the second part of the token entropy requirement isn't qu= ite correct. Specifically, the thing we want to avoid is that by setting up= some ACME software on a server, someone accidentally allows a third party = to come along and get a certificate for that server without actually controlling it, by exploiting that ACME s= oftware's willingness to automatically reply to challenges. This is why we = include the account key thumbprint as part of the keyAuthorization. An atta= cker cannot get a certificate for a "stateless" validation server setup like the one you described= because the account key thumbprint that server is echoing belongs to the a= ctual administrator of the server, not the attacker.

In practice we have seen this happen in non-malicious ways: recently I answ= ered a question on Let's Encrypt's forum from someone who had a "state= less" validation server set up. They were actually getting validation = failures, because they started trying to validate using a different client with a different account key, but the old statele= ss setup was taking precedence: https://community.letsencrypt.org/t/letsencrypt-vesta-client-error-the-key-= authorization-file-from-the-server-did-not-match/32822/12?u=3Djsha.
--_000_CY4PR05MB3045D3923BCBCD8ACFA20007C0ED0CY4PR05MB3045namp_-- From nobody Fri May 12 04:28:39 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 AA22512EAB8 for ; Fri, 12 May 2017 04:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 2kzA13iyqGZB for ; Fri, 12 May 2017 04:28:34 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2578112EAC4 for ; Fri, 12 May 2017 04:23:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 467585FEF8; Fri, 12 May 2017 14:23:24 +0300 (EEST) 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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id LjcnbCajcSv4; Fri, 12 May 2017 14:23:24 +0300 (EEST) 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 1E69D2313; Fri, 12 May 2017 14:23:24 +0300 (EEST) Date: Fri, 12 May 2017 14:23:22 +0300 From: Ilari Liusvaara To: Zach Shepherd Cc: Jacob Hoffman-Andrews , "acme@ietf.org" Message-ID: <20170512112322.GA29942@LK-Perkele-V2.elisa-laajakaista.fi> References: <49f045b4-2ef3-3e36-5b2e-f5d75c4d33b1@eff.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 11:28:37 -0000 On Thu, May 11, 2017 at 11:46:10PM +0000, Zach Shepherd wrote: > If this sort of "stateless" server is acceptable, why do we require > 128 bits of entropy for the token? CAB Forum Baseline Requirements. > * - If stateless http clients are acceptable, why not stateless DNS > clients? I think allowing administrators to set a single TXT record > containing the account key thumbprint and have it be re-used for > multiple challenges would make it much more feasible to use the DNS > challenge in environments where DNS management access is tightly > controlled. Again, CAB Forum Baseline Requirements. -Ilari From nobody Fri May 12 09:44:41 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 6464312EC92 for ; Fri, 12 May 2017 09:44:39 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 LYTDw9-wOd9B for ; Fri, 12 May 2017 09:44:36 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4C97B1293EC for ; Fri, 12 May 2017 09:39:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 7522B5FEF8; Fri, 12 May 2017 19:39:29 +0300 (EEST) 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 UkJKmGAjGDZ0; Fri, 12 May 2017 19:39:28 +0300 (EEST) 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 BAB4E21C; Fri, 12 May 2017 19:39:28 +0300 (EEST) Date: Fri, 12 May 2017 19:39:27 +0300 From: Ilari Liusvaara To: Jacob Hoffman-Andrews Cc: Zach Shepherd , "acme@ietf.org" Message-ID: <20170512163927.GA30547@LK-Perkele-V2.elisa-laajakaista.fi> References: <49f045b4-2ef3-3e36-5b2e-f5d75c4d33b1@eff.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <49f045b4-2ef3-3e36-5b2e-f5d75c4d33b1@eff.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 16:44:39 -0000 On Thu, May 11, 2017 at 02:03:55PM -0700, Jacob Hoffman-Andrews wrote: > Thanks for the detailed look at this. > > On 05/08/2017 03:21 PM, Zach Shepherd wrote: > > The following feedback is based on cd7c5e9 (current HEAD of master). > > > > Section 8.3 states that the token value for HTTP validation "MUST have > > at least 128 bits of entropy." > > > > Section 11.3 explains that one goal of this is that "the entropy > > requirement prevents ACME clients from implementing a “naive” > > validation server that automatically replies to challenges without > > participating in the creation of the intial authorization request." > > > > However, because of the way the token is used in the validation > > process, as a part of the request, this goal is not met. It is > > possible to configure a webserver to respond to all requests under > > .well-known/acme-challenge with the ASCII representation of the key > > authorization. (See, e.g., > > https://github.com/Neilpang/acme.sh/wiki/Stateless-Mode > > .) > I think this type of "stateless" validation server, as opposed to the > "naive" validation server described in ACME, is fine. Though I am of > course open to being convinced otherwise. Well, the general tone of the "10 methods" is against such "stateless" setups. But that might be because those are written assuming much more primitive capabilities than what ACME provodes. > You're right that the second part of the token entropy requirement isn't > quite correct. Specifically, the thing we want to avoid is that by > setting up some ACME software on a server, someone accidentally allows a > third party to come along and get a certificate for that server without > actually controlling it, by exploiting that ACME software's willingness > to automatically reply to challenges. This is why we include the account > key thumbprint as part of the keyAuthorization. An attacker cannot get a > certificate for a "stateless" validation server setup like the one you > described because the account key thumbprint that server is echoing > belongs to the actual administrator of the server, not the attacker. The key does not necressarily belong to the adminstrator of the server! It can also belong to the administrator of the virtual host, in setups that delegate certificate maintenance (which is common in shared hosting setups that don't just grab certs for all their residents from one CA). Also, I consider ACME too complicated to be implemented in the web- server or closely associated software. However, the needed support functions, certificate provisioning and challenge provisioning (with the remaining logic being replaceable) are simple enough. However, to split those functions, you need to be able to perform approprate access control. With HTTP-01 and DNS-01 this is possible (not that you need often do do it with DNS-01). However, not with TLS-SNI-02, because the requests are not verifiably bound into the domain being validated. -Ilari From nobody Fri May 12 11:38:41 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 B935512FEE1 for ; Fri, 12 May 2017 11:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 siNp5zGdipno for ; Fri, 12 May 2017 11:38:35 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 CDB3C127599 for ; Fri, 12 May 2017 11:34:49 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id k74so54919886qke.1 for ; Fri, 12 May 2017 11:34:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CLXYHwqYEe0hwkdzWc5ROZCVOEYLRMgLDe+xFJS5LLY=; b=vUeWKg49YmkpmgfClby22OqQlQM33CNDWZ+m2IGzbpfMHY04qKFbYgz2mulV4UX/NC fATMWonLBFsuFMaWsEOi8Vf8S6bY2i3K8xqDs3U/M2+OO49SxDNPlYp9gWroSwDeCAcL eYm308j8Cr2HvydBNeUTNgfIF/TMBe+FNsvp8+xnfP2AihIQIUWD47OEtjrAWZ8CVIqA Wu2F5uRlhTO2ESOdZBvvwbtxt1htzSZyi2HWyiJf1g3aD9Urfuxo0HazaTZdi/Yb013j KBwGuMMtJAaDG85CICJykwo01GTzZBQhlPEiv3+OTJ2+ax3B9ODJ4SRpYVQbNL4yM5s5 x4jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CLXYHwqYEe0hwkdzWc5ROZCVOEYLRMgLDe+xFJS5LLY=; b=Ouf5oZKm4lA2B0ZLewENvxltjmmMMnoRszfEoXTjzC7bbhHAZtOTT8CoCLJW6fIwzL suurtGgSbHNpbyB4y856TDeLfCVHBv83hXVDNDm/IdE78ka8ERSwIAqbJdLRzOb6ChmS FqjU461mN/WAi1B2J0N/G1xzIt3q5Q+imVr2OAWMJG4n+zS3xIx28KgOjIR25+uAVtQ7 7+XOyZI9kMzZQebXfu2fK9zSV5XAc+jfbgRffeXPWJxDLyaWfnPKH6+kJ1dVe31RPn8h SbCmvK40RSk3XcJn9Qo1lldNguiDKNdU29k5BH74ndrdRZCUYG9kGWkgT7Fke0z+XwIK giXQ== X-Gm-Message-State: AODbwcBkbVuZwp0hgQoIlrzsX+dWG+6tyOfvQj4h7hpd/fsdAjM6xoot 0g6QyJMEMeIxSGcofoOvnpSNsmfAJQ== X-Received: by 10.55.215.65 with SMTP id m62mr4575042qki.286.1494614088870; Fri, 12 May 2017 11:34:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.63.45 with HTTP; Fri, 12 May 2017 11:34:18 -0700 (PDT) In-Reply-To: <37f92587e2f245829383f65b3ef38a30@usma1ex-dag1mb1.msg.corp.akamai.com> References: <37f92587e2f245829383f65b3ef38a30@usma1ex-dag1mb1.msg.corp.akamai.com> From: Ted Hardie Date: Fri, 12 May 2017 11:34:18 -0700 Message-ID: To: "Salz, Rich" Cc: ACME WG Content-Type: multipart/alternative; boundary="001a1149e836d7ee7e054f57f51a" Archived-At: Subject: Re: [Acme] ACME interm meeting poll X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 18:38:40 -0000 --001a1149e836d7ee7e054f57f51a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just a reminder of this poll; please respond by midnight May 16, 2017 (any timezone), and we'll work out the time to request from that. thanks, Ted and Rich On Tue, May 9, 2017 at 1:28 PM, Salz, Rich wrote: > We are trying to decide if we should meet in Prague. To help make the > decision, we are holding a Doodle poll for a one-hour virtual interim. > Please go here and vote: > > http://doodle.com/poll/u56c5xwr7nb23wqe > > > > > The main ACME draft is essentially done, and should enter a second WGLC > soon. That alone would not justify a meeting. > > > > In the early message thread that was labeled =E2=80=9CFutures=E2=80=9D th= e following > possible work items came up: > > Hugo=E2=80=99s CAA draft (already adopted, short, might b= e ready > for WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01 > > > > The following drafts are possible calls for adoption: > > Yaron Sheffer et al draft on STAR -- > https://tools.ietf.org/html/draft-sheffer-acme-star-lurk-00 > > Mary Barnes on an ACME challenge for ATIS/SIP -- > https://tools.ietf.org/html/draft-barnes-acme-service-provider-00 > > Roland Shoemaker on an ACME challenge for validating IP > addresses -- https://tools.ietf.org/html/draft-shoemaker-acme-ip-00 > > > > In addition, Alexey is interested in helping with an ACME challenge for > email certificates. Is anyone else interested in helping to draft draftin= g? > > > > We would like to know if people are interested in adopting, advancing, > working-on these drafts within the ACME WG. And if anyone will commit to > working on any of them. If so, then we will discuss them in Prague, and > have a re-chartering discussion to cover this new work. > > > > Please see the Doodle poll and mark your availability. > > > > For the good of the order, > > /r$ > > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a1149e836d7ee7e054f57f51a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just a reminder of this poll; please respond by = midnight May 16, 2017 (any timezone), and we'll work out the time to re= quest from that.

thanks,

Ted and Rich

On Tue, May 9, 2017= at 1:28 PM, Salz, Rich <rsalz@akamai.com> wrote:

We are trying to decide if we should meet in Prague.= =C2=A0 To help make the decision, we are holding a Doodle poll for a one-ho= ur virtual interim.=C2=A0 Please go here and vote:

http://doodle.com/= poll/u56c5xwr7nb23wqe

=C2=A0

The main ACME draft is essentially done, and should = enter a second WGLC soon.=C2=A0 That alone would not justify a meeting.<= /u>

=C2=A0

In the early message thread that was labeled =E2=80= =9CFutures=E2=80=9D the following possible work items came up:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Hugo=E2=80=99s CAA draft (already a= dopted, short, might be ready for WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01

=C2=A0

The following drafts are possible calls for adoption= :

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yaron Sheffer et al draft on STAR -= - https://tools.ietf.org/html/draft-sheffer-acme-star-lurk-00

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mary Barnes on an ACME challenge fo= r ATIS/SIP -- https://tools.ietf.org/html/draft-barnes-acme-ser= vice-provider-00

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Roland Shoemaker on an ACME challen= ge for validating IP addresses -- https://tools.ietf.org/html/draft-shoemaker-acme-ip-00=

=C2=A0

In addition, Alexey is interested in helping with an= ACME challenge for email certificates. Is anyone else interested in helpin= g to draft drafting?

=C2=A0

We would like to know if people are interested in ad= opting, advancing, working-on these drafts within the ACME WG. And if anyon= e will commit to working on any of them.=C2=A0 If so, then we will discuss = them in Prague, and have a re-chartering discussion to cover this new work.

=C2=A0

Please see the Doodle poll and mark your availabilit= y.

=C2=A0

For the good of the order,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 /r$

=C2=A0


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


--001a1149e836d7ee7e054f57f51a-- From nobody Fri May 12 15:37:23 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 E30C2129B2D for ; Fri, 12 May 2017 15:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=onevmw.onmicrosoft.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 Ll0kw0MgEqBK for ; Fri, 12 May 2017 15:37:18 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0062.outbound.protection.outlook.com [104.47.40.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D8B129B5C for ; Fri, 12 May 2017 15:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=onevmw.onmicrosoft.com; s=selector1-vmware-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=C+KAonziB4toZd329Y7kAq1jWA3pq1Iq0axdvFcfvH0=; b=L8uh2hFEYALKhMF/421XnN5c/NuZXSqa0tpVdqKRMQCI/luDd2Ni5G91lHpsZ4FbPqxegDkX3kQU/D7Ct+kAWubhg2DlQKCetlTzt0tytR1pqD/RxisAMMcpsFKkEZANDPhcPuchSR1Sm3PyWvM347m+MdV6aYLQqPLmDHe+AEI= Received: from CY4PR05MB3045.namprd05.prod.outlook.com (10.172.155.135) by CY4PR05MB3046.namprd05.prod.outlook.com (10.172.155.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1084.7; Fri, 12 May 2017 22:33:40 +0000 Received: from CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) by CY4PR05MB3045.namprd05.prod.outlook.com ([10.172.155.135]) with mapi id 15.01.1084.020; Fri, 12 May 2017 22:33:40 +0000 From: Zach Shepherd To: Ilari Liusvaara CC: Jacob Hoffman-Andrews , "acme@ietf.org" Thread-Topic: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token Thread-Index: AQHSyEjYBSJMcNvrJ0+rg/Q+1mjkwKHvo6GAgAAqwoeAAMVfAIAAtzXt Date: Fri, 12 May 2017 22:33:40 +0000 Message-ID: References: <49f045b4-2ef3-3e36-5b2e-f5d75c4d33b1@eff.org> , <20170512112322.GA29942@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170512112322.GA29942@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: eff.org; dkim=none (message not signed) header.d=none;eff.org; dmarc=none action=none header.from=vmware.com; x-originating-ip: [25.173.177.4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR05MB3046; 7:pSB71qMpHt37FcY3pkIo9LIZ6mee2OI92KjV2cLXiwvPCfHN93JJiJv9SfUaff81H3aqfXeK7sCeMW1F26/e26HJ1YMeNEhEeBwQAwf/tP8jKS7XO9jSQMHwgA+JGJ89KhqMv0BDL2rfORhVt2LFNnihlVMd4sn/lRCpxoOT7bVru6tkndLg8IIi/T66jhh4sBAmjuCgfZ30erwBL2+p3JkzuaKtGRYPYld6ovSrurQrZvNpiVTy4TLiTk8yH6NYpy7o2VUAaZZjzLzj+FRcBHN4OBbjNax/2T17pF6EFf3mRJa9pg/SNiFagYlZ3zPypIqq6L/uj7j2G00o0W6u5g==; 20:TyaqcEBglmZjxMIZ76vnhhFjhfCahuCoCx9bat7/E+0pE0WKq/LazBWKev3AoVZz/aBH/KjbtlGvmsTyYKQaBPuENROw5AfOlMAIAurDiyptyNRI6Fb/hXLSWebcabK3WBslZt44c3NjWejzAAyX/xOX+mfvp/VZoD7xgU8uodc= x-ms-office365-filtering-correlation-id: 7735213e-2c94-4caf-898b-08d49986f0a4 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:CY4PR05MB3046; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148); SRVR:CY4PR05MB3046; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3046; x-forefront-prvs: 0305463112 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39400400002)(39410400002)(39840400002)(39850400002)(39450400003)(24454002)(377454003)(189998001)(3280700002)(3846002)(6116002)(102836003)(6916009)(74316002)(2950100002)(55016002)(77096006)(76176999)(53936002)(50986999)(6506006)(2900100001)(66066001)(54906002)(54356999)(54896002)(9686003)(6246003)(99286003)(38730400002)(110136004)(6436002)(7696004)(25786009)(19627405001)(4326008)(5660300001)(2906002)(6606003)(122556002)(81166006)(478600001)(86362001)(8676002)(7736002)(3660700001)(8936002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR05MB3046; H:CY4PR05MB3045.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR05MB304569BFB92963FFDF48B261C0E20CY4PR05MB3045namp_" MIME-Version: 1.0 X-OriginatorOrg: vmware.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2017 22:33:40.5913 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: b39138ca-3cee-4b4a-a4d6-cd83d9dd62f0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3046 Archived-At: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 May 2017 22:37:21 -0000 --_000_CY4PR05MB304569BFB92963FFDF48B261C0E20CY4PR05MB3045namp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable For use of a token with http-01, it seems like the relevant section of the = baseline requirements would be 3.2.2.4.6 Agreed=1B$B!>=1B(BUpon Change to W= ebsite. Is that correct? That section seems to explicitly state "where the Request Token or Random V= alue MUST NOT appear in the request". Including the token (which the docume= nt seems to refer to as the "Random Value") in the request path (as http-01= does) would seem to violate this normative language. Am I misunderstanding= the content of that section? ________________________________ From: ilariliusvaara@welho.com on behalf of Ilar= i Liusvaara Sent: Friday, May 12, 2017 4:23 AM To: Zach Shepherd Cc: Jacob Hoffman-Andrews; acme@ietf.org Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of= entropy for the http-01 token On Thu, May 11, 2017 at 11:46:10PM +0000, Zach Shepherd wrote: > If this sort of "stateless" server is acceptable, why do we require > 128 bits of entropy for the token? CAB Forum Baseline Requirements. > * - If stateless http clients are acceptable, why not stateless DNS > clients? I think allowing administrators to set a single TXT record > containing the account key thumbprint and have it be re-used for > multiple challenges would make it much more feasible to use the DNS > challenge in environments where DNS management access is tightly > controlled. Again, CAB Forum Baseline Requirements. -Ilari --_000_CY4PR05MB304569BFB92963FFDF48B261C0E20CY4PR05MB3045namp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

For use of a token with http-01, it seems like the relevant section of t= he baseline requirements would be 3.2.2.4.6 Agreed=1B$B!>=1B(BUpon Change to Website. Is that co= rrect?


That section seems to explicitly state "where the Request Tok= en or Random Value MUST NOT appear in the request". Including t= he token (which the document seems to refer to as the "Random Value&qu= ot;) in the request path (as http-01 does) would seem to violate this normative language. Am I mi= sunderstanding the content of that section?


From: ilariliusvaara@welh= o.com <ilariliusvaara@welho.com> on behalf of Ilari Liusvaara <ila= riliusvaara@welho.com>
Sent: Friday, May 12, 2017 4:23 AM
To: Zach Shepherd
Cc: Jacob Hoffman-Andrews; acme@ietf.org
Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 = bits of entropy for the http-01 token
 
On Thu, May 11, 2017 at 11:46:10PM +0000, Zach= Shepherd wrote:
> If this sort of "stateless" server is acceptable, why do we = require
> 128 bits of entropy for the token?
 
CAB Forum Baseline Requirements.

> * - If stateless http clients are acceptable, why not stateless DNS > clients? I think allowing administrators to set a single TXT record > containing the account key thumbprint and have it be re-used for
> multiple challenges would make it much more feasible to use the DNS > challenge in environments where DNS management access is tightly
> controlled.

Again, CAB Forum Baseline Requirements.


-Ilari

--_000_CY4PR05MB304569BFB92963FFDF48B261C0E20CY4PR05MB3045namp_-- From nobody Thu May 18 05:59:18 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 EB7A2129B9C; Thu, 18 May 2017 05:59:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: IESG Secretary To: "IETF-Announce" Cc: acme@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.51.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149511235670.6643.9258509651795173920@ietfa.amsl.com> Date: Thu, 18 May 2017 05:59:16 -0700 Archived-At: Subject: [Acme] Automated Certificate Management Environment (acme) WG Virtual Meeting: 2017-06-02 X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 May 2017 12:59:17 -0000 The Automated Certificate Management Environment (acme) Working Group will hold a virtual interim meeting on 2017-06-02 from 11:00 to 12:00 America/New_York. Agenda: In the early message thread that was labeled “Futures” the following possible work items came up: Hugo’s CAA draft (already adopted, short, might be ready for WGLC) -- https://tools.ietf.org/html/draft-ietf-acme-caa-01 The following drafts are possible calls for adoption: Yaron Sheffer et al draft on STAR -- https://tools.ietf.org/html/draft-sheffer-acme-star-lurk-00 Mary Barnes on an ACME challenge for ATIS/SIP -- https://tools.ietf.org/html/draft-barnes-acme-service-provider-00 Roland Shoemaker on an ACME challenge for validating IP addresses -- https://tools.ietf.org/html/draft-shoemaker-acme-ip-00 And also Jon Petersonet al https://tools.ietf.org/html/draft-peterson-acme-telephone-00 In addition, Alexey is interested in helping with an ACME challenge for email certificates. Is anyone else interested in helping to draft drafting? -------------------- JOIN WEBEX MEETING https://akamai.webex.com/akamai/j.php?MTID=mb576c8ed0d9ea410b005d94fc7250aad Meeting number (access code): 920 560 490 JOIN BY PHONE 1-408-792-6300 Call-in toll number (US/Canada) 1-877-668-4490 Call-in toll-free number (US/Canada) Global call-in numbers: https://akamai.webex.com/akamai/globalcallin.php?serviceType=MC&ED=524935677&tollFree=1 Toll-free dialing restrictions: https://www.webex.com/pdf/tollfree_restrictions.pdf Information about remote participation: See below, after agenda From nobody Sat May 27 13:13:09 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 34D9C120726; Sat, 27 May 2017 13:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 nozZDg6J3YWW; Sat, 27 May 2017 13:13:05 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 0B99E120046; Sat, 27 May 2017 13:13:05 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id l50so17027707wrc.3; Sat, 27 May 2017 13:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=tYRr2au2W/ehJFAW3ZSAg1oLo3YmTHplC6272NZfFHs=; b=QcvkkO0QF7RHL/3LHMpJDhlUyq1mIIFZJ+oPC49108ApAEbeC7iXDH1aN+BmNbKpnf pdpAIxUx6rCGhgh3z7ryvNKAULYnbHNCL5sVJzHDG0fQ6b/RXL1HFqgK0LzrljWH6L5T r+JQvhCN1j9H8DNsgm573waNg81oHXz2hXiXjg4CIQYlALuATH3qJFeGe3JAauKOVshQ T5sSD5h4n0mCKygF9IA0O4jZL2QHT1T/+E1j+na1HOXq8s2Vl+tifKn/Ov+ZSj+kby+d wipT7Dj4MMXgWK2CTEPlDJ6Oo9JOqUl5q5WbDnGtmwVGySeQ4IPMZ5q7KpUFjIBPyQby AHuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=tYRr2au2W/ehJFAW3ZSAg1oLo3YmTHplC6272NZfFHs=; b=Qx41qWpaUX1IcufuMbuwhJlcFe+YfuhpR5vEKIYaOg1lLqQA+jEPGwI7nDXCGNw3dT vtEOmixi9/O8QRzmDRkM0Wmu96fbkrt3GYq28749/oMV++yW4Wa3whN+0c1EU7qmkcz1 vAT/2IT+Bs0c4TqfCpiAHdyVv4+rrPPDcoxmZXhQYu1wM/UFwfaLAVSuQtsDyvioqdQt 83JKTSGVxqvYaIib3yUVyEMu4f4toplYYo1k3WbAiXmGyk583CJUX9Jwh1FDOkk85Vwg mcI/NnugcCdBg4jKaIyi9hVYPR4249vev2GS4HT+j2gOJASKedIza8gt3aHf7m4JtNjx sGWQ== X-Gm-Message-State: AODbwcDy/5pOqZwE7cHeJ+Hs4WviX/8PFaj5rJp9dHg3qDsV8JJT6ukk AxQ4cYNXn4k2rxRAscA= X-Received: by 10.223.153.166 with SMTP id y35mr1333051wrb.41.1495915983308; Sat, 27 May 2017 13:13:03 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-58-28.red.bezeqint.net. [79.178.58.28]) by smtp.gmail.com with ESMTPSA id p76sm5979216wma.15.2017.05.27.13.13.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 May 2017 13:13:02 -0700 (PDT) References: <149591558469.8616.9293762831257790142.idtracker@ietfa.amsl.com> To: acme@ietf.org, lurk@ietf.org From: Yaron Sheffer X-Forwarded-Message-Id: <149591558469.8616.9293762831257790142.idtracker@ietfa.amsl.com> Message-ID: Date: Sat, 27 May 2017 23:13:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <149591558469.8616.9293762831257790142.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------A11B07A0A094A80E680E7E3B" Content-Language: en-US Archived-At: Subject: [Acme] Fwd: New Version Notification for draft-sheffer-acme-star-02.txt X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 May 2017 20:13:07 -0000 This is a multi-part message in MIME format. --------------A11B07A0A094A80E680E7E3B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit We just submitted a new version of our certificate delegation draft, which we are requesting the ACME WG to adopt (to be discussed at the interim). The main changes are around terminology (now more general than just CDNs) and new text that describes the public cloud use case for this solution. Thanks, Yaron -------- Forwarded Message -------- Subject: New Version Notification for draft-sheffer-acme-star-02.txt Date: Sat, 27 May 2017 13:06:24 -0700 From: internet-drafts@ietf.org To: Oscar de Dios , Yaron Sheffer , Thomas Fossati , Diego Lopez , Oscar Gonzalez de Dios A new version of I-D, draft-sheffer-acme-star-02.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository. Name: draft-sheffer-acme-star Revision: 02 Title: Use of Short-Term, Automatically-Renewed (STAR) Certificates to Delegate Authority over Web Sites Document date: 2017-05-27 Group: Individual Submission Pages: 18 URL: https://www.ietf.org/internet-drafts/draft-sheffer-acme-star-02.txt Status: https://datatracker.ietf.org/doc/draft-sheffer-acme-star/ Htmlized: https://tools.ietf.org/html/draft-sheffer-acme-star-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-sheffer-acme-star-02 Diff: https://www.ietf.org/rfcdiff?url2=draft-sheffer-acme-star-02 Abstract: This memo proposes two mechanisms that work in concert to allow a third party (e.g., a content delivery network) to terminate TLS sessions on behalf of a domain name owner (e.g., a content provider). The proposed mechanisms are: Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------A11B07A0A094A80E680E7E3B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

We just submitted a new version of our certificate delegation draft, which we are requesting the ACME WG to adopt (to be discussed at the interim).

The main changes are around terminology (now more general than just CDNs) and new text that describes the public cloud use case for this solution.

Thanks,

    Yaron


-------- Forwarded Message --------
Subject: New Version Notification for draft-sheffer-acme-star-02.txt
Date: Sat, 27 May 2017 13:06:24 -0700
From: internet-drafts@ietf.org
To: Oscar de Dios <oscar.gonzalezdedios@telefonica.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Thomas Fossati <thomas.fossati@nokia.com>, Diego Lopez <diego.r.lopez@telefonica.com>, Oscar Gonzalez de Dios <oscar.gonzalezdedios@telefonica.com> 


A new version of I-D, draft-sheffer-acme-star-02.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:		draft-sheffer-acme-star
Revision:	02
Title:		Use of Short-Term, Automatically-Renewed (STAR) Certificates to Delegate Authority over Web Sites
Document date:	2017-05-27
Group:		Individual Submission
Pages:		18
URL:            https://www.ietf.org/internet-drafts/draft-sheffer-acme-star-02.txt
Status:         https://datatracker.ietf.org/doc/draft-sheffer-acme-star/
Htmlized:       https://tools.ietf.org/html/draft-sheffer-acme-star-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-sheffer-acme-star-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-sheffer-acme-star-02

Abstract:
   This memo proposes two mechanisms that work in concert to allow a
   third party (e.g., a content delivery network) to terminate TLS
   sessions on behalf of a domain name owner (e.g., a content provider).

   The proposed mechanisms are:

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat
--------------A11B07A0A094A80E680E7E3B-- From nobody Tue May 30 08:32:58 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 0C21E1294F8 for ; Tue, 30 May 2017 08:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 rzu5dBec9XMi for ; Tue, 30 May 2017 08:32:56 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 D271A129576 for ; Tue, 30 May 2017 08:32:55 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id 7so95109080wmo.1 for ; Tue, 30 May 2017 08:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=yb6U1oH5+BVk2pWAFUEryfOdbFFfTOkQk4muR30CjCY=; b=Y8pyfA5suA4VwMCop1KTUdnxlO8/bdAgIpn98zvnLWM65VLXRzNaGswhrI9wTHxVpe v1zz3uA9ZVShu/zFIAMofNtGyJVkNd7b0fUaEnSn8KbW7NViIkEogxDI0rpEZ5n2D+UT 2hM61ChdcHlYTO9LHCS7s7Jbp2ABg87/7cpJh/ChGNkj+0J/0UAfhcn+9P0OAFA+wRHe xqLjMUNPjudSYvufi+jWRtFfgvuaL+4zcSDvl2RzqxETAKnMnUJYs/G+y5YYjRBZnOZw SpCH13Nme1eYGCidwKIQTXB3svaYXoGNtNtjxDwZjp8E6RXYvkmRGT2qTooH640soVn2 af1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=yb6U1oH5+BVk2pWAFUEryfOdbFFfTOkQk4muR30CjCY=; b=NI59DdpQLgUt9h3HQfrOqm27lxXnkmyn7JffVfabxU+lqK26NL69sK/jPPZTSPW8Z9 dssqRPCKtS/xF4k0vEMGbOUI/dEgO/CM7BGN0brW5Fq9aLI3919SZLTbMVRkZUvuBFVG 28ZX/O8ChyIBOGk1tZqEDaeszSVBgl8vqYzwW/jYFC5y8m0P8qMHxkcBEyHuy9Oz9C8d Himw5/AtR4CJLhA6UU8xkmPlyPFkgOF/zrUro0QEspE3ZGFyDC+OxqbTrWbyRMbMntAL +m6AMnTi0HSjQC5Z/4ZiSrBqlAoo5R9g4+H1FUyJzGPSK6iJUloIFQBIyB0OF+mT8AFm vIuA== X-Gm-Message-State: AODbwcBfRjq+OkzlgYyUNe2NPv+Moma5hLswQzSWPXY7EMnaRGk/0N3R RJpDXhT3l5IMmBn9G4I= X-Received: by 10.28.169.198 with SMTP id s189mr2086291wme.91.1496158374196; Tue, 30 May 2017 08:32:54 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-58-28.red.bezeqint.net. [79.178.58.28]) by smtp.gmail.com with ESMTPSA id c8sm12437857wme.3.2017.05.30.08.32.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 08:32:53 -0700 (PDT) From: Yaron Sheffer To: acme@ietf.org Message-ID: <7526b3be-65ec-29b6-d657-3e19be06ea6a@gmail.com> Date: Tue, 30 May 2017 18:32:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Acme] ACME -06: HTTPS authorization X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:32:57 -0000 I'm not sure I understand why the section that describes HTTP validation so specifically forbids using HTTPS. On the other hand, I can think of use cases where I would want *only* HTTPS authorization:

- The server only supports HTTPS, and perhaps port 80 is blocked by a firewall. This situation applies to many REST endpoints.
- I am migrating from a non-ACME to an ACME cert, and so the server has a perfectly valid HTTPS cert. Or migrating from one ACME CA to a different one.
- I would like to ensure (using CAA records) that my CA is not subject to a DNS cache corruption attack - a threat that the ACME Security Considerations specifically mention.

I would suggest that we specify a HTTPS validation that's exactly like http-01, except that it runs over authenticated HTTPS.

Thanks,
    Yaron
From nobody Tue May 30 08:38:36 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 2ABF5129576 for ; Tue, 30 May 2017 08:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 sg2_pNrz-6Zn for ; Tue, 30 May 2017 08:38:32 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 16209129572 for ; Tue, 30 May 2017 08:38:32 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id 7so95244635wmo.1 for ; Tue, 30 May 2017 08:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MTTGQP1q0HBpRw2rOm9a4jlySy03Gm4OYfJc1KbAk1k=; b=1lMNKeD3sL/OOFi8UpYYL8yCM7+8LQbpdbCoUBs69Ph+ygbBY6T2SwsGIBTS8fFkWx FjcOqD4SUcRQ9rvcdFRdcJIv2PmWev4ezZkh8JlSXcffSo3bhluBnu9DWboLPNpH5VVa uK72oquIDJ4DulZcXg5dOL8gqVKe26KUdmznaXJJRWcgDSF6GKLEtNwabd9FCsmngWpt E0bxpt3Ck/CKvCDKlXwipojqZkS9usaWI7dvISUcTIx95+h8YjEbnedpYeqUxiRkMuRs Xcwn4SX9Xh+2Wm1RY4ZR2bY5gHMPQQtqM7L6QDFlvhzyQW2U4WollCqcYNrQ6TTqS6V0 WWmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MTTGQP1q0HBpRw2rOm9a4jlySy03Gm4OYfJc1KbAk1k=; b=sWV9yjbE09pjSsNq7JlP9oQUvAVbg7gZ8lqZhKADeyUtmohkdhu9+UJJu/d4AqO8ti nvQ2KGl76wZWUCVUhYncK7zK405Yn7uDv2l5iUxC1bRcj2jN2hNk41Lx0PDULveLiA6F wzoD0Bp8tCixLnHXlj5ZH+dqM5GqV0Be/AoROGWHyF4sem/0oPaLgKr8MbiLgeLvs+qL +BhFTLInGf2uK0yJgvyYrHtclV1SpN4vJnRYVfldJOf/RWFT/8EqquRS1SWP+u5oTCqw XjjichEBCAL5+9i6l/QFXKO4L7Y8w74sTfTmwbakM8Hm3SwU8HObNSdIxtVQI3L/SPjV +xow== X-Gm-Message-State: AODbwcBneKoRCFGw0m8MECdtB4hool1tI7xUxMeGWdnyRV1BnDxrGA1n 9u/50zhU/h5F87LoXFMchMemVcp9sOC8 X-Received: by 10.28.153.143 with SMTP id b137mr2288546wme.15.1496158710386; Tue, 30 May 2017 08:38:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.82 with HTTP; Tue, 30 May 2017 08:38:29 -0700 (PDT) In-Reply-To: <7526b3be-65ec-29b6-d657-3e19be06ea6a@gmail.com> References: <7526b3be-65ec-29b6-d657-3e19be06ea6a@gmail.com> From: Richard Barnes Date: Tue, 30 May 2017 11:38:29 -0400 Message-ID: To: Yaron Sheffer Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="001a114b37d87605b90550bf9841" Archived-At: Subject: Re: [Acme] ACME -06: HTTPS authorization X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:38:34 -0000 --001a114b37d87605b90550bf9841 Content-Type: text/plain; charset="UTF-8" On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer wrote: > I'm not sure I understand why the section that describes HTTP validation > so specifically forbids using HTTPS. > This was because of the default-vhost attack. https://ietf-wg-acme.github.io/acme/#rfc.section.11.2 Given that we don't really have any data on how common this vulnerability is, I'm split on whether to keep the restriction. --Richard > On the other hand, I can think of use cases where I would want *only* > HTTPS authorization: > > - The server only supports HTTPS, and perhaps port 80 is blocked by a > firewall. This situation applies to many REST endpoints. > - I am migrating from a non-ACME to an ACME cert, and so the server has a > perfectly valid HTTPS cert. Or migrating from one ACME CA to a different > one. > - I would like to ensure (using CAA records) that my CA is not subject to > a DNS cache corruption attack - a threat that the ACME Security > Considerations specifically mention. > > I would suggest that we specify a HTTPS validation that's exactly like > http-01, except that it runs over authenticated HTTPS. > > Thanks, > Yaron > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > --001a114b37d87605b90550bf9841 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer <<= a href=3D"mailto:yaronf.ietf@gmail.com" target=3D"_blank">yaronf.ietf@gmail= .com> wrote:
=20 =20 =20 =20
I'm not sure I understand why the section that describes HTTP validation so specifically forbids using HTTPS.

This was because of the default-vhost attack.

=
Given that we don't really have any data on how common this = vulnerability is, I'm split on whether to keep the restriction.

--Richard

=C2=A0
On the other hand, I can think of use cases where I would want *only* HTTPS authorization:

- The server only supports HTTPS, and perhaps port 80 is blocked by a firewall. This situation applies to many REST endpoints.
- I am migrating from a non-ACME to an ACME cert, and so the server has a perfectly valid HTTPS cert. Or migrating from one ACME CA to a different one.
- I would like to ensure (using CAA records) that my CA is not subject to a DNS cache corruption attack - a threat that the ACME Security Considerations specifically mention.

I would suggest that we specify a HTTPS validation that's exactly like http-01, except that it runs over authenticated HTTPS.

Thanks,
=C2=A0=C2=A0=C2=A0 Yaron

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


--001a114b37d87605b90550bf9841-- From nobody Tue May 30 08:42: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 511BE1296CF for ; Tue, 30 May 2017 08:42:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 FfxhvoFAJTEm for ; Tue, 30 May 2017 08:42:15 -0700 (PDT) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (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 893461295A0 for ; Tue, 30 May 2017 08:42:15 -0700 (PDT) Received: by mail-wr0-x22f.google.com with SMTP id g76so3066035wrd.1 for ; Tue, 30 May 2017 08:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=ZW7IKv42XSwano3a3zV4DKCjbEyoitRgoEX3np0kqQk=; b=buCnvhYs5AYl7NhGqF0++/U+qg0bEDequ7fRz4B30Dp/kwcx+i9WV26TOrfGHwbFpc AR4puVeIBrLKYFtUn3dJIn/08Mvpf9Owe5U9cNMiYZGLSEQjU5AGuiudlT+sGVti7gNy VcTt/gwatVPG5+Zoaw7Yvz1QUNZXbrcgFzdC5sXiK8Z1Ag7TpEq95bqufL6HkYyfEWQ9 NP5sTnXhPark2zz/swX66PV5mlk7PnoUTXwNEsdzs1H62xvgtCi7bcrVSUx2diskPvW2 As6d5xuMTuDOyu3sJe4n9yBhs9NoUIA4G3/yAVfr1wa+qY2KVGiRi3D62Y6mHuq/7kYn BjUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=ZW7IKv42XSwano3a3zV4DKCjbEyoitRgoEX3np0kqQk=; b=afxrqBo53rRxTXdC7mDurWHRTsxqVQDdIFb0hC8QWtZH7Qef5/v8Xvw+AloRpXln/I TctUBWM5lWxx7Z4GiLiDTj+OHo8qJHNj4sb5c/ml6dxtXtGodGT26M4993dyLkHs50DB 88PC8fnYHlvZoVVSXFhXlri8gKez2YZU7Gz4OJKXq8iY5x4eKZF9mDSOW3b5OXM+HMi7 Pk2b4VcpApRZ8p4ekX0SoOUT2k/3veS56VAq8rmpn/VsGNk0sY9u49cFFp1++wjJ19sp LPxZLR9pvEWGEWwcKdSg9fy1X+AHJzIDF74h5827+1LQc9X/qutz3el36vVw4ow3HU8S J5Cg== X-Gm-Message-State: AODbwcDi6RSbm5zR1auTMqQgIHh54HQJvAE+mrLr+2b5x3DOw8HvSlBx 3MutJ4ZNoqTBnSkjIFk= X-Received: by 10.223.152.18 with SMTP id v18mr13277655wrb.8.1496158933864; Tue, 30 May 2017 08:42:13 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-58-28.red.bezeqint.net. [79.178.58.28]) by smtp.gmail.com with ESMTPSA id b78sm11459786wmf.23.2017.05.30.08.42.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 08:42:13 -0700 (PDT) To: acme@ietf.org From: Yaron Sheffer Message-ID: Date: Tue, 30 May 2017 18:42:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Acme] ACME -06: revocation X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:42:17 -0000 When we allow the issued certificate to revoke itself, this has major implications, in particular for delegated certificates. But even for regular certs, it is the account's private key that's more secure (it is managed by the security personnel where such exist, it is not deployed on multiple servers) and that is the certificate that should be preferred for revocation. So I suggest to use MAY for revocation by the issued certificate's private key, instead of SHOULD. Also, including the actual certificate in the request means that the CA needs to perform multiple preliminary checks that would not be required if the client sent the certificate URL (or its serial number). The CA MUST parse the certificate, MUST validate it, MUST ensure that it was issued by the current CA, and then MUST identify it in its database of issued certs. More complexity, more opportunities for security holes. Thanks, Yaron From nobody Tue May 30 08:46: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 7F35F12957C for ; Tue, 30 May 2017 08:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 z6zXBXcYQNxh for ; Tue, 30 May 2017 08:46:03 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA8C12954D for ; Tue, 30 May 2017 08:46:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 71DE626E9F; Tue, 30 May 2017 18:46:00 +0300 (EEST) 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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id I5kfDzgEiESp; Tue, 30 May 2017 18:46:00 +0300 (EEST) 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 441A92313; Tue, 30 May 2017 18:46:00 +0300 (EEST) Date: Tue, 30 May 2017 18:45:57 +0300 From: Ilari Liusvaara To: Yaron Sheffer Cc: acme@ietf.org Message-ID: <20170530154557.GA5098@LK-Perkele-V2.elisa-laajakaista.fi> References: <7526b3be-65ec-29b6-d657-3e19be06ea6a@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7526b3be-65ec-29b6-d657-3e19be06ea6a@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] ACME -06: HTTPS authorization X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:46:05 -0000 On Tue, May 30, 2017 at 06:32:51PM +0300, Yaron Sheffer wrote: > > I'm not sure I understand why the section that describes HTTP > validation so specifically forbids using HTTPS. On the other hand, I > can think of use cases where I would want *only* HTTPS > authorization: > > - The server only supports HTTPS, and perhaps port 80 is blocked by > a firewall. This situation applies to many REST endpoints. > - I am migrating from a non-ACME to an ACME cert, and so the server > has a perfectly valid HTTPS cert. Or migrating from one ACME CA to a > different one. > - I would like to ensure (using CAA records) that my CA is not > subject to a DNS cache corruption attack - a threat that the ACME > Security Considerations specifically mention. > > I would suggest that we specify a HTTPS validation that's exactly > like http-01, except that it runs over authenticated HTTPS. The issue is that many webservers just pick the first vhost they find as default vhost, and attacker might be able to make oneself the default vhost for HTTPS (HTTP is seemingly also subject to similar behavior, but it is controlled by different options). If attacker can get itself as default vhost, he can pass validation for any domain name that isn't explicitly configured (for HTTP or HTTPS, depending on what is used for valdiation). -Ilari From nobody Tue May 30 08:48:13 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 131F0129A9A for ; Tue, 30 May 2017 08:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 va5eZ2wErYq3 for ; Tue, 30 May 2017 08:48:08 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 842621296B3 for ; Tue, 30 May 2017 08:48:08 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id b84so95824148wmh.0 for ; Tue, 30 May 2017 08:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=MUla3EyDnj38WuFNABwGT6wGDzt5jvvkZ963UsLNyzI=; b=fxQ0YQ3agCTQH+/YwGB+He/f9i3A4Dfy0vRmo7kRISqF9O1oJdGt2j4tRiduXSnLIM jA5qlIuao3ocd34WEzDdoiAyEuLNWx5mC2Df5Bc7Og7eMw4Wq7KLJVfuKbNXFEXrsZ62 c6oBsLQomSbj9/niVsCs1zjfQvDPrZA1DiToXbpY9diqHEGobigSS9TAH4/5rjF0MEo3 A7FEtXDXjOts+iV6atQhiELPf0QCZtXkTuXGJ/ewq+9FVl+yEfEmGxO9Szw+7V+ID31f hk6L3HLv9GQBDItfp+eZSLp61BlPevxbympaEwWAeY+EcCWQ3iO28jnEJMS68ngdPDz1 puUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=MUla3EyDnj38WuFNABwGT6wGDzt5jvvkZ963UsLNyzI=; b=swriyYdTn4rg31fx4R8PekFy1W0zh6qufrw7pzwJqMB51Z5NMttCktirkL3i/PGJ2B HvFuzm4qap7Y1sztizqBLxO56dMZ2Kw6tUh6bNjXvPS984oFXGYBOxGNCW46SsP4E/H5 LLl7vYSEtCUeBfeMmeFD2lSs+OwUnjSZQ1ayWf5NgeCJa8PdeXAwcFvZ4lFkbq1IXznI OVnvR3uHLVZ61jLpRaJGBh++6ffZcX4VLWJPoMB2Qzo5s3DSAtl3uyzB7D0s0jq/eIkH qcSB/lhtzGGngPp+FYbRnwpJCbaH+oxcEcE2/arrLphhagpHgH5UJCMxAoaB7bW9U2qC rbPw== X-Gm-Message-State: AODbwcCiUYtzcxDNzWEreC9sR84rslslFh/fpVmpSg0LC/5AeqiQ6XNi 9u3sKTw29osF/cGbnlE= X-Received: by 10.28.24.207 with SMTP id 198mr2177017wmy.86.1496159286825; Tue, 30 May 2017 08:48:06 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-58-28.red.bezeqint.net. [79.178.58.28]) by smtp.gmail.com with ESMTPSA id l190sm18092833wmb.18.2017.05.30.08.48.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 08:48:06 -0700 (PDT) To: Richard Barnes Cc: "acme@ietf.org" References: <7526b3be-65ec-29b6-d657-3e19be06ea6a@gmail.com> From: Yaron Sheffer Message-ID: <3764ff8c-dc46-70e7-e95f-c722fe38768a@gmail.com> Date: Tue, 30 May 2017 18:47:59 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7495FAA425B46332D0207802" Content-Language: en-US Archived-At: Subject: Re: [Acme] ACME -06: HTTPS authorization X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:48:11 -0000 This is a multi-part message in MIME format. --------------7495FAA425B46332D0207802 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit But removing the restriction would mean that the CA is free to do either HTTP or HTTPS, and the client doesn't know what to expect. So if my port 80 is firewalled, I'm still not in good shape. Thanks, Yaron On 30/05/17 18:38, Richard Barnes wrote: > > > On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer > wrote: > > I'm not sure I understand why the section that describes HTTP > validation so specifically forbids using HTTPS. > > > This was because of the default-vhost attack. > > https://ietf-wg-acme.github.io/acme/#rfc.section.11.2 > > Given that we don't really have any data on how common this > vulnerability is, I'm split on whether to keep the restriction. > > --Richard > > On the other hand, I can think of use cases where I would want > *only* HTTPS authorization: > > - The server only supports HTTPS, and perhaps port 80 is blocked > by a firewall. This situation applies to many REST endpoints. > - I am migrating from a non-ACME to an ACME cert, and so the > server has a perfectly valid HTTPS cert. Or migrating from one > ACME CA to a different one. > - I would like to ensure (using CAA records) that my CA is not > subject to a DNS cache corruption attack - a threat that the ACME > Security Considerations specifically mention. > > I would suggest that we specify a HTTPS validation that's exactly > like http-01, except that it runs over authenticated HTTPS. > > Thanks, > Yaron > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > > --------------7495FAA425B46332D0207802 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

But removing the restriction would mean that the CA is free to do either HTTP or HTTPS, and the client doesn't know what to expect. So if my port 80 is firewalled, I'm still not in good shape.

Thanks,

    Yaron


On 30/05/17 18:38, Richard Barnes wrote:


On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
I'm not sure I understand why the section that describes HTTP validation so specifically forbids using HTTPS.

This was because of the default-vhost attack.


Given that we don't really have any data on how common this vulnerability is, I'm split on whether to keep the restriction.

--Richard

 
On the other hand, I can think of use cases where I would want *only* HTTPS authorization:

- The server only supports HTTPS, and perhaps port 80 is blocked by a firewall. This situation applies to many REST endpoints.
- I am migrating from a non-ACME to an ACME cert, and so the server has a perfectly valid HTTPS cert. Or migrating from one ACME CA to a different one.
- I would like to ensure (using CAA records) that my CA is not subject to a DNS cache corruption attack - a threat that the ACME Security Considerations specifically mention.

I would suggest that we specify a HTTPS validation that's exactly like http-01, except that it runs over authenticated HTTPS.

Thanks,
    Yaron

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



--------------7495FAA425B46332D0207802-- From nobody Tue May 30 08:48:27 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 2B70C129576 for ; Tue, 30 May 2017 08:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 4BdhRbqL2r4L for ; Tue, 30 May 2017 08:48:15 -0700 (PDT) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 A72B6129A9D for ; Tue, 30 May 2017 08:48:13 -0700 (PDT) Received: by mail-wr0-x233.google.com with SMTP id g76so3166772wrd.1 for ; Tue, 30 May 2017 08:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9nmSmvspOPi3rqpwqcUEQdVR5ytW9vvMKukOL86t6FQ=; b=P3J3sf9O8GDoCqIWBJ0y+eLiwgo3W84hMZRDH0OvpnMF29Dp6hUDSd1IJedMzOOfIq ahIlG+ISYtnJNQFvuYdgjfYdMgeRFkIWsQfOhoKG6nTLGzpI1LKKHiAbyrJMhOIIodjw S6MSHuNPftst2Fqted08RlsHkifB4Sy4SInRLjXoFTD93amV8BN834zsfKU5O/3skZUC L5vqrhdkQcIxWTCKzHDdz4jnjkMJLeubJ4t+CvZDLXjIqc3JIvMpBGasqEVKfIgXokCU FmA+Z5u35jwEveR/iCi1EXjVNUApcaBzSq125TPRkm8iTJN9IsQ2i6bT9HuxtyW5AJ6+ aE0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9nmSmvspOPi3rqpwqcUEQdVR5ytW9vvMKukOL86t6FQ=; b=HLH27oRhJy1PINfPOQ+QFk62nbTrb02T9+QCgs6H4EpDpKqXuAr4JdY/sxH/CLsln1 026ZG4xaluN0F8kucFrc1aq9/vsHTPcNWWeCJnmRsSDRzg0tDIcM2aFKANv13z5ovCSF F/+tyZOPQ4vtI98YRKsbB91zl8zEDyS2GPBveMx1a4ZRBFFnPK/uF2ArEXmvkzgTMdqj VQCospccz0SXJjqR4/z0R6xazDyjejLfHG0L7TaETyJzHwHcl+rWb5Q/SKqqcT+1P+Jg GCKwcWarmFf1eQUtCbQJxttz0xXNyv264iM/xldoqM00Cw6I6zHsJsEcTDwc4r0y90hM kwkw== X-Gm-Message-State: AODbwcDd4BNKAUIw0Fl8rb92CVqxakvba/++lvOoW30kU//t4slS6nP3 nrAwgkF5pxVUXtfG1ORLKGtMEK0Gq8x0aN3Z+Q== X-Received: by 10.223.156.26 with SMTP id f26mr14237121wrc.187.1496159291455; Tue, 30 May 2017 08:48:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.82 with HTTP; Tue, 30 May 2017 08:48:10 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Tue, 30 May 2017 11:48:10 -0400 Message-ID: To: Yaron Sheffer Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1cd24418b8af0550bfbb79" Archived-At: Subject: Re: [Acme] ACME -06: revocation X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:48:17 -0000 --94eb2c1cd24418b8af0550bfbb79 Content-Type: text/plain; charset="UTF-8" On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer wrote: > When we allow the issued certificate to revoke itself, this has major > implications, in particular for delegated certificates. But even for > regular certs, it is the account's private key that's more secure (it is > managed by the security personnel where such exist, it is not deployed on > multiple servers) and that is the certificate that should be preferred for > revocation. So I suggest to use MAY for revocation by the issued > certificate's private key, instead of SHOULD. > You MAY not like the latest change we made, which upgraded this requirement to MUST :) https://github.com/ietf-wg-acme/acme/pull/300 > Also, including the actual certificate in the request means that the CA > needs to perform multiple preliminary checks that would not be required if > the client sent the certificate URL (or its serial number). The CA MUST > parse the certificate, MUST validate it, MUST ensure that it was issued by > the current CA, and then MUST identify it in its database of issued certs. > More complexity, more opportunities for security holes. > The idea of including the certificate (as well as allowing a certificate to revoke itself) was to support the case where an admin just finds a certificate + private key lying around, and wants to kill it. In that case, you have neither the Certificate URI nor the account private key. I would note that we have shifted from referencing keys by value to by reference in request JWS objects, requiring clients to track their account URIs. We made that change in the interest of forcing the server to look up a public key for the account, reducing the likelihood of the server accepting a signature by an unknown key. We might get some similar benefits here, but maybe not -- after all, if the certificate doesn't correspond to a URI, then it's probably not from this CA, in which case it the CA can't revoke it anyway. --Richard > > Thanks, > Yaron > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --94eb2c1cd24418b8af0550bfbb79 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer <<= a href=3D"mailto:yaronf.ietf@gmail.com" target=3D"_blank">yaronf.ietf@gmail= .com> wrote:
When we allow the issued certificate to revoke itself, this has major = implications, in particular for delegated certificates. But even for regula= r certs, it is the account's private key that's more secure (it is = managed by the security personnel where such exist, it is not deployed on m= ultiple servers) and that is the certificate that should be preferred for r= evocation. So I suggest to use MAY for revocation by the issued certificate= 's private key, instead of SHOULD.

= You MAY not like the latest change we made, which upgraded this requirement= to MUST :)

=

=C2=A0
Also, including the actual certificate in the request means that the CA nee= ds to perform multiple preliminary checks that would not be required if the= client sent the certificate URL (or its serial number). The CA MUST parse = the certificate, MUST validate it, MUST ensure that it was issued by the cu= rrent CA, and then MUST identify it in its database of issued certs. More c= omplexity, more opportunities for security holes.

=
The idea of including the certificate (as well as allowing a cer= tificate to revoke itself) was to support the case where an admin just find= s a certificate + private key lying around, and wants to kill it.=C2=A0 In = that case, you have neither the Certificate URI nor the account private key= .

I would note that we have shifted from refer= encing keys by value to by reference in request JWS objects, requiring clie= nts to track their account URIs.=C2=A0 We made that change in the interest = of forcing the server to look up a public key for the account, reducing the= likelihood of the server accepting a signature by an unknown key.

We might get some similar benefits here, but maybe not -- = after all, if the certificate doesn't correspond to a URI, then it'= s probably not from this CA, in which case it the CA can't revoke it an= yway.

--Richard

=C2= =A0

Thanks,
=C2=A0 =C2=A0 Yaron

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

--94eb2c1cd24418b8af0550bfbb79-- From nobody Tue May 30 08:49:54 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 44EF2129A9D for ; Tue, 30 May 2017 08:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 NFRLQIEvpe2d for ; Tue, 30 May 2017 08:49:46 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 122381293DB for ; Tue, 30 May 2017 08:49:46 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id q97so8434361wrb.2 for ; Tue, 30 May 2017 08:49:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PdJYxFkUw6HXKv/hB2p+nTKsXBg/MrtPfmTs1HeikiU=; b=EeMuWDwjIO1WqAHQMi7crM3N3SXhetBE+bniezBNeWKtpY7eCd87tdDniyOre27KRA GGy9kBRvjVxDBw4X/6xZOjZLGRGUB0UEwuuKAgfmmpgYKDSGrmEMjFf779ovC8MRXA2c Xiy8oxj8S54sf08Lx6w98AWCr84inaT8ET7gzaudwIN+9S/lP9+8YoXZp65mgFXHEBua 5BHt6uiSq3mi6bKccPR7/6WgmkC5v5E+FUszeQq597bnuaGc27szfkM9wOXAxXnAhOCf lCBISVAROQVfGGk0BfDS7+7wuTyJBZxJgCld/C4rI4adj5LQRhZHotfs/UPjr9e6FvFd vYiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PdJYxFkUw6HXKv/hB2p+nTKsXBg/MrtPfmTs1HeikiU=; b=F+SBBUYdka2ytPcmtel8koCmjiBr2bvImDf4pL2zR5VER/J4uY3vq20QRK77ND20aX r6gvyGyyeWISbVcTvOysDscpT4UHpKNk49AMw0H641BX2zZl1Tt2JyEOxwYMztDaadLo QMQ+xxKik1RwtEO0dC7Irvg8LQ2HGHoZFuREfQsw5VCFL1wHKM0fUr+MqoChCukoClNS dWlzJHO0YEFbZ5JUNf/Sl1j4nNQuUzDS1qU49JDwQq9QK8+s7MakaBxy67LVqOoBPm1T s/rBIp8HH814bQUL2KdLaZfk5IXMOH8cbF5a5+60qtbQBHsfprx+mXv4CmzuxWD1BAZU FN2g== X-Gm-Message-State: AODbwcD4Y4j6nPhq/isPW6l9+Pvt+rcZHHhTtmkRr4vYPN8yG4iSsjyk +19oBUjSy+bvAEz0x3lfdfBsHAjetIispl8= X-Received: by 10.223.142.150 with SMTP id q22mr7721372wrb.180.1496159384531; Tue, 30 May 2017 08:49:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.82 with HTTP; Tue, 30 May 2017 08:49:43 -0700 (PDT) In-Reply-To: <3764ff8c-dc46-70e7-e95f-c722fe38768a@gmail.com> References: <7526b3be-65ec-29b6-d657-3e19be06ea6a@gmail.com> <3764ff8c-dc46-70e7-e95f-c722fe38768a@gmail.com> From: Richard Barnes Date: Tue, 30 May 2017 11:49:43 -0400 Message-ID: To: Yaron Sheffer Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="f403045f50b8a4b03a0550bfc0b9" Archived-At: Subject: Re: [Acme] ACME -06: HTTPS authorization X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:49:48 -0000 --f403045f50b8a4b03a0550bfc0b9 Content-Type: text/plain; charset="UTF-8" That just argues for adding for an "https-06" (which is always HTTPS) to go alongside "http-01" (which is always HTTP). On Tue, May 30, 2017 at 11:47 AM, Yaron Sheffer wrote: > But removing the restriction would mean that the CA is free to do either > HTTP or HTTPS, and the client doesn't know what to expect. So if my port 80 > is firewalled, I'm still not in good shape. > > Thanks, > > Yaron > > On 30/05/17 18:38, Richard Barnes wrote: > > > > On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer > wrote: > >> I'm not sure I understand why the section that describes HTTP validation >> so specifically forbids using HTTPS. >> > > This was because of the default-vhost attack. > > https://ietf-wg-acme.github.io/acme/#rfc.section.11.2 > > Given that we don't really have any data on how common this vulnerability > is, I'm split on whether to keep the restriction. > > --Richard > > > >> On the other hand, I can think of use cases where I would want *only* >> HTTPS authorization: >> >> - The server only supports HTTPS, and perhaps port 80 is blocked by a >> firewall. This situation applies to many REST endpoints. >> - I am migrating from a non-ACME to an ACME cert, and so the server has a >> perfectly valid HTTPS cert. Or migrating from one ACME CA to a different >> one. >> - I would like to ensure (using CAA records) that my CA is not subject to >> a DNS cache corruption attack - a threat that the ACME Security >> Considerations specifically mention. >> >> I would suggest that we specify a HTTPS validation that's exactly like >> http-01, except that it runs over authenticated HTTPS. >> >> Thanks, >> Yaron >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> > > --f403045f50b8a4b03a0550bfc0b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That just argues for adding for an "https-06" (w= hich is always HTTPS) to go alongside "http-01" (which is always = HTTP).

On Tue, May 30, 2017 at 11:47 AM, Yaron Sheffer <yaronf.ietf@gmail.= com> wrote:
=20 =20 =20

But removing the restriction would mean that the CA is free to do either HTTP or HTTPS, and the client doesn't know what to expect. So if my port 80 is firewalled, I'm still not in good shape.

Thanks,

=C2=A0=C2=A0=C2=A0 Yaron


On 30/05/17 18:38,= Richard Barnes wrote:


On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
I'm not= sure I understand why the section that describes HTTP validation so specifically forbids using HTTPS.

This was because of the default-vhost attack.


Given that we don't really have any data on how common this vulnerability is, I'm split on whether to keep the restriction.

--Richard

=C2=A0
On the other hand, I can think of use cases where I would want *only* HTTPS authorization:

- The server only supports HTTPS, and perhaps port 80 is blocked by a firewall. This situation applies to many REST endpoints.
- I am migrating from a non-ACME to an ACME cert, and so the server has a perfectly valid HTTPS cert. Or migrating from one ACME CA to a different one.
- I would like to ensure (using CAA records) that my CA is not subject to a DNS cache corruption attack - a threat that the ACME Security Considerations specifically mention.

I would suggest that we specify a HTTPS validation that's exactly like http-01, except that it runs over authenticated HTTPS.

Thanks,
=C2=A0=C2=A0=C2=A0 Yaron

_______________________________________________
Acme mailing list
Acme@ietf.= org
https://www.ietf.org/mailman/listinfo/a= cme




--f403045f50b8a4b03a0550bfc0b9-- From nobody Tue May 30 08:51:58 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 E365D129AA3 for ; Tue, 30 May 2017 08:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 ChlgC2cj1FRT for ; Tue, 30 May 2017 08:51:50 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::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 B55C1129A9D for ; Tue, 30 May 2017 08:51:45 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id q97so8467354wrb.2 for ; Tue, 30 May 2017 08:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=7+cwW/VCs/8KCBvIDzzGe7N5g18gWPeEjQdrlPhq4V8=; b=bP1wX8+W50p2jR7UUpyZ7eb+bVPKLTy6mpnT1nMBk+ytV2kcrSZUTyAtpJlfq8/ogl SPKwAqBzBsNXtvfYcj7ejaweNFZMX3NoxJgM3R1TZpPx8VQfag0JyR48t521L1qJPKwP teDV+Iq5jHkqd3hxaVCQH5jPZrEbQ87MaHhSnNLjLnKnKLvDKGcy4AdHXhs/IlCtRwmM 0B0llL5tma+U7UjkVXxybFJWWiDJlQCpnYpqf4g5t6ptvxY4srV/HvmG9vZep02Uz7sm 8x5w/LGOkMAoSi4yB2B9RaPx0QFCxa34TpBV+6X7sgZ8yvevJRPBAJ9nC8zCrhocYSPK tapw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=7+cwW/VCs/8KCBvIDzzGe7N5g18gWPeEjQdrlPhq4V8=; b=p19dqDQ9HZVXbtwUr+EfEfQPdQsHfmvuaOKx6OCvS4quwJjY3sexD+a1h+tYxTdYYq gQltRqSiTuuBjNis9lba8bzju0Bd3Jz4REKIzRbku2OU2FuQTvbNo69rmidEHyHDD0Un 6cd2K6cXSSLy2tGAT5G2WFBjOyJ9+LiToRaNzm4TIv3b4K0TpZdtxVBFryFU9Oy4ywGy 8yPhy3sgRNTYnf4OsD/22hynreynLw5OWk1M56Xf4U3L1tR0nwq7opXfmxT48/epMYTH flKz/H2vF/RmUjXnOkJF60syXNQYM2GChTAONkDjCjg1sKUW7K5RPwrAQZjcuBmiaaRK ai0w== X-Gm-Message-State: AODbwcCgKCuFEJXujmv7GW4KYZX9AmO8Fu5qsKeMD9ThwFCVJz76yWKm 1lkQ2xTGt2Umx8Nh6Bo= X-Received: by 10.223.134.150 with SMTP id 22mr13626522wrx.121.1496159504121; Tue, 30 May 2017 08:51:44 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-58-28.red.bezeqint.net. [79.178.58.28]) by smtp.gmail.com with ESMTPSA id y16sm18043123wry.46.2017.05.30.08.51.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 08:51:43 -0700 (PDT) To: "acme@ietf.org" From: Yaron Sheffer Message-ID: <1dabba80-765e-d39b-bc69-c1bd41ce1646@gmail.com> Date: Tue, 30 May 2017 18:51:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [Acme] ACME -06 - notBefore/notAfter X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:51:52 -0000 In the "Applying for Certificate Issuance" section: the notBefore and notAfter fields are not part of the CSR, and it is not clear if the server is allowed to change them according to its own policy. E.g. for a shorter period than requested. Thanks, Yaron From nobody Tue May 30 08:52: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 3C88D129A9D for ; Tue, 30 May 2017 08:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 9QsPZ-G-2Fsj for ; Tue, 30 May 2017 08:52:32 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 814711293DB for ; Tue, 30 May 2017 08:52:32 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id 7so95583969wmo.1 for ; Tue, 30 May 2017 08:52:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=tFNvayzfQQnIBBpCt75e3tbzINyt5Je+2UwAifz28iI=; b=ILf7LqYwCZPwCC5BXHR6mgO4OAkC3CfX2feT4ZDOpdNLs0csbB6o1aSMooBPQYuZI/ zTC289Bq4E6kH39XNGshtFZF8SKj3uFgThSkYldAn9HhDwoWOg8Mci3Gow4aSoZd5ZqK IuWxExrodRkNQSCZp1ycLhzK3O1U0ap0k2svgwxuGTZptRgxBG/XenmKCeqXIHwqUpiG Irt1dsIUNBRUPv2HYT/5mkmG701hcQ2+uHV3/DBoFnObDXOJb4ni+T3o8hFdiEQ/kh3+ d7Yt1C9IiJzl5UQ2LunTJ6qjWWGY+7lhi/H/MmMhaWgqYUqOK+NG3ixy/rioSAHrbpSM hkvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=tFNvayzfQQnIBBpCt75e3tbzINyt5Je+2UwAifz28iI=; b=UsGkffjZ7IbpqkI0VDOWWurfwekRpe6lQY2dUo/75QPL99qW4xtUBPT/ZU0we+eR8U lcR3gKENNYAHncTTYSm2bj2pYttz7lE/tv4aJGy0QJrtCPYjIWjEA14c59dSMkSzOBjN AD+Tx6LUjTmAJ68Ulj+bPg5wILb7uQUpQBxjHW5gsGGOzkl6iFrLH2EIbbGYK0ng78bO duXVVnDXLRt1ASQeYfcXZPd1/zLeh8vqxJ9wJr6Mv1lX07gPMC9sPpRAzAU+9y5QfYfi eZ1JXLn7Vm8kUbsN103gvGJch9lr17iX2nrc2dAnEhbsYQkv+A5xxpcCveFEcsMqMeC6 6UMg== X-Gm-Message-State: AODbwcDXBaZRx4DNVJArMWZmvLfm5Z2dytOoQiQnktrG5FeZXw2xL3C1 c/oukYzDsGCyx7JVE0c= X-Received: by 10.28.23.9 with SMTP id 9mr2156928wmx.108.1496159550813; Tue, 30 May 2017 08:52:30 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-58-28.red.bezeqint.net. [79.178.58.28]) by smtp.gmail.com with ESMTPSA id w68sm20237390wrb.49.2017.05.30.08.52.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 08:52:30 -0700 (PDT) To: acme@ietf.org From: Yaron Sheffer Message-ID: Date: Tue, 30 May 2017 18:52:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Acme] ACME -06: smaller issues X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:52:34 -0000 * Order Objects, "authorizations". The text says, "For final orders, the authorizations that were completed." Are we using "completed" to mean "successfully completed"? Maybe we should say so explicitly. * Directory object: not wishing to be drawn into the TOS discussion again, but I think the example would be more useful, if the URL was https://example.com/acme/terms/2017-5-30 instead of https://example.com/acme/terms, because clients can then detect changes more easily. * Changes of Terms of Service: the example is missing the mandatory Link header that's mentioned in the text. * Account key roll-over: the current check #8 is "Check that the “newKey” field of the key-change object also verifies the inner JWS." I think that requiring that "newKey" is bitwise identical to the inner "jwk" is both strictier and more correct. * Account deactivation: shouldn't we also say that all pending Orders MUST be invalidated? * Downloading the Certificate: in the example, the client asks for a single cert (Accept: application/pkix-cert) and receives a chain (application/pem-certificate-chain) - is this legal? This also seems to conflict with the last paragraph of the section. * MIME Type: application/pem-certificate-chain - typo: "Carries a cryptographic certificate" should be "Carries a list of cryptographic certificates" Thanks, Yaron From nobody Tue May 30 08:53: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 3FC4F1294C4 for ; Tue, 30 May 2017 08:53:50 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains text/plain,.exe X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 v-MIifENj-5Y for ; Tue, 30 May 2017 08:53:48 -0700 (PDT) Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 C18A9129A9D for ; Tue, 30 May 2017 08:53:46 -0700 (PDT) Received: by mail-wr0-x22a.google.com with SMTP id j27so3183108wre.3 for ; Tue, 30 May 2017 08:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aeuOsKfylxe2uZeFqT0VTRdbKOkDpFDwCQCp/2u/Gzs=; b=07iGeaIDDA0rqPC9o6GFclqrgIn9JXiHDbFj3HFJXgcEfN30ZAAskfmsiEhEJd2ll4 OOH9PubL3adIgissUJqo7jkzbk3bCypdxB41DViNm9Zi9DU/gqqCrfdqxKJjlfilMPgh nPXFvD0mF36I7/wnuApHywNk4GPCdLVJmi7tFHNWBATHdHK4d1Y2SbSohLnhWkLva7Sh xsovhdB5AywOFs/TfLJaN/90+C3jCKESvLa8mW6eHqEtzLNJCC8Uyz9GZ+B6x2+VAgB3 aFTfdN1iCFfHdtsRHSopP/33EQYzmbyDM/EhEwdbyTBrqANzSQIjf8E5EUOPghseBr7C 3SqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aeuOsKfylxe2uZeFqT0VTRdbKOkDpFDwCQCp/2u/Gzs=; b=a1PSDp1oFGTDTMFp6v3xtp/bJ7bupilCW6mBgqKgT4KtagfeQUJwPTZzc4fzp+sTTj y7hWE3omqQKvg4+Pzj8+lSPIckwiBU0/AlgtRg7oYTzCtoxBZCbZZ26KKmHYj7uNov5O rMJ2utoQEEsnQGmmQk4JRrsF8Tf4AMub+04jIkJsVSAhY11kUdNdqH1ckHbDrU2oiOE1 DA5G/aOhVPokRNxtXKLxrgY1LGS14DiJPsQj386nI432pBTE9ja/sJe8F94IuZEMwrU0 +3KcKQSZZwGohzm9s0r+eGYgFBDhjFuUduVQN8m8PVrshXHIMBhH4mngns0pVFYyQjei C7fA== X-Gm-Message-State: AODbwcDVRERlpXySej7ypEnUvM6HMOVJIN5qUQxpNEFuIpVkbZwK1ohD wSHEApvawqAc4spFRGstDL17ByG2gxICgplN9A== X-Received: by 10.223.156.26 with SMTP id f26mr14254226wrc.187.1496159625259; Tue, 30 May 2017 08:53:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.82 with HTTP; Tue, 30 May 2017 08:53:44 -0700 (PDT) In-Reply-To: <1dabba80-765e-d39b-bc69-c1bd41ce1646@gmail.com> References: <1dabba80-765e-d39b-bc69-c1bd41ce1646@gmail.com> From: Richard Barnes Date: Tue, 30 May 2017 11:53:44 -0400 Message-ID: To: Yaron Sheffer Cc: "acme@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1cd244fdc0090550bfce3d" Archived-At: Subject: Re: [Acme] ACME -06 - notBefore/notAfter X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:53:50 -0000 --94eb2c1cd244fdc0090550bfce3d Content-Type: text/plain; charset="UTF-8" """ The server MUST return an error if it cannot fulfill the request as specified, and MUST NOT issue a certificate with contents other than those requested. """ https://ietf-wg-acme.github.io/acme/#rfc.section.7.4 On Tue, May 30, 2017 at 11:51 AM, Yaron Sheffer wrote: > In the "Applying for Certificate Issuance" section: the notBefore and > notAfter fields are not part of the CSR, and it is not clear if the server > is allowed to change them according to its own policy. E.g. for a shorter > period than requested. > > Thanks, > Yaron > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > --94eb2c1cd244fdc0090550bfce3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"""
The server MUST return a= n error if it cannot fulfill the request as=20 specified, and MUST NOT issue a certificate with contents other than=20 those requested.
"""



On Tue, May 30, 2017 at 11:= 51 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">In the "Applying for = Certificate Issuance" section: the notBefore and notAfter fields are n= ot part of the CSR, and it is not clear if the server is allowed to change = them according to its own policy. E.g. for a shorter period than requested.=

Thanks,
=C2=A0 =C2=A0 Yaron

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

--94eb2c1cd244fdc0090550bfce3d-- From nobody Tue May 30 08:59:33 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 96E8F1293DB for ; Tue, 30 May 2017 08:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 zDiuUStB7B_F for ; Tue, 30 May 2017 08:59:28 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 24713126B6D for ; Tue, 30 May 2017 08:59:28 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id q97so8595054wrb.2 for ; Tue, 30 May 2017 08:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Ri+ucLLFmCINQxuI128hSTdfkiiP1KFO8U4Aa0ET0jw=; b=mPDSYUTvZM7RsrMRxgYz4O6mDYCYCoJRDgka4umkfoVBoJrrTjXGTXXtc+I2/EGRn6 DW7ynxttmJnzOrnY4ZWrcxvdVphRAxyVEb5geSRlBtMGmfEqdLEOoF9pJnDcTbvzKldD SZY4KG5r28kjGECSn+6eZEmtPVMbOUh4rzhsQziPx6EF8LkaHBH/q7ZX6lIPmUICYCWd 1nVq8mYmWqUTpXN1YxLoqDFdvkdJx5cylL8v1PItYpkUcK/2Y9wpqel36VyXVIL+SceI AnlmJIMY9nhV8RJTpgy4v3u5XEnd7DiPelBr0k3YHa+DN56wdlXrUVCh4zBCgfYIeayg agFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Ri+ucLLFmCINQxuI128hSTdfkiiP1KFO8U4Aa0ET0jw=; b=OTfTMVj09H+8nNQwcmcneHNs6C8iqTeK0SYvSfc0tf3Wdj/SO/Xyqd9yO6FALo/x2m njXNKlt7OD9si2KxV+5i41NVdefPRNkIJ54q0Snh28gOgLmJu9uNQ9otWDKKa1TL6SKz vOn01dAkWswSrAY4BOBKS8tZZPLON2U+TsOvnSw2LcbV0xIrg8C6TP5VWvZOyZOYczx8 IPvRysJgWeYXVvPRP2ctKgWbMXLZBCZEWC4Bqd5ljlC2ca4c1mgFpezcdE5UMCNVX30c YRFmdXGpOv2jE0y8oePj1Ac6TF0Cu1kaRnAQ229wsylEpWBF1rgOwaQ/6TjkKpz9aXpw 6JPg== X-Gm-Message-State: AODbwcAzAh+QT4cXIQMXaPUb11jA1dcfRFuGomXQoCaUN4Plss1WFV+B 9ELLIiCZhSoQVF9Sv1U= X-Received: by 10.223.129.229 with SMTP id 92mr15020521wra.57.1496159966514; Tue, 30 May 2017 08:59:26 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-58-28.red.bezeqint.net. [79.178.58.28]) by smtp.gmail.com with ESMTPSA id b78sm11523912wmf.23.2017.05.30.08.59.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 08:59:25 -0700 (PDT) To: Richard Barnes Cc: "acme@ietf.org" References: From: Yaron Sheffer Message-ID: Date: Tue, 30 May 2017 18:59:21 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DD6AF0AFF895988B3CE9ADD1" Content-Language: en-US Archived-At: Subject: Re: [Acme] ACME -06: revocation X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 15:59:31 -0000 This is a multi-part message in MIME format. --------------DD6AF0AFF895988B3CE9ADD1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 30/05/17 18:48, Richard Barnes wrote: > > > On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer > wrote: > > When we allow the issued certificate to revoke itself, this has > major implications, in particular for delegated certificates. But > even for regular certs, it is the account's private key that's > more secure (it is managed by the security personnel where such > exist, it is not deployed on multiple servers) and that is the > certificate that should be preferred for revocation. So I suggest > to use MAY for revocation by the issued certificate's private key, > instead of SHOULD. > > > You MAY not like the latest change we made, which upgraded this > requirement to MUST :) > > https://github.com/ietf-wg-acme/acme/pull/300 > > Also, including the actual certificate in the request means that > the CA needs to perform multiple preliminary checks that would not > be required if the client sent the certificate URL (or its serial > number). The CA MUST parse the certificate, MUST validate it, MUST > ensure that it was issued by the current CA, and then MUST > identify it in its database of issued certs. More complexity, more > opportunities for security holes. > > > The idea of including the certificate (as well as allowing a > certificate to revoke itself) was to support the case where an admin > just finds a certificate + private key lying around, and wants to kill > it. In that case, you have neither the Certificate URI nor the > account private key. > > I would note that we have shifted from referencing keys by value to by > reference in request JWS objects, requiring clients to track their > account URIs. We made that change in the interest of forcing the > server to look up a public key for the account, reducing the > likelihood of the server accepting a signature by an unknown key. > > We might get some similar benefits here, but maybe not -- after all, > if the certificate doesn't correspond to a URI, then it's probably not > from this CA, in which case it the CA can't revoke it anyway. > > --Richard > I certainly don't like the latest change :-) I understand the use case of "finding a key lying around" (although I've never personally found a key lying around), but if you think of an enterprise with a small group of people managing security but a much larger group of people with access to server certs, this provides any server admin with a trivial way to DoS the organization by revoking www.bigcorp.com, so trivial that people can do it by mistake. Thanks, Yaron --------------DD6AF0AFF895988B3CE9ADD1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 30/05/17 18:48, Richard Barnes wrote:


On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
When we allow the issued certificate to revoke itself, this has major implications, in particular for delegated certificates. But even for regular certs, it is the account's private key that's more secure (it is managed by the security personnel where such exist, it is not deployed on multiple servers) and that is the certificate that should be preferred for revocation. So I suggest to use MAY for revocation by the issued certificate's private key, instead of SHOULD.

You MAY not like the latest change we made, which upgraded this requirement to MUST :)


 
Also, including the actual certificate in the request means that the CA needs to perform multiple preliminary checks that would not be required if the client sent the certificate URL (or its serial number). The CA MUST parse the certificate, MUST validate it, MUST ensure that it was issued by the current CA, and then MUST identify it in its database of issued certs. More complexity, more opportunities for security holes.

The idea of including the certificate (as well as allowing a certificate to revoke itself) was to support the case where an admin just finds a certificate + private key lying around, and wants to kill it.  In that case, you have neither the Certificate URI nor the account private key.

I would note that we have shifted from referencing keys by value to by reference in request JWS objects, requiring clients to track their account URIs.  We made that change in the interest of forcing the server to look up a public key for the account, reducing the likelihood of the server accepting a signature by an unknown key.

We might get some similar benefits here, but maybe not -- after all, if the certificate doesn't correspond to a URI, then it's probably not from this CA, in which case it the CA can't revoke it anyway.

--Richard

I certainly don't like the latest change :-)

I understand the use case of "finding a key lying around" (although I've never personally found a key lying around), but if you think of an enterprise with a small group of people managing security but a much larger group of people with access to server certs, this provides any server admin with a trivial way to DoS the organization by revoking www.bigcorp.com, so trivial that people can do it by mistake.

Thanks,

    Yaron


--------------DD6AF0AFF895988B3CE9ADD1-- From nobody Tue May 30 09:03:29 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 D0B68126E01 for ; Tue, 30 May 2017 09:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 2oHg2GFUCaoq for ; Tue, 30 May 2017 09:03:22 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 E523F1294C4 for ; Tue, 30 May 2017 09:03:21 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id e127so104870012wmg.1 for ; Tue, 30 May 2017 09:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=hjpAAt9hJ05sp9FIC2xjUH+CZEPaVz0FHsXjCcubnbk=; b=XqwjVzR4xgCbET8fe1TEl/mVoaiXdpSlNc8iT7He1Xegh82w9dqIcc3wQuv7WwHC9h LuoahfkJOLnxJJZvbP8YrUC/+qQm/uCr6BnJCHtcgrM2bR3F3FjYQimQvF6yTGJJyK5A ho77c/KHmhdaQ3fAeGlfVzWSZ7o2Evwhpc9p5ruvAtKklBL23ApptDQqUcOYsHoSTtm5 UNjuOjlHIha6ZDYr1kv244YNJSTpFZN3ovdkzKEQUAbee2HZPMqnIO9cjWv2z7YwzI3O M2CtcsyFvaPJSyOZGAptbpi6XuLJ+yJLddiVfoZZYv6UsqdHJsXlO1VZFcEYQVCGfU9S 8sww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=hjpAAt9hJ05sp9FIC2xjUH+CZEPaVz0FHsXjCcubnbk=; b=sWXnz7Du0AKBe429csCqBiRI7X7dAmIqT3zKsREeRKXp03RRNIOGl11aMrDknCa8bI 9hTbMRyJ49CW95FfK7NQ7zclJzeWI0+NoNMBbQKrNPEa69o5WKorhZZ8J5H3TfDqqcci Q5TsSZWHeMhQOZmdzqqmRBZXWiPfvnm/wuKhGlVqJZcDrYUN5h8FkKk8EH7+6C8IFWaA gx6r+ujvak9G8nPRRc5ccoY+PWWC7Rz96pbIGcv5SMXQRIx+9DvEhxlNjHTsXirmNd6n FrKjq8n12k12sv8wuppmeWsqq57OGlTXU/dbjfIix2kTFKyQEaKzLhze9gLgBVym0DJI 7dnA== X-Gm-Message-State: AODbwcDq69KG28JpKGjDV1dEKtbacGWJc35t2Zmax2dhy4N+jEt1DNsN khVoCO5KlnJKYKf7kgU= X-Received: by 10.28.31.16 with SMTP id f16mr2402580wmf.118.1496160200278; Tue, 30 May 2017 09:03:20 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-58-28.red.bezeqint.net. [79.178.58.28]) by smtp.gmail.com with ESMTPSA id 97sm8401750wrc.5.2017.05.30.09.03.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 09:03:19 -0700 (PDT) To: Richard Barnes Cc: "acme@ietf.org" References: <1dabba80-765e-d39b-bc69-c1bd41ce1646@gmail.com> From: Yaron Sheffer Message-ID: Date: Tue, 30 May 2017 19:03:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8E4AB337E0D8529D2D638D4B" Content-Language: en-US Archived-At: Subject: Re: [Acme] ACME -06 - notBefore/notAfter X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 16:03:24 -0000 This is a multi-part message in MIME format. --------------8E4AB337E0D8529D2D638D4B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit OK, that wasn't clear to me in the context. Maybe change to: The server MUST return an error if it cannot fulfill the request as specified (including the CSR any other fields), and MUST NOT issue a certificate with contents other than those requested. On 30/05/17 18:53, Richard Barnes wrote: > """ > The server MUST return an error if it cannot fulfill the request as > specified, and MUST NOT issue a certificate with contents other than > those requested. > """ > > https://ietf-wg-acme.github.io/acme/#rfc.section.7.4 > > > On Tue, May 30, 2017 at 11:51 AM, Yaron Sheffer > wrote: > > In the "Applying for Certificate Issuance" section: the notBefore > and notAfter fields are not part of the CSR, and it is not clear > if the server is allowed to change them according to its own > policy. E.g. for a shorter period than requested. > > Thanks, > Yaron > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme > > > --------------8E4AB337E0D8529D2D638D4B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

OK, that wasn't clear to me in the context. Maybe change to:


The server MUST return an error if it cannot fulfill the request as specified (including the CSR any other fields), and MUST NOT issue a certificate with contents other than those requested.

On 30/05/17 18:53, Richard Barnes wrote:
"""
The server MUST return an error if it cannot fulfill the request as specified, and MUST NOT issue a certificate with contents other than those requested.
"""



On Tue, May 30, 2017 at 11:51 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
In the "Applying for Certificate Issuance" section: the notBefore and notAfter fields are not part of the CSR, and it is not clear if the server is allowed to change them according to its own policy. E.g. for a shorter period than requested.

Thanks,
    Yaron

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


--------------8E4AB337E0D8529D2D638D4B-- From nobody Tue May 30 09:04:45 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 05E3412954D for ; Tue, 30 May 2017 09:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 Dz75DzUXIv6M for ; Tue, 30 May 2017 09:04:41 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 B0917126E01 for ; Tue, 30 May 2017 09:04:40 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id b84so96222586wmh.0 for ; Tue, 30 May 2017 09:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=iyS7ePeflv/SmAuEJ13w/jb+0TPhNPmu52SLdflWAFE=; b=KrynHd/hMvmiCWa1xegTEaELy4PvZeSZ6tKi1GKbKVD87YCwqRGRsHE4ZktT12Ujhf wdEHjem8BbznZ2sEV61MSvmlc+HHvs6+xzmyBcKATHD1eaRNp0gYiTb3pt2wWXawITYU 4NgU0UhwlbcUEQwIhHoBWiOBJ2U6/vfKIRNCDE8BNVHH9xqbfk2o79isadts7iht0enH A/b1BwRzUqv8o415/gkxzJHhgi3ECVY63Zju0HJ29S8OuTUvHqF0HyUzJXr8pKfeyQaj iQXssBrzpjHW1WPo0JV6NcdLhfJHi2+xal1kNh4tfktQ4TITaduKQtgjHnYZ7p0HZjij mCHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=iyS7ePeflv/SmAuEJ13w/jb+0TPhNPmu52SLdflWAFE=; b=owk02BhBgRD4nu1xGuCGLfptJqjPCf1ajzZDqve/UtIHbBv01lKKe8bwT/LPfbL7bR XHu06IhvGnJeNL9DtulcM581c9qtGt2KA/xpQoIoSdHI76qILdPPrmRz7LXo4axZQgSM MGnLT/xUfyWQs1QNB1A3wRotHMiQd384ryi2P/w099WBHzk1bBplMFHsjfIhTInryIU+ 038r5p9GFCJFABal3AK/UmlliwP/9iIJujCMqr7owcRA86oZnWn795VXZ0lZiKAe1VFm gHTWWPahmViBa6PFGn0MHAbEuPYc07zkZqQiHvgGtto9WEIgQLnhdiHy7hYcbpKUzao6 8dZw== X-Gm-Message-State: AODbwcDHh3URE8fcDPobuRSxWHYz+mSaGtI47gYtXRuclBI5eOP9RNHM N2rl5FeVxPv5GYzYedk= X-Received: by 10.28.32.19 with SMTP id g19mr2187519wmg.123.1496160278179; Tue, 30 May 2017 09:04:38 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-58-28.red.bezeqint.net. [79.178.58.28]) by smtp.gmail.com with ESMTPSA id u141sm16903513wmd.28.2017.05.30.09.04.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 09:04:37 -0700 (PDT) To: Richard Barnes Cc: "acme@ietf.org" References: <7526b3be-65ec-29b6-d657-3e19be06ea6a@gmail.com> <3764ff8c-dc46-70e7-e95f-c722fe38768a@gmail.com> From: Yaron Sheffer Message-ID: <0472ebc1-8e59-ebe4-0f46-d82520f17f60@gmail.com> Date: Tue, 30 May 2017 19:04:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------2A5F8FAF61DC48AE537DBFF8" Content-Language: en-US Archived-At: Subject: Re: [Acme] ACME -06: HTTPS authorization X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 16:04:43 -0000 This is a multi-part message in MIME format. --------------2A5F8FAF61DC48AE537DBFF8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Yes, exactly. On 30/05/17 18:49, Richard Barnes wrote: > That just argues for adding for an "https-06" (which is always HTTPS) > to go alongside "http-01" (which is always HTTP). > > On Tue, May 30, 2017 at 11:47 AM, Yaron Sheffer > wrote: > > But removing the restriction would mean that the CA is free to do > either HTTP or HTTPS, and the client doesn't know what to expect. > So if my port 80 is firewalled, I'm still not in good shape. > > Thanks, > > Yaron > > > On 30/05/17 18:38, Richard Barnes wrote: >> >> >> On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer >> > wrote: >> >> I'm not sure I understand why the section that describes HTTP >> validation so specifically forbids using HTTPS. >> >> >> This was because of the default-vhost attack. >> >> https://ietf-wg-acme.github.io/acme/#rfc.section.11.2 >> >> >> Given that we don't really have any data on how common this >> vulnerability is, I'm split on whether to keep the restriction. >> >> --Richard >> >> On the other hand, I can think of use cases where I would >> want *only* HTTPS authorization: >> >> - The server only supports HTTPS, and perhaps port 80 is >> blocked by a firewall. This situation applies to many REST >> endpoints. >> - I am migrating from a non-ACME to an ACME cert, and so the >> server has a perfectly valid HTTPS cert. Or migrating from >> one ACME CA to a different one. >> - I would like to ensure (using CAA records) that my CA is >> not subject to a DNS cache corruption attack - a threat that >> the ACME Security Considerations specifically mention. >> >> I would suggest that we specify a HTTPS validation that's >> exactly like http-01, except that it runs over authenticated >> HTTPS. >> >> Thanks, >> Yaron >> >> _______________________________________________ >> Acme mailing list >> Acme@ietf.org >> https://www.ietf.org/mailman/listinfo/acme >> >> >> > > --------------2A5F8FAF61DC48AE537DBFF8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Yes, exactly.

On 30/05/17 18:49, Richard Barnes wrote:
That just argues for adding for an "https-06" (which is always HTTPS) to go alongside "http-01" (which is always HTTP).

On Tue, May 30, 2017 at 11:47 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

But removing the restriction would mean that the CA is free to do either HTTP or HTTPS, and the client doesn't know what to expect. So if my port 80 is firewalled, I'm still not in good shape.

Thanks,

    Yaron


On 30/05/17 18:38, Richard Barnes wrote:


On Tue, May 30, 2017 at 11:32 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
I'm not sure I understand why the section that describes HTTP validation so specifically forbids using HTTPS.

This was because of the default-vhost attack.


Given that we don't really have any data on how common this vulnerability is, I'm split on whether to keep the restriction.

--Richard

 
On the other hand, I can think of use cases where I would want *only* HTTPS authorization:

- The server only supports HTTPS, and perhaps port 80 is blocked by a firewall. This situation applies to many REST endpoints.
- I am migrating from a non-ACME to an ACME cert, and so the server has a perfectly valid HTTPS cert. Or migrating from one ACME CA to a different one.
- I would like to ensure (using CAA records) that my CA is not subject to a DNS cache corruption attack - a threat that the ACME Security Considerations specifically mention.

I would suggest that we specify a HTTPS validation that's exactly like http-01, except that it runs over authenticated HTTPS.

Thanks,
    Yaron

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





--------------2A5F8FAF61DC48AE537DBFF8-- From nobody Tue May 30 09:42:14 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 9E259129ACC for ; Tue, 30 May 2017 09:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 HiKZj-CwIdSO for ; Tue, 30 May 2017 09:42:11 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2E7129AC5 for ; Tue, 30 May 2017 09:42:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 66DF026A95; Tue, 30 May 2017 19:42:10 +0300 (EEST) 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 qcUdMIbDiq1g; Tue, 30 May 2017 19:42:10 +0300 (EEST) 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 2A02BC4; Tue, 30 May 2017 19:42:10 +0300 (EEST) Date: Tue, 30 May 2017 19:42:07 +0300 From: Ilari Liusvaara To: Richard Barnes Cc: Yaron Sheffer , "acme@ietf.org" Message-ID: <20170530164207.GB5098@LK-Perkele-V2.elisa-laajakaista.fi> References: <7526b3be-65ec-29b6-d657-3e19be06ea6a@gmail.com> <3764ff8c-dc46-70e7-e95f-c722fe38768a@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] ACME -06: HTTPS authorization X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 16:42:13 -0000 On Tue, May 30, 2017 at 11:49:43AM -0400, Richard Barnes wrote: > That just argues for adding for an "https-06" (which is always HTTPS) to go > alongside "http-01" (which is always HTTP). One idea would be to require matching SAN in certificate (but not trusted signer nor in-validity-window). That is required anyway for HTTPS site selection on webservers to operate sanely. Lack of trusted signer requirement allows using self-signed certs for the initial validation and lack of in-validity-window allows renewing an expired certificate. However, that wouldn't fix the issues if the host lets one upload arbitrary certificates for one's vhost (however, if one can do that, then even TLS-SNI-02 is vulernable). -Ilari From nobody Tue May 30 09:51:02 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 AC416129AC9 for ; Tue, 30 May 2017 09:51:00 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 PwKBqYxC3LL8 for ; Tue, 30 May 2017 09:50:59 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 11EF1129AC6 for ; Tue, 30 May 2017 09:50:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 21E5460C37; Tue, 30 May 2017 19:50:57 +0300 (EEST) 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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id GbKsSxLgxjk9; Tue, 30 May 2017 19:50:56 +0300 (EEST) 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 8BD672318; Tue, 30 May 2017 19:50:56 +0300 (EEST) Date: Tue, 30 May 2017 19:50:54 +0300 From: Ilari Liusvaara To: Yaron Sheffer Cc: Richard Barnes , "acme@ietf.org" Message-ID: <20170530165054.GC5098@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [Acme] ACME -06: revocation X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 16:51:01 -0000 On Tue, May 30, 2017 at 06:59:21PM +0300, Yaron Sheffer wrote: > I understand the use case of "finding a key lying around" (although I've > never personally found a key lying around), but if you think of an > enterprise with a small group of people managing security but a much larger > group of people with access to server certs, this provides any server admin > with a trivial way to DoS the organization by revoking www.bigcorp.com, so > trivial that people can do it by mistake. Well, if the server admin is maliscous and has access to keys, he can do worse things than to revoke certificates. This mechanism is also limited to the single keypair, unlike say the revoke- with-domain-authorization, which can revoke certificates with arbitrary domain and account keys. Also, if maliscous actors get ahold of private key, that is very definition of private key compromise (and revocation is REQUIRED in that case, the ToS of every public CA says so, since it is BR requirement). And I think serious admins know when to request revocation, unlike lots of persons on community.letsencrypt.org or similar places. -Ilari From nobody Tue May 30 10:10:39 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 C0167129AD3 for ; Tue, 30 May 2017 10:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, URIBL_BLOCKED=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 FJ8_klIkb93m for ; Tue, 30 May 2017 10:10:35 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67007129ACD for ; Tue, 30 May 2017 10:10:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B201830057A for ; Tue, 30 May 2017 13:10:34 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4-JtPYprRPEq for ; Tue, 30 May 2017 13:10:32 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 5D93930042E; Tue, 30 May 2017 13:10:32 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_45F27A9C-76A4-4A68-8649-7B9CB1626970" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 30 May 2017 13:10:32 -0400 In-Reply-To: Cc: IETF ACME To: Yaron Sheffer References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Acme] ACME -06: revocation X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 17:10:38 -0000 --Apple-Mail=_45F27A9C-76A4-4A68-8649-7B9CB1626970 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yaron: If a party that has access to the private key is telling the CA that the = certificate ought to be revoked. I=E2=80=99m thinking that the CA ought = to revoke it. Any party that has access to that private key can do far = more malicious things. Russ > On May 30, 2017, at 11:48 AM, Richard Barnes wrote: >=20 >=20 >=20 > On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer > wrote: > When we allow the issued certificate to revoke itself, this has major = implications, in particular for delegated certificates. But even for = regular certs, it is the account's private key that's more secure (it is = managed by the security personnel where such exist, it is not deployed = on multiple servers) and that is the certificate that should be = preferred for revocation. So I suggest to use MAY for revocation by the = issued certificate's private key, instead of SHOULD. >=20 > You MAY not like the latest change we made, which upgraded this = requirement to MUST :) >=20 > https://github.com/ietf-wg-acme/acme/pull/300 = >=20 > =20 > Also, including the actual certificate in the request means that the = CA needs to perform multiple preliminary checks that would not be = required if the client sent the certificate URL (or its serial number). = The CA MUST parse the certificate, MUST validate it, MUST ensure that it = was issued by the current CA, and then MUST identify it in its database = of issued certs. More complexity, more opportunities for security holes. >=20 > The idea of including the certificate (as well as allowing a = certificate to revoke itself) was to support the case where an admin = just finds a certificate + private key lying around, and wants to kill = it. In that case, you have neither the Certificate URI nor the account = private key. >=20 > I would note that we have shifted from referencing keys by value to by = reference in request JWS objects, requiring clients to track their = account URIs. We made that change in the interest of forcing the server = to look up a public key for the account, reducing the likelihood of the = server accepting a signature by an unknown key. >=20 > We might get some similar benefits here, but maybe not -- after all, = if the certificate doesn't correspond to a URI, then it's probably not = from this CA, in which case it the CA can't revoke it anyway. >=20 > --Richard >=20 > =20 >=20 > Thanks, > Yaron >=20 > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme = >=20 > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme --Apple-Mail=_45F27A9C-76A4-4A68-8649-7B9CB1626970 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yaron:

If = a party that has access to the private key is telling the CA that the = certificate ought to be revoked.  I=E2=80=99m thinking that the CA = ought to revoke it.  Any party that has access to that private key = can do far more malicious things.

Russ



On = May 30, 2017, at 11:48 AM, Richard Barnes <rlb@ipv.sx> wrote:



On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer = <yaronf.ietf@gmail.com> = wrote:
When we allow the issued certificate = to revoke itself, this has major implications, in particular for = delegated certificates. But even for regular certs, it is the account's = private key that's more secure (it is managed by the security personnel = where such exist, it is not deployed on multiple servers) and that is = the certificate that should be preferred for revocation. So I suggest to = use MAY for revocation by the issued certificate's private key, instead = of SHOULD.

You MAY not like the latest change we = made, which upgraded this requirement to MUST :)

https://github.com/ietf-wg-acme/acme/pull/300

 
Also, including the actual certificate in the request means that the CA = needs to perform multiple preliminary checks that would not be required = if the client sent the certificate URL (or its serial number). The CA = MUST parse the certificate, MUST validate it, MUST ensure that it was = issued by the current CA, and then MUST identify it in its database of = issued certs. More complexity, more opportunities for security holes.

The idea of including the certificate (as well as allowing a = certificate to revoke itself) was to support the case where an admin = just finds a certificate + private key lying around, and wants to kill = it.  In that case, you have neither the Certificate URI nor the = account private key.

I would note that we have shifted from = referencing keys by value to by reference in request JWS objects, = requiring clients to track their account URIs.  We made that change = in the interest of forcing the server to look up a public key for the = account, reducing the likelihood of the server accepting a signature by = an unknown key.

We might get some similar benefits here, but maybe not -- = after all, if the certificate doesn't correspond to a URI, then it's = probably not from this CA, in which case it the CA can't revoke it = anyway.

--Richard

 

Thanks,
    Yaron

_______________________________________________
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

= --Apple-Mail=_45F27A9C-76A4-4A68-8649-7B9CB1626970-- From nobody Tue May 30 13:26: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 2503512943E for ; Tue, 30 May 2017 13:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 0uc6FrU-ubW4 for ; Tue, 30 May 2017 13:26:15 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (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 27A081292F4 for ; Tue, 30 May 2017 13:26:15 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id v104so6995733wrb.0 for ; Tue, 30 May 2017 13:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=AIJ5/GnmNJ5mn/5Axa1pbMwP2fMFD+ib0vfzU57TaaY=; b=M2pJAsk2KFuTlMfwR1Cb1cMKTyXFnIHy8wNwBjJWPtHAQVAinfXSYQQRvnEPqULD3O m4zzj47m8YVVpMTnsBQPsc/DcJneUmrKoyxrKXQErvIXcWzXXlIDcCzkLH6YX4NZIAE1 y9HcnOPEHjJv6KQ6tEVg2MPYW4wX/CMG5TEO1vyAupPnj7vVrd9fOw5Ch6hbcmoqQEn3 08eutKiGoA3thX+vkxa7kF4W9CAh7UF5OFA9ZPGEeDishYiqCCo6Gu1ExpE9mMWjWcj0 3dI8HtA6/x008A/zMAY5XYwx7gLXsEFNo6Qmg+nJJJcsEJnAUDtqe1NWJN2b0ShpfmDq eCIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=AIJ5/GnmNJ5mn/5Axa1pbMwP2fMFD+ib0vfzU57TaaY=; b=sltHlQoJ+ZR+G9iOVB8/A45KeAXmMouhKnqVSwdvzICrWInnirL4V30KvR2iSjTVj7 3VZubGzPVdprp8Y5X0vGnafTAV6qTbiw8LZyLLC8SMhz/u1jQWkSqygD7BZ076RZ2BSs 8b84LPNhhL3Qs/FbVhcOND053bToxFbwxam4t7VBZHzUpHX4eflvAvq8EPI7LEBgzGR7 KDqYFWn3ZvMmzMUz9Hi0ruvNKZcAEfCb2KdN4bxHRug/Mo91wTr6NiERYW9fsmyxssJy V25gwDkfuFfNYZXOmrTGPXGJBoE0RgvA/TqXqbOEAqenU9U4BQchRkhQm1JJbSfX5dav HwrQ== X-Gm-Message-State: AODbwcDlnq+O6DbQnRvonk3+Cjun2aQNIThPozqyyN4GW5JtueekHEzo QW0YvVaNIicb5xTZBBU= X-Received: by 10.223.129.4 with SMTP id 4mr15513376wrm.153.1496175973507; Tue, 30 May 2017 13:26:13 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-178-58-28.red.bezeqint.net. [79.178.58.28]) by smtp.gmail.com with ESMTPSA id 140sm10347434wmu.23.2017.05.30.13.26.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 May 2017 13:26:12 -0700 (PDT) To: Russ Housley Cc: IETF ACME References: From: Yaron Sheffer Message-ID: <0e6c6358-72b5-9fff-293d-c672b03acd95@gmail.com> Date: Tue, 30 May 2017 23:26:09 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0147D971B070FC14E6DDF145" Content-Language: en-US Archived-At: Subject: Re: [Acme] ACME -06: revocation X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 May 2017 20:26:18 -0000 This is a multi-part message in MIME format. --------------0147D971B070FC14E6DDF145 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I know I'm in the rough here, but IMHO for many enterprises, when they compare between a certain downtime and a not so certain MITM threat, they would decide differently. But I'm not going to argue this point any further. Thanks, Yaron On 30/05/17 20:10, Russ Housley wrote: > Yaron: > > If a party that has access to the private key is telling the CA that > the certificate ought to be revoked. I’m thinking that the CA ought > to revoke it. Any party that has access to that private key can do > far more malicious things. > > Russ > > > >> On May 30, 2017, at 11:48 AM, Richard Barnes > > wrote: >> >> >> >> On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer >> > wrote: >> >> When we allow the issued certificate to revoke itself, this has >> major implications, in particular for delegated certificates. But >> even for regular certs, it is the account's private key that's >> more secure (it is managed by the security personnel where such >> exist, it is not deployed on multiple servers) and that is the >> certificate that should be preferred for revocation. So I suggest >> to use MAY for revocation by the issued certificate's private >> key, instead of SHOULD. >> >> >> You MAY not like the latest change we made, which upgraded this >> requirement to MUST :) >> >> https://github.com/ietf-wg-acme/acme/pull/300 >> >> Also, including the actual certificate in the request means that >> the CA needs to perform multiple preliminary checks that would >> not be required if the client sent the certificate URL (or its >> serial number). The CA MUST parse the certificate, MUST validate >> it, MUST ensure that it was issued by the current CA, and then >> MUST identify it in its database of issued certs. More >> complexity, more opportunities for security holes. >> >> >> The idea of including the certificate (as well as allowing a >> certificate to revoke itself) was to support the case where an admin >> just finds a certificate + private key lying around, and wants to >> kill it. In that case, you have neither the Certificate URI nor the >> account private key. >> >> I would note that we have shifted from referencing keys by value to >> by reference in request JWS objects, requiring clients to track their >> account URIs. We made that change in the interest of forcing the >> server to look up a public key for the account, reducing the >> likelihood of the server accepting a signature by an unknown key. >> >> We might get some similar benefits here, but maybe not -- after all, >> if the certificate doesn't correspond to a URI, then it's probably >> not from this CA, in which case it the CA can't revoke it anyway. >> >> --Richard >> >> >> Thanks, >> Yaron >> >> _______________________________________________ >> 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 > --------------0147D971B070FC14E6DDF145 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I know I'm in the rough here, but IMHO for many enterprises, when they compare between a certain downtime and a not so certain MITM threat, they would decide differently. But I'm not going to argue this point any further.

Thanks,

    Yaron


On 30/05/17 20:10, Russ Housley wrote:
Yaron:

If a party that has access to the private key is telling the CA that the certificate ought to be revoked.  I’m thinking that the CA ought to revoke it.  Any party that has access to that private key can do far more malicious things.

Russ



On May 30, 2017, at 11:48 AM, Richard Barnes <rlb@ipv.sx> wrote:



On Tue, May 30, 2017 at 11:42 AM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:
When we allow the issued certificate to revoke itself, this has major implications, in particular for delegated certificates. But even for regular certs, it is the account's private key that's more secure (it is managed by the security personnel where such exist, it is not deployed on multiple servers) and that is the certificate that should be preferred for revocation. So I suggest to use MAY for revocation by the issued certificate's private key, instead of SHOULD.

You MAY not like the latest change we made, which upgraded this requirement to MUST :)


 
Also, including the actual certificate in the request means that the CA needs to perform multiple preliminary checks that would not be required if the client sent the certificate URL (or its serial number). The CA MUST parse the certificate, MUST validate it, MUST ensure that it was issued by the current CA, and then MUST identify it in its database of issued certs. More complexity, more opportunities for security holes.

The idea of including the certificate (as well as allowing a certificate to revoke itself) was to support the case where an admin just finds a certificate + private key lying around, and wants to kill it.  In that case, you have neither the Certificate URI nor the account private key.

I would note that we have shifted from referencing keys by value to by reference in request JWS objects, requiring clients to track their account URIs.  We made that change in the interest of forcing the server to look up a public key for the account, reducing the likelihood of the server accepting a signature by an unknown key.

We might get some similar benefits here, but maybe not -- after all, if the certificate doesn't correspond to a URI, then it's probably not from this CA, in which case it the CA can't revoke it anyway.

--Richard

 

Thanks,
    Yaron

_______________________________________________
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


--------------0147D971B070FC14E6DDF145-- From nobody Wed May 31 05:30:09 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 F12B4129BDA for ; Wed, 31 May 2017 05:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 GUJ0c8jezLM6 for ; Wed, 31 May 2017 05:30:05 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id EAFFF129BCF for ; Wed, 31 May 2017 05:30:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 01B62285DF; Wed, 31 May 2017 15:30:04 +0300 (EEST) 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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id rxmOfSKNbFU3; Wed, 31 May 2017 15:30:03 +0300 (EEST) 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 C234421C; Wed, 31 May 2017 15:30:03 +0300 (EEST) Date: Wed, 31 May 2017 15:30:01 +0300 From: Ilari Liusvaara To: Zach Shepherd Cc: "acme@ietf.org" , Jacob Hoffman-Andrews Message-ID: <20170531123001.GB7298@LK-Perkele-V2.elisa-laajakaista.fi> References: <49f045b4-2ef3-3e36-5b2e-f5d75c4d33b1@eff.org> <20170512112322.GA29942@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: Subject: Re: [Acme] Bypassing the intended purpose of requiring 128 bits of entropy for the http-01 token X-BeenThere: acme@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Automated Certificate Management Environment List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 May 2017 12:30:08 -0000 On Fri, May 12, 2017 at 10:33:40PM +0000, Zach Shepherd wrote: > For use of a token with http-01, it seems like the relevant section of > the baseline requirements would be 3.2.2.4.6 Agreed‐Upon Change to > Website. Is that correct? Yes, that is correct. > That section seems to explicitly state "where the Request Token or > Random Value MUST NOT appear in the request". Including the token > (which the document seems to refer to as the "Random Value") in the > request path (as http-01 does) would seem to violate this normative > language. Am I misunderstanding the content of that section? This was actually briefly discussed on this list. I had the same understanding, that was apparently mistaken. On changing validation methods, the current Key Authorization does not seem to be sufficient. It does not bind the name to be validated. Now, HTTP and DNS validation weakly binds the validated name (via host header and owner name, respectively). Even this weak binding is sufficient to consider the domain itself validated (the validation can be deputized). However TLS-SNI (including -02) does not bind the name in any way. This results in TLS-SNI failing to actually validate the domain name itself, instead validating the underlying IP address (it is not possible to deputized the validation). Furthermore, I have real problems matching up TLS-SNI-02 and method #10 (Section 3.2.2.4.10) validation. Reading the phrases in a way that would match seemingly unavoidably results other validation methods with the same phrases becoming very insecure. This is ignoring other problems with method #10 validation (e.g. seemingly allowing the PZB's insecure certificate chaining validation, due to seemingly not restricting random values properly). -Ilari