Change:
Applicability section 2 says: I'm not sure how practical this advice is. Requiring a fallback to TLS 1.3 specifically seems problematic due to the diversity of HTTP versions and TLS versions that are deployed today. (NB: I agree with a general raising of the bar for security, but I don't think this document is the place to state it) We can assume that any HTTP version might learn about HTTP/3 via Alt-Svc or HTTPSVC. This could for example be HTTP/1.1 over TCP port 80. Such a client could fallback to the version it learned about QUIC from, and nothing bad would happen.
This wasn't meant to enforce any restriction. The assumption was simply that if you have implemented QUIC, you might have probably also implemented TLS1.3... however, I guess we can just remove the "1.3" here and only say "TLS over TCP". Okay?
One could argue it should require TLS 1.3, since otherwise there's an easy security downgrade, but I'm not sure that's something we could require.
IMO we need to accommodate disparate support across versions. To give an example, a CDN operator may have QUIC and HTTP endpoints that are configured differently according to customer configuration. With QUIC v1 it is safe to assume only TLS 1.3 so a CDN might not provide configuration for TLS version. However, other HTTP versions could theoretically be configured only to support a maximum of TLS 1.2. Since plaintext HTTP and TLS 1.2 are not prohibited for use on the internet, it seems odd to levy a requirement that prevents them being used in one specific chain of interactions. Mirja's suggestion to say "TLS over TCP" is better but would still not address the plaintext HTTP case. A user agent might see URL, connect to port 80, and get Alt-Svc'd to HTTP/3. If the something goes wrong and TLS is not permitted, then all connectivity might be broken forever.
In the same section later we say I hope that addresses your point about security downgrade, NAME ?
It might be worth saying "likely to impose a degradation on performance and can degrade security;"?
I created a PR and also changed the order of sentences a bit to make the it more clear. NAME is there anything else you think we need to say here?

Discussion:
applications running on top of QUIC must therefore either be prepared to accept connectivity failure on such networks, or be engineered to fall back to some other transport protocol.  In the case of HTTP, <del> this fallback is TLS 1.3 over TCP. </del> <ins> this fallback is TLS over TCP. </ins> The IETF TAPS specifications I-D.ietf-taps-arch describe a system with a common API for multiple protocols and some of the implications

secure protocols. An application that implements fallback needs to consider the <del> security consequences.  A fallback to TCP and TLS 1.3 exposes control </del> <ins> security consequences.  A fallback to TCP and TLS exposes control </ins> information to modification and manipulation in the network.  Further <del> downgrades to older TLS versions might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </del> <ins> downgrades to older TLS versions than used in QUIC, which is 1.3, might result in significantly weaker cryptographic protection.  For example, the results of protocol negotiation RFC7301 only have confidentiality protection if TLS 1.3 is used. </ins> These applications must operate, perhaps with impaired functionality, in the absence of features provided by QUIC not present in the fallback protocol.  For fallback to TLS over TCP, the most obvious difference is that TCP does not provide stream multiplexing and therefore stream multiplexing would need to be implemented in the <del> application layer if needed. Further, TCP implementations and network paths often do not support the Fast Open option, which is analogous to 0-RTT session resumption. Even if Fast Open successfully operates end-to-end, it is limited to a single packet of payload, unlike QUIC 0-RTT. Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog). Any fallback mechanism is likely to impose a degradation of performance; however, fallback must not silently violate the application's expectation of confidentiality or integrity of its payload data. </del> <ins> application layer if needed.  Further, TCP implementations and network paths often do not support the Fast Open option, which is analogous to 0-RTT session resumption.  Note that there is some evidence of middleboxes blocking SYN data even if TFO was successfully negotiated (see PaaschNanog).  And even if Fast Open successfully operates end-to-end, it is limited to a single packet of payload, unlike QUIC 0-RTT. </ins> Moreover, while encryption (in this case TLS) is inseparably integrated with QUIC, TLS negotiation over TCP can be blocked.  If

instead, in order to enable the application to present a suitable prompt to the user that secure communication is unavailable. <ins> In summary, any fallback mechanism is likely to impose a degradation of performance and can degrade security; however, fallback must not silently violate the application's expectation of confidentiality or integrity of its payload data. </ins> 3. QUIC provides for 0-RTT connection establishment.  Though the same