Subject: [quicwg/base-drafts] Receiver's behavior on key update (#2791)

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

With help from @marten-seemann, I have composed a PR explains how a receiver should renew it's keys when seeing the KEY_PHASE bit changing.

This replaces #2788 (which I initially thought was correct, but was in fact incorrect as Marten has pointed out).

However, the question is if the approach being described in this PR is secure...
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * explain the procedure of the receiver installing new 1-RTT keys
  * Marten's rewording

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2791.patch
https://github.com/quicwg/base-drafts/pull/2791.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/2791

---

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

@kazuho pushed 1 commit.

557c66365108d041bd5cccf3662688a5784f15f6  remove redundancy

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2791/files/d3a809cd2d42b3562ef0f9798fb9548cb0278b3a..557c66365108d041bd5cccf3662688a5784f15f6

---

From: Marten Seemann <[email-masked]>
Date: Thu, 13 Jun 2019 22:15:07 -0700

marten-seemann approved this pull request.

-- 
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/2791#pullrequestreview-249711478

---

From: Nick Banks <[email-masked]>
Date: Fri, 14 Jun 2019 07:14:34 -0700

nibanks approved this pull request.

LGTM. I compared it to my code and this is pretty much exactly how we do 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/pull/2791#pullrequestreview-249928572

---

From: David Schinazi <[email-masked]>
Date: Fri, 14 Jun 2019 11:51:21 -0700

