Section 3.6: The downside is the the client will not verify the identity of the fronting service with risks discussed in , but solutions will have to mitigate this risks. Overall, end-to-end TLS to the protected service is preferable. "the the" => "that the" "discussed in ," presumably was intended to include a reference to... something. "this risks" => "these risks" Section 3.7: These applications too will benefit of SNI encryption. HTTP only methods like those described in Section 4.1 would not apply there. In fact, even for the HTTPS case, the HTTPS tunneling service described in Section 4.1 is compatible with HTTP 1.0 and HTTP 1.1, but interacts awkwardly with the multiple streams feature of HTTP 2.0 [RFC7540]. This points to the need of an application-agnostic solution, that would be implemented fully in the TLS layer. "benefit to" => "benefit from" "HTTP only" => "HTTP-only" "HTTP 2.0" => "HTTP/2" "solution, that would" => "solution which can" Section 4.2 This requires a controlled way to indicate which fronting ferver is acceptable by the hidden service. "ferver" => "server" We can observe that content distribution network have a similar requirement. They need to convince the client that "www.example.com" can be accessed through the seemingly unrelated "cdn-node- xyz.example.net". Most CDNs have deployed DNS-based solutions to this problem. It might be worth mentioning that when a CDN deploys a "DNS-based solution to this problem," it also holds the authoritative certificate of the origin.. There is simultaneously verification of a relationship between the origin and the CDN (because the certificate can be verified) and a risk that the CDN can spoof the content from the origin. Section 5 Having described in 2.3 that encrypting SNI will simultaneously thwart invasions of the TLS exchange whose purpose is to improve some forms of security, I suspect this is worth a mention in the Security Considerations as well.. Section 7 "Martin Rex Martin Thomson and" => "Martin Rex, Martin Thomson, and" -----Original Message----- From: IETF-Announce <ietf-announce-bounces@xxxxxxxx> On Behalf Of The IESG Sent: Monday, August 19, 2019 9:59 AM To: IETF-Announce <ietf-announce@xxxxxxxx> Cc: draft-ietf-tls-sni-encryption@xxxxxxxx; tls@xxxxxxxx; tls-chairs@xxxxxxxx Subject: Last Call: <draft-ietf-tls-sni-encryption-05.txt> (Issues and Requirements for SNI Encryption in TLS) to Informational RFC The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Issues and Requirements for SNI Encryption in TLS' <draft-ietf-tls-sni-encryption-05.txt> as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@xxxxxxxxx mailing lists by 2019-09-02. Exceptionally, comments may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This draft describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a Hidden Service behind a fronting service, only disclosing the SNI of the fronting service to external observers. The draft lists known attacks against SNI encryption, discusses the current "co-tenancy fronting" solution, and presents requirements for future TLS layer solutions. In practice, it may well be that no solution can meet every requirement, and that practical solutions will have to make some compromises. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-sni-encryption/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf-announce
