From ba30582447bdad9b23f3586175bd0ec28b9649f3 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 19 Nov 2020 14:56:10 +1100 Subject: [PATCH 1/7] Semicolon --- draft-ietf-quic-tls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 11bba719be..f3ff5225e8 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -741,7 +741,7 @@ the server has sent a NEW_TOKEN frame; see Section 8.1 of {{QUIC-TRANSPORT}}. ### Accepting and Rejecting 0-RTT A server accepts 0-RTT by sending an early_data extension in the -EncryptedExtensions (see Section 4.2.10 of {{!TLS13}}). The server then +EncryptedExtensions; see Section 4.2.10 of {{!TLS13}}. The server then processes and acknowledges the 0-RTT packets that it receives. A server rejects 0-RTT by sending the EncryptedExtensions without an early_data From d490ef0226cc0f95ce42fd960b6ad0a5a119665c Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 19 Nov 2020 15:45:42 +1100 Subject: [PATCH 2/7] Rewrite replay section This was wrong. Idempotency is not the standard we use to determine whether something is safe to send in 0-RTT. RFC 8470 has a lot more subtlety to it than just saying "be idempotent". The recommendation there is for _safe_ methods only. Closes #4393. --- draft-ietf-quic-tls.md | 28 ++++++++++++++++++++++++---- 1 file changed, 24 insertions(+), 4 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index f3ff5225e8..f3b2766347 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1276,10 +1276,30 @@ 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}}, only the STREAM frame is +potentially unsafe for use with 0-RTT as it carries 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. + +An application protocol that uses QUIC MUST include a profile that defines +acceptable use of 0-RTT; otherwise, 0-RTT can only be used to carry QUIC frames +that do not carry application data. For example, a profile for HTTP is +described in {{?HTTP-REPLAY=RFC8740}}. + +Though replaying packets might result in additional connection attempts, the +effect of processing replayed frames that do not carry application data is +limited to changing the state of the affected connection. A TLS handshake +cannot be successfully completed using replayed packets. + +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 cannot send certain frames with 0-RTT keys; see Section 12.5 of +{{QUIC-TRANSPORT}}. A client that receives an indication that its 0-RTT data has been accepted by a server can send 0-RTT data until it receives all of the server's handshake From b5ce525ff5c24660a2e80c7ceeac5132f38db3d4 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 19 Nov 2020 18:57:01 +1100 Subject: [PATCH 3/7] RESET_STREAM and CONNECTION_CLOSE too --- draft-ietf-quic-tls.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index f3b2766347..41e88b4ed3 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1276,13 +1276,14 @@ 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. -Of the frames defined in {{QUIC-TRANSPORT}}, only the STREAM frame is -potentially unsafe for use with 0-RTT as it carries 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. +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 can +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. An application protocol that uses QUIC MUST include a profile that defines acceptable use of 0-RTT; otherwise, 0-RTT can only be used to carry QUIC frames From c2e040afd15b5fa9a513205209fbe3a3403a84e0 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Thu, 19 Nov 2020 19:07:06 +1100 Subject: [PATCH 4/7] they do, not they can Co-authored-by: Kazuho Oku --- draft-ietf-quic-tls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 41e88b4ed3..5543527c4e 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1277,7 +1277,7 @@ means that restrictions on their use are necessary to avoid replay attacks on the protocol. 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 can +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 From ee55b3530985b8721e7ad2215eb003649334863d Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 20 Nov 2020 11:34:12 +1100 Subject: [PATCH 5/7] Remove one errant use of idempotent --- draft-ietf-quic-tls.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 5543527c4e..04edb5ebd5 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -195,7 +195,8 @@ TLS provides two basic handshake modes of interest to QUIC: * A 0-RTT handshake, in which the client uses information it has previously learned about the server to send Application Data immediately. This Application Data can be replayed by an attacker so 0-RTT is not suitable for - carrying instructions that might initiate any non-idempotent action. + carrying instructions that might initiate any action that could cause + unwanted effects if replayed. A simplified TLS handshake with 0-RTT application data is shown in {{tls-full}}. From 98239d66b2b8c4c6196582c2cad911be227490fb Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Fri, 20 Nov 2020 11:34:59 +1100 Subject: [PATCH 6/7] RFC 8470 and HTTP/3 references added --- draft-ietf-quic-tls.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 04edb5ebd5..553de13581 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1289,7 +1289,8 @@ that is in use. An application protocol that uses QUIC MUST include a profile that defines acceptable use of 0-RTT; otherwise, 0-RTT can only be used to carry QUIC frames that do not carry application data. For example, a profile for HTTP is -described in {{?HTTP-REPLAY=RFC8740}}. +described in {{?HTTP-REPLAY=RFC8470}} and used for HTTP/3; see Section 10.9 of +{{QUIC-HTTP}}. Though replaying packets might result in additional connection attempts, the effect of processing replayed frames that do not carry application data is From d1870b8d6699e9253bff9f395db496d2ab8eef71 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Mon, 7 Dec 2020 21:00:54 +1100 Subject: [PATCH 7/7] don't use unless requested Co-authored-by: Jana Iyengar --- draft-ietf-quic-tls.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 553de13581..c9452abc8b 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1283,8 +1283,8 @@ 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. +MUST NOT use 0-RTT for application data unless specifically +requested by the application that is in use. An application protocol that uses QUIC MUST include a profile that defines acceptable use of 0-RTT; otherwise, 0-RTT can only be used to carry QUIC frames