On Sat, Jun 24, 2017 at 9:47 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 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). > That's a good point. 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. > This is the calculation I made as well. Note that removing aliasing in this fashion actually is useful in measuring packet loss (this is what QUIC does). > 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. > That seems correct to me. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
