Re: [TLS] Connection ID in TLS

Richard Barnes <rlb@ipv.sx> Tue, 20 March 2018 17:37 UTC

Return-Path: <rlb@ipv.sx>
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 39674126BF7 for <tls@ietfa.amsl.com>; Tue, 20 Mar 2018 10:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 kADTHVb8m-dS for <tls@ietfa.amsl.com>; Tue, 20 Mar 2018 10:37:03 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 94CDB126CB6 for <TLS@ietf.org>; Tue, 20 Mar 2018 10:37:03 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id f125so5086145wme.4 for <TLS@ietf.org>; Tue, 20 Mar 2018 10:37:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sFOOe/6HWupyaVv5xKlsK/xHOJ3CaROPXlp50SCoors=; b=JMuN4qQP9A20P7uH+nGkN4BBJgG/BCq7SBLsjHWpGWuyWUY9OgD8Fa5UW4zXtfk9Jg GB/n2PlNbsDMubN+EuSJ0cO7NIACBKqSo0xcvEMhAUj7Ddo+fnnizWHyXOjvLGSLLR5X 96uRa3TKrwujAdVYLV1ffqI2jB6uM+GAVdKzNDv7F3h1Qn8Qu1qs+j2Ffr1hP7KBmSBU huX/sRzlLWIwyrdOnvkCbGEOx1ubafugI4PXF+mgYI/W+hnnVYnAPYBzVQef8qi54XXW hDqtyl/HypDmT/DFlPUMi/HD8zdLxYLRJveMLRVu1i/Ug4SA9sLNuwlfV6cmiyFO2p2Z 1VvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sFOOe/6HWupyaVv5xKlsK/xHOJ3CaROPXlp50SCoors=; b=SUH08vNRk9ZTlGmA63C/iOf+bcFq+ciFfTq0uZXkUTZW7kg2zza6YaoUjFym37KvDv E/ugePpuaBoXeQdH3sictBa79x89p1kpOnpyyclyvpJbzJu7IVioDA3d4HDKAr1UJxIz Yigw/jz0IlNhqGEhHps3SIEQjGwI1j0lH5ezS/pgP0Pnnt4w912MoRBAmvuVyzl3YSon x0xgD+GxXG4TRNKPeNm14NvV5yam1TZ03186/agK+cipaVV5KdsWPXk+5jRGtCg/7J1n GL+WD8s3IwmVJT0JsDj+GYQK5pEk1CKFv7As7om7t+1//E7qQSpECG+zgZ3E7kAuxwCa s9xA==
X-Gm-Message-State: AElRT7Hzvrb8XQGacF45c+vzGhNCE5eZAqg2D8RGCHsUTcMRI+6MMVFV Fz1Qwk+237EfjoV8QwkqM5yPlx73Xkj/bdirWKZ3GQ==
X-Google-Smtp-Source: AG47ELsSvGQvnTnZqxuw9g9lN0dvemL4CdM7AavssmhgN9BxVBfKWL5wN6DIYNsjchlkpMBRPJuOf/BCz+K3n9/vVxQ=
X-Received: by 10.28.6.149 with SMTP id 143mr405022wmg.61.1521567422066; Tue, 20 Mar 2018 10:37:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.12.140 with HTTP; Tue, 20 Mar 2018 10:37:01 -0700 (PDT)
In-Reply-To: <A32E0C44-51E8-4D2D-AF1C-A55A5065E143@nokia.com>
References: <A32E0C44-51E8-4D2D-AF1C-A55A5065E143@nokia.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Tue, 20 Mar 2018 17:37:01 +0000
Message-ID: <CAL02cgRLdOBTWECGP9rSWVAO0nRHbDAjnFi62ZLr-5xqnbXJ7g@mail.gmail.com>
To: "Fossati, Thomas (Nokia - GB/Cambridge)" <thomas.fossati@nokia.com>
Cc: John Mattsson <john.mattsson@ericsson.com>, "TLS@ietf.org" <TLS@ietf.org>
Content-Type: multipart/alternative; boundary="001a11442348b1ccf70567db856e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-CRqntNTKC3p9Vh9n4B4wg-AzmI>
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 17:37:06 -0000

I don't think Connection-ID is really required for ATLS.  As Carsten and
Owen mentioned in the side meeting, there are a few ways to use HTTP to
correlate the relevant messages.

On Tue, Mar 20, 2018 at 5:15 PM, Fossati, Thomas (Nokia - GB/Cambridge) <
thomas.fossati@nokia.com>; wrote:

> On 20/03/2018, 16:38, "TLS on behalf of John Mattsson" <
> tls-bounces@ietf.org on behalf of john.mattsson@ericsson.com>; wrote:
> > 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?
>
> Are you referring to slide 13 of [1]?
>
> If so, the problem is not CID-specific.  It's more generally what
> could happen if we try and reuse the top bit of the length field
> for other purposes.
>
> Yoav brought up the case of an intercepting middlebox - one that needs to
> pretend to be a fully-fledged TLS server.  That kind of box might
> either:
> - let the extension that enables repurposing the length's MSB pass
>   through, and subsequently choke on the invalid length [HARD FAIL];
> - eat up the unknown extension and therefore break the feature
>   negotiation [SOFT FAIL].
>
> Cheers
>
>
> [1] https://datatracker.ietf.org/meeting/101/materials/slides-
> 101-tls-sessb-record-header-extensions-for-dtls-00
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>