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