IETF Logo Mail Archive

[Acme] Removing TLS-SNI-02, plans for continuation of last-call

Daniel McCarney <cpu@letsencrypt.org> Fri, 12 January 2018 17:46 UTC

Return-Path: <dmccarney@letsencrypt.org>
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 D868512D7EA for <acme@ietfa.amsl.com>; Fri, 12 Jan 2018 09:46:02 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=letsencrypt.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxVanSvL6dD5 for <acme@ietfa.amsl.com>; Fri, 12 Jan 2018 09:46:00 -0800 (PST)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::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 D433B129C6E for <acme@ietf.org>; Fri, 12 Jan 2018 09:45:57 -0800 (PST)
Received: by mail-it0-x22b.google.com with SMTP id 68so10156880ite.4 for <acme@ietf.org>; Fri, 12 Jan 2018 09:45:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=letsencrypt.org; s=google; h=mime-version:reply-to:from:date:message-id:subject:to; bh=KyBESedOLqp40O95OWeHn9BqSTUlj6godHzY7TM8xxM=; b=QOyJplxkormqAbBVa8FywpFYzYf5kvyzFlrLaucU0+ZiTbqQqImfbg2Y3tKYRZwIC1 im9xU09gUg9nILZwHO0X+bRMIZh6IXBYc76RsIno17xGt7dFaNJqmiHJiltiTeUrO2xK DPyVz6vY8GuCNSYPcRTj5mlwGcpnEqHBLxUYU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=KyBESedOLqp40O95OWeHn9BqSTUlj6godHzY7TM8xxM=; b=sH77QJ+5A8RJogZVnu/EET9SWU1q9zah+XdTRRuqulrGG2VeOBkQuOf0txDqu0eazm JNpfIqoYQR7fXc9jYuVh8KgKkmEpHww7msXBQj4xP/PGcWR95AmtVZsVYpmGVQbYlfbW YuBG07tIYK5KMpbDeBuOGLur5Z6Hi4UIUKi6bAgeQDkC+InrBftgnr0JjAVKOtixHntr NB4f9RnSCJbKzfETH6dYvVgwobkqXVUQuMubb8vBjtkH9V117wjALPU2JPYj4LWckiNm mLFQRSYOEsVtalzuRr+0NisUjLUSNnHag6xKEN8y0wxn2CChrCihDBTWlVQleaHYZncK CR9A==
X-Gm-Message-State: AKwxytfs2iBup4rixncJb0tD1/GJZsvBSwnfd0Za/r+PyKRCrpad19ZK GimKY2R+HV7DS65uKpDSR4uv+RyMolipuKE81tF+O+2KWq4=
X-Google-Smtp-Source: ACJfBouQ4tPU74Dr7i6gsTWjSM794IQn1uruLUaB0O+bO3B6uH0opYk+IfuogxDPPDkKImG97OG+q+V+mzAwYhGo4Qs=
X-Received: by 10.36.203.131 with SMTP id u125mr6028139itg.78.1515779157004; Fri, 12 Jan 2018 09:45:57 -0800 (PST)
MIME-Version: 1.0
Reply-To: cpu@letsencrypt.org
Received: by 10.107.32.4 with HTTP; Fri, 12 Jan 2018 09:45:55 -0800 (PST)
From: Daniel McCarney <cpu@letsencrypt.org>
Date: Fri, 12 Jan 2018 12:45:55 -0500
Message-ID: <CAKnbcLgr3p3KZuUTAvBAcT_Nk-z0_smew4rfhAYm8D-vZp+i5g@mail.gmail.com>
To: IETF ACME <acme@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0afb68362a33056297d649"
Archived-At: <https://mailarchive.ietf.org/arch/msg/acme/sRUZ97KTHF-aXvLOEv64bZ8VsFo>
Subject: [Acme] Removing TLS-SNI-02, plans for continuation of last-call
X-BeenThere: acme@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Automated Certificate Management Environment <acme.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/acme>, <mailto:acme-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/acme/>
List-Post: <mailto:acme@ietf.org>
List-Help: <mailto:acme-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/acme>, <mailto:acme-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jan 2018 17:46:03 -0000

Hello folks,

As I'm sure many of you are aware by now, recent developments[0] [1] [2]
have identified real-world server/hosting configurations that violate the
assumptions of TLS-SNI-01 as well as its currently specified replacement,
TLS-SNI-02.

In light of these issues and the feasibility of addressing them across the
entire Internet it seems prudent that the ACME specification remove this
challenge type pending the development of a better alternative
(TLS-SNI-03?). I've submitted https://github.com/ietf-wg-acme/acme/pull/390
to make this change.

It also seems prudent that the working group take its time considering the
design and specification of TLS-SNI-03. It will also take time for there to
be server and client implementations of a new TLS-SNI-03 specification once
ready.

With these thoughts in mind I think we should consider TLS-SNI-03 outside
the scope of the current draft and proceed with a draft that has only
HTTP-01 and DNS-01 challenge types, deferring TLS-SNI-03 for a follow-up
document.

What are the thoughts of the other WG participants?

- Daniel / @cpu

[0]:
https://community.letsencrypt.org/t/2018-01-09-issue-with-tls-sni-01-and-shared-hosting-infrastructure/49996
[1]:
https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188
[2]:
https://labs.detectify.com/2018/01/12/how-i-exploited-acme-tls-sni-01-issuing-lets-encrypt-ssl-certs-for-any-domain-using-shared-hosting/

v2.23.0 | Report a Bug | By Email