Subject: [quicwg/base-drafts] Handshake failure after Retry (#1784)

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Fri, 21 Sep 2018 07:29:35 -0700

I found that there is a corner case that handshake fails after Retry.
The current specification allows server not to change its SCID in Retry packet.  In other words, server is allowed to set client chosen CID in SCID field of Retry packet.
The spec also allows client to create fresh TLS context each time it receives Retry packet.
If they are used, there is a case that handshake fails after Retry packet.
Here is the possible scenario.

1. client sends Initial to server with TLS context T0: Initial SCID=A DCID=B
2. client resends Initial to server with TLS context T0: Initial SCID=A DCID=B
3. client receives Retry from server: Retry SCID=B DCID=A ODCID=B
4. in response to Retry(3), client sends Initial to server with TLS context T1: Initial SCID=A DCID=B
5. client receives Retry from server (in response to client Initial(2)): Retry SCID=B DCID=A ODCID=B ODCID=B
6. in response to Retry(5), client sends Initial to server with TLS context T2: Initial SCID=A DCID=B
7. client receives Initial from server (in response to client Initial(4), thus using TLS context T1): Initial SCID=C DCID=A
8. client receives Handshake from server (which uses TLS context T1): Handshake SCID=C DCID=A

client cannot decrypt Handshake packet from server because client uses TLS context T2 meanwhile server uses TLS context T1.

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

---

From: Nick Banks <[email-masked]>
Date: Fri, 21 Sep 2018 14:42:11 +0000 (UTC)

I guess the solution is to either:

a) Require Retry to change the CID.
b) Restrict the client from starting a new TLS context in response to Retry.
c) Have some other way for the client to differentiate between Retries, other than CID.

a) sounds like the simplest option to me.,

-- 
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/1784#issuecomment-423556054

---

From: ianswett <[email-masked]>
Date: Fri, 21 Sep 2018 08:16:27 -0700

My previous assumption was that if the client the connection ID the same,
it was the same connection, and therefore the TLS context should be kept
the same.

a) is likely ok, but I believe the variant of b) above fits better with the
design we have I believe?

On Fri, Sep 21, 2018 at 10:42 AM Nick Banks <[email-masked]>
wrote:

> —
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/1784#issuecomment-423556054>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ATJJcSr8v9UPI1m-htRqfb1VvBA8PDHIks5udPrDgaJpZM4W0RMP>
> .
>

-- 
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/1784#issuecomment-423569167

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Sep 2018 16:50:12 -0700

Good catch.  This is effectively the same as the case where we required connection ID to change for the client's benefit, except in reverse.  I have a PR in chain that includes the discussed changes to Retry that I can roll this into.

-- 
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/1784#issuecomment-423698731

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Sep 2018 14:12:06 -0700

Closed #1784 via #1788.

-- 
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/1784#event-1862138254