Change:
8.4. <del> The TLS with Server Name Indication (TLS SNI) validation method proves control over a domain name by requiring the client to configure a TLS server referenced by the DNS A and AAAA resource records for the domain name to respond to specific connection attempts utilizing the Server Name Indication extension RFC6066.  The server verifies the client's challenge by accessing the TLS server and verifying a particular certificate is presented. The string "tls-sni-02" A random value that uniquely identifies the challenge.  This value MUST have at least 128 bits of entropy.  It MUST NOT contain any characters outside the base64url alphabet, including padding characters ("="). A client responds to this challenge by constructing a self-signed certificate which the client MUST provision at the domain name concerned in order to pass the challenge. The certificate may be constructed arbitrarily, except that each certificate MUST have exactly two subjectAlternativeNames, SAN A and SAN B.  Both MUST be dNSNames RFC5280. SAN A MUST be constructed as follows: compute the SHA-256 digest FIPS180-4 of the challenge token and encode it in lowercase hexadecimal form.  The dNSName is "x.y.token.acme.invalid", where x is the first half of the hexadecimal representation and y is the second half. SAN B MUST be constructed as follows: compute the SHA-256 digest of the key authorization and encode it in lowercase hexadecimal form. The dNSName is "x.y.ka.acme.invalid" where x is the first half of the hexadecimal representation and y is the second half. The client MUST ensure that the certificate is served to TLS connections specifying a Server Name Indication (SNI) value of SAN A. The response to the TLS-SNI challenge simply acknowledges that the client is ready to fulfill this challenge. The key authorization for this challenge.  This value MUST match the token from the challenge and the client's account key. On receiving a response, the server MUST verify that the key authorization in the response matches the "token" value in the challenge and the client's account key.  If they do not match, then the server MUST return an HTTP error in response to the POST request in which the client sent the challenge. Given a challenge/response pair, the ACME server verifies the client's control of the domain by verifying that the TLS server was configured appropriately, using these steps: Compute SAN A and SAN B in the same way as the client. Open a TLS connection to the domain name being validated, presenting SAN A in the SNI field.  This connection MUST be sent to TCP port 443 on the TLS server.  In the ClientHello initiating the TLS handshake, the server MUST include a server_name extension (i.e., SNI) containing SAN A.  The server SHOULD ensure that it does not reveal SAN B in any way when making the TLS connection, such that the presentation of SAN B in the returned certificate proves association with the client. Verify that the certificate contains a subjectAltName extension containing dNSName entries of SAN A and SAN B and no other entries.  The comparison MUST be insensitive to case and ordering of names. If all of the above verifications succeed, then the validation is successful.  Otherwise, the validation fails. 8.5. </del> When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a TXT resource record containing a designated value for a specific validation domain name.

Discussion:
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. [0]: URL [1]: URL [2]: URL
NAME I don't think we need a place-holder in-doc for this
r+ with the one comment addressedShould there be any mention of that makes sure we use in a future RFC in case if gets re-added?