On Fri, Oct 27, 2017 at 04:56:08AM -0700, Eric Rescorla wrote: > On Thu, Oct 26, 2017 at 10:37 PM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > On Thu, Oct 26, 2017 at 04:37:47PM -0700, Eric Rescorla wrote: > > > Hi folks, > > > > > > Building on our discussion in Prague I've posted two PRs for shrinking > > the > > > header size: > > > > > > https://github.com/tlswg/dtls13-spec/pull/16 > > > - This introduces a shortened header format that just has a truncated > > > sequence > > > number and epoch but no length so it has to be packet one per datagram > > > > > > https://github.com/tlswg/dtls13-spec/pull/20 > > > - This builds on top of PR#16 to reduce the long header format, removing > > the > > > version number and shortening the epoch/sequence number. > > > > > > > How does the latter one interact with the stuff in "Establishing New > > Associations with Existing Parameters"? The initial packets are > > distinguishable yes, but that subsection talks about possibly doing > > full handshake before discarding old state, which could prove rather > > messy. > > > I'm not sure I understand your concern here. Is it that you would > have packets from both connections in the short format and not be > able to know which is which? That seems like it's a problem now too > just made a bit worse by the reduced epoch/seq. The real answer > here is, of course, conn-id.
Yes, the problem is not being able to tell apart epochs 0-2 used by the handshake and epochs 3- used by established connection. And with regards to conn-id, unless the server just aborts every connection attempt without conn-id extension, you can get situations where one of the overlapping connections has conn-id and the other not. > > Also, I think that due to DTLS 1.2 compatiblity, only record type 23 > > (and 25) can use new record format. In practicular, I think 21 and 22 > > can not, since existing DTLS 1.2 libraries use those without > > negotiation. > > > > Sorry, I'm not following you here: this is only for DTLSCipherText, so > the external type will always be 23. All the other external types will > be using the old format, so easily distinguishable. " Implementations can distinguish the two header formats by examining the first byte, which in the DTLSCiphertext header represents the content type. The only valid values for the content type are alert(21), handshake(22), application_data(23), and ack(25), with application_data actually representing protected data with the true content type being encrypted. If any of these values is present, then the record MUST be handled as DTLSCiphertext. " That seems to imply that records starting with 22 have 32-bit shortened RSN, which obviously is not correct. > Also, on fast transmission, loss burst of ~2000 packets doesn't take > > much time. Such loss burst could result, e.g., from transient routing > > failure. One might want to discuss how to prevent desyncs from those. > > > > Sure. The answer for this is to use the longer header :) Might put a note that if one should use longer header if there can be more than about 2000 consequtive lost packets. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
