Re: [TLS] Possible deadlock when ACKing KeyUpdate messages?
Hi Hannes, Thank for opening a PR! I think the underlying issue here is the conception that all that needs to be ensured is the ability to ACK retransmissions of the KeyUpdate, and the modified version still gives that impression. If that was true, the use of 'canned ACKs' as in Draft 37 would be fine. However, the example shows that there's more to retaining old keying material than just ACKing retransmitted KeyUpdates, and I'd therefore opt for a more intrusive change of wording, such as: Due to the possibility of an ACK message for a KeyUpdate being lost and thereby preventing the sender of the KeyUpdate from updating its keying material, receivers MUST retain the pre-update keying material until receipt and successful decryption of a message using the new keys. Receivers MUST NOT delete the pre-update keying material immediately and use canned ACK messages for retransmitted KeyUpdate messages, since situations can occur in which receivers still need to be able to decrypt messages secured with pre-update keying material. Maybe the second part is better treated as a note or implementation warning, though. Best, Hanno From: Hannes Tschofenig Sent: Tuesday, March 31, 2020 7:28 AM To: Hanno Becker ; tls@ietf.org Subject: RE: [TLS] Possible deadlock when ACKing KeyUpdate messages? Hi Hanno, I believe the part of the paragraph that talks about “canned ACKs” needs to be clarified. In https://github.com/tlswg/dtls13-spec/pull/135 I changed the text from “ Although KeyUpdate MUST be acknowledged, it is possible for the ACK to be lost, in which case the sender of the KeyUpdate will retransmit it. Implementations MUST retain the ability to ACK the KeyUpdate for up to 2MSL. It is RECOMMENDED that they do so by retaining the pre- update keying material, but they MAY do so by responding to messages which appear to be out-of-epoch with a canned ACK message; in this case, implementations SHOULD rate limit how often they send such ACKs. " To: “ Although KeyUpdates MUST be acknowledged, it is possible for the ACK to be lost, in which case the sender of the KeyUpdate will retransmit it. The receiver of the KeyUpdate MUST retain the ability to ACK the KeyUpdate for up to 2MSL. It is RECOMMENDED that they do so by retaining the pre-update keying material, but they MAY remove the pre-update keying material only upon receipt and successful decryption of a message using the new keys. “ Ciao Hannes From: Hanno Becker Sent: Monday, March 30, 2020 8:02 PM To: Hannes Tschofenig ; tls@ietf.org Subject: Re: [TLS] Possible deadlock when ACKing KeyUpdate messages? Hi Hannes, > In your example below, the sender of the initial KeyUpdate has to re-send it > because of the lost ACK. In order to resubmit it, it has to use the old > keying material (or cache the message). The receiver cannot immediately > delete keying material after processing the initial KeyUpdate message because > it does not know whether the ACK will subsequently get lost. My point is that the paragraph cited at the top of my post appears to say that receivers MAY immediately delete keying material after receiving a KeyUpdate IF they blindly ACK retransmissions of the KeyUpdate (even though they can't decrypt it anymore). The example shows that this doesn't work, unless I've made a mistake. Best, Hanno From: Hannes Tschofenig mailto:hannes.tschofe...@arm.com>> Sent: Monday, March 30, 2020 11:57 AM To: Hanno Becker mailto:hanno.bec...@arm.com>>; tls@ietf.org<mailto:tls@ietf.org> mailto:tls@ietf.org>> Subject: RE: [TLS] Possible deadlock when ACKing KeyUpdate messages? Hi Hanno, Hi all, I believe it would be useful to add some extra sentences to the draft to retaining the old key material. In your example below, the sender of the initial KeyUpdate has to re-send it because of the lost ACK. In order to resubmit it, it has to use the old keying material (or cache the message). The receiver cannot immediately delete keying material after processing the initial KeyUpdate message because it does not know whether the ACK will subsequently get lost. Ciao Hannes From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of Hanno Becker Sent: Saturday, March 28, 2020 11:31 PM To: tls@ietf.org<mailto:tls@ietf.org> Subject: [TLS] Possible deadlock when ACKing KeyUpdate messages? In relation to ACKs for KeyUpdate messages, DTLS 1.3 Draft 37 states: Although KeyUpdate MUST be acknowledged, it is possible for the ACK to be lost, in which case the sender of the KeyUpdate will retransmit it. Implementations MUST retain the ability to ACK the KeyUpdate for up to 2MSL. It is RECOMMENDED that they do so by retaining the pre- update keying material, but they MAY do so by responding to messages which appear to be
Re: [TLS] Possible deadlock when ACKing KeyUpdate messages?
Hi Hanno, I believe the part of the paragraph that talks about "canned ACKs" needs to be clarified. In https://github.com/tlswg/dtls13-spec/pull/135 I changed the text from " Although KeyUpdate MUST be acknowledged, it is possible for the ACK to be lost, in which case the sender of the KeyUpdate will retransmit it. Implementations MUST retain the ability to ACK the KeyUpdate for up to 2MSL. It is RECOMMENDED that they do so by retaining the pre- update keying material, but they MAY do so by responding to messages which appear to be out-of-epoch with a canned ACK message; in this case, implementations SHOULD rate limit how often they send such ACKs. " To: " Although KeyUpdates MUST be acknowledged, it is possible for the ACK to be lost, in which case the sender of the KeyUpdate will retransmit it. The receiver of the KeyUpdate MUST retain the ability to ACK the KeyUpdate for up to 2MSL. It is RECOMMENDED that they do so by retaining the pre-update keying material, but they MAY remove the pre-update keying material only upon receipt and successful decryption of a message using the new keys. " Ciao Hannes From: Hanno Becker Sent: Monday, March 30, 2020 8:02 PM To: Hannes Tschofenig ; tls@ietf.org Subject: Re: [TLS] Possible deadlock when ACKing KeyUpdate messages? Hi Hannes, > In your example below, the sender of the initial KeyUpdate has to re-send it > because of the lost ACK. In order to resubmit it, it has to use the old > keying material (or cache the message). The receiver cannot immediately > delete keying material after processing the initial KeyUpdate message because > it does not know whether the ACK will subsequently get lost. My point is that the paragraph cited at the top of my post appears to say that receivers MAY immediately delete keying material after receiving a KeyUpdate IF they blindly ACK retransmissions of the KeyUpdate (even though they can't decrypt it anymore). The example shows that this doesn't work, unless I've made a mistake. Best, Hanno From: Hannes Tschofenig mailto:hannes.tschofe...@arm.com>> Sent: Monday, March 30, 2020 11:57 AM To: Hanno Becker mailto:hanno.bec...@arm.com>>; tls@ietf.org<mailto:tls@ietf.org> mailto:tls@ietf.org>> Subject: RE: [TLS] Possible deadlock when ACKing KeyUpdate messages? Hi Hanno, Hi all, I believe it would be useful to add some extra sentences to the draft to retaining the old key material. In your example below, the sender of the initial KeyUpdate has to re-send it because of the lost ACK. In order to resubmit it, it has to use the old keying material (or cache the message). The receiver cannot immediately delete keying material after processing the initial KeyUpdate message because it does not know whether the ACK will subsequently get lost. Ciao Hannes From: TLS mailto:tls-boun...@ietf.org>> On Behalf Of Hanno Becker Sent: Saturday, March 28, 2020 11:31 PM To: tls@ietf.org<mailto:tls@ietf.org> Subject: [TLS] Possible deadlock when ACKing KeyUpdate messages? In relation to ACKs for KeyUpdate messages, DTLS 1.3 Draft 37 states: Although KeyUpdate MUST be acknowledged, it is possible for the ACK to be lost, in which case the sender of the KeyUpdate will retransmit it. Implementations MUST retain the ability to ACK the KeyUpdate for up to 2MSL. It is RECOMMENDED that they do so by retaining the pre- update keying material, but they MAY do so by responding to messages which appear to be out-of-epoch with a canned ACK message; in this case, implementations SHOULD rate limit how often they send such ACKs. This seems to allow implementations to remove old incoming keys immediately after ACKing the KeyUpdate, which appears to open the door for the following situation leading to deadlock: +-+ | KeyUpdate, epoch N|-> received +-+ ++ lost x-| ACK, epoch M | ++ [ new incoming epoch N+1, remove keys for epoch N ] - ++ received <-| KeyUpdate, epoch M | ++ +-+ | ACK, epoch N |---[ irrelevant whether it goes through - see below ] +-+ [ new incoming epoch M+1, remove keys for epoch M ] Note: This isn't an entirely unlikely situation, since a KeyUpdate with update_requested flag will result in a subsequent KeyUpdate fro
Re: [TLS] Possible deadlock when ACKing KeyUpdate messages?
Hi Hannes, > In your example below, the sender of the initial KeyUpdate has to re-send it > because of the lost ACK. In order to resubmit it, it has to use the old > keying material (or cache the message). The receiver cannot immediately > delete keying material after processing the initial KeyUpdate message because > it does not know whether the ACK will subsequently get lost. My point is that the paragraph cited at the top of my post appears to say that receivers MAY immediately delete keying material after receiving a KeyUpdate IF they blindly ACK retransmissions of the KeyUpdate (even though they can't decrypt it anymore). The example shows that this doesn't work, unless I've made a mistake. Best, Hanno From: Hannes Tschofenig Sent: Monday, March 30, 2020 11:57 AM To: Hanno Becker ; tls@ietf.org Subject: RE: [TLS] Possible deadlock when ACKing KeyUpdate messages? Hi Hanno, Hi all, I believe it would be useful to add some extra sentences to the draft to retaining the old key material. In your example below, the sender of the initial KeyUpdate has to re-send it because of the lost ACK. In order to resubmit it, it has to use the old keying material (or cache the message). The receiver cannot immediately delete keying material after processing the initial KeyUpdate message because it does not know whether the ACK will subsequently get lost. Ciao Hannes From: TLS On Behalf Of Hanno Becker Sent: Saturday, March 28, 2020 11:31 PM To: tls@ietf.org Subject: [TLS] Possible deadlock when ACKing KeyUpdate messages? In relation to ACKs for KeyUpdate messages, DTLS 1.3 Draft 37 states: Although KeyUpdate MUST be acknowledged, it is possible for the ACK to be lost, in which case the sender of the KeyUpdate will retransmit it. Implementations MUST retain the ability to ACK the KeyUpdate for up to 2MSL. It is RECOMMENDED that they do so by retaining the pre- update keying material, but they MAY do so by responding to messages which appear to be out-of-epoch with a canned ACK message; in this case, implementations SHOULD rate limit how often they send such ACKs. This seems to allow implementations to remove old incoming keys immediately after ACKing the KeyUpdate, which appears to open the door for the following situation leading to deadlock: +-+ | KeyUpdate, epoch N|-> received +-+ ++ lost x-| ACK, epoch M | ++ [ new incoming epoch N+1, remove keys for epoch N ] - ++ received <-| KeyUpdate, epoch M | ++ +-+ | ACK, epoch N |---[ irrelevant whether it goes through - see below ] +-+ [ new incoming epoch M+1, remove keys for epoch M ] Note: This isn't an entirely unlikely situation, since a KeyUpdate with update_requested flag will result in a subsequent KeyUpdate from the other side, and the only unlucky thing that needs to happen is for the original ACK to be lost while both KeyUpdate messages go through. At this point, both sides have updated their incoming key material but not their outgoing key material, since they're still awaiting the ACK - however, it turns out that they can't actually read those ACKs anymore: After some time, the peers resend the KeyUpdate messages, which will be blindly ACKed by the peer according to the recommendation in the spec; however, the ACKs will be encrypted with the wrong keys and cannot be parsed on either side: +---+ | resent KeyUpdate, epoch N |-> received, but can't be read +---+ because incoming epoch N+1 send 'blind' ACK received, but can't be read++ because incoming epoch M+1 <--| ACK, epoch M | ++ The same will happen to KeyUpdate retransmission from the other side. It seems that this results in a deadlock. Am I missing / misunderstanding something? A possible mitigation would be to force retaining the old key material for 2MSL, or alternatively, to mandate that old key material must only be removed upon receipt and successful decryption of a message using the new keys. IMPORTANT NOTICE: The contents of this email and any attachments are
Re: [TLS] Possible deadlock when ACKing KeyUpdate messages?
Hi Hanno, Hi all, I believe it would be useful to add some extra sentences to the draft to retaining the old key material. In your example below, the sender of the initial KeyUpdate has to re-send it because of the lost ACK. In order to resubmit it, it has to use the old keying material (or cache the message). The receiver cannot immediately delete keying material after processing the initial KeyUpdate message because it does not know whether the ACK will subsequently get lost. Ciao Hannes From: TLS On Behalf Of Hanno Becker Sent: Saturday, March 28, 2020 11:31 PM To: tls@ietf.org Subject: [TLS] Possible deadlock when ACKing KeyUpdate messages? In relation to ACKs for KeyUpdate messages, DTLS 1.3 Draft 37 states: Although KeyUpdate MUST be acknowledged, it is possible for the ACK to be lost, in which case the sender of the KeyUpdate will retransmit it. Implementations MUST retain the ability to ACK the KeyUpdate for up to 2MSL. It is RECOMMENDED that they do so by retaining the pre- update keying material, but they MAY do so by responding to messages which appear to be out-of-epoch with a canned ACK message; in this case, implementations SHOULD rate limit how often they send such ACKs. This seems to allow implementations to remove old incoming keys immediately after ACKing the KeyUpdate, which appears to open the door for the following situation leading to deadlock: +-+ | KeyUpdate, epoch N|-> received +-+ ++ lost x-| ACK, epoch M | ++ [ new incoming epoch N+1, remove keys for epoch N ] - ++ received <-| KeyUpdate, epoch M | ++ +-+ | ACK, epoch N |---[ irrelevant whether it goes through - see below ] +-+ [ new incoming epoch M+1, remove keys for epoch M ] Note: This isn't an entirely unlikely situation, since a KeyUpdate with update_requested flag will result in a subsequent KeyUpdate from the other side, and the only unlucky thing that needs to happen is for the original ACK to be lost while both KeyUpdate messages go through. At this point, both sides have updated their incoming key material but not their outgoing key material, since they're still awaiting the ACK - however, it turns out that they can't actually read those ACKs anymore: After some time, the peers resend the KeyUpdate messages, which will be blindly ACKed by the peer according to the recommendation in the spec; however, the ACKs will be encrypted with the wrong keys and cannot be parsed on either side: +---+ | resent KeyUpdate, epoch N |-> received, but can't be read +---+ because incoming epoch N+1 send 'blind' ACK received, but can't be read++ because incoming epoch M+1 <--| ACK, epoch M | ++ The same will happen to KeyUpdate retransmission from the other side. It seems that this results in a deadlock. Am I missing / misunderstanding something? A possible mitigation would be to force retaining the old key material for 2MSL, or alternatively, to mandate that old key material must only be removed upon receipt and successful decryption of a message using the new keys. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Possible deadlock when ACKing KeyUpdate messages?
In relation to ACKs for KeyUpdate messages, DTLS 1.3 Draft 37 states: Although KeyUpdate MUST be acknowledged, it is possible for the ACK to be lost, in which case the sender of the KeyUpdate will retransmit it. Implementations MUST retain the ability to ACK the KeyUpdate for up to 2MSL. It is RECOMMENDED that they do so by retaining the pre- update keying material, but they MAY do so by responding to messages which appear to be out-of-epoch with a canned ACK message; in this case, implementations SHOULD rate limit how often they send such ACKs. This seems to allow implementations to remove old incoming keys immediately after ACKing the KeyUpdate, which appears to open the door for the following situation leading to deadlock: +-+ | KeyUpdate, epoch N|-> received +-+ ++ lost x-| ACK, epoch M | ++ [ new incoming epoch N+1, remove keys for epoch N ] - ++ received <-| KeyUpdate, epoch M | ++ +-+ | ACK, epoch N |---[ irrelevant whether it goes through - see below ] +-+ [ new incoming epoch M+1, remove keys for epoch M ] Note: This isn't an entirely unlikely situation, since a KeyUpdate with update_requested flag will result in a subsequent KeyUpdate from the other side, and the only unlucky thing that needs to happen is for the original ACK to be lost while both KeyUpdate messages go through. At this point, both sides have updated their incoming key material but not their outgoing key material, since they're still awaiting the ACK - however, it turns out that they can't actually read those ACKs anymore: After some time, the peers resend the KeyUpdate messages, which will be blindly ACKed by the peer according to the recommendation in the spec; however, the ACKs will be encrypted with the wrong keys and cannot be parsed on either side: +---+ | resent KeyUpdate, epoch N |-> received, but can't be read +---+ because incoming epoch N+1 send 'blind' ACK received, but can't be read++ because incoming epoch M+1 <--| ACK, epoch M | ++ The same will happen to KeyUpdate retransmission from the other side. It seems that this results in a deadlock. Am I missing / misunderstanding something? A possible mitigation would be to force retaining the old key material for 2MSL, or alternatively, to mandate that old key material must only be removed upon receipt and successful decryption of a message using the new keys. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
