Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Stephen Checkoway <s@pahtak.org>
In-Reply-To: <1C32782E-02E4-4743-9E26-E5C0593C1BCF@ericsson.com>
Date: Tue, 20 Mar 2018 14:28:53 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <6964A867-2406-4190-AFFE-E52C15A10A8A@pahtak.org>
References: <1C32782E-02E4-4743-9E26-E5C0593C1BCF@ericsson.com>
To: "TLS@ietf.org" <TLS@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fzhOjLHpz8g-ID5uQtw0JsBeDW4>
Subject: Re: [TLS] Connection ID in TLS
Precedence: list



> On Mar 20, 2018, at 11:38, John Mattsson <john.mattsson@ericsson.com> =
wrote:
>=20
> 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.
>=20
>   struct {
>      ContentType opaque_type =3D application_data; /* 23 */
>      ProtocolVersion legacy_record_version =3D 0x0303; /* TLS v1.2 */
>      uint16 length;
>      opaque cid[cid_length];               // New field
>      opaque encrypted_record[TLSCiphertext.length];
>   } TLSCiphertext;
>=20
>   length  The sum of cid_length and TLSCiphertext.length

This defines length in terms of itself since length is =
TLSCiphertext.length.

--=20
Stephen Checkoway