Remove TLS-SNI-02 challenge type and associated refs. #390
Conversation
Recent developments[0][1] have identified real-world server/hosting configurations that violate the assumptions of TLS-SNI-01 and 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 the vulnerable challenge type pending the development of a better alternative (TLS-SNI-03?). This will allow the draft last-call to proceed while the details of TLS-SNI-03 are worked out. The "Default Virtual Hosts" sub-section of the "Operational Considerations" section is removed since it spoke exclusively to a concern with TLS-SNI-02 validation. When the dust has settled on TLS-SNI-03 we should certainly include a section that describes why TLS-SNI-01/02 were removed that could replace this information. [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
Ilari Liusvaara rightly points out that an HTTP-01 validation that is redirected to port 443 may encounter an error that justifies the TLS error type.
@kelunik I don't think we need a place-holder in-doc for this |
| @@ -2709,7 +2603,6 @@ Initial Contents | |||
| | Label | Identifier Type | ACME | Reference | | |||
| |:-----------|:----------------|:-----|:----------| | |||
| | http-01 | dns | Y | RFC XXXX | | |||
| | tls-sni-02 | dns | Y | RFC XXXX | | |||
There was a problem hiding this comment.
I agree with @kelunik that it would be good to have a tombstone here. The standard practice is to have a "reserved" entry in the registry, so that you don't conflict later, but you also don't define it. Here, I think the right row would be:
| tls-sni-02 | RESERVED | N | N/A |
There was a problem hiding this comment.
@bifurcation Shouldn't there be one for tls-sni-01 by the same logic? Should I add both in this PR?
There was a problem hiding this comment.
I added both in 0bb71a0 - I can drop one if there's a reason we should only have a tombstone for tls-sni-02.
There was a problem hiding this comment.
Confirmed OOB this addresses @bifurcation's comment.
Recent developments[0] [1] [2] have identified real-world server/hosting
configurations that violate the assumptions of TLS-SNI-01 and 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 the affected
challenge type pending the development of a better alternative
(TLS-SNI-03?). This will allow the draft last-call to proceed while
the details of TLS-SNI-03 are worked out.
The "Default Virtual Hosts" sub-section of the "Operational
Considerations" section is removed since it spoke exclusively to
a concern with TLS-SNI-02 validation. When the dust has settled on
TLS-SNI-03 we should certainly include a section that describes why
TLS-SNI-01/02 were removed that could replace this information.