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

From: Daniel McCarney <[email-masked]>
Date: Fri, 12 Jan 2018 12:45:55 -0500

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/

---

From: Jonathan Rudenberg <[email-masked]>
Date: Fri, 12 Jan 2018 13:02:30 -0500

> On Jan 12, 2018, at 12:45, Daniel McCarney <[email-masked]> wrote:
> 
> 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.
> 

I support this plan. Given the late stage, I think it makes sense to move the new TLS challenge type work to a new document.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 12 Jan 2018 18:03:13 +0000

> 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<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_ietf-2Dwg-2Dacme_acme_pull_390&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=lD9fhB4R9RB19cI9GZRim3b1tMV3ftrWRKjrdQ8rIfA&s=pdniJCRiAq6-ze7TblykSE-M7LgoWreu4S1r-f2VOes&e=> to make this change.

Does anyone on the WG object to doing this?  Please respond by the end of next week.  Editors, please hold off on merging the PR until we confirm consensus.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 12 Jan 2018 20:23:37 +0200

> What are the thoughts of the other WG participants?

This removes the "tls" error. I do not think this is appropriate, as
http-01 can redirect to https://, and such validation can hit TLS
errors. I think separating TLS failures and TCP failures is useful for
debugging.

Example of TLS failure is that somewhat common misconfiguration where
port 443 is not using TLS: That is _not_ a connection error, the error
happens inside TLS. Saying it is a connection error is misleading.

Other than that, I agree that we can't block on TLS-SNI-03, or
whatever -> Punt it to future draft (work on which should start soon
after getting acme-acme through IESG).

-Ilari

---

From: Daniel McCarney <[email-masked]>
Date: Fri, 12 Jan 2018 13:29:42 -0500

>
> This removes the "tls" error. I do not think this is appropriate, as http-01
> can redirect to https://, and such validation can hit TLS errors.

Good point. I didn't consider HTTP-01 :80 -> :443. Restored in
https://github.com/ietf-wg-acme/acme/pull/390/commits/3441d4435a6e8454fa68749231d801ec4f894bbc

Thanks Ilari,

- Daniel / cpu

---

From: Daniel McCarney <[email-masked]>
Date: Tue, 23 Jan 2018 09:59:40 -0500

Only positive responses were noted and the discussion period Rich mentioned
has passed so I've merged https://github.com/ietf-wg-acme/acme/pull/390

Thanks all,

- Daniel / cpu

On Fri, Jan 12, 2018 at 1:29 PM, Daniel McCarney <[email-masked]>
wrote:

> On Fri, Jan 12, 2018 at 1:23 PM, Ilari Liusvaara <[email-masked]
> > wrote:
>