This PR removes the text about sending keys. Perhaps we should keep `and one set for protecting packets` and add details about what `the endpoint installs the updated keys` means - I think you mean `the endpoint installs the updated receive keys and if the packet decrypts successfully also updates sending 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/2791#issuecomment-502223603

---

From: ianswett <[email-masked]>
Date: Sat, 15 Jun 2019 04:44:27 -0700

ianswett approved this pull request.

-- 
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/2791#pullrequestreview-250189835

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 16 Jun 2019 23:05:05 -0700

@kazuho pushed 1 commit.

656539b83480fd01831e49e479beb867abc76f42  s/MAY limit to two/SHOULD retain at least two/, clarify which side of keys we are talking about

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2791/files/557c66365108d041bd5cccf3662688a5784f15f6..656539b83480fd01831e49e479beb867abc76f42

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 16 Jun 2019 23:09:52 -0700

@DavidSchinazi Thank you for the comments.

> Perhaps we should keep `and one set for protecting packets`

I've updated the text to clarify that only one send keys is needed at a time (it's a fact, not something we need to enforce or encourage), and have changed "MAY limit to two" to "SHOULD retain at least two receive keys." Technically this changes the RFC 2119 keyword, but I think that the intent of the text is better clarified with the change.

> and add details about what `the endpoint installs the updated keys` means - I think you mean the endpoint installs the updated receive keys and if the packet decrypts successfully also updates sending keys.

I've changed the text to "the endpoint installs the updated _receive_ keys." What needs to be done when the receive key is updated is clarified later on, in the paragraph that starts with "If the packet can be decrypted and authenticated using the updated key and IV...". I think that the text flows better 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/pull/2791#issuecomment-502547320

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 16 Jun 2019 23:35:49 -0700

@kazuho pushed 1 commit.

be1d0bbffe7282f9781d85e3123974c6e6672973  merge the calculation logic of the next key to the paragraph describing the logic to detect a key update

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2791/files/656539b83480fd01831e49e479beb867abc76f42..be1d0bbffe7282f9781d85e3123974c6e6672973

---

From: MikkelFJ <[email-masked]>
Date: Sun, 16 Jun 2019 23:38:15 -0700

As suggested earlier, I'd still prefer a change from

>Therefore, 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.

to using "at least 3  PTO", or "no less than 3 PTO", since it otherwise reads as if frequent key updates are recommended:

> Therefore, an endpoint SHOULD NOT initiate
a key update for some time after it has last updated keys; the RECOMMENDED time
period is no less than times the PTO.

Perhaps also add, "and typically significantly more, depending on the TLS security parameters:

> Therefore, an endpoint SHOULD NOT initiate
a key update for some time after it has last updated keys; the RECOMMENDED time
period is no less than times the PTO, and typically significantly more, within the TLS security parameters of the cipher in use.

-- 
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/2791#issuecomment-502553607

---

From: Marten Seemann <[email-masked]>
Date: Sun, 16 Jun 2019 23:40:20 -0700

marten-seemann commented on this pull request.

> @@ -1162,19 +1162,24 @@ number sent with each KEY_PHASE, and the highest acknowledged packet number
 in the 1-RTT space: once the latter is higher than or equal to the former,
 another key update can be initiated.
 
-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.  Updating keys multiple times rapidly can cause packets to be
-effectively lost if packets are significantly reordered.  Therefore, 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. This avoids
-valid reordered packets being dropped by the peer as a result of the peer
-discarding older keys.
-
-A receiving endpoint detects an update when the KEY_PHASE bit does not match
-what it is expecting.  It creates a new secret (see Section 7.2 of {{!TLS13}})
-and the corresponding read key and IV using the KDF function provided by TLS.
-The header protection key is not updated.
+While only one send key is used at a time, an endpoint SHOULD retain at least
+two receive keys during key update so that it can unprotect packets arriving

During *a* key update. Or during key update*s*.

> -discarded.  Updating keys multiple times rapidly can cause packets to be
-effectively lost if packets are significantly reordered.  Therefore, 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. This avoids
-valid reordered packets being dropped by the peer as a result of the peer
-discarding older keys.
-
-A receiving endpoint detects an update when the KEY_PHASE bit does not match
-what it is expecting.  It creates a new secret (see Section 7.2 of {{!TLS13}})
-and the corresponding read key and IV using the KDF function provided by TLS.
-The header protection key is not updated.
+While only one send key is used at a time, an endpoint SHOULD retain at least
+two receive keys during key update so that it can unprotect packets arriving
+out-of-order.
+
+An endpoint can detect which receive key to use by tracking the lowest packet

s/can detect/determines

> -discarding older keys.
-
-A receiving endpoint detects an update when the KEY_PHASE bit does not match
-what it is expecting.  It creates a new secret (see Section 7.2 of {{!TLS13}})
-and the corresponding read key and IV using the KDF function provided by TLS.
-The header protection key is not updated.
+While only one send key is used at a time, an endpoint SHOULD retain at least
+two receive keys during key update so that it can unprotect packets arriving
+out-of-order.
+
+An endpoint can detect which receive key to use by tracking the lowest packet
+number among the packets received with the currently active key phase.  If a
+packet is received that has a different KEY_PHASE bit and a lower packet number
+than this value, the endpoint uses the old receive keys for unprotecting the
+packet, if these keys are still available.  If the packet has a higher packet
+number, the endpoint installs the new receive keys by calculating the next

s/derives/installs.

We don't want to change any state before authenticating the packet, as discussed in #2792.

-- 
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/2791#pullrequestreview-250312383

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 16 Jun 2019 23:44:51 -0700

@kazuho pushed 1 commit.

8ce0e916bbcc42ef656722c13157fc5054daf457  editorial suggestions by @marten-seemann

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2791/files/be1d0bbffe7282f9781d85e3123974c6e6672973..8ce0e916bbcc42ef656722c13157fc5054daf457

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 16 Jun 2019 23:45:24 -0700

kazuho commented on this pull request.

Thank you for the suggestions. Applied in 8ce0e91.

-- 
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/2791#discussion_r294153801

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 16 Jun 2019 23:50:52 -0700

-

I am hesitant to make such a change because that creates a DoS vector against endpoint that retain only two receive keys (which we explicitly state as being allowed).

Rather, I think we should keep this PR editorial, and open a subsequent PR that addresses the issue at a later moment, after we conclude how to fix #2792.

-- 
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/2791#discussion_r294155016

---

From: Marten Seemann <[email-masked]>
Date: Sun, 16 Jun 2019 23:59:48 -0700

-

I think what I'm suggesting is compatible with the current text (and therefore also necessary to keep this PR editorial):
> A receiving endpoint detects an update when the KEY_PHASE bit does not match what it is expecting. It creates a new secret (see Section 7.2 of [TLS13]) and the corresponding read key and IV using the KDF function provided by TLS. The header protection key is not updated.
> 
> If the packet can be decrypted and authenticated using the updated key and IV, then the keys the endpoint uses for packet protection are also updated.

-- 
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/2791#discussion_r294157131

---

From: Marten Seemann <[email-masked]>
Date: Mon, 17 Jun 2019 00:05:34 -0700

-

To be clear, all of the options (deriving / creating / installing) come with the timing side channel.

What I've remarked here is about the key phase of the next packet being sent, after authentication of a packet with a higher key phase failed. That's I would prefer saying "derive" or "create" instead of "install".

-- 
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/2791#discussion_r294158513

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 17 Jun 2019 00:21:17 -0700

@kazuho pushed 1 commit.

13424d83c5ea5ab4c9d6840fc0c278cb9ccbb027  derive every time when receiving a packet with a new key-phase, until it successfully decrypts and authenticates

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2791/files/8ce0e916bbcc42ef656722c13157fc5054daf457..13424d83c5ea5ab4c9d6840fc0c278cb9ccbb027

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 17 Jun 2019 00:22:17 -0700

-

Ah. Thank you for the clarification. Updated the text and rearranged the following two paragraphs to better clarify when installation of the updated receive keys happen. PTAL.

-- 
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/2791#discussion_r294162982

---

From: David Schinazi <[email-masked]>
Date: Mon, 17 Jun 2019 09:28:31 -0700

I like the new text about send keys, thanks @kazuho !

However, the change from
> Endpoints MAY limit the number of keys they retain to two sets

to
>an endpoint SHOULD retain at least two receive keys

is not as obvious to me.

The algorithm you describe actually uses 3 receive keys: you have the old one, the current one, and the new one. The new algorithm only overwrites the old keys with the new ones if decryption succeeds, which requires keeping 3 keys in memory while you're decrypting. The minimal algorithm immediately overwrites the old key when receiving the new packet, and that only requires keeping two keys in memory. It's not possible for this to work safely while only saving one set of keys. That's why the old text mentioned that you MAY go as low as 2, but it's not possible to go lower. If you want to change the phrasing, then this should be a MUST as opposed to a SHOULD. Perhaps MUST >= 2, SHOULD >= 3 and then you describe the 3-key algorithm? But then we'd probably want to also describe the 2-key algorithm.

-- 
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/2791#issuecomment-502755865

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 17 Jun 2019 17:08:05 -0700

@DavidSchinazi Thank you for your comments. As I am uncertain what the correct approach is, I have so far tried to keep this PR a clarification of what's already written.

#2792 is the issue that discusses the problem in the current algorithm.

> The algorithm you describe actually uses 3 receive keys: you have the old one, the current one, and the new one. The new algorithm only overwrites the old keys with the new ones if decryption succeeds, which requires keeping 3 keys in memory while you're decrypting. The minimal algorithm immediately overwrites the old key when receiving the new packet, and that only requires keeping two keys in memory.

Current text states that a new key is computed every time when a received packet specifies an epoch for which a key has not been installed. This process is repeated until packet unprotection using that key succeeds and the key gets installed. Quoting from the current text: _"A receiving endpoint detects an update when the KEY_PHASE bit does not match what it is expecting. It creates a new secret (see Section 7.2 of [TLS13]) and the corresponding read key and IV using the KDF function provided by TLS."_

So at the moment, the text only requires an endpoint to retain 2 keys in state, and that is in line with "MAY limit to 2 keys." However, such algorithm does have side channel vulnerability, hence we need to discuss how to fix the issue (see #2792).

-- 
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/2791#issuecomment-502895107

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 17 Jun 2019 17:12:52 -0700

@kazuho pushed 1 commit.

1b30bfd33b4241193f61a4059301453015e9fcf2  "MAY limit to two" is "MUST at least two" rather than a SHOULD

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2791/files/13424d83c5ea5ab4c9d6840fc0c278cb9ccbb027..1b30bfd33b4241193f61a4059301453015e9fcf2

---

From: David Schinazi <[email-masked]>
Date: Tue, 18 Jun 2019 10:31:49 -0700

Thanks @kazuho. I still think we can improve this, the MUST stems from avoiding an attacker messing with the KEY_PHASE bit, not from out of order packets. Perhaps something like the following?

```
While only one send key is used at a time, an endpoint MUST retain at least two
receive keys (the "current" key and "future" key) during a key update to prevent
attackers from triggering key updates. An endpoint SHOULD retain a third
receive key (the "past" key) so that it can unprotect older packets that arrive
out-of-order.

