Re: [quicwg/base-drafts] Idempotent is not the standard for 0-RTT (#4394)

[kaduk <[e-mail]>]

@kaduk commented on this pull request.



> @@ -1276,10 +1276,31 @@ If 0-RTT keys are available (see {{enable-0rtt}}), the lack of replay protection
 means that restrictions on their use are necessary to avoid replay attacks on
 the protocol.
 
-A client MUST only use 0-RTT keys to protect data that is idempotent.  A client
-MAY wish to apply additional restrictions on what data it sends prior to the
-completion of the TLS handshake.  A client otherwise treats 0-RTT keys as
-equivalent to 1-RTT keys, except that it MUST NOT send ACKs with 0-RTT keys.
+Of the frames defined in {{QUIC-TRANSPORT}}, the STREAM, RESET_STREAM, and
+CONNECTION_CLOSE frames are potentially unsafe for use with 0-RTT as they
+carry application data.  Application data that is received in 0-RTT could cause
+an application at the server to process the data multiple times rather than
+just once. Additional actions taken by a server as a result of processing
+replayed application data could have unwanted consequences. A client therefore
+MUST only use 0-RTT for application data that is permitted by the application
+that is in use.

Do we want to have QUIC 0-RTT data and TLS 0-RTT data treated as equivalent for the purposes of being allowed by an application profile?  For example, the next paragraph cites RFC 8470 for HTTP 0-RTT data, but as written that document covers only TLS and not QUIC.
(AFAICT the security properties are the same so there shouldn't be a problem with letting "0-RTT" apply to both raw TLS and QUIC, but it seems like we should consciously choose to do that instead of implicitly doing it.)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/4394#pullrequestreview-534984869