On Sat, Jun 24, 2017 at 07:57:21AM -0700, Eric Rescorla wrote: > Hi folks, > > https://github.com/tlswg/dtls13-spec/pull/9 > > I have just posted a PR to implement ACKs, largely as we discussed in > Chicago. > Here's the pull comment: > > I have taken a slightly different approach here than we discussed > in Chicago. Specifically: > > - > > ACKs are not handshake messages but a new content type. This > avoids the need to ack ACKs or worry about reassembling > when ACKs are lost. > - > > The receipt of a flight also counts as an implicit ACK and > so you shouldn't ACK full flights. I tried removing this > feature but it leads to weird anomalies where you have > two flights you should be retransmitting if the ACKs get > lost. > - > > ACKs are always encrypted with the then-current key. > - > > I also removed the rule that you don't stop retransmitting > when you receive a partial flight. That was intended to have > fast retransmission for missing messages because the retransmit > of flight A triggered retransmission of partial flight B, but > ACKs serve this purpose > > Comments welcome.
I think ACKing a post-handshake CertificateRequest would make sense, if the response can't be generated immediately (e.g., prompting user to select a certificate). It seems ACKs work in terms of RSNs. This generates a weirdness that a fragment can be known with multiple IDs, in case a packet gets delayed enough to trigger retransmission but the original is then accepted. But OTOH, retransmission at fragment granularity is useful with potentially "obese" messages like Certificate. And what is the precise interaction between restarts, 0-RTT and message sequence numbers on client side? As far as I can tell, end_of_early_data is always client message_seq=1, and appears only iff server accepts 0-RTT. Restart client_hello is also always client message_sseq=1. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
