[TLS] a slightly different DTLSShortCiphertext

["Fossati, Thomas (Nokia - GB/Cambridge)" <[e-mail]>]

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