Subject: [TLS] New header PRs

From: Eric Rescorla <[email-masked]>
Date: Thu, 26 Oct 2017 16:37:47 -0700

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.

Please take a look. In the interest of forward progress, I intend to merge
before
I do the next draft but I recognize that is getting ahead of consensus, so
we can
discuss in Singapore too.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 27 Oct 2017 08:37:44 +0300

> 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.

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.

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.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2017 04:56:08 -0700

> full handshake before discarding old state, which could prove rather

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.

> can not, since existing DTLS 1.2 libraries use those without

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.

> failure. One might want to discuss how to prevent desyncs from those.

Sure. The answer for this is to use the longer header :)

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 27 Oct 2017 15:25:31 +0300

> 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.
 
> 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.

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2017 06:14:22 -0700

On Fri, Oct 27, 2017 at 5:25 AM, Ilari Liusvaara <[email-masked]>
wrote:

> > > > Building on our discussion in Prague I've posted two PRs for
> shrinking
> > > the
> > > > header size:
> > > >
> > > > - This builds on top of PR#16 to reduce the long header format,
> removing
> > > the

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

> 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.

> more than about 2000 consequtive lost packets.

Yes, thanks.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 28 Oct 2017 12:45:00 +0300

> > more than about 2000 consequtive lost packets.

"
+Note: the DTLSShortCiphertext format does not allow for easy
+reconstruction of sequence numbers if ~2000 datagrams in sequence
+are lost. Implementations which may encounter this situation
+SHOULD use the DTLSDCiphertext format.
"

I presume s/DTLSDCiphertext/DTLSCiphertext/ as I don't see the 
definition of "DTLSDCiphertext" anywhere.

-Ilari