Hi Ben,
Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for an endpoint to use a globally constant length for such connection identifiers. This can in turn ease parsing and connection lookup, for example by having the length in question be a compile-time constant. Implementations, which want to use variable-length CIDs, are responsible for constructing the CID in such a way that its length can be determined on reception. Such implementations must still be able to send CIDs of different length to other parties. Note that there is no CID length information included in the record itself....and thanks for the reminder about how we say so in the text already.
(your example from a previous e-mail) > Attempting to construct a trivial example on the fly, (hex) > 01 01 02 02 01 <513 bytes of plaintext content> > could be cid_length=1, cid=0x01, length_of_DTLSInnerPlaintext=0x0202, > DTLSInnerPlaintext.content = 0x01 <513 bytes>, or it could be > cid_length=2, cis=0x0101, length_of_DTLSInnerPlaintext=0x0201, > DTLSInnerPlaintext.content = <513 bytes>. I would feel much more comfortable, if you state, that you consider now either 1. that example was not compliant to the draft, or 2. the draft is not clear enough about that. If 1. is true, https://github.com/tlswg/dtls-conn-id/issues/76 could be closed. best regards Achim Kraus _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
