There has clearly been a lot of work put into this. It's a surprisingly understandable document, given its length and the complexity of the subject. I am balloting yes, but I have a few minor comments and nits. None of these are showstoppers, so please do with them as you will.
ClientHello as its first message. "
Is that intended to prohibit the use of STARTTLS or similar application layer patterns?
follow the procedures for the appropriate prior version of TLS."
[RFC5246], even if ClientHello.legacy_version is 0x0304 or later."
... which seems inconsistent (noting that this paragraph talks about "implementations"
rather than "servers", so perhaps there's a subtle difference?
may continue to be useful for some time.
group as one of the client’s shares. "
missing comma prior to "which".
is in the non-PSK case discussed in the previous paragraph."
I read "need not be fatal" to mean that it may still be fatal at times. Is that the intent?
§11: The IANA considerations have a number of constructions similar to "SHALL update/has updated".
Is that text expected to collapse to "has updated" at some point?
I found this document to be clear despite its length and complexity. The Gen-ART reviewer wrote a lengthy review that I encourage the author/WG to look at. Many of his comments relate to stylistic preferences in the text and some of them might have been more actionable earlier in the process (e.g., the suggestion for a minor error code, which I like but wouldn't hold this up over), but they are worth reviewing. For example, I was also confused about the use of "fatal alert" versus "error alert," and I also found the invocation of the SNI check in 4.6.1 to be introduced abruptly.
Thank you (Editor, Work Group, and all the contributors) for an exceedingly well written document, pragmatic structure, and meaningful appendices (esp Appendix E.5 for 0-RTT).
and a field in the server extension response for the latter."
Really nice plan to use 0x7f00 as the draft version indicator.
Thank you for dealing with padding as you have. Much appreciated!
A legacy TLS client performing renegotiation with TLS 1.2 or prior  and which receives a TLS 1.3 ServerHello during renegotiation MUST  abort the handshake with a "protocol_version" alert.  Note that  renegotiation is not possible when TLS 1.3 has been negotiated.
TLS 1.2 implementations SHOULD also process this extension.
2) DER need a Normative Reference on first use. There are some references on 2nd/3rd use.
I read this several times and still don't understand what this is saying. It is saying "ignores ... until it is able to receive". I think you either don't mean "ignore" (as in discard the rest) or I misunderstood. I clarifying example or a reference to another section (e.g. with the diagram) would be very helpful here.
Just to double check: are you saying that before the handshake TLS application layer effectively results in plain text messages (with some extra octets to signal record type)?
6) The diagram in section 7.1 was a bit cryptic. Maybe explain that when you use '0' you mean as many bytes of 0s as needed for various functions.
and look forward to its widespread deployment.
This document obsoletes 5077, 5246, and 6961; and updates 4492, 5705, and 6066.
>  the list of versions.
versions" implementation situation that is mentioned elsewhere in the document.
with this situation, we end up in the same "can't move versions forward"
corner that led to freezing the legacy version string at 0x0303.
given the relatively generous allocation in RFC 5246, is two going to be enough?
>  underlying primitive (AES or ChaCha20) has no weaknesses.
>  prior to reaching these limits.
[AEAD-LIMITS], which means [AEAD-LIMITS] needs to be a normative reference.
>     not currently allocated are reserved for backwards compatibility.
one being 8 characters in excess of 72.
it is unusual for a document to switch back and forth. I recommend consistency.
>     are both the corresponding hash algorithm as defined in [SHS].
>  is willing to perform post-handshake authentication Section 4.6.2.
>  which was provided with the ticket.  The "obfuscated_ticket_age"
>  Section 4.6.1 modulo 2^32.
"...the ticket (see Section 4.1.6), modulo 2^32."
contain extra line feeds and indenting spaces.
Presumably "...and left padded...", correct?
>             Designs, Codes and Cryptography , 1992.
>  [HCJ16]    Husak, M., &#268;ermak, M., Jirsik, T., and P.
>             DOI 10.1186/s13635-016-0030-7, February 2016.
"...of this document); in particular, one..."
based on the RSA encryption standard PKCS #1".
which is made of wood, leads outside.") This document uses "which" where "that"
below, I'm highlighting the locations where a literal reading of "which"
(except those that occur at the beginning of a paragraph).
>    server: The endpoint which did not initiate the TLS connection.
>    version prior to TLS 1.2 if one side supports a sparse range.
>    ServerHello.version and MUST NOT send the "supported_versions"
>    TLS 1.2 implementations SHOULD also process this extension.
>    takes as input an arbitrary-length message, rather than a digest.
>    value pairs which it would like the client's certificate to match.
>    which was provided with the ticket.  The "obfuscated_ticket_age"
>    length) MUST terminate the connection with a "decode_error" alert.
>    requiring additional care by applications which use these exporters.
described in section Section 4.4.2.1.
is a run-on sentence. Perhaps a period after "section 7.5"?
Is "forward secrecy" (the term used in this draft) the same thing as "perfect forward secrecy" (the term I hear most often, and it does appear in one reference title)?
between 300 and 400 bytes of type opaque.
was pretty hard to parse until I read further. Did anyone else find that confusing?
same type in a given extension block.
I didn't see what to do if the MUST NOT is violated. Is that worth mentioning?
peer's Finished message MUST be treated as an unexpected record type.
Registry as described in Section 11.
I wondered if there was a difference between an unexpected record type and and unexpected message.
negotiate the most preferred common parameters.
Also, thanks to the doc shepherd for a good write-up.
I'm balloting NoObj instead of Yes only because I don't think I have enough background/expertise in the topic.
1) I'm a bit uncertain if obsoleting is the right approach as many other protocols usually do not obsolete older versions. However, I understand that this has been the approach TLS has previously taken and is supported by the way the document is written. Still, I find it especially confusing that also two TLS1.2 extensions are deprecated which are not needed with TLS1.3 anymore but still probably valid to be used with TLS1.2, right?
I would recommend for this version to at least already note in the abstract or very early in the intro that it changes the versioning mechanism itself, and thereby basically declares the TLS handshake as an invariant for all future versions and extensibility is only provided using extensions anymore.
2) Can you provide further explanation (potentially in the draft) why the Pre-Shared Key Exchange Modes are provided in an extra/separate extension?
3) I know previous versions of TLS didn't say that much either, but I find it a bit wired that there are NO requirements for the underlaying transport in this document. Previous version this at least said in the intro that a reliable transport (like TCP) is assumed, but even this minimal information seems to have gotten lost in this document. However, I would usually also expect to seen some minimal text about connection handling, e.g. is it okay to transparently try to reestablish the connection by the underlying transport protocol if it broke for some reason? Or it is okay to use the same TCP connection to first send other data and then start the TLS handshake?
4) Regarding the registration policies: I assume the intend of changing them is to make it easier to specify and use new extensions/mechanism. However, I am wondering why the policies have been changed to "Specification Required" and not "IETF consensus" or RFC Required"?
5) I find it a bit strange that basically the whole working group is listed as contributors. My understanding was that Contributors are people that have contributed a "significant" amount of text, while everybody else who e.g. brought ideas in during mailing list discussion would be acknowledged only.