On Sun, Jul 2, 2017 at 1:13 PM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Sun, Jul 02, 2017 at 12:30:09PM -0700, Eric Rescorla wrote: > > On Sun, Jul 2, 2017 at 12:54 AM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > Suppose that certificate is rather big (needs spliting to four parts), > > > and: > > > > > > > > > * The server preprares its flight, giving: > > > > > > - RSN 2:0 -> EncryptedExtensions, Certificate part 1/4 > > > - RSN 2:1 -> Certificate part 2/4 > > > - RSN 2:2 -> Certificate part 3/4 > > > - RSN 2:3 -> Certificate part 4/4, CertificateVerify, Finished. > > > > > > * Now, RSNs 2:1, 2:3 disappear, 2:0 and 2:2 make it through. > > > > > > * Client ACKs RSNs 2:0 and 2:2. > > > > > > * Server sees the ACK, and re-encrypts the offending packets: > > > > > > - RSN 2:4 -> Certificate part 2/4 > > > - RSN 2:5 -> Certificate part 4/4, CertificateVerify, Finished. > > > > > > * Now, RSN 2:4 disappears, 2:5 makes it through. > > > > > > * Client is one-message at a time. It can't ACK anything new. RSNs 2:1, > > > 2:3 and 2:4 are lost. RSN 2:5 can not be ACKed, because that would > > > imply the client received CV and F, which it did not. > > > > > > > > Thanks for clarifying your case. I think what you're assuming here is > > that when the client receives out of order handshake messages, it > discards > > them rather than buffering them. Is that correct? > > Yes, that is what one message at a time means. > Well it could mean other things. That's why I asked. > In that case, yes, it > > should pretend it didn't get the records as well, and I think the right > > answer would be to not generate a new ACK and rely on the server's > > retransmission timer (which needs to run anyway). > > One thing to note that there is no way for either side to say: "I > received _something_, but nothing useful". Well, we could in fact use an ACK for that, which is basically what TCP does. There can also be interactions with giving up on fragment transmissions > (in order to limit memory usage). > > Suppose similar case as before, but 2:1 gets lost instead of disappearing, > and is found after 2:5 is received by the client. > > The client will then generate second ACK, which ACKs 2:1. The server then > receives the ACK and has no idea what the client is talking about, since > server has dropped the state. But presumably fast-retransmits 2:4 and 2:5, > now as 2:6 and 2:7 (3rd transmission for both). > It's not clear to me it's useful for implementations to delete state in this case. -Ekr > > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
