Subject: [TLS] Connection ID in TLS

From: John Mattsson <[email-masked]>
Date: Tue, 20 Mar 2018 16:38:36 +0000

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

(Also draft-ietf-tls-dtls-connection-id-00 says obsoletes RFC6347, should be updates).

Cheers,
John

---

From: Stephen Checkoway <[email-masked]>
Date: Tue, 20 Mar 2018 14:28:53 -0500

> On Mar 20, 2018, at 11:38, John Mattsson <[email-masked]> wrote:
> 

This defines length in terms of itself since length is TLSCiphertext.length.

-- 
Stephen Checkoway

---

From: John Mattsson <[email-masked]>
Date: Tue, 20 Mar 2018 23:45:59 +0000

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" <[email-masked]> wrote:

    
    
    -- 
    Stephen Checkoway

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 20 Mar 2018 18:57:42 -0500

The issue is that the "TLSCiphertext.length" is the same field as
the "uint16 length", so you are saying that this field has the value
of "cid_length plus itself", which is impossible in integers modulo
[a value larger than cid_length].  In the "formal" grammar, you'd
need to define a new field.

-Ben

On Tue, Mar 20, 2018 at 11:45:59PM +0000, John Mattsson wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Stephen Checkoway <[email-masked]>
Date: Tue, 20 Mar 2018 18:58:40 -0500

> On Mar 20, 2018, at 18:45, John Mattsson <[email-masked]> wrote:
> 

There is no field called encrypted_record.length. TLSCiphertext.length refers to the length field in the TLSCiphertext struct rather than the length of the TLSCiphertext itself (which is a few bytes longer). See Section 3, Presentation Language, for the precise definitions.

Steve

-- 
Stephen Checkoway