Draft: draft-ietf-tls-dtls13

Commentary: This is a bikeshed colour , but I think a good one . In the 5 bits that we have , we can pack two epoch bits ( we only need one in practice , but let 's leave that aside for the moment ) , and a bit each to signal presence of connection ID and length . That leaves one spare bit . I 'm suggesting that we spend this on signaling the difference between an 8 - bit and 16 - bit sequence number . 16 bits is far more comfortable than 14 , and 8 is probably enough for many use cases ( saving a byte ) . That is , unless you were saving this for a spin bit and VEC . This does n't do anything about , but I think that we can save a bit from the epoch . More on that later . 
 If epoch can be one bit - the you provided is quite convincing - then this proposal could coexist with . 
 Instead of , make the fixed prefix by picking one of the three reserved bits : This way the implicit Content Type allocation is halved to [ 48 , 63 ] and we get back 16 codepoints . 
 I think that we can do better . I 've just opened . That uses all the bits in that first octet , which would seem to be a regression , but there are two ways in which we could get another bit back . The first option is to drop the S - bit I propose and have sequence numbers be 16 bits always . I 'd be sad that we lost the small optimization , but that is n't the end of the world . Perhaps a better option is to drop the second epoch bit . This seems like a bad idea because you potentially have multiple epochs inbound to a server during a 0 - RTT handshake . In that case , you have to distinguish between ClientHello ( 001 or 0011 would work for that ) , 0 - RTT ( epoch 1 ) , Handshake ( epoch 2 ) , and the ultimate Application Data ( epoch 3 ) . If you only have one bit of epoch , then 1 and 3 are indistinguishable . However , if you look at the way we handle 0 - RTT in stacks , it might be OK to allow those late - arriving 0 - RTT records to be dropped . For instance , NSS processes 0 - RTT and handshake linearly . We do n't read the Finished until we have the EndOfEarlyData , and as soon as we process the EOED , we stop accepting new 0 - RTT . Part of the reason for this is that once we report handshake success , we do n't provide any other signal to an application about the data it receives . So , for NSS , dropping 0 - RTT when 1 - RTT is available would n't change anything for us . The final option is to not worry about this . The codepoints are there to use . The number of public bits we have is small , and we do n't need to signal content type in the clear any more . As I suggested in discussing tlswg / dtls - conn - id , perhaps the right answer is to backport the TLS 1.3 record format to DTLS 1.2 and use only one codepoint . 
 With regards to 1 . Losing the ability to signal 8- v 16 - bits sequence would be a bit of a shame , especially in constrained networks ( opinions ? ) , but I agree with you it 's not the end of the world and I 'd be more than happy to immolate it to get one of the reserved bits back . In fact , one bit is sufficient to build a whole if we 'd need to -- for spin bit , VEC , etc . I value that much more than a tiny optimisation . WRT 2 . Your argument in favour of dropping the second epoch bit is pretty convincing , so personally I 'd be OK with one - bit epoch . So , I guess we could have something like : and 16 bits sequence , always ? 
 You have n't made a convincing case for an extension mechanism to my mind . And given the choice between having two sequence number lengths and extensions , I 'd take the former every time . 
 The appalling amount of cycles we have been spending on devising how to do CID signalling in 1.2 is a very good argument in favour of having some kind of extension built in in 1.3 . Next time we realise we missed something we wo n't have to struggle like Houdini . To me this is far more important than a small optimisation of undetermined benefit . 
 I do n't think this is the right answer . Given that as soon as we can recognize the CID , we can make extensions without changing the header here , I agree with MTabout filling the bits .
Paragraph (version A):
The low order 14 bits of the record sequence number.
Paragraph (version B):
The C bit is set if the connection ID is present.
Paragraph (version B):
The L bit is set if the length is present.
Paragraph (version B):
The size of the sequence number.  0 means an 8-bit sequence
number, 1 means 16-bit.
Paragraph (version B):
The low order 8 or 16 bits of the record sequence number.  This
value is 16 bits if the S bit is set to 1, and 8 bits if the S bit
is 0.