Subject: Re: [quicwg/base-drafts] Can a client send 0-RTT data when receiving Retry? (#1507)

From: Martin Thomson <[email-masked]>
Date: Sun, 01 Jul 2018 18:04:36 -0700

What does the server do with the 0-RTT packets?  Does the server have to keep the same connection ID for the packets to arrive at the right place?

TLS could have allowed 0-RTT to continue after a HelloRetryRequest, but decided not to allow it.  For that reason, I'd assumed that we would follow the same design here.  If 0-RTT is accepted (and can't see a concrete reason not to allow it), then we need to consider what the consequences 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/issues/1507#issuecomment-401646548

---

From: ekr <[email-masked]>
Date: Sun, 01 Jul 2018 19:42:28 -0700

> What does the server do with the 0-RTT packets?

This is already an issue with 0-RTT, because the client generates a fresh CID which sends you to a random location 

> Does the server have to keep the same connection ID for the packets to arrive at the right place?

I don't understand the question. You mean the same CID when it sends the Retry? Why would that be needed?

> TLS could have allowed 0-RTT to continue after a HelloRetryRequest, but decided not to allow it. For that reason, I'd assumed that we would follow the same design here. If 0-RTT is accepted (and ca…

I don't think that's a very good analogy, because a consequence of this design is that the Retry happens entirely below the TLS layer. Saying that 0-RTT is forbidden here is more like saying that it's forbidden if you have a TFO failure.

-- 
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/issues/1507#issuecomment-401656606

---

From: Martin Thomson <[email-masked]>
Date: Sun, 01 Jul 2018 21:19:34 -0700

The point is that if the handshake is successful, then the ClientHello and all the 0-RTT have the same destination connection ID, so they probably end up at the same point.  Add Retry and they might not.

I think that the TLS analogy is fine.  In TLS, a server could want a different key share, but find the PSK perfectly adequate for the purposes of 0-RTT.  There's no reason a server that sends HelloRetryRequest would need to stop accepting 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/issues/1507#issuecomment-401668401

---

From: ekr <[email-masked]>
Date: Mon, 02 Jul 2018 05:55:55 -0700

> The point is that if the handshake is successful, then the ClientHello and all the 0-RTT have the same destination connection ID, so they probably end up at the same point. Add Retry and they might…

Huh? If you do Retry, you resend initial and this includes resending CH and 0-RTT.

> I think that the TLS analogy is fine. In TLS, a server could want a different key share, but find the PSK perfectly adequate for the purposes of 0-RTT. There's no reason a server that sends HelloRe…

Yes, of course, but that creates complexity in the TLS state machine because of the way CH and HRR are intertwined. That is not so for Retry.

-- 
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/issues/1507#issuecomment-401795136

---

From: MikkelFJ <[email-masked]>
Date: Mon, 02 Jul 2018 06:18:57 -0700

A 0-RTT retry probably should mean try again with a 1-RTT if it should at
all respond to retry because as Martin already pointed out, a redirected
server likely won’t have the keys whether an endpoint or a middlebox
triggers the retry.

DoS considerations:

You could argue that a dump middle issuing retries under DoS attack might
inadvertently redirect 0-RTT instead of letting it through. Under DoS a
0-RTT handshake could be a way to let priority traffic through.

It might, however, also be that a DoS attack could drain resources be
sending many invalid 0-RTT packets. So the DoS argument isn’t entirely
clear cut.

Attacks in the opposite direction are also possible by man-on-the-side by
sending false retries to the client which could prevent a 0-RTT priority
client from getting through.

Another consideration is to have 0-RTT specific non-stateless retry - I’m
not sure about TLS here - it could be it already supports  that - and it
ties in with servers preferred address which I’m also not up to speed with.

On 2 July 2018 at 14.55.53, ekr ([email-masked]) wrote:

The point is that if the handshake is successful, then the ClientHello and
all the 0-RTT have the same destination connection ID, so they probably end
up at the same point. Add Retry and they might not.

Huh? If you do Retry, you resend initial and this includes resending CH and
0-RTT.

I think that the TLS analogy is fine. In TLS, a server could want a
different key share, but find the PSK perfectly adequate for the purposes
of 0-RTT. There's no reason a server that sends HelloRetryRequest would
need to stop accepting 0-RTT.

Yes, of course, but that creates complexity in the TLS state machine
because of the way CH and HRR are intertwined. That is not so for Retry.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<https://github.com/quicwg/base-drafts/issues/1507#issuecomment-401795136>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AALzN2V8KH-ojf_bpuTvVu1CrPRG09Urks5uChhZgaJpZM4U9xPP>
.

-- 
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/issues/1507#issuecomment-401801284

---

From: ekr <[email-masked]>
Date: Mon, 02 Jul 2018 06:44:35 -0700

> A 0-RTT retry probably should mean try again with a 1-RTT if it should at all respond to retry because as Martin already pointed out, a redirected server likely won’t have the keys whether an endpoint or a middlebox triggers the retry.

I don't see why this would be the case. The original Initial packet is destined to some random server in the server farm. At worst, the retried Initial packet will also be sent to a random server, but at best the server will redirect it. How is that worse?

-- 
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/issues/1507#issuecomment-401808742

---

From: MikkelFJ <[email-masked]>
Date: Mon, 02 Jul 2018 06:48:06 -0700

Ignoring retry, a 0-RTT that is routed to a random location isn't worth very much in the general case. If that is really the case, we should look at how 0-RTT manages the original DCID.

-- 
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/issues/1507#issuecomment-401810064

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 18 Jul 2018 15:52:48 +0000 (UTC)

Note that since -13, the settings of the previous connection will be retained in the token, because we no longer define an extension slot in NewSessionTicket. The conveyer of address validation data _and setting information_ have moved to token.

However, token (which is contained in a Initial that attempts a 0-RTT) is replaced once the server sends a Retry packet.

That makes handling of 0-RTT a bit complicated, especially when the information about previous settings is necessary to determine if a server accepts the 0-RTT (see #1541).

-- 
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/issues/1507#issuecomment-405981043

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Jul 2018 05:18:29 -0700

I don't think that token handling is all that difficult here.  The token doesn't need to be treated any differently than a second Retry: the client replaces the token it has with the token from Retry.

Some text might be necessary though.

-- 
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/issues/1507#issuecomment-406256511

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 19 Jul 2018 17:02:59 +0000 (UTC)

> I don't think that token handling is all that difficult here.

One of the issues here is that an on-path or a man-on-the-side attacker can mount a cut-and-paste attack that replaces token with a different value.

Let me explain one possible attack, that happens in following steps:
1. attacker connects to the server and obtains a token that says "server-config=A"
2. client connects to the server and obtains a NST and a token that says "server-config=B". At this 
3. client tries to reconnect to the server using the NST and the token obtained in step 2
4. an attacker enforces a retry by sending a token obtained in step 1

At this point, client believes that it can send 0-RTT packets based on the negotiated settings in step 2, which is "server-config=B". The server would assume that the 0-RTT packets that it will receive is based on "server-config=C".

I am not sure how scary it sounds right now, however it could become a practical concern when we start adding extension frames to QUIC.

To avoid this type of attack, the server needs to do something like:
* store the server settings in the session ticket rather than the token. TLS stacks will need to provide an interface for that (if they do not provide one yet), or
* have a different STEK for every server-config, so that resumption will fail if the client provides tries to resume with a PSK that is not bound to the server-config found in the token

-- 
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/issues/1507#issuecomment-406347056

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Jul 2018 22:14:16 -0700

Closed #1507 via #1514.

-- 
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/issues/1507#event-1761808156