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

From: Luca Niccolini <[email-masked]>
Date: Tue, 05 Mar 2019 20:14:39 -0800

lnicco commented on this pull request.

> @@ -1478,6 +1478,10 @@ could pose a security risk to an incautious implementer.  An implementation MUST
 ensure that the length of a frame exactly matches the length of the fields it
 contains.
 
+The use of 0-RTT with HTTP/3 creates an exposure to replay attack.  The

Just a minor suggestion.
Is this really just an HTTP/3 issue? 
The rest of the text refers to "the application protocol" which I believe is more correct. 

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

---

From: Luca Niccolini <[email-masked]>
Date: Tue, 05 Mar 2019 20:16:38 -0800

nevermind. I didn't notice this is in the http draft. 
Looks good then.

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

---

From: Marten Seemann <[email-masked]>
Date: Tue, 05 Mar 2019 20:17:20 -0800

marten-seemann commented on this pull request.

>  - PADDING frames MAY appear in packets of any encryption level.
 
+- CRYPTO and CONNECTION_CLOSE frames MAY appear in packets of any encryption

You can't really prevent implementations from sending CONNECTION_CLOSE in 0-RTT. How would the peer punish them for misbehaving, by closing the connection? So we might as well allow it and read the error code and error message.

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

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 05 Mar 2019 21:39:15 -0800

kazuho commented on this pull request.

The fear I have in allowing the CONNECTION_CLOSE frame to be sent in 0-RTT packet is that it might cause confusion among the people reading the specification.

