Draft: draft-ietf-quic-applicability

Commentary: These are pretty big . If you would prefer that I create a PR for each individual commit , that can be done . It turns out that there were a lot of things I found needed work . For instance , this completely redoes the 0 - RTT advice . 
 It did kinda snowball , for which I apologize . I was trying to get something under your nose before I got swamped by meetings . I am also on vacation next week . I 'm reading through and there is some really good stuff in the doc . I have started to open issues where I do n't think the fixes are so simple . 
 Aside from the keep - alive tweak and the idempotence change , these are all editorial and LGTM , thanks ! The keepalive tweak is also good . Having looked at , the text here is a good applicability - appropriate view on what 's there now . assuming discussion there converges to mostly the same thing , I 'd be happy to merge this . ( in the future , no need to make tiny PRs , but splitting into " editorial - rollup " and " substantive editorial changes " would be nice to separate discussion , since the former should n't need much of it)Changes look all ready good . Thanks ! I just have left one minor comment / question to double - check before we merge .
Paragraph (version A):
QUIC QUIC is a new transport protocol providing a number of advanced
features.  While initially designed for the HTTP use case, like most
transports it is intended for use with a much wider variety of
applications.  QUIC is encapsulated in UDP.  The version of QUIC that
is currently under development will integrate TLS 1.3 TLS13 to
encrypt all payload data and most control information.  HTTP
operating over QUIC is known as HTTP/3.
Paragraph (version B):
QUIC QUIC is a new transport protocol providing a number of advanced
features.  While initially designed for the HTTP use case, it
provides capabilities that can be used with a much wider variety of
applications.  QUIC is encapsulated in UDP.  QUIC version 1 integrate
TLS 1.3 TLS13 to encrypt all payload data and most control
information.  HTTP operating over QUIC is known as HTTP/3.
Paragraph (version A):
The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this
document.  It's not shouting; when these words are capitalized, they
have a special meaning as defined in RFC2119.
Paragraph (version A):
QUIC uses UDP as a substrate for userspace implementation and port
numbers for NAT and middlebox traversal.  While there is 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.  This fallback SHOULD
provide TLS 1.3 or equivalent cryptographic protection, if available,
in order to keep fallback from being exploited as a downgrade attack.
In the case of HTTP, this fallback is TLS 1.3 over TCP.
Paragraph (version B):
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all
capitals, as shown here.
Paragraph (version B):
QUIC uses UDP as a substrate.  This enables both userspace
implementation traversal of middleboxes and NAT without requiring
updates.
Paragraph (version B):
While there is 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):
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 ALPN only have confidentiality protection if TLS 1.3 is
used.
Paragraph (version A):
A transport protocol that provides 0-RTT connection establishment to
recently contacted servers is qualitatively different than one that
does not from the point of view of the application using it.
Relative trade-offs between the cost of closing and reopening a
connection and trying to keep it open are different; see resumption-
v-keepalive.
Paragraph (version A):
Applications must be slightly rethought in order to make best use of
0-RTT resumption.  Most importantly, application operations must be
divided into idempotent and non-idempotent operations, as only
idempotent operations may appear in 0-RTT packets.  This implies that
the interface between the application and transport layer exposes
idempotence either explicitly or implicitly.
Paragraph (version A):
Retransmission or (malicious) replay of data contained in 0-RTT
resumption packets could cause the server side to receive two copies
of the same data.  This is further described in HTTP-RETRY.  Data
sent during 0-RTT resumption also cannot benefit from perfect forward
secrecy (PFS).
Paragraph (version A):
whether rejected 0-RTT data should be retransmitted or withdrawn.
Paragraph (version A):
Some TLS implementations may offer replay protection, which may
mitigate some of these issues.
Paragraph (version B):
A transport protocol that provides 0-RTT connection establishment is
qualitatively different than one that does not from the point of view
of the application using it.  Relative trade-offs between the cost of
closing and reopening a connection and trying to keep it open are
different; see resumption-v-keepalive.
Paragraph (version B):
Applications must be slightly rethought in order to make best use of
0-RTT resumption.  Using 0-RTT requires an understanding of the
implication of sending application data that might be replayed by an
attacker.
Paragraph (version B):
Application protocols that use 0-RTT require a profile that describes
the types of information that can be safely sent.  For HTTP, this
profile is described in HTTP-REPLAY.
Paragraph (version B):
Retransmission or (malicious) replay of data contained in 0-RTT
packets could cause the server side to receive two copies of the same
data.
Paragraph (version B):
Application data sent by the client in 0-RTT packets could be
processed more than once if it is replayed.  Applications need to be
aware of what is safe to send in 0-RTT.  Application protocols that
seek to enable the use of 0-RTT need a careful analysis and a
description of what can be sent in 0-RTT; see Section 5.6 of QUIC-
TLS.
Paragraph (version B):
In some cases, it might be sufficient to limit application data sent
in 0-RTT to that which only causes actions at a server that are known
to be free of lasting effect.  Initiating data retrieval or
establishing configuration are examples of actions that could be
safe.  Idempotent operations - those for which repetition has the
same net effect as a single operation - might be safe.  However, it
is also possible to combine individually idempotent operations into a
non-idempotent sequence of operations.
Paragraph (version B):
Once a server accepts 0-RTT data there is no means of selectively
discarding data that is received.  However, protocols can define ways
to reject individual actions that might be unsafe if replayed.
Paragraph (version B):
Some TLS implementations and deployments might be able to provide
partial or even complete replay protection, which could be used to
manage replay risk.
Paragraph (version A):
By using a Connection ID, QUIC is designed to be robust to NAT
address rebinding after a timeout.  However, some QUIC connections
may not be robust to rebinding because the routing infrastructure (in
particular, load balancers) uses the address/port four-tuple to
direct traffic.  Furthermore, middleboxes with functions other than
address translation may still affect the path.  In particular,
firewalls will often not admit server traffic for which it has not
kept state for corresponding packets from the client.
Paragraph (version B):
By using a Connection ID, QUIC is designed to be robust to NAT
address rebinding after a timeout.  However, this only helps if one
endpoint maintains availability at the address its peer uses, and the
peer is the one to send after the timeout occurs.
Paragraph (version B):
Some QUIC connections may not be robust to rebinding because the
routing infrastructure (in particular, load balancers) uses the
address/port four-tuple to direct traffic.  Furthermore, middleboxes
with functions other than address translation could still affect the
path.  In particular, firewalls will often not admit server traffic
for which it has not kept state for corresponding packets from the
client.
Paragraph (version A):
lower network and computational load.  Sending PING frames more
frequently than every 30 seconds over long idle periods may result in
excessive unproductive traffic in some situations, and to
unacceptable power usage for power-constrained (mobile) devices.
Additionally, time-outs shorter than 30 seconds can make it harder to
handle trasient network interruptions, such as VM migration or
coverage loss during mobilty.
Paragraph (version B):
lower network and computational load.
Paragraph (version B):
Sending PING frames more frequently than every 30 seconds over long
idle periods may result in excessive unproductive traffic in some
situations, and to unacceptable power usage for power-constrained
(mobile) devices.  Additionally, time-outs shorter than 30 seconds
can make it harder to handle transient network interruptions, such as
VM migration or coverage loss during mobilty.
Paragraph (version A):
Alternatively, the client (but not the server) can use session
resumption instead of sending keepalive traffic.  In this case, a
client that wants to send data to a server over a connection idle
longer than the server's idle timeout (available from the
idle_timeout transport parameter) can simply reconnect.  When
possible, this reconnection can use 0-RTT session resumption,
reducing the latency involved with restarting the connection.  This
of course only applies in cases in which 0-RTT data is safe, when the
client is the restarting peer, and when the data to be sent is
idempotent.
Paragraph (version B):
Alternatively, the client (but not the server) can use session
resumption instead of sending keepalive traffic.  In this case, a
client that wants to send data to a server over a connection idle
longer than the server's idle timeout (available from the
idle_timeout transport parameter) can simply reconnect.  When
possible, this reconnection can use 0-RTT session resumption,
reducing the latency involved with restarting the connection.  This
of course only applies in cases in which 0-RTT data is safe, when the
client is the restarting peer, and when the data to be sent is
idempotent.  Using resumption in this way also assumes that the
protocol does not accumulate any non-persistent state in association
with a connection.  State bound to a connection cannot reliably be
transferred to a resumed connection.