Subject: [TLS] a slightly different DTLSShortCiphertext

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Sat, 3 Mar 2018 17:33:30 +0000

Hi all,

In an off-list discussion on the wire format for DTLS CID Eric raised
the point that a DTLSShortCiphertext header is completely stuffed, and
it'd be impossible to grab another bit from the sequence number (already
down to 12 bits) to signal the presence of a CID.

I made a proposal for a slightly different layout of DTLSShortCiphertext
that makes room for the CID bit, which I'd like to bring to the list for
further scrutiny:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|1|E|C|X|X|X|            sequence           |               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
|                                                               |
+                                                               +
|                                                               |
+                   [CID,] encrypted_record                     +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 0                   1                   2                   3

Where:
- First 4 bits are the same as in current DTLSShortCiphertext (demux +
  low order epoch bit)
- Subsequent 4 bits are: C, the connection-id indicator followed by 3
  reserved bits (to be greased, I suppose)
- Then, a 16-bit sequence number.

It'd still be 4 bytes shorter than usual DTLSCiphertext, so I guess it's
OK to keep calling it "short".  There is the question about these 3
reserved bits, which seem like good candidates for greasing, I guess.

What do people think?

Cheers, thanks

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Mar 2018 10:11:56 +1100

We are about to remove that bit from the QUIC packet.  I don't see any
advantage in adding it here.

Can you explain in more detail who you think consumes this bit?

On Sun, Mar 4, 2018 at 4:33 AM, Fossati, Thomas (Nokia - GB/Cambridge)
<[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Mon, 5 Mar 2018 00:12:54 +0000

> Can you explain in more detail who you think consumes this bit?

Server or server-side middleware that doesn't know whether the packet
that needs parsing belongs to a session that negotiated CID or not.  I'm
not sure the analogy with QUIC holds here: AFAIU, in QUIC the server can
always say "use CID when you are talking to me"; in DTLS, the server has
to live with a mix of CID and non-CID sessions.

On-path diagnostic tooling.  E.g., if you have a huge fleet of sensors
deployed behind a NAT where rebindings happen basically every time the
sensor sends the update upstream (the 5-tuple is totally ephemeral), and
you need to do anomaly detection, being able to extract the CID from the
flows is pretty handy.  But in general, when you don't own the endpoints
and are asked to debug, having a working wireshark is nice.

I genuinely can't see what advantage we get by not having its
presence explicitly signalled.  Could you elaborate a bit on that?

Cheers, thanks

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 4 Mar 2018 16:26:53 -0800

> to live with a mix of CID and non-CID sessions.

Well, this actually isn't strictly true: the server could refuse to
negotiate TLS 1.3
if the client didn't negotiate CID. And because you can distinguish TLS 1.3
from
TLS 1.2, ....

> presence explicitly signalled.  Could you elaborate a bit on that?

Well, you're making every packet 1 byte bigger, for starters.

-Ekr

---

From: "Fossati, Thomas (Nokia - GB/Cambridge)" <[email-masked]>
Date: Mon, 5 Mar 2018 08:09:50 +0000

On 05/03/2018, 00:27, "Eric Rescorla" <[email-masked]<mailto:[email-masked]>> wrote:
I genuinely can't see what advantage we get by not having its
presence explicitly signalled.  Could you elaborate a bit on that?

If the cost of having simple, straightforward implementations while at the same time easing the operational side of the world is 1 byte per packet, I’m happy to pay the price.

People with use cases where a 1-byte overhead really matters already think (D)TLS is too chatty.  In fact, that’s one of the main reasons OSCORE exists.