Packets received with the current active key phase are unprotected using the
"current" key. When a packet arrives with the opposite key phase, an endpoint
determines which receive key to use by tracking the lowest packet number
among the packets received with the currently active key phase.  If a
packet is received that has a different KEY_PHASE bit and a lower packet number
than this value, the endpoint uses the "past" receive key for unprotecting the
packet, if that key is available.  If the packet has a higher packet number, the
endpoint derives the "future" receive key by calculating the next secret
(see Section 7.2 of {{!TLS13}}), the corresponding read key and IV using the KDF
function provided by TLS.  The header protection key is not updated.

If the packet can be decrypted and authenticated using the "future" receive key
and IV, then the endpoint switches to the next key phase, installs the "current"
key as its "past" key, and installs the "future" key as its "current" key.  The
endpoint also updates its send key to match its "current" receive key. The next
packet sent by the endpoint MUST then use the new send key.  Once an
endpoint has sent a packet encrypted with a given key phase, it MUST NOT
send a packet encrypted with an older key phase.

Updating keys multiple times rapidly can cause packets to be effectively lost if
packets are significantly reordered.  Therefore, 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.  This avoids valid reordered packets being
dropped by the peer as a result of the peer discarding older 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/2791#issuecomment-503234742

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 18 Jun 2019 21:20:28 -0700

@kazuho pushed 1 commit.

20c3351bf0460f438234d3026efe397f9ff93881  clarify how the keys are retained / dropped, based on suggestions from @DavidSchinazi

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2791/files/1b30bfd33b4241193f61a4059301453015e9fcf2..20c3351bf0460f438234d3026efe397f9ff93881

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 18 Jun 2019 21:28:30 -0700

@DavidSchinazi Thank you for the suggestions.

> the MUST stems from avoiding an attacker messing with the KEY_PHASE bit, not from out of order packets.

Yes. An endpoint should not calculate the next receive key whenever it receives a packet with a header claiming that it uses the next key phase, meaning that it needs to cache the next receive key. That leads us to "MUST at least two during a key update."

> An endpoint SHOULD retain a third receive key (the "past" key) so that it can unprotect older packets that arrive out-of-order.

While I like your suggested text for clarifying better how the keys are generated / dropped, this sounds like a new requirement. I think it's unnecessary (and also would oppose to introducing such a requirement).

Therefore, while incorporating the suggested text, I've instead went on to clarify how a 2-key design should replace the "past" key with the "future" key. Also, Instead of naming the three keys, I've changed the text to refer to the key phases using terms "current", "next", "previous", and to talk about their corresponding keys.

PTAL.

-- 
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/2791#issuecomment-503401282

---

From: MikkelFJ <[email-masked]>
Date: Wed, 19 Jun 2019 00:26:26 -0700

I read through the latest commit and I think it is largely fine, but I found the attack discussion a bit difficult, and the text is not distinguishing between receiving a key and authenticating a key. Also, it is probably not clear to the reader that the intent is to compute a key ahead of time when reading the first section. Furthermore, there is also an attack on send since if you compute the send key when you respond immediately, that can be timed.

The text also does not discuss what to do with a packet that does not authenticate. Do you drop, or something else. After trying to formulate that, I ended up with some problems that you can hopefully help clarify.

Here is my proposed text:

```
Packets received with the current key phase are unprotected using the
corresponding receive key.  When a packet arrives with the opposite key phase,
an endpoint determines which receive key to use by tracking the lowest packet
number among the packets received and successfully decrypted and authenticate
with the currently key phase. If a packet is received that has a different
KEY_PHASE bit and a lower packet number than this value, the endpoint uses the
receive key of the previous key phase for unprotecting the packet, if that key
is available.

If the packet has a higher packet number and it can be decrypted and
authenticated with the receive key of the next key phase, the receiver switches
to the new keyphase.

An an endpoint SHOULD compute the secret and related receive and send keys of
the next keyphase ahead of time to protect against timing attacks. The receiver
therefore has at least two installed receive keys but SHOULD transitionally
maintain older an older key to deal with late arriving packets for a duration of
3 PTO after switching to a new key phase.

The endpoint derives keys of the next key phase by calculating the
next secret (see Section 7.2 of {{!TLS13}}), the corresponding read key and IV
using the KDF function provided by TLS.

Once an endpoint has sent a packet encrypted with a given key phase, it MUST NOT
send a packet encrypted with an older key phase. (EDITORIAL: see note below)
If packet cannot be decrypted the reciever drops the packet but MAY also close
the connection with a PROTOCOL_VIOLOATION error if it finds that it can decrypt
and authenticate a packet with receive key that is retired for that packet number. 

(EDITORIAL NOTE: I'm struggling with when a key is fully retired and in violation because
it is always possible that an earlier packet is received after a key switch
which also carries the new key phase. You could formulate something but it gets
complicated).
```

Maybe we can just use "successfully unprotect" instead of decrypt and authenticate. Or perhaps it is enough to authenticate without decrypting. Noting that these are parallel and separate steps in GCM that can be processed separately.

-- 
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/2791#issuecomment-503441559

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 19 Jun 2019 01:16:11 -0700

@mikkelfj Thank you for the suggestions.

> An endpoint SHOULD compute the secret and related receive and send keys of the next key phase ahead of time

> SHOULD transitionally maintain an older key to deal with late arriving packets for a duration of 3 PTO after switching to a new key phase.

It is my understanding that if we should make these non-editorial changes is an open issue (see #2792).

> (EDITORIAL NOTE: I'm struggling with when a key is fully retired and in violation because it is always possible that an earlier packet is received after a key switch which also carries the new key phase. You could formulate something but it gets complicated).

An endpoint should not call it a violation when it receives a packet carrying an awfully outdated key phase, because such behavior would allow an on-path attacker to disrupt a connection, by buffering a and injecting a very old packet. That also means that there's no reason to define when an old key is dropped.

> Maybe we can just use "successfully unprotect" instead of decrypt and authenticate. Or perhaps it is enough to authenticate without decrypting. Noting that these are parallel and separate steps in…

It is true that we use "decrypt and authenticate" as a synonym of "unprotect." I can see that it might be confusing. OTOH, we should never allow decryption or authentication as a separate operation, because that would lead to timing attacks.

-- 
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/2791#issuecomment-503457264

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 19 Jun 2019 01:21:34 -0700

@kazuho pushed 1 commit.

a087a88798474ad144a3dbc99620a796bbc37b0f  s/decrypt and authenticate/unprotect/

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2791/files/20c3351bf0460f438234d3026efe397f9ff93881..a087a88798474ad144a3dbc99620a796bbc37b0f

---

From: MikkelFJ <[email-masked]>
Date: Wed, 19 Jun 2019 01:22:02 -0700

> An endpoint should not call it a violation when it receives a packet carrying an awfully outdated key phase, because such behavior would allow an on-path attacker to disrupt a connection, by buffer…

My point is the arrival of a packet encrypted with a very new key in a very old packet number. Exactly when that packet number is too old is the question. It relates to the sender MUST not send with an older key. Ultimately it comes down to not observing keys with overlapping ranges. We cannot say that a packet should always be dropped since it is valid to close in some cases, it is just hard to specify.

My mention of unprotect relates to my own text which uses your term "authenticate and decrypt" repetitively in order to be precise.

-- 
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/2791#issuecomment-503459242

---

From: MikkelFJ <[email-masked]>
Date: Wed, 19 Jun 2019 01:23:05 -0700

On editorial vs non-editorial I'll leave that to you. Know you have my suggestions at least.

-- 
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/2791#issuecomment-503459582

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 19 Jun 2019 01:32:10 -0700

> My point is the arrival of a packet encrypted with a very new key in a very old packet number. Exactly when that packet number is too old is the question. It relates to the sender MUST not send with an older key. Ultimately it comes down to not observing keys with overlapping ranges.

Thank you for the clarification. It is my understanding that a "sender MUST NOT" implies "receiver MAY close when it detects violation," and IIRC we have agreed that such behavior is either desirable or permissible in this specific case.

I think we can clarify that and the mechanism could be simple, because we already suggest that an endpoint might track the lowest, successfully unprotected packet number of the current key phase.

-- 
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/2791#issuecomment-503462939

---

From: MikkelFJ <[email-masked]>
Date: Wed, 19 Jun 2019 01:33:30 -0700

Clarification on violation:
a new key in an old packet: should never be violation, unless it is too old in which case it can optionally trigger a close.

If it is too old, it is not an attack vector because client mixed up keys without discussion. Only, it is hard to specify exactly when old is too old without complex text.

-- 
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/2791#issuecomment-503463377

---

From: MikkelFJ <[email-masked]>
Date: Wed, 19 Jun 2019 01:41:40 -0700

My previous comment landed without me reading your latest comment.

>I think we can clarify that and the mechanism could be simple, because we already suggest that an endpoint might track the lowest, successfully unprotected packet number of the current key phase.

This is the hard part because that goal post keeps moving down as delayed packets arrive.
The problem is exactly if this goal post moves past a packet number observed with a more recent 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/pull/2791#issuecomment-503466270

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 19 Jun 2019 06:08:24 -0700

@kazuho pushed 1 commit.

43943c1290aac062ff52171f7053d09e611a7d07  clarify how to detect a misbehaving peer

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2791/files/a087a88798474ad144a3dbc99620a796bbc37b0f..43943c1290aac062ff52171f7053d09e611a7d07

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 19 Jun 2019 06:09:01 -0700

@mikkelfj PTAL at 43943c1.

-- 
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/2791#issuecomment-503553258

---

From: David Schinazi <[email-masked]>
Date: Wed, 19 Jun 2019 14:26:27 -0700

@kazuho Thanks, I like the text referring to key phases and corresponding keys rather than keys directly.

However, you've dropped the requirement to immediately perform a key update when you unprotect with the next key phase. How about changing the start of the second to last paragraph to something like:

```
If the packet can be unprotected using the next receive key and IV, then the
endpoint switches to the next key phase: both send and receive keys associated
with the next key phase become current. The next packet sent by the endpoint
MUST then use the new send key. Once an endpoint has sent a packet...
```

-- 
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/2791#issuecomment-503752866

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 19 Jun 2019 17:54:25 -0700

@kazuho pushed 1 commit.

1768b35c30d28a7c1c98b2eea2d1d35dc977f726  describe how the key phase is inceremented in response to peer-initiated key update

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2791/files/43943c1290aac062ff52171f7053d09e611a7d07..1768b35c30d28a7c1c98b2eea2d1d35dc977f726

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 19 Jun 2019 17:55:11 -0700

@DavidSchinazi Thank you for checking. I missed your change in that paragraph. The suggested text looks fine, I've incorporated it in 1768b35.

-- 
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/2791#issuecomment-503798814

---

From: David Schinazi <[email-masked]>
Date: Thu, 20 Jun 2019 09:44:50 -0700

DavidSchinazi approved this pull request.

Thanks @kazuho ! Latest text looks good to me!

-- 
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/2791#pullrequestreview-252407808