Subject: Re: [quicwg/base-drafts] Allow most frames in 0-RTT (#2355)

From: Martin Thomson <[email-masked]>
Date: Tue, 05 Feb 2019 21:32:24 -0800

@martinthomson pushed 1 commit.

9400c2f9b2c5a235ce15377538bc8dc354467f39  Replay protection is the responsibility of application protocols

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2355/files/fdfb19d5922e75b5d6b93eda217e3a9c242308f6..9400c2f9b2c5a235ce15377538bc8dc354467f39

---

From: MikkelFJ <[email-masked]>
Date: Wed, 06 Feb 2019 13:13:35 -0800

mikkelfj commented on this pull request.

> +
+As described in Section 8 of {{!TLS13}}, use of TLS early data comes with an
+exposure to replay attack.  The use of 0-RTT in QUIC is similarly vulnerable to
+replay attack.
+
+Endpoints MUST implement and use the replay protections described in {{!TLS13}},
+however it is recognized that these protections are imperfect.  Therefore,
+additional consideration of the risk of replay are needed.
+
+QUIC is not inherently vulnerable to replay attack.  The management of QUIC
+protocol state based on the frame types defined in {{QUIC-TRANSPORT}} is not
+vulnerable to replay.  Processing of QUIC frames is idempotent and cannot result
+in invalid connection states if frames are reordered or lost.  QUIC connections
+do not produce effects that last beyond the lifetime of the connection, except
+for those produced by the application protocol that QUIC serves.
+

Except new 0-RTT tokens, which of course are made under 1-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/2355#pullrequestreview-200807476

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Feb 2019 13:32:18 -0800

MikeBishop approved this pull request.

I'm okay with the text as it stands, but had a few things to consider.

> @@ -324,19 +324,15 @@ the connection can usually appear at any encryption level, whereas those
 associated with transferring data can only appear in the 0-RTT and 1-RTT
 encryption levels:

The beginning of this paragraph (which GitHub won't let me comment on) is no longer true -- there isn't a specific list of frames per encryption level, but a list of exceptions to a general rule.

> +MUST describe how the protocol uses 0-RTT and the measures that are employed to
+protect against replay attack.  Disabling 0-RTT entirely is the most effective
+strategy.
+
+In the core protocol, particular attention needs to be paid to STREAM frames,
+which carry application data.  If another frame type carries, or could carry,
+application semantics, then the risk from replay attack needs to be considered.
+For instance, though this is likely to be inadvisable, an application that
+attached semantics to increases in flow control credit or stream cancellation
+would need to assess whether those uses were vulnerable to replay attack.
+
+Extensions to QUIC might create an additional exposure to replay attack if they
+are used by application protocols.  QUIC extensions SHOULD describe how replay
+attacks affects their operation.  Application protocols MUST either disable
+extensions in 0-RTT or provide replay mitigation strategies for any use of the
+extension.

This last sentence feels a little weird.  The application protocol is responsible for rules about transport extensions?  I would expect to be able to add support for new extensions to a transport library without needing to rev the application layer, unless the extension is explicitly used by the application layer.

It seems like the requirement that extensions describe how replay attacks are mitigated would be sufficient in general, and scope that last requirement to extensions which carry explicit application semantics (e.g. DATAGRAM).

-- 
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/2355#pullrequestreview-202914936

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Feb 2019 13:37:14 -0800

@MikeBishop pushed 1 commit.

5bbe441637b02e211265464931913e393ef13fb8  Merge remote-tracking branch 'origin/master' into 0rtt-reset

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2355/files/9400c2f9b2c5a235ce15377538bc8dc354467f39..5bbe441637b02e211265464931913e393ef13fb8

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Feb 2019 13:44:26 -0800

f95c289d1b49ed188ba1aa940de4feb3133adc4d  Mike's comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2355/files/5bbe441637b02e211265464931913e393ef13fb8..f95c289d1b49ed188ba1aa940de4feb3133adc4d

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 12 Feb 2019 15:16:21 -0800

janaiyengar commented on this pull request.

-- All other frame types MUST only appear at the 1-RTT levels.
+Note that it is not possible to send some frames in 0-RTT for various reasons.

Suggested reword:
"Note that it is not possible to send the following frames in 0-RTT for various reasons: ACK, CRYPTO ..."

-- 
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/2355#pullrequestreview-202958358

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Feb 2019 15:36:00 -0800

@martinthomson pushed 2 commits.

0974bda7da7977b5504d8eae222a1a57d5aa2af5  Reword
0bb2046abc730c39e245f1041a4c074ce714454d  application semantics stuff

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2355/files/f95c289d1b49ed188ba1aa940de4feb3133adc4d..0bb2046abc730c39e245f1041a4c074ce714454d

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Feb 2019 23:37:41 +0000 (UTC)

-- 
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/2355#pullrequestreview-202965077

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 12 Feb 2019 15:59:14 -0800

> +this could increase these costs because attackers can send copies of 0-RTT
+packets to different server instances, causing the processing to be repeated.
+Servers MUST ensure that they account for any increase in costs before accepting
+connections or 0-RTT.
+
+Ultimately, the responsibility for managing the risks of replay attacks with
+0-RTT lies with an application protocol.  An application protocol that uses QUIC
+MUST describe how the protocol uses 0-RTT and the measures that are employed to
+protect against replay attack.  Disabling 0-RTT entirely is the most effective
+strategy.
+
+In the core protocol, particular attention needs to be paid to STREAM frames,
+which carry application data.  If another frame type carries, or could carry,
+application semantics, then the risk from replay attack needs to be considered.
+For instance, though this is likely to be inadvisable, an application that
+attached semantics to increases in flow control credit or stream cancellation

```suggestion
attaches semantics to increases in flow control credit or stream cancellation
```

-- 
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/2355#pullrequestreview-202971055

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 12 Feb 2019 23:59:44 +0000 (UTC)

janaiyengar 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/2355#pullrequestreview-202971201

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Feb 2019 16:01:15 -0800

c4e459ffda2a56980f5e61322342566ab263c179  attachment issue

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2355/files/0bb2046abc730c39e245f1041a4c074ce714454d..c4e459ffda2a56980f5e61322342566ab263c179

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 12 Feb 2019 16:07:34 -0800

kazuho commented on this pull request.

-- All other frame types MUST only appear at the 1-RTT levels.
+Note that it is not possible to send the following frames in 0-RTT for various
+reasons: ACK, CRYPTO, NEW_TOKEN, PATH_RESPONSE, and RETIRE_CONNECTION_ID.

I am not sure if this is accurate.

IIUC their is nothing that mandates the client to switch to using 1-RTT when it receives ServerFinished. In fact, on a lossy network, a client would benefit from using 0-RTT packets until it receives an ACK for ClientFinished. In such case, it would be natural to observe these frames in a 0-RTT packet.

I think we should either forbid them or clarify that there are allowed, instead of suggesting (IMO incorrectly) that it’s impossible.

-- 
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/2355#pullrequestreview-202973228

---

From: Mike Bishop <[email-masked]>
Date: Tue, 12 Feb 2019 16:47:17 -0800

MikeBishop commented on this pull request.

This issue is now #2458.

-- 
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/2355#discussion_r256208183

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 25 Feb 2019 16:38:14 -0800

> +## Replay Attacks with 0-RTT
+

```suggestion
for those produced by TLS or the application protocol that QUIC serves.
```

(addresses @mikkelfj's point below)

-- 
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/2355#pullrequestreview-207709019