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) <thomas.foss...@nokia.com> wrote: > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
