On Fri, Oct 27, 2017 at 5:25 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote:
> 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. Sure, this was already sort of an issue with epoch=1 for DTLS 1.2 connections, though content type helped. I'll add some text with suggestions > > 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. > Oh, I see. Yes, I got stuck in QUIC-think and forgot that in DTLS we use "DTLSPlaintext" here. I'll fix that. > 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. > Yes, thanks. -Ekr > > > -Ilari >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
