Draft: draft-ietf-quic-applicability

Commentary: 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 do n't think this document is the place to state it ) We can assume that any HTTP version might learn about HTTP/3 via    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 was n'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 .  's suggestion to say " TLS over TCP " is better but would still not address the plaintext HTTP case . A user agent might see , connect to port 80 , and get    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 , ? 
 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 . is there anything else you think we need to say here ?
Paragraph (version A):
While recent measurements have shown no evidence of widespread,
systematic disadvantage of UDP traffic compared to TCP in the
Internet Edeline16, somewhere between three Trammell16 and five
Swett16 percent of networks simply block UDP traffic.  All
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,
this fallback is TLS 1.3 over TCP.
Paragraph (version B):
While recent measurements have shown no evidence of widespread,
systematic disadvantage of UDP traffic compared to TCP in the
Internet Edeline16, somewhere between three Trammell16 and five
Swett16 percent of networks simply block UDP traffic.  All
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,
this fallback is TLS over TCP.
Paragraph (version A):
An application that implements fallback needs to consider the
security consequences.  A fallback to TCP and TLS 1.3 exposes control
information to modification and manipulation in the network.  Further
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.
Paragraph (version A):
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
application layer if needed.
Paragraph (version A):
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.
Paragraph (version A):
Note that there is some evidence of middleboxes blocking SYN data
even if TFO was successfully negotiated (see PaaschNanog).
Paragraph (version A):
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.
Paragraph (version B):
An application that implements fallback needs to consider the
security consequences.  A fallback to TCP and TLS exposes control
information to modification and manipulation in the network.  Further
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.
Paragraph (version B):
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
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.
Paragraph (version B):
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.