I haven't time at the moment to go through this document in detail. But I did notice a few obvious errors in the mentioned sections. 6.2 SNI encryption has been adopted by the TLS WG, but that doesn't mean that all future versions of TLS will include the capability - or even be able to use it - as the text implies. Encrypting SNI calls for some hard trade-offs that likely mean that encryption won't be universally deployed. I do appreciate the effort to forewarn about this, but it misses the point somewhat. The point here is that SNI is being used as a proxy for identification of content. That it is a poor proxy is widely acknowledged (though not in the draft), but it has been more or less accepted as adequate for some applications of content-based discrimination. Let's say that we accept that as implicit - rather than a cleaner explicit statement - and continue to focus on identification of content via SNI. In that case, RFC 7540 defined something that should be more of a concern: connection coalescing. That feature is also widely implemented in browsers. The ORIGIN frame (draft-ietf-httpbis-origin-frame) makes this stronger by potentially taking DNS out of the loop. Add the likely-to-be-adopted draft-bishop-httpbis-http2-additional-certs and things far more challenging for snooping than merely encrypting SNI. This is misleading: It should be noted that HTTP/2 introduces the Alt-SVC method for upgrading the connection from HTTP/1 to either unencrypted or encrypted HTTP/2. If the initial HTTP/1 request is unencrypted, the destination alternate service name can be identified before the communication is potentially upgraded to encrypted HTTP/2 transport. RFC 8164 defines the use of Alt-Svc [check capitalization] for opportunistically upgrading to an encrypted (and authenticated!) transport. The claim here that the service name can be identified is perhaps correct, but also unnecessary, since the alternative is contacted using the SNI of the original (as defined in RFC 7838). 6.3 As I mentioned in a previous review, ALPN is not encrypted in TLS 1.3. The correct statement would be that ALPN options are available to the network (just like SNI), but the selection by the server is not. I'm still not sure what use cases this datum drives though. 6.4 This mentions nothing of padding. Padding is available in HTTP/2 and TLS 1.3, plus many other protocols. It at least deserves some recognition, even if it isn't widely deployed (outside of some relatively specialized uses, that is). There's a whole RFC on traffic analysis and countermeasures missing from our dialogue here, but a mention is probably wise.