Subject: [quicwg/base-drafts] Discarding keys can lead to a connection deadlock (#4078)

From: Marten Seemann <[email-masked]>
Date: Tue, 08 Sep 2020 01:31:47 -0700

I've been debugging a connection failure that seems to be caused by a key update. Here's what's happening:

At some point during the connection, an endpoint decides to update its keys. After the key update, it doesn't send any (ack-eliciting) packets. If it sent non-ack-eliciting packets during this time, these packets are lost. After a while (e.g. 3 PTOs) it drops the old keys.
The peer never received a packet in the new key phase, so it continues sending using the old key phase. Because the keys are dropped, these packets will all end up being undecryptable.

Note that this is not an uncommon situation: An endpoint downloading a large object might initiate the key update, but not have anything to send but acknowledgements.

[Section 6.5](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#name-receiving-with-different-ke) says that receive keys MAY be discarded after 1 PTO:
> An endpoint MAY allow a period of approximately the Probe Timeout (PTO; see [QUIC-RECOVERY]) after a key update before it creates the next set of packet protection keys. These updated keys MAY replace the previous keys at that time.

... and SHOULD be discarded after 3 PTO:
> An endpoint SHOULD retain old read keys for no more than three times the PTO. After this period, old read keys and their corresponding secrets SHOULD be discarded.

It seems like this advice is not safe. The deadlock could be avoided if old keys are kept until an ACK has been received for a packet encrypted with the new keys.

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

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 08 Sep 2020 01:51:56 -0700

Just wondering, but isn't section 6.5 about *receiving* key updates?

I might argue that the the moment of "key update" referred to by that section is the moment the endpoint *receives* a packet using a new key phase.

If we interpret that way, then this is a non-issue, I think? FWIW, quicly does something along these lines.

-- 
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/4078#issuecomment-688722814

---

From: Marten Seemann <[email-masked]>
Date: Tue, 08 Sep 2020 02:51:39 -0700

> Just wondering, but isn't section 6.5 about receiving key updates?

I read this text as being about receiving packets during a key update, no matter who initiated the update.

Even if you interpret as only applying when the peer initiated the update, that still leaves us lacking any text when it’s safe to discard old keys for the endpoint that initiated the update. As the deadlock shows, there’s no duration that can be considered safe.

-- 
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/4078#issuecomment-688756713

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 08 Sep 2020 03:17:26 -0700

> Even if you interpret as only applying when the peer initiated the update, that still leaves us lacking any text when it’s safe to discard old keys for the endpoint that initiated the update. As th…

Right. As stated, my argument is that the receive key of generation N is not supposed to de dropped until the endpoint receives a packet protected using a receive key of generation N+1. Once a packet protected using a receive key of generation N+1 is received, the endpoint is recommended to drop key of generation N within the 3 PTO window.

That is what the text quoted above says: _An endpoint SHOULD retain old read keys for no more than three times the PTO. After this period, old read keys and their corresponding secrets SHOULD be discarded._

-- 
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/4078#issuecomment-688771339

---

From: Martin Thomson <[email-masked]>
Date: Thu, 10 Sep 2020 01:51:33 +0000 (UTC)

Closed #4078 via #4079.

-- 
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/4078#event-3748528641