Re: [TLS] Efficiency of ACKing scheme

[Eric Rescorla <[e-mail]>]

On Thu, Apr 9, 2020 at 7:28 AM Thomas Fossati <[e-mail]>
wrote:

> On 09/04/2020, 15:18, "Eric Rescorla" <[e-mail]> wrote:
> > > On Thu, Apr 9, 2020 at 6:59 AM Thomas Fossati <[e-mail]>
> wrote:
> > > On 09/04/2020, 14:20, "Eric Rescorla" <[e-mail]> 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.
>