From 47958226abfbd3f82e0c93b5be83382d5fba64fb Mon Sep 17 00:00:00 2001 From: seanturner Date: Wed, 14 Mar 2018 17:32:57 +0000 Subject: [PATCH] Addressing issue#1147 --- draft-ietf-quic-tls.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index f515bee7e9..e3811bf0bb 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1068,7 +1068,7 @@ key updates in a short time frame succession and significant packet reordering. As shown in {{quic-tls-handshake}} and {{ex-key-update}}, there is never a situation where there are more than two different sets of keying material that might be received by a peer. Once both sending and receiving keys have been -updated, +updated, the peers immediately begin to use them. A server cannot initiate a key update until it has received the client's Finished message. Otherwise, packets protected by the updated keys could be