On Thu, Apr 9, 2020 at 7:28 AM Thomas Fossati <thomas.foss...@arm.com>
wrote:
> On 09/04/2020, 15:18, "Eric Rescorla" <e...@rtfm.com> wrote:
> > > On Thu, Apr 9, 2020 at 6:59 AM Thomas Fossati <thomas.foss...@arm.com>
> wrote:
> > > On 09/04/2020, 14:20, "Eric Rescorla" <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.
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