Currently, an endpoint is expected to send a CONNECTION_CLOSE frame using a packet that it knows that the peer can decrypt (see https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#rfc.section.10.3). I think we should retain that principle, and based on that principle, an endpoint would never be sending a CONNECTION_CLOSE frame in a 0-RTT packet.

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

---

From: MikkelFJ <[email-masked]>
Date: Tue, 05 Mar 2019 22:02:43 -0800

mikkelfj commented on this pull request.

On CONNECTION_CLOSE: There are cases why you might send possible not received messages with minimal overhead and close immediately. Like a sensor reading. This isn't really idempotent, but it might be good enough for the application. MQTT added the MQTT-SN variant that accepts single packet messages on UDP although technically the connection is still open.

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

---

From: MikkelFJ <[email-masked]>
Date: Tue, 05 Mar 2019 22:05:27 -0800

But there are other problems: I suppose you can't send multiple such messages without a new 0-RTT token. Maybe a use case for v2?

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Mar 2019 13:01:33 -0800

martinthomson commented on this pull request.

There is no reason to send CONNECTION_CLOSE in 0-RTT.  CONNECTION_CLOSE has those rules (which need to be clarified, but they won't materially change), which I'd say are fine.  During the handshake, implementations have to be specially aware of where CONNECTION_CLOSE lands, that's all.

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Mar 2019 13:37:29 -0800

> +## Replay Attacks with 0-RTT
+
+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.

I realize that I had typed a response to this, but didn't post it...

This change would be a mistake.  TLS, like QUIC itself, is not the application protocol.  While it is true that the effects of tickets and address validation tokens last beyond the connection (and this might have some implications for the text), they are not effects that an application needs to worry about.

I would prefer to add "TLS session tickets and address validation tokens might be carried between connections, but these mechanisms are distinct from application state and require independent protection against reuse."  Or something to that effect.

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

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 06 Mar 2019 14:05:31 -0800

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 06 Mar 2019 16:12:59 -0800

Proposed shortening of replay section

## Replay Attacks with 0-RTT

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.

The QUIC transport protocol is not vulnerable to replay attacks and does
tolerate replayed frames because all frames are idempotent and because
no state is carried across connections.

Applications might carry state across connections and can be confused by
STREAM frame content under 0-RTT keys and also by other content such as
flow control credits. Servers can be configured to reject old 0-RTT
packets but it is not perfect nor guaranteed. Only application protocols
can define semantics that are acceptable for 0-RTT sessions, if any.

A copied 0-RTT session is cheap to establish and can be exploited to
expend excessive server resources. Applications MUST account for this
overhead before accepting 0-RTT connections.

QUIC extensions SHOULD describe how replay attacks affect their
operation. Applications MUST prohibit extensions where efficient
replay mitigation strategies cannot be provided.

-- 
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#issuecomment-470329092

---

From: Martin Thomson <[email-masked]>
Date: Wed, 06 Mar 2019 17:37:25 -0800

@martinthomson pushed 1 commit.

e03aa6b5caf2644e813c4412d2cfe162b72e7134  Taking Mikkel's review/suggestions into account, trimming, adding

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

---

From: MikkelFJ <[email-masked]>
Date: Wed, 06 Mar 2019 23:49:47 -0800

> +Processing of QUIC frames is idempotent and cannot result in invalid connection
+states if frames are replayed, 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.
+
+Note:
+
+: TLS session tickets and address validation tokens are used to carry QUIC
+  configuration information between connections.  These MUST NOT be used to
+  carry application state.  The potential for reuse of these tokens means that
+  they require stronger protections against replay.
+
+A server that accepts 0-RTT on a connection incurs a higher cost than accepting
+a connection without 0-RTT.  This includes higher processing and computation
+costs.  Servers need to consider the probability of replay and all associated
+costs when accepting 0-RTT.

I’m not sure 0-RTT server cost is higher, except relative to the client?

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 07 Mar 2019 21:36:33 +0000 (UTC)

Your point being that a client can keep their costs low?  That's not relevant here.  What matters is what the server spends relative to other connections.

Keep in mind that a client can replay a ClientHello to a server and have it do the work of connection establishment (which is considerable in terms of computation).  The delta for 0-RTT is all the processing that might be triggered by the replayed 0-RTT packets, which might mean buffering or application-level actions.  If that work is significant, and it could be, then you have an exposure.  Add the relatively negligible work of accepting packets and decrypting them if you must.

In terms of outright expense to a server, it is entirely possible that spamming bogus ClientHello messages (which don't even need valid key shares, possibly not even valid anything) could more effective than spamming 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/2355#discussion_r263578413

---

From: MikkelFJ <[email-masked]>
Date: Thu, 07 Mar 2019 13:45:32 -0800

With that argument a client might as well use 1-RTT connections and make the server pay for Diffie-Helmann exchanges in addition to buffering. What makes 0-RTT costly is the ease with which the server can be made to pay that cost. 0-RTT is expensive because it is cheap for the client to incur th expense on the server.

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

---

From: Mike Bishop <[email-masked]>
Date: Fri, 08 Mar 2019 16:28:47 -0800

MikeBishop commented on this pull request.

> -Servers MUST ensure that they account for any increase in costs before accepting
-connections or 0-RTT.
+QUIC is not vulnerable to replay attack, except via the application protocol
+information it might carry.  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 replayed, 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.
+
+Note:
+
+: TLS session tickets and address validation tokens are used to carry QUIC
+  configuration information between connections.  These MUST NOT be used to
+  carry application state.  The potential for reuse of these tokens means that
+  they require stronger protections against replay.

This contradicts the advice about using session tickets to validate HTTP settings for 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/2355#pullrequestreview-212532375

---

From: Mike Bishop <[email-masked]>
Date: Fri, 08 Mar 2019 16:33:37 -0800

MikeBishop approved this pull request.

+: TLS session tickets and address validation tokens are used to carry QUIC
+  configuration information between connections.  These MUST NOT be used to
+  carry application state.  The potential for reuse of these tokens means that
+  they require stronger protections against replay.
+
+A server that accepts 0-RTT on a connection incurs a higher cost than accepting
+a connection without 0-RTT.  This includes higher processing and computation
+costs.  Servers need to consider the probability of replay and all associated
+costs when accepting 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.  An analysis of replay risk needs to consider
+all QUIC protocol features carry application semantics.

```suggestion
all QUIC protocol features which carry application semantics.
```

> @@ -1281,6 +1280,50 @@ Never assume that because it isn't in the security considerations section it
 doesn't affect security.  Most of this document does.

```suggestion
additional consideration of the risk of replay is needed.
```
(or "considerations ... are")

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

---

From: Martin Thomson <[email-masked]>
Date: Sun, 10 Mar 2019 16:03:30 -0700

e5ca7387db8a6eac53d655304dc4be07673c8d1e  Editorial tweaks

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 11 Mar 2019 15:51:33 -0700

Merged #2355 into master.

-- 
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#event-2195501427