Subject: Consensus Call on #2344: Frames that are allowed in 0-RTT packets

From: Mark Nottingham <[email-masked]>
Date: Wed, 6 Mar 2019 14:51:27 +1100

Regarding:
  <https://github.com/quicwg/base-drafts/issues/2344>

We discussed this in Tokyo, and then continued discussion on-list. The editors now believe that this PR resolves the issue:
  <https://github.com/quicwg/base-drafts/pull/2355>

.... and discussion so far seems to support consensus to do so. If you object, please do so on the issue or in response to this message; absent any pushback, we'll declare consensus at the end of the week.

Regards,

--
Mark and Lars, WG Chairs

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 6 Mar 2019 05:38:48 +0000

There is a pending suggested change on TLS impact on state. I’m fine with a negative list in 0-RTT, but would prefer a positive list, possibly in a table. I think the discussion on replay could be trimmed a bit.

________________________________
Fra: QUIC <[email-masked]> på vegne af Mark Nottingham <[email-masked]>
Sendt: onsdag, marts 6, 2019 4:51 AM
Til: IETF QUIC WG
Cc: Lars Eggert
Emne: Consensus Call on #2344: Frames that are allowed in 0-RTT packets

Regarding:

..... and discussion so far seems to support consensus to do so. If you object, please do so on the issue or in response to this message; absent any pushback, we'll declare consensus at the end of the week.

Regards,

--
Mark and Lars, WG Chairs

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 06 Mar 2019 16:38:17 -0500

I responded to the suggestion (it got lost in the noise).  If you have specific suggestions about what text might be removed, that would be great.

On Wed, Mar 6, 2019, at 16:39, Mikkel Fahnøe Jørgensen wrote:
>  
> There is a pending suggested change on TLS impact on state. I’m fine 
> with a negative list in 0-RTT, but would prefer a positive list, 
> possibly in a table. I think the discussion on replay could be trimmed 
> a bit.
> 
> *Fra:* QUIC <[email-masked]> på vegne af Mark Nottingham <[email-masked]>
> *Sendt:* onsdag, marts 6, 2019 4:51 AM
> *Til:* IETF QUIC WG
> *Cc:* Lars Eggert
> *Emne:* Consensus Call on #2344: Frames that are allowed in 0-RTT packets 
>  Regarding: 
>  We discussed this in Tokyo, and then continued discussion on-list. The 
> editors now believe that this PR resolves the issue: 
>  ...... and discussion so far seems to support consensus to do so. If 
> you object, please do so on the issue or in response to this message; 
> absent any pushback, we'll declare consensus at the end of the week. 
> 
>  Regards, 
> 
>  -- 
>  Mark and Lars, WG Chairs 
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 7 Mar 2019 01:03:26 +0100

## 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 guarenteed. 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. Application MUST prohibit extensions where efficient
replay mitigation strategies cannot be provided.

On 6 March 2019 at 22.38.36, Martin Thomson ([email-masked]) wrote:

I responded to the suggestion (it got lost in the noise). If you have
specific suggestions about what text might be removed, that would be great.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 06 Mar 2019 20:39:56 -0500

Hi Mikkel,

Thanks for writing this up.  This was a great help.

I've made some changes based on this.  It maybe isn't as short as you would like, but I think it is better for the attempt.

On Thu, Mar 7, 2019, at 11:03, Mikkel Fahnøe Jørgensen wrote:
[Snip shared text]
> no state is carried across connections.

Your own comment here suggested that we point out the exception to this, which is the 0-RTT session ticket and the connection state.  If this said "no application state is carried across connections", that might be more accurate.

This also removes my text that qualifies this by saying that only the frames defined in -transport have this property.  That's probably not critical, but it is more precise.

> can define semantics that are acceptable for 0-RTT sessions, if any.

I don't understand what you are trying to say here.  There seem to be several ideas:

* Confusion about STREAM frame content: The main 0-RTT hazard is not about confusion, but about the effects resulting from doing the same work twice.

* Flow control credits: I don't believe there is any concern about flow control other than the one Kazuho articulated: the need to buffer an arbitrary amount of 0-RTT data in the case where 0-RTT was accepted.  I don't think that needs discussion here because we have good mechanisms in place for constraining that (aside from just dropping 0-RTT packets when the buffer is full, which was always possible, if suboptimal).

* Rejecting 0-RTT: that's a protection measure described in TLS, so I don't think we need to repeat it.

* Only applications and application protocols can say what is OK in 0-RTT: Yes.  That's the most important message here.  I spent a two whole paragraphs on that.  With a MUST that I think is critical.  I've cut this down to one now.

> overhead before accepting 0-RTT connections.

This is very terse, but think that it is better than what I had in its general scope.  I would rather concentrate less on "cheap to establish" and more on the fact that accepting 0-RTT on a new connection is inherently much more expensive in terms of computation and state than other types of connection.  Replay protections from TLS do severely limit the scope of attacks.
 
> replay mitigation strategies cannot be provided.

This is a fine change.

> On 6 March 2019 at 22.38.36, Martin Thomson ([email-masked] 
> <mailto:mt@lowentropy..net>) wrote:
> 
> > > We discussed this in Tokyo, and then continued discussion on-list.. The

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 12 Mar 2019 09:29:25 +1100

It seems like we have consensus here.

Regards,

> On 6 Mar 2019, at 2:51 pm, Mark Nottingham <[email-masked]> wrote:
> 
> Regarding:

--
Mark Nottingham   https://www.mnot.net/