IETF Logo Mail Archive

Re: [TLS] Connection ID Draft

"Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com> Fri, 13 October 2017 06:31 UTC

Return-Path: <thomas.fossati@nokia.com>
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 C368D132924 for <tls@ietfa.amsl.com>; Thu, 12 Oct 2017 23:31:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level:
X-Spam-Status: No, score=-4.7 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 bGiq1x9NnHQP for <tls@ietfa.amsl.com>; Thu, 12 Oct 2017 23:31:18 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0102.outbound.protection.outlook.com [104.47.0.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB90B12421A for <tls@ietf.org>; Thu, 12 Oct 2017 23:31:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nPTYmQsN80phnvIm57e9CwUB0tENsc378Y5XUBc3QbA=; b=bIdQgRtR/zFt+OZLdIDkVJ0qfvP51z6m8uI/wQGUT8sZQxhhKy4WE45EsYEdYQ5+LzGMtCkWg12GmYR7I1Le+/d9oRmWU6vhv8SdHjC2/x8IeCV6gGAI68cC/RaXLck9OckKYi+fQdfgbNroMVEgY8lQB+GvpPzX7//mC5HZ7Yw=
Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Fri, 13 Oct 2017 06:31:14 +0000
Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::c0d1:2c07:79aa:1d9e]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::c0d1:2c07:79aa:1d9e%14]) with mapi id 15.20.0077.018; Fri, 13 Oct 2017 06:31:14 +0000
From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com>
To: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Connection ID Draft
Thread-Index: AQHTQ6/ei1Eh6DPTUUK7WLQddJSSYqLhYyGA
Date: Fri, 13 Oct 2017 06:31:13 +0000
Message-ID: <B286EFDE-24D3-4B50-A0DE-1A87563A962E@nokia.com>
References: <CABcZeBPXB6cOSztzDHtKSWUCJrgET+9cF_rAiiE8CYCUSY_uLA@mail.gmail.com>
In-Reply-To: <CABcZeBPXB6cOSztzDHtKSWUCJrgET+9cF_rAiiE8CYCUSY_uLA@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com;
x-originating-ip: [2.96.101.129]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB1102; 6:0gb4nRypyMJlPe3lGlUXCeI8nAeoUV6YdVUeXoVKMzs4aUbVvCPeiOJgDq3C/xpb5wUC5fa3usBX6SUHVZIrYX1bZRWMkd7tYG4CIZUz3tXnFZby158azzlkQvjchARMita+FIl7GlrdRp4aX8kwLJHS8sO10LZdnxe3b6R3rXSFhedpwcYJRgK8tcKjhvEqK3N1TbuvUY/yU229M1rXu5QSwCZHYOac4ondOlCxQIcN+A5S+5lhZiFMavs/Y2HCQ/BixLxBekWxvi25c9NKCuGTEigNfRWpW1th5nY1FcFLB9IAK2EhmT23mYwToYdyjWaZX4xjoL0w6BmB89gBtQ==; 5:EV9SISz9W5VFuQwsKls/lgqvrc2le0evIP+tyPkzERR9TpJ+vrIeS+lN648T/Ghwv3vICx/NApPQs5ngPva9YS8v+VWQI1T+10sKOIMQUFUIM25msiy/KQisAAfVHshZ6Wsi3PDxeEH/3NRjhh51TQ==; 24:e1q0B6pV8sv2FCd/tVTZCqN6iro6RpSa/PZdYrMRB6vL64hSa3Jl5pDzZ2F3REnajWUI0KFqQrLgug31jcko774DmTW9Et/yXNAAywAOb/E=; 7:tDV9Uh0kjnvpLdEjXz/o8zKj1+WFOF95DKSrGWbws6muOcHEddsCTjtQhlyQukjMXLyJ0IyGZG3D2RRlA/UTmyxehiMhG2uedAx+MxqWcSrIdm11aeDrMEsEr5nDFDZlGTCrOKL5jPiVlv/DlDXe+MRijpddz89SlXI2hJ77nEkY79m+v+jL6jNyF6xxFPAE6d5w/Z76xMuHSE1gcRHnSGZCGiGaM8ykjLqH8QN1+zs=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(376002)(346002)(199003)(24454002)(51914003)(189002)(6436002)(6486002)(101416001)(8936002)(8676002)(81156014)(229853002)(81166006)(3660700001)(82746002)(966005)(3280700002)(6506006)(68736007)(106356001)(76176999)(50986999)(25786009)(58126008)(105586002)(66066001)(54356999)(97736004)(7736002)(5660300001)(3846002)(14454004)(99286003)(316002)(2501003)(2950100002)(110136005)(53546010)(83716003)(33656002)(606006)(2906002)(86362001)(2900100001)(189998001)(478600001)(6306002)(83506001)(6116002)(4326008)(54896002)(107886003)(236005)(6512007)(36756003)(5250100002)(53936002)(6246003)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1102; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
x-ms-office365-filtering-correlation-id: 452fc65c-9cf7-4847-a1ff-08d512040088
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:VI1PR07MB1102;
x-ms-traffictypediagnostic: VI1PR07MB1102:
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-microsoft-antispam-prvs: <VI1PR07MB11023FC170A4841D590FC86880480@VI1PR07MB1102.eurprd07.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1102; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1102;
x-forefront-prvs: 04599F3534
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_B286EFDE24D34B50A0DE1A87563A962Enokiacom_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2017 06:31:13.9354 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1102
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RdXbSyZl57n1ynORWN2RNlFqKbs>
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: Fri, 13 Oct 2017 06:31:22 -0000

First, thanks for the draft.

As discussed off-list, wrt framing / wire format, we probably have an opportunity to do slightly better than this, at least for 1.2.

The thing is that, since there is no flag in the record that says: "I'm carrying a CID", a receiver has no explicit way to know whether a record is coming from a CID-enabled session or a legacy-DTLS.

This ambiguity complicates the decoder because the receiving end now needs to implement a heuristic like:

-          let's first assume at offset +11 we have a CID

-          and then lookup the SAs store using this "maybe" CID

-          if found, OK (*), go on with the parsing

-          if not, fall back to assuming at offset +11 we have the length field and go on parsing

This is not ideal for a bunch of reasons:
    1. For every incoming record, the receiver needs to lookup the CID store just to parse the record;
    2. The implementation is more complicate;
    3. Heuristics are intrinsically fragile and are known to deal badly with corner cases (think the many creative ways the many moving parts can conspire: 5-tuple reshuffling because of NAT rebinding, lost state due to reboot/restart of one or more nodes, co-existing CID and legacy DTLS);
    4. Wireshark & co will choke because they typically don't have enough context to handle the two different framings;

To solve this, we'd need a place in the wire image of the record with semantics: "I'm carrying a CID."

In 1.2, we could use CT or version.  (In 1.3, that would not be possible because the diet header doesn't have them - too bad.)  To me it'd make slightly more sense to use the version. (I had previous discussions on this topic with Nikos and he told me that though anyconnect does this version override for some reasons, there is no reported conflict with middle-boxes.)  Also, there would be only one code-point to allocate, instead of separate code-points for each CID-enabled content type variant.  I'm happy to be convinced of the opposite, though.

I guess my main point here is to make sure we do as much as we can to allow simple, efficient, robust implementations, which are also, en passant, Wireshark-friendly, and leave heuristics-based approaches only for when there is no real alternative.

Cheers, t

(*) assuming CID is entropic enough, which may or may not be the case.


On 13/10/2017, 00:13, "TLS on behalf of Eric Rescorla" <tls-bounces@ietf.org<mailto:tls-bounces@ietf.org> on behalf of ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote:

Hi folks,

I have just posted a first cut at a connection ID draft.
https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00

Comments welcome.

-Ekr

v2.23.0 | Report a Bug | By Email