Change:
Remove self-signed, since the key point is that it's a trust anchor that was independently distributed. Note here that some trust anchors are signed, though that usually indicates a reason for it to be included, the signing might persist for longer than the actual need for it. Also the explanation had more words than it needed. n.b., I only loosely wrapped this stuff, if you want a proper wrapping of lines, name a preferred wrap column, because I couldn't work out what to do here.
The existing note is 722 char, the current PR is 700 char, and with the above suggestions it drops to 600 char. I think it's also a little easier to read, as a bit of that was redundant, especially after you reordered the sentences (which I agree flows in a more logical way now: what was different? -> why was it a problem? -> what should we do about it?).
NAME I sent you a PR to this PR for my suggested changes. URL
Server Name Indication could be encrypted to protect it from being inspected by passive attackers. There are some virtual-hosting type situations where hiding this information is considered desirable. If we can encrypt SNI, then it is probably trivial to encrypt other extensions. However, this complicates the handshake. A lot. It also complicates virtual-hosting scenarios. Rich summarizes the issues pretty well here: URL
Is this already ruled-out? How could the SNI be encrypted without an addition RTT? One could hash the SNI in the Client Hello which would at least help if the served host name is not publicly known (e.g. using a self-signed certificate).
It seems likely that there will eventually be an (optional?) extension that permits an encrypted "real" SNI, with some fake public SNI. But maybe that is not what you are asking.
NAME why was this closed?
Because we are not going to do anything about it in the base specification. I have concerns some about SNI encryption. First, I think it addresses a problem that is actually not that important for most. There are comparatively few sites on the web that have multiple properties served from a single host (or cluster). Certainly the biggest sites that received the most publicity for being under attack by the NSA -- Microsoft, Google, Yahoo, etc. -- are really a few to smallish number of services. And those companies have the wherewithal to deploy separate identities and IP addresses for their properties. Second, it potentially disadvantages a portion of the net: large CDN's and their customers. My employer, for example, serves thousands of sites on its TLS network, and encrypting SNI requires us to either have a single long-lived keypair for all customers, or require an extra RTT for clients to fetch an EDH key, perhaps still shared, but hopefully more secure. The latter is particularly off-putting since customers paying for a "faster, better" end-user experience are now at a disadvantage. Some in this community might not deploy TLS 1.3 to avoid the "retry penalty." This would be a shame. Third, we have not heard from the real potential community of consumers of this. I posit that they are mid-size sites with a "handful" of hosted properties. They are currently adequately served by virtual IP's, and even more so in the future by IPv6. And in terms of adversaries, does it matter which property within peacefire, for example, a user is contacting? A site under surveillance by a national-scale adversary will have everything scooped up anyway. Let me put some numbers on the previous points. We deliver content for around 10K domains, each with its own RSA keypair, out of 1500 locations. Without SNI, that means we need 15Million IP addresses, while being able to use SNI we only need one per location (region in our terminology). With SNI encryption we either need to share keys (bad for security, and perhaps not compliant with some regulations) or fragment IPs (bad for the web long-term). And that's just us. Add in all the CDNs, hosting companies, cloud providers... it's big. Do we know what people like AWS, Rackspace, IBM Cloud, etc., think about this? Fourth, it potentially "unlevels" the playing field. Organizations that have both a browser and servers of interest could, trivially, arrange to push out keys on a regular basis. I am not suggesting that anyone is planning on doing this, but I fear the temptation to do so in the name of "improving the user experience" will prove too great. In darker moments, I extrapolate the " browser list of CA's" story and imagine a future where Chrome talking to Google will be faster than IE talking to Bing, and Firefox will end up selling slots in its EDH store (sic) to attract revenue. Fifth, it introduces unknown security and trust implications in browsers. It took years to make "certificate stores" actually secure. And we are potentially opening up a new avenue of active attacks over the network while increasing the expectation that things are more secure. We are also increasing the client-side attack surface. Sixth, it adds an extra burden to servers. I think it also improves potential DoS attacks, since they could start at the first PDU exchange. Seventh, it ignores some of our own history. When HTTP/1.1 mandated the Host header, the virtual hosting industry was created. Until virtual IP's were well-known and SNI was widely adopted (I'm being charitable here), adoption of TLS among hosting providers had significant drag. If SNI is routing, then routing is plaintext and we are now going hide it without understanding the trade-offs. Finally, it is a lot of mechanism. As ekr said in London, "you have to do all this if you want to protect the SNI." It's not worth it. I think we're going too far, and we should come down on the side of simplicity, not for its own sake, but for security's sake. /r$ Principal Security Engineer Akamai Technology Cambridge, MA

Discussion:
certificate MUST come first in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed <del> independently, a self-signed certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates they may require. Note: Prior to TLS 1.3, "certificate_list" ordering was required to be strict, however some implementations already allowed for some flexibility.  For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version (with the exception of the sender's certificate).  Some servers are configured to send both a current and deprecated intermediate for transitional purposes, and others are simply configured incorrectly, but these cases can nonetheless be validated properly by clients capable of doing so. Although the chain MAY be ordered in a variety of ways, the peer's end-entity certificate MUST be the first element in the vector. </del> <ins> independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it, however some implementations allowed some flexibility.  Servers sometimes send both a current and deprecated intermediate for transitional purposes, and others are simply configured incorrectly, but these cases can nonetheless be validated properly.  For maximum compatibility, all implementations SHOULD be prepared to handle potentially extraneous certificates and arbitrary orderings from any TLS version, with the exception of the end-entity certificate which MUST be first. </ins> The same message type and structure will be used for the client's response to a certificate request message.  Note that a client MAY