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

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Nov 2020 21:07:42 -0800

This captures the outcome of an older analysis I did.  Basically, if a replay is attempted, you get a new connection attempt.  Only the application data that is processed at that time is a risk.

Also, all protocols need a profile that describes how to use 0-RTT, otherwise it can only be used for QUIC things.  Like NEW_CONNECTION_ID (I&#39;m struggling to think of anything else that might reasonably go here).

Closes #4393.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/4394

-- Commit Summary --

  * Semicolon
  * Rewrite replay section

-- File Changes --

    M draft-ietf-quic-tls.md (30)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/4394.patch
https://github.com/quicwg/base-drafts/pull/4394.diff

-- 
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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 18 Nov 2020 22:36:24 -0800

@kazuho commented on this pull request.

> @@ -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.

Let me nitpick, as you seem to be wondering about frames that might have issues.

I think that this sentence is slightly incorrect. There are other frames that also carry application data. Specifically, CONNECTION_CLOSE (type 0x1d) and RESET_STREAM carry information defined by the application, and we do not require the integers carried by those frames to be replay-safe. See #3440.

I think we should either discuss about "application data" in general, or name the three frames (STREAM, RESET_STREAM, CONNECTION_CLOSE (type 0x1d)) that carry information defined by the application.

-- 
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-534117493

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Nov 2020 23:54:57 -0800

@martinthomson commented on this pull request.

Excellent point.  Will amend.

-- 
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#discussion_r526657313

---

From: Martin Thomson <[email-masked]>
Date: Wed, 18 Nov 2020 23:57:41 -0800

@martinthomson pushed 1 commit.

b5ce525ff5c24660a2e80c7ceeac5132f38db3d4  RESET_STREAM and CONNECTION_CLOSE too

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4394/files/d490ef0226cc0f95ce42fd960b6ad0a5a119665c..b5ce525ff5c24660a2e80c7ceeac5132f38db3d4

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 19 Nov 2020 00:06:11 -0800

@kazuho approved this pull request.

Thank you for the changes. LGTM modulo one editorial nitpick.

> @@ -1276,10 +1276,31 @@ If 0-RTT keys are available (see {{enable-0rtt}}), the lack of replay protection
 
-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 can

```suggestion
CONNECTION_CLOSE frames are potentially unsafe for use with 0-RTT as they
```

The three frames are defined to carry application data, I think.

-- 
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-534162779

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Nov 2020 00:07:17 -0800

I was thinking about the transport-layer CONNECTION_CLOSE.  Maybe that doesn't matter.

-- 
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#discussion_r526663289

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Nov 2020 00:07:29 -0800

c2e040afd15b5fa9a513205209fbe3a3403a84e0  they do, not they can

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4394/files/b5ce525ff5c24660a2e80c7ceeac5132f38db3d4..c2e040afd15b5fa9a513205209fbe3a3403a84e0

---

From: MikkelFJ <[email-masked]>
Date: Thu, 19 Nov 2020 01:56:03 -0800

@mikkelfj commented on this pull request.

-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.
+
+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}}.

Suggest rephrasing MUST since there is a way out in not using 0-RTT. For example, if an application is connecting over QUIC 0-RTT, the application protocol MUST ...

-- 
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-534251188

---

From: David Schinazi <[email-masked]>
Date: Thu, 19 Nov 2020 12:22:54 -0800

@DavidSchinazi approved this pull request.

-- 
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-534819174

---

From: ianswett <[email-masked]>
Date: Thu, 19 Nov 2020 13:06:49 -0800

@ianswett commented on this pull request.

This looks sensible, but I'm unclear on why replaying RESET_STREAM and CONNECTION_CLOSE would be problematic.

RESET_STREAM and CONNECTION_CLOSE don't really carry application data, but I guess they could impact application data being delivered or lack thereof?  I'm also a bit unclear as to how replaying a RESET_STREAM could change state?

I do find this sentence a bit odd and I'm not completely sure we need to include any frames besides STREAM.  If so, maybe providing just a bit more explanation about why would be worthwhile?

-- 
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-534842066

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Nov 2020 14:59:15 -0800

I specifically chose this phrasing.  I know that prohibiting 0-RTT is a valid way to define a profile, but I think that is unnecessary for QUIC.  This would still allow that approach, but I would prefer a more nuanced profile that said "don't send application data in 0-RTT" than "don't send 0-RTT".

-- 
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#discussion_r527260669

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Nov 2020 15:00:14 -0800

The error codes (and message for CONNECTION_CLOSE) carry application information that might be acted upon by an application.  It's a fine point, but worth covering.

-- 
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#discussion_r527261099

---

From: kaduk <[email-masked]>
Date: Thu, 19 Nov 2020 16:22:42 -0800

@kaduk commented on this pull request.

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Nov 2020 16:30:54 -0800

I think that it is OK that we treat HTTP/3 differently to HTTP/2, even if the underlying principles are the same.

It is relatively trivial for a protocol that is ported to QUIC to reuse guidance from TCP versions, as [HTTP/3 does in Section 10.9](https://quicwg.org/base-drafts/draft-ietf-quic-http.html#name-early-data).

Citing 8470 isn't perfect, as you say, because that means we are citing something that addresses TCP, so maybe I should acknowledge that directly.

-- 
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#discussion_r527303214

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Nov 2020 16:35:38 -0800

@martinthomson pushed 2 commits.

ee55b3530985b8721e7ad2215eb003649334863d  Remove one errant use of idempotent
98239d66b2b8c4c6196582c2cad911be227490fb  RFC 8470 and HTTP/3 references added

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/4394/files/c2e040afd15b5fa9a513205209fbe3a3403a84e0..98239d66b2b8c4c6196582c2cad911be227490fb

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 24 Nov 2020 19:40:26 -0800

@janaiyengar approved this pull request.

This is good. 

-- 
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-538134091

---

From: ianswett <[email-masked]>
Date: Wed, 25 Nov 2020 07:41:17 -0800

Fair point on the error codes, but I'm still having a very difficult time understanding the scenario of interest here.  RESET_STREAM has no impact unless you send STREAM frames, so let's focus on CONNECTION_CLOSE.

If I replay only a CONNECTION_CLOSE with no STREAM frames sent on the connection, what could that do?

-- 
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#discussion_r530466708

---

From: David Schinazi <[email-masked]>
Date: Wed, 25 Nov 2020 11:01:15 -0800

@DavidSchinazi commented on this pull request.

Imagine if your application protocol does something that's both important to the user and non-idempotent when the server receives an application layer connection close. Letting an attacker replay that would be bad. I think it's worth having some text for designers of application protocols that highlight this risk.

-- 
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#discussion_r530586602

---

From: ianswett <[email-masked]>
Date: Wed, 25 Nov 2020 13:12:07 -0800

The canonical example is a bank transaction where each request deposits a dollar in someone else's account.  Using a connection close error code to convey such a transaction seems implausible to me, so I'm not saying it's impossible, just that I can't construct an example that causes any issues.

-- 
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#discussion_r530644762

---

From: ianswett <[email-masked]>
Date: Wed, 25 Nov 2020 13:12:18 -0800

@ianswett approved this pull request.

-- 
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-538848649

---

From: martinduke <[email-masked]>
Date: Wed, 25 Nov 2020 16:15:51 -0800

@martinduke commented on this pull request.

I don't know that there's an attack here, but RESET_STREAM can be sent without a STREAM, to retire that stream ID. I suppose if an application was applying semantic meaning to a particular stream-id, then canceling those stream-ids could be some sort of transaction? For example, I report a metric measurement on each stream, and if I reset that stream, then it's the default value? I dunno.

-- 
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#discussion_r530703910

---

From: Nick Banks <[email-masked]>
Date: Mon, 30 Nov 2020 08:17:18 -0800

@nibanks approved this pull request.

-- 
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-541066272