Re: [TLS] Connection ID in TLS

Stephen Checkoway <s@pahtak.org> Tue, 20 March 2018 23:58 UTC

Return-Path: <s@pahtak.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927F21205F0 for <tls@ietfa.amsl.com>; Tue, 20 Mar 2018 16:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.399
X-Spam-Level: **
X-Spam-Status: No, score=2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=pahtak-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkFKaWbLYAur for <tls@ietfa.amsl.com>; Tue, 20 Mar 2018 16:58:43 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FAB41200B9 for <TLS@ietf.org>; Tue, 20 Mar 2018 16:58:43 -0700 (PDT)
Received: by mail-io0-x22d.google.com with SMTP id o4so4504105iod.3 for <TLS@ietf.org>; Tue, 20 Mar 2018 16:58:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pahtak-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CG38ZgqMXVbY8GCpmAZpa1xl6e31LgCdTEaE4Dzq4P0=; b=IxMREEiruCWLnP2LH86bS5JC7BRuGXfPZaU993R7xVIlQnY7xDyRhY7TDAPBM3dLhl 5cGbhP7+ltEUrxObbxeiqanZbe63nFevUShE2jMk9rifb4ftC8L3LJteXf5j06Wca7sa 0DPiEl6m1b62C9+G1XzmlvcPvkU+JzHkvxXO7cfZzmo0z2/0vaLhi9vEyoVa+3+avmWa D9TQEPf7bdHdn6g+yQaq0BDiUy9FncqLliF4F05RmUa5QHL2a54binhCszlB7SBpg8yj AOpxf3J0dnfG4CXVCu84Hxg++P6ObAECCKfV4d4aCBIXbFJwRqWhK6r+9nivFtkvZfHj skBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=CG38ZgqMXVbY8GCpmAZpa1xl6e31LgCdTEaE4Dzq4P0=; b=B649Iz1un8xntZ1E7fTp/MrvzjavyHuZvVd02oukEIi+etBSylhZNztxF6w30+xASt SFs+Yo82Ty972OkxmJm518KdofbxiG4G2fzfV1Ihj9+sBDX8nM3kAbm3DWPG3SJQzPaa idjZUKvBaDXh7+g/DV590VDDvFl0NKAhfEQJMWkbdrjrBZkXYveJyXp4RBcQifppECTV +RwLtzCiWlV4QBWLt6bVDaAz8JrkAjhJrUNTwF35rccxIdcWusaR2WKrGLWu3ZZh+DnY YN+01G7sEgdftGFkJoT2GWUT8XYa7KnNPe1T3TJwj78Ws1oIoJjz0zdDz6euxAVdMKNp iZtA==
X-Gm-Message-State: AElRT7Ge6JoRSJyIglbW8oC02xb3JJxuGnyV6780NA7siIM5WNMNH8yd 0nIXcHuzZBGXD8xvLDbCWHDBDA==
X-Google-Smtp-Source: AG47ELsxIoHGLTOgVLskUhKLZqFdH9kV9nDWKtJ4erXf6ONOI2Zj40S/jFDbCYR7fY0hH7hDNuaVdQ==
X-Received: by 10.107.139.70 with SMTP id n67mr18281124iod.109.1521590322352; Tue, 20 Mar 2018 16:58:42 -0700 (PDT)
Received: from zbox.pahtak.org (c-73-111-204-119.hsd1.in.comcast.net. [73.111.204.119]) by smtp.gmail.com with ESMTPSA id g12sm1721974iob.18.2018.03.20.16.58.41 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Mar 2018 16:58:41 -0700 (PDT)
Received: from hackintosh.hsd1.il.comcast.net (router [192.168.1.1]) by zbox.pahtak.org (Postfix) with ESMTPSA id 22B44AC34C1; Tue, 20 Mar 2018 18:58:41 -0500 (CDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Stephen Checkoway <s@pahtak.org>
In-Reply-To: <EF62879E-C621-4E51-8006-727328E69BF7@ericsson.com>
Date: Tue, 20 Mar 2018 18:58:40 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <55BB1982-5004-4DCF-BBFD-5A69AE7DBBA2@pahtak.org>
References: <1C32782E-02E4-4743-9E26-E5C0593C1BCF@ericsson.com> <6964A867-2406-4190-AFFE-E52C15A10A8A@pahtak.org> <EF62879E-C621-4E51-8006-727328E69BF7@ericsson.com>
To: "TLS@ietf.org" <TLS@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bcHrii2mF_MHvrsHC-sA3lrcmVM>
Subject: Re: [TLS] Connection ID in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Mar 2018 23:58:45 -0000

> On Mar 20, 2018, at 18:45, John Mattsson <john.mattsson@ericsson.com>; wrote:
> 
> 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;
> -----------------------------------------------------

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

> 
> 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.mattsson@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
> 
> 
> 
> 
> 
> 
> 

-- 
Stephen Checkoway