Hi Thomas, Hi Ekr, It seems we need to fix Figure 11 of Section 7.1 of https://www.ietf.org/id/draft-ietf-tls-dtls13-37.html<https://www.ietf.org/id/draft-ietf-tls-dtls13-37.html#section-7.1> (ACK[1] should actually be ACK[])
It should follow the “empty ACK” description of the last paragraph of the same section. Good catch! Ciao Hannes From: TLS <tls-boun...@ietf.org> On Behalf Of Eric Rescorla Sent: Thursday, April 9, 2020 4:33 PM To: Thomas Fossati <thomas.foss...@arm.com> Cc: tls@ietf.org Subject: Re: [TLS] Efficiency of ACKing scheme On Thu, Apr 9, 2020 at 7:28 AM Thomas Fossati <thomas.foss...@arm.com<mailto:thomas.foss...@arm.com>> wrote: On 09/04/2020, 15:18, "Eric Rescorla" <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: > > On Thu, Apr 9, 2020 at 6:59 AM Thomas Fossati > > <thomas.foss...@arm.com<mailto:thomas.foss...@arm.com>> wrote: > > On 09/04/2020, 14:20, "Eric Rescorla" <e...@rtfm.com<mailto:e...@rtfm.com>> > > wrote: > > > Assuming I understand Hanno's proposal, I do not believe that this > > > is in fact an improvement, as it does not cover the important case > > > where the record containing the SH is lost and then the rest of > > > the messages from the server are uninterpretable. > > > > I don't want to speak for Hanno here but the refinement proposed in > > [1], specifically the bit that says: > > > > [...] They may also proactively retransmit parts of a flight early > > if an ACK message indicates a gap. > > > > should cover the case you mention I think. > > But this requires being able to send an empty ACK that means "I got > nothing". In which case, I don't see how it's really different from > the current text except that it gives the sender less guidance. Not sure there's an "empty ACK" in Hanno's proposal. This is how I interpret it in the context of your example: in the second flight, if rec#0 (containing SH) is lost and rec#1 gets through, the receiver sends ACK {1}. From that the sender can infer the gap and retransmit rec#0. You can't send ACK{1} because you can't decrypt it because it is out of order with respect to the DH key. This is the point of the empty ACK. -Ekr (But again, I'm not him and that's why I suggested collecting all the pieces of this discussion together in one PR.) 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
