Re: [TLS] Connection ID Draft

Simon Bernard <contact@simonbernard.eu> Wed, 08 November 2017 13:38 UTC

Return-Path: <contact@simonbernard.eu>
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 A162C1201F2 for <tls@ietfa.amsl.com>; Wed, 8 Nov 2017 05:38:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level:
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 v0c7HXsKnDvJ for <tls@ietfa.amsl.com>; Wed, 8 Nov 2017 05:38:00 -0800 (PST)
Received: from 6.mo3.mail-out.ovh.net (6.mo3.mail-out.ovh.net [188.165.43.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E982A126D45 for <tls@ietf.org>; Wed, 8 Nov 2017 05:37:58 -0800 (PST)
Received: from player771.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id D784816ECF8 for <tls@ietf.org>; Wed, 8 Nov 2017 14:37:56 +0100 (CET)
Received: from [10.41.51.212] (130.163-14-84.ripe.coltfrance.com [84.14.163.130]) (Authenticated sender: contact@simonbernard.eu) by player771.ha.ovh.net (Postfix) with ESMTPSA id 12C8984007C; Wed, 8 Nov 2017 14:37:53 +0100 (CET)
To: Matt Caswell <matt@openssl.org>, Martin Thomson <martin.thomson@gmail.com>
Cc: "tls@ietf.org" <tls@ietf.org>
References: <CABcZeBPXB6cOSztzDHtKSWUCJrgET+9cF_rAiiE8CYCUSY_uLA@mail.gmail.com> <CABkgnnXT7nv9aNQh12deeitF1CurENpxgUicn9GHjMbojcEvJg@mail.gmail.com> <D0524862-083C-4576-98B8-6D8A4825D458@nokia.com> <CABkgnnW4d=H5RZ0E+Hwo4jQptDpshVVuFtD-xQudJzxLXyReAQ@mail.gmail.com> <4833b54e-880b-c2c4-99ed-4dde0c96fc5c@openssl.org> <CABkgnnUSBQ3+YG4BkGPAqmMt3YLiDVcivp_vYcdeOHrsD0ca4A@mail.gmail.com> <f128b6ea-4d2f-5aa3-9289-2439e71ee21a@openssl.org> <CABkgnnW=sYnzWUE8zVdo_kjFdES5PG74vmbc4aExrHOAJvWrKQ@mail.gmail.com> <46a95f41-ee4a-dccc-b6f4-8b2bce6582d4@openssl.org>
From: Simon Bernard <contact@simonbernard.eu>
Message-ID: <6c02b7a5-cda0-bb1c-3f31-833b9cca78c0@simonbernard.eu>
Date: Wed, 08 Nov 2017 14:37:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <46a95f41-ee4a-dccc-b6f4-8b2bce6582d4@openssl.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Ovh-Tracer-Id: 627126248619194609
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedttddrheelgdehhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/6m-Jdcn8SWh3zY915rNcojCvmVQ>
Subject: Re: [TLS] Connection ID Draft
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: Wed, 08 Nov 2017 13:38:04 -0000

Hi,

Here are the scenarios we would be interested to see covered by this CID 
extension.

1. Clients in unstable IP environment (like NAT)
2. stateless middlebox (like load balancer) with mixed CID and no CID 
connections.
3. stateless packet introspection (wireshark), with mixed CID and no CID 
connections.

Linkability is not an issue for us, we have almost the same kind of 
linkability than with fixed IP.

Point 1. seems already supported.
Points 2. and 3. seems not ok for now because its not so easy to know if 
a record contains a CID or not.

To know if a record contains a CID, the proposed solution in this thread 
are:
- using content type (not sure to see how?)
- using version (not available in DTLS 1.3? impact on current 
implementation?)
- add a MAC for CID (bandwidth cost?)

I don’t know which one could be the best, but I have one question: how 
to know the CID length for stateless middlebox or packet introspector ?

Simon

Le 03/11/2017 à 11:12, Matt Caswell a écrit :
>
> On 03/11/17 09:28, Martin Thomson wrote:
>> On Fri, Nov 3, 2017 at 8:15 PM, Matt Caswell <matt@openssl.org> wrote:
>>> It was my understanding that it is precisely this sort of problem that
>>> this draft was attempting to address. Explicit marking would solve this.
>> Yes, and the connection ID is that marking.  The contention - I think
>> - is what to do when there is a mix of marked connections and
>> unmarked.
> Right - where you have a mix of packets with connection ID and no
> connection ID you don't know whether to look for one or not. IMO this
> draft won't really be addressing the issues unless it includes a
> mechanism for determining that.
>
> Matt
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls