Hi Mike, Thanks for this. The first two at least are already fixed in the editor's copy, and I'll make sure that the rest get addressed before publication. -Ben On Wed, Aug 21, 2019 at 07:26:29PM +0000, Mike Bishop wrote: > 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 >
