Subject: [quicwg/base-drafts] Clarify the side-effect of frequent key updates (#2788)

From: Kazuho Oku <[email-masked]>
Date: Thu, 13 Jun 2019 00:21:46 -0700

After some discussion with @marten-seemann, I think that the following changes need to be made to the paragraph describing the side-effect of frequent key updates.

* Removes "MAY limit the number of keys to one set for proceting packets"; it *is* limited to one elsewhere, I think.
* Fix incorrect clarification; the side-effect of key updates before 3PTO is packet drops of all packets within that period, not just the ones being reordered.
* Reroder the paragraphs so that the side effect is discussed after the recommendation to retain the old keys 3 PTO after a Key Update.

The changes does not change the required behaviors or suggestions; therefore it's my view that this is an editorial PR.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/2788

-- Commit Summary --

  * Clarify the side-effect of frequent key updates.

-- File Changes --

    M draft-ietf-quic-tls.md (17)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2788.patch
https://github.com/quicwg/base-drafts/pull/2788.diff

-- 
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/pull/2788

---

From: Marten Seemann <[email-masked]>
Date: Thu, 13 Jun 2019 01:08:06 -0700

I disagree that this is editorial an PR. 

As I understand, in the current text we're
1. Limiting the the frequency of key updates to avoid the deadlock in the case of frequent key updates (#2214). This is achieved by requiring a peer to not update keys to N+1 before receiving an acknowledgement for a packet sent at key phase N (which effectively limits key updates to no more than once per RTT).
1. For crypto hygienic reasons (and to limit memory consumption), we're only keeping old keys alive for a maximum of 3 PTOs, and dropping them afterwards.
1. If key updates are performed more frequently than once per 3 PTOs, endpoints MAY drop old keys sooner (again, in order to limit memory consumption). Note that this leads to (effective) packet loss if there's sufficient reordering of packets encrypted with the old keys. However, if there's no reordering, no packets are lost.

This PR changes the text such that a peer could effectively refuse to update to the new keys for a period of 3 PTO, thereby inducing massive packet loss on all packets encrypted with the new key phase, even in the absence of packet reordering.

In my opinion, this change is therefore not editorial, but a design change. 
Furthermore, I'm also not convinced that this is the right way to go. The current text has the nice property that there's a very clear definition when a key update is allowed: as soon as you receive an acknowledgment for the current key phase. According to this PR, this clear definition is replaced by saying that a subsequent key update shouldn't happen within 3 PTOs. The problem is that the PTO is a local value, and peers might disagree about the precise value at any given time. Therefore, there's no clear point in time when a key update could be performed safely (i.e. without risking that the peer refuses to update 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/pull/2788#issuecomment-501597224

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 13 Jun 2019 01:24:53 -0700

@marten-seemann 
> This PR changes the text such that a peer could effectively refuse to update to the new keys for a period of 3 PTO, thereby inducing massive packet loss on all packets encrypted with the new key ph…

I think what you are missing is "endpoint SHOULD retain old keys for a period of no more than three times the PTO" (quoting from section 6). As you can see, the current text already effectively refuses updates more frequent than every 3 PTO. Hence my argument that this is an editorial change.

I also do not see why an endpoint need to update the key as frequently as couple of PTOs. Key update exists so that endpoints can replace the keys becoming weak after being used extensively. A key that becomes weak just after couple of PTOs should never be used. Therefore, it is my view is that seeing performance degradation when updating keys too frequently (due to packets being deemed lost) is a non-issue.

-- 
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/pull/2788#issuecomment-501603137

---

From: Marten Seemann <[email-masked]>
Date: Thu, 13 Jun 2019 01:43:17 -0700

> I also do not see why an endpoint need to update the key as frequently as couple of PTOs. Key update exists so that endpoints can replace the keys becoming weak after being used extensively. A key that becomes weak just after couple of PTOs should never be used. 

I agree with that, however, I'm very much in favor of having a clear-cut definition, instead of second-guessing what the peer's view of the PTO might be).

> I think what you are missing is "endpoint SHOULD retain old keys for a period of no more than three times the PTO" (quoting from section 6). As you can see, the current text already effectively ref…

This sets a **maximum** time on how long keys should be kept. I don't see how this would impose a limit on the frequency at all.

To the contrary, we say that as soon as you receive a packet with the new key phase, you immediately update your keys:
> A receiving endpoint detects an update when the KEY_PHASE bit does not match what it is expecting. It creates a new secret [...] and the corresponding read key and IV using the KDF function provided by TLS.

The spec goes on to clarify that IF you want to limit the number of keys, you drop **the old keys**:
> Endpoints MAY limit the number of keys they retain to two sets for removing packet protection and one set for protecting packets. Older keys can be discarded.

This leads to the risk that packets are dropped **in the case of significant reordering**. Every time this section talks about packet loss, it's always in the case of reordering.

> I think that this interpretation is incorrect; we already have the following in the spec: "an endpoint SHOULD NOT initiate a key update for some time after it has last updated keys; the RECOMMENDED time period is three times the PTO".

I think we have this text because we want to guarantee optimal performance on connections that experience significant amounts of reordering, and waiting for 3 PTOs is a good way to ensure that all old packets are actually received.

-- 
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/pull/2788#issuecomment-501609317

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 13 Jun 2019 02:19:43 -0700

Thank you for the discussion.

While we agree that excessive use is key update is something unnecessary, I think you are correct in point out that an endpoint is expected to process an incoming packet protected by a newer generation of key, presumably be comparing the PN of the incoming packet and the highest PN and epoch of the packet received previously.

That’d make this PR worthless with the exception of the removal of the MAY requirement on the number of the send keys.

Thank you for the discussion.

OTOH, this means that we need to discuss if and how we need to prevent excessive key updates being used as a DoS vector...

-- 
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/pull/2788#issuecomment-501622514

---

From: MikkelFJ <[email-masked]>
Date: Thu, 13 Jun 2019 07:40:08 -0700

> Therefore, it is my view that seeing performance degradation when updating keys too frequently (due to packets being deemed lost) is a non-issue.

and

> OTOH, this means that we need to discuss if and how we need to prevent excessive key updates being used as a DoS vector...

This is why language is interesting for short key update intervals. A dumb buggy implementation that looks like a DoS attack shouldn't say - it's according to spec.

But it isn't worth too much thought since the issue is limited, overall.

-- 
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/pull/2788#issuecomment-501732260

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 13 Jun 2019 08:22:16 -0700

Closed #2788.

-- 
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/pull/2788#event-2410996139