On 09/04/2020, 15:34, "Eric Rescorla" <e...@rtfm.com> wrote:
> > > 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.
True, so you send ACK{} (as per last para of Section 7.1) and similarly
the receiver can deduce a gap -- indeed a very precise one -- and
re-send record containing the SH.
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
