Correct, I just copied pasted the length of the arrays, should be length =
cid_length + encrypted_record.length.
The example was taken from draft-ietf-tls-tls13-27. If I understand correctly,
It seems like the same circular definition is done there as well....
-----------------------------------------------------
struct {
ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
uint16 length;
opaque encrypted_record[TLSCiphertext.length];
} TLSCiphertext;
-----------------------------------------------------
Shouldn't this be...
-----------------------------------------------------
struct {
ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
uint16 length;
opaque encrypted_record[encrypted_record.length];
} TLSCiphertext;
-----------------------------------------------------
Does this mean the
On 2018-03-20, 19:29, "Stephen Checkoway" <s...@pahtak.org> wrote:
> On Mar 20, 2018, at 11:38, John Mattsson <john.matts...@ericsson.com>
wrote:
>
> I think Connection ID is an important enabler for end-to-end security
with (D)TLS. There seems to be important use cases for connection ID in TLS as
well, see https://www.ietf.org/mailman/listinfo/atlas. At the Monday afternoon
TLS session, it was stated that Connection ID in TLS was unemployable in the
wild due to middleboxes. Couldn't that be solved by placing the cid field after
the length field? E.g.
>
> struct {
> ContentType opaque_type = application_data; /* 23 */
> ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
> uint16 length;
> opaque cid[cid_length]; // New field
> opaque encrypted_record[TLSCiphertext.length];
> } TLSCiphertext;
>
> length The sum of cid_length and TLSCiphertext.length
This defines length in terms of itself since length is TLSCiphertext.length.
--
Stephen Checkoway
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
