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
nes
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
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
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
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
