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. > 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. 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 :) -Ekr > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
