Subject: [quicwg/base-drafts] Clients cannot abandon Initial packets while server can still send initial close (#2541)

From: mjoras <[email-masked]>
Date: Thu, 21 Mar 2019 11:37:05 -0700

17.2.2.1 of the spec current reads:
"**A client stops both sending and processing Initial packets when it sends its first Handshake packet.** A server stops sending and processing Initial packets when it receives its first Handshake packet. Though packets might still be in flight or awaiting acknowledgment, no further Initial packets need to be exchanged beyond this point. Initial packet protection keys are discarded (see Section 4.10 of [QUIC-TLS]) along with any loss recovery and congestion control state (see Sections 5.3.1.2 and 6.9 of [QUIC-RECOVERY])."

I believe this is inconsistent with section 10.3, regarding sending an initial connection close:
"If the connection has been successfully established, endpoints MUST send any CONNECTION_CLOSE frames in a 1-RTT packet. Prior to connection establishment a peer might not have 1-RTT keys, so endpoints SHOULD send CONNECTION_CLOSE frames in a Handshake packet. **If the endpoint does not have Handshake keys, or it is not certain that the peer has Handshake keys, it MAY send CONNECTION_CLOSE frames in an Initial packet.** If multiple packets are sent, they can be coalesced (see Section 12.2) to facilitate retransmission."

The client may have started sending handshake packets at the point which the server decides to send a close. Since the server does not know if the client has the handshake keys it MAY send the close in an initial packet. However since the client stops (though it is missing a MUST or MAY qualifier) processing initial packets it will never process the close from 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/issues/2541

---

From: Subodh Iyengar <[email-masked]>
Date: Fri, 22 Mar 2019 14:06:59 -0700

Ya we encountered this issue while interoping with @larseggert. mvfst sends the close in initial keys until we're sure that the client has the onertt keys. I think this should be allowed.

-- 
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/2541#issuecomment-475783211

---

From: Nick Banks <[email-masked]>
Date: Fri, 22 Mar 2019 14:09:16 -0700

We really want to throw away initial keys ASAP. What about sending connection close in ALL encryption levels the peer might accept?Send a coalesced Initial/Handshake packet, each containing connection close.

-- 
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/2541#issuecomment-475783884

---

From: David Schinazi <[email-masked]>
Date: Fri, 22 Mar 2019 23:09:10 -0700

I agree with @nibanks. Keeping the initial keys around for longer opens up a DoS attack vector. Instead having the server send CONNECTION_CLOSE with all the keys it supports sounds safer, and using a coalesced packet can make that efficient.

-- 
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/2541#issuecomment-475843070

---

From: Kazuho Oku <[email-masked]>
Date: Sat, 23 Mar 2019 01:46:47 -0700

I agree with the principle of throwing Initial keys ASAP. Another strategy that can be employed by the server to avoid the issue is send CONNECTION_CLOSE in Initial packets, but continue waiting for Handshake packets until it discards the connection. When it receives a Handshake packet (that successfully authenticates), it sends a CONNECTION_CLOSE frame in Handshake packet. The approach works because a client is required to send an empty Handshake packet even if there's no data to be sent.

-- 
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/2541#issuecomment-475852470

---

From: Subodh Iyengar <[email-masked]>
Date: Sat, 23 Mar 2019 12:55:25 -0700

that's an interesting idea, but kind of annoying. It makes coalesced packets a requirement for correct behavior, that we don't have right now.

-- 
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/2541#issuecomment-475899651

---

From: Nick Banks <[email-masked]>
Date: Sat, 23 Mar 2019 16:09:28 -0700

I don't think coalesced packets would be a requirement. You could still send separate UDP datagrams.

-- 
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/2541#issuecomment-475912568

---

From: ianswett <[email-masked]>
Date: Sat, 23 Mar 2019 18:03:23 -0700

My understanding is that the KEYS_READY/RETIRE_KEYS/etc(#2214) change is going to change the key discarding dynamics enough that this issue may not longer be a problem?

In particular, I'd expect the client to send RETIRE_KEYS when it first has Handshake keys and the server to send it when it receives a Handshake packet from the client.  That would delay dropping the Initial keys just enough that I believe there should no longer be a confusion about what the highest encryption level the peer will process?

-- 
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/2541#issuecomment-475918359