Draft: draft-ietf-tls-tls13

Commentary: 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 could n'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 ? ) . 
 I sent you a PR to this PR for my suggested changes . 
 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 : 
 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 . 
 why was this closed ? 
 Because we are not going to do anything about it in the base specification .
Paragraph (version A):
This is a sequence (chain) of certificates.  The sender's
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
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.
Paragraph (version A):
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.
Paragraph (version B):
This is a sequence (chain) of certificates.  The sender's
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
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.
Paragraph (version B):
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.