Re: [TLS] Connection ID in TLS

Stephen Checkoway <s@pahtak.org> Tue, 20 March 2018 19:29 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 6F5B2126DFF for <tls@ietfa.amsl.com>; Tue, 20 Mar 2018 12:29:00 -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 5hyLv-Yti203 for <tls@ietfa.amsl.com>; Tue, 20 Mar 2018 12:28:58 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 BEA861241F5 for <TLS@ietf.org>; Tue, 20 Mar 2018 12:28:58 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id y20-v6so3839779itc.5 for <TLS@ietf.org>; Tue, 20 Mar 2018 12:28:58 -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=fIgbcEJfqFiX/FVCnl8wEkePUc/m5nbnBsBOFOC5yX4=; b=skES3A4al95vqybBgxk+ibkstDvvKqlwy0NcvkCwgJGnQ4IJeppmClRNeyHvgc2LzQ 4fHlz/ONFDCdbLacrUR7oGNXIN7cOIIkt/W4rG4zGxUlJf+H5i2HLavBK7zFfjIdmkpu sIyT1dVohhehY0bPVbdcFywL2LKp+Lx8lGkaZlt7n8XUJJjxOtSHHoQ321+mg8fB/PN/ LexYaL0ittC4YZksLLe+imubkJkQL/cVaXAVUrWBt9/gq+4B4jYt4FDvUCLTcXhsjJX6 +4x0Apgz/pjHutjMauXHIUyaGWyj5/Oqqv4z5a5Z0zWCIlys5H4LDfHkguloMcG9zTHg vo4Q==
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=fIgbcEJfqFiX/FVCnl8wEkePUc/m5nbnBsBOFOC5yX4=; b=VKZW0PvbusRqdMf/NMpau8lXRDswJuEORz1NJiGRwRlATOtdCRtny0Rkp9afHz6GGj RioaYOi4OHHYwpfA9gRqK+6UPCoRSSu09HmDr4M4UDayIdjFpCdxAT90uypjjLqwcEEx aRr83EsN30jziQ9oIBaMcZcumw4FV9eyTQJyZPoYWx4To+54BZW9S2cJvBj55HjUJVVf 4duzzcHGe4cghWA3/DwLr2Z5liOFzpKs7xf4MkjZLK5xRlr1lXIn7tYEu1q0xLM/Icxy ZcT3linPJsaQubCC0RnI8CaHuhlU9hzXiGs3MyLNntoRZoJWOkEnta6MiklhDxOAWpTv 3cjA==
X-Gm-Message-State: AElRT7ErLK/CkKj7mbeQa9ChjUiNiDxiikdIe6ULpPWIxErIDDmgyPJm /3RPCV/mDPrkrgByK9lZa5VQ8ZFxRbU=
X-Google-Smtp-Source: AG47ELu8ObNEB/FkxjFqISPTMitEQA7pZPsJVyErhidrfVNW27KCqrje46hbU7kG2DDjjTkwBvRtyA==
X-Received: by 2002:a24:5b04:: with SMTP id g4-v6mr1064202itb.68.1521574137895; Tue, 20 Mar 2018 12:28:57 -0700 (PDT)
Received: from zbox.pahtak.org ([2601:241:8e00:544d:201:2eff:febc:8976]) by smtp.gmail.com with ESMTPSA id d4sm1522342iop.83.2018.03.20.12.28.57 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 20 Mar 2018 12:28:57 -0700 (PDT)
Received: from 10-31-48-201.ece.uic.edu (unknown [131.193.45.212]) by zbox.pahtak.org (Postfix) with ESMTPSA id D8217AC34C1; Tue, 20 Mar 2018 14:28:54 -0500 (CDT)
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>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fzhOjLHpz8g-ID5uQtw0JsBeDW4>
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 19:29:00 -0000


> 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