Subject: [quicwg/base-drafts] TLS-31: Sending with Updated keys (#4199)

From: Magnus Westerlund <[email-masked]>
Date: Tue, 13 Oct 2020 07:35:11 -0700

Section 6.4:

An endpoint always sends packets that are protected with the newest keys. Keys used for packet protection can be discarded immediately after switching to newer keys.

I do get confused by the first sentence reference to "newest" key. So the previous section talks about the requirement that one retain the current and next key. If one have created the next key, then that key is newest. I don't think this is intention, but the text can be interpret that one need to switch to the next key as soon as one is allowed if one have created it. The only question is when it is created. 

If I would guess the above section 6.4 sentence is to ensure that one never uses the previous key, if a key change has occurred. However, one should not be forced to switch to the next key unless the other side has switched or the key has exhausted its protection life time. 

However, I think the current formulation can result in that an outside attacker that can inject a packet with a toggled key-phase bit can force an endpoint to switch its key, even if the peer hasn't initiated a key update. This simply by forcing it to generate it, and then have the packet integrity check to fail for the injected packet. Because now there is a newer "next key" in store. 

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Oct 2020 17:07:30 -0700

Never using old keys is a nice way of putting this.  I'll make that change.

-- 
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/4199#issuecomment-708074995

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Oct 2020 17:19:39 -0700

On the last point (which I glossed over initially, as it relates to a different concept), the attacker can *at best* force the installation of the next set of read keys and only if the receiver is willing to do so.  Flipping the key phase bit has the effect of causing a receiver to select the previous or next read keys.  If the receiver generates keys on demand (which is not a great idea, but some implementations do...), then it will generate those keys.  That key generation should be a one-off event (we recommend saving keys in [S6.3](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#section-6.3-3)).

A bit flip cannot result in any change to any other state (other than the global anti-forgery counter, which is a recent addition).  Updates only occur as a result of successfully removing packet protection and a bit flip will cause the integrity check to fail and the packet to be dropped with no other state changes.

-- 
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/4199#issuecomment-708078704

---

From: Lars Eggert <[email-masked]>
Date: Thu, 15 Oct 2020 04:27:11 -0700

@gloinul do these explanations plus 52c5f4f41bb1a1128af8f52398224cd2c9f83e45 address your issue? Or are further text changes required?

-- 
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/4199#issuecomment-709219333

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Oct 2020 05:08:37 -0700

Mostly, I think one could use the previous sections discussion of "current" and "next" to clarify this. 

For example:
OLD: An endpoint never sends packets that are protected with old keys.

New:
An endpoint never sends packets that are protected with old keys (previous key) only the current key.

-- 
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/4199#issuecomment-709254134

---

From: Martin Thomson <[email-masked]>
Date: Thu, 15 Oct 2020 16:43:44 -0700

I did that in #4224, but somehow it slipped the net and I failed to create the pull request.  Sorry about that.  I'll make the recommended change (or something like it).

-- 
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/4199#issuecomment-709645896

---

From: Martin Thomson <[email-masked]>
Date: Thu, 15 Oct 2020 16:55:57 -0700

Closed #4199 via #4224.

-- 
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/4199#event-3884006073