On Sun, Jul 2, 2017 at 12:54 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> On Sat, Jul 01, 2017 at 03:52:37PM -0700, Eric Rescorla wrote: > > On Sat, Jul 1, 2017 at 2:00 PM, Ilari Liusvaara < > ilariliusva...@welho.com> > > wrote: > > > > > On Sat, Jul 01, 2017 at 10:26:17AM -0700, Eric Rescorla wrote: > > > > On Sat, Jul 1, 2017 at 10:01 AM, Ilari Liusvaara < > > > ilariliusva...@welho.com> > > > > wrote: > > > > > > > Just noticed that DTLS allows packing multiple independent fragments > > > into one record (and then multiple records into one packet). > > > > > > Which impiles that an implementation that only prcesses one message at > > > a time is not guaranteed to even be able to generate a valid list of > > > RSNs to ACK, in case the peer sends sufficiently twisted (but still > > > seemingly in-spec) input. > > > > > > > I'm not following how that's true. When you decrypt, you record the > received > > RSNs and when you send an ACK you send the entire list. Then when you > > finish a flight, you reset the list. Can you maybe show me a sequence of > > events that would cause an error here? > > I think I figured out a case that doesn't involve peer intentionally > generating very dubious input: > > > 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? 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). -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
