Subject: [quicwg/base-drafts] Is Retry a new connection or what? (#2180)

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 17:15:31 -0800

I've been trying to reason about Retry and in particular the following text:

```
   The next Initial packet from the client uses the connection ID and
   token values from the Retry packet (see Section 7.2).  Aside from
   this, the Initial packet sent by the client is subject to the same
   restrictions as the first Initial packet.  A client can either reuse
   the cryptographic handshake message or construct a new one at its
   discretion.
```

This seems like it really is saying that a Retry is a new connection, and in particular that the server cannot memorize the CRYPTO from the previous Initial (which it might otherwise choose to do). I'm still trying to figure out if this is the right answer, but it seems confusing to allow the client to have both behaviors, especially as we encourage the "construct a new one". Also, if you construct a new one, could you potentially reuse the KeyShare values (might be an issue with PQ). 

I'm not quite sure what I think about this, but I wanted to post an issue to see if other people think it's weird and if so, maybe we should take a more prescriptive stance.

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Dec 2018 18:07:00 -0800

I think that it's OK to resend the same cryptographic handshake message.  The semantics of Retry mean that the first wasn't used.

The only thing that might be a concern is if an attacker can use this to cause two parallel connections to be established from the same ClientHello.  I don't think that's possible, and the protocol is structured in a way that avoids that.

(Your point about reuse and PQ does make me think that the stuff @kazuho was contemplating as a defense against packet injection is potentially dangerous in that context.  I'm glad that there are now other approaches being contemplated for that.)

-- 
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/2180#issuecomment-447188104

---

From: martinduke <[email-masked]>
Date: Fri, 14 Dec 2018 16:42:16 -0800

It is the same connection. Otherwise, the original_connection_id transport parameter has no clear meaning.

-- 
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/2180#issuecomment-447519785

---

From: janaiyengar <[email-masked]>
Date: Fri, 14 Dec 2018 17:30:24 -0800

What @martinduke says makes sense. We may want to tease out the text a bit
to articulate this point, but I think it's part of the same connection
establishment and therefore part of the same connection.

On Fri, Dec 14, 2018 at 4:42 PM martinduke <[email-masked]> wrote:

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

-- 
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/2180#issuecomment-447525263