From b3defa9c1d9b8a97b445bcc5ca40cd7dfcc75321 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 12 Nov 2019 13:52:49 +1100 Subject: [PATCH 1/3] No reading of 1-RTT before the handshake is complete We really mean it. The effect of #3159 has been to shame some implementations into the right behaviour, but on reviewing this section, it really was unambiguous. This tweaks the text slightly and adds a cautionary note, but it is otherwise unchanged other than a few editorial tweaks. Closes #3159. --- draft-ietf-quic-tls.md | 35 +++++++++++++++++++++-------------- 1 file changed, 21 insertions(+), 14 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index 3005087f68..e50ae7877a 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1171,27 +1171,34 @@ Note: ## Receiving Out-of-Order Protected Frames {#pre-hs-protected} Due to reordering and loss, protected packets might be received by an endpoint -before the final TLS handshake messages are received. A client will be unable -to decrypt 1-RTT packets from the server, whereas a server will be able to -decrypt 1-RTT packets from the client. +before the final TLS handshake messages are received. Each endpoint MUST NOT +decrypt 1-RTT packets from its peer prior to completing the handshake. Even though 1-RTT keys are available to a server after receiving the first handshake messages from a client, it is missing assurances on the client state: - The client is not authenticated, unless the server has chosen to use a -pre-shared key and validated the client's pre-shared key binder; see -Section 4.2.11 of {{!TLS13}}. + pre-shared key and validated the client's pre-shared key binder; see Section + 4.2.11 of {{!TLS13}}. + - The client has not demonstrated liveness, unless a RETRY packet was used. + - Any received 0-RTT data that the server responds to might be due to a replay -attack. - -Therefore, the server's use of 1-RTT keys is limited before the handshake is -complete. A server MUST NOT process data from incoming 1-RTT -protected packets before the TLS handshake is complete. Because -sending acknowledgments indicates that all frames in a packet have been -processed, a server cannot send acknowledgments for 1-RTT packets until the -TLS handshake is complete. Received packets protected with 1-RTT keys MAY be -stored and later decrypted and used once the handshake is complete. + attack. + +Therefore, the server's use of 1-RTT keys MUST be limited to sending data before +the handshake is complete. A server MUST NOT process data from incoming 1-RTT +protected packets before the TLS handshake is complete. Because sending +acknowledgments indicates that all frames in a packet have been processed, a +server cannot send acknowledgments for 1-RTT packets until the TLS handshake is +complete. Received packets protected with 1-RTT keys MAY be stored and later +decrypted and used once the handshake is complete. + +Note: + +: TLS implementations might provide all 1-RTT secrets prior to handshake + completion. Even where QUIC implementations have 1-RTT read keys, those keys + cannot be used prior to completing the handshake. The requirement for the server to wait for the client Finished message creates a dependency on that message being delivered. A client can avoid the From e2ee0d4652ea2f3a405da6ba14d08416bc4f6b3d Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 12 Nov 2019 15:59:16 +1100 Subject: [PATCH 2/3] Simplify --- draft-ietf-quic-tls.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index e50ae7877a..f837dfe4e9 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1187,12 +1187,12 @@ handshake messages from a client, it is missing assurances on the client state: attack. Therefore, the server's use of 1-RTT keys MUST be limited to sending data before -the handshake is complete. A server MUST NOT process data from incoming 1-RTT -protected packets before the TLS handshake is complete. Because sending -acknowledgments indicates that all frames in a packet have been processed, a -server cannot send acknowledgments for 1-RTT packets until the TLS handshake is -complete. Received packets protected with 1-RTT keys MAY be stored and later -decrypted and used once the handshake is complete. +the handshake is complete. A server MUST NOT process incoming 1-RTT protected +packets before the TLS handshake is complete. Because sending acknowledgments +indicates that all frames in a packet have been processed, a server cannot send +acknowledgments for 1-RTT packets until the TLS handshake is complete. Received +packets protected with 1-RTT keys MAY be stored and later decrypted and used +once the handshake is complete. Note: From 459ef0f8b646af38e381acab8f2dfb1769391df0 Mon Sep 17 00:00:00 2001 From: Martin Thomson Date: Tue, 19 Nov 2019 10:44:33 +0800 Subject: [PATCH 3/3] Keep context --- draft-ietf-quic-tls.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-tls.md b/draft-ietf-quic-tls.md index f837dfe4e9..3c9b9f68ac 100644 --- a/draft-ietf-quic-tls.md +++ b/draft-ietf-quic-tls.md @@ -1171,8 +1171,10 @@ Note: ## Receiving Out-of-Order Protected Frames {#pre-hs-protected} Due to reordering and loss, protected packets might be received by an endpoint -before the final TLS handshake messages are received. Each endpoint MUST NOT -decrypt 1-RTT packets from its peer prior to completing the handshake. +before the final TLS handshake messages are received. A client will be unable +to decrypt 1-RTT packets from the server, whereas a server will be able to +decrypt 1-RTT packets from the client. Endpoints in either role MUST NOT +decrypt 1-RTT packets from their peer prior to completing the handshake. Even though 1-RTT keys are available to a server after receiving the first handshake messages from a client, it is missing assurances on the client state: