Re: [TLS] extended headers for (D)TLS (and their use with connection-id)

"Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com> Wed, 24 January 2018 16:26 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 97F54126C26 for <tls@ietfa.amsl.com>; Wed, 24 Jan 2018 08:26:01 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 wGeshpNaO--y for <tls@ietfa.amsl.com>; Wed, 24 Jan 2018 08:25:59 -0800 (PST)
Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40130.outbound.protection.outlook.com [40.107.4.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA27F1205D3 for <tls@ietf.org>; Wed, 24 Jan 2018 08:25:58 -0800 (PST)
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=NC2Pol3HnnUGNGOey/iNtTbPv24hysCoa2mU4ZBKNLA=; b=IdlDglYD1AJHmj9IESdHczgFeoILPrNgOUj3DODD4oNLDM8arS5k1GE1c0JD8O5gf4CYKrD0tDS6AWROywIMbbh5d41ULV+yrPVKTO9rqQzNiUvI9Od3MPpRqGbGahHJM3HXaU580zDAaSV7HqgOxkmbsY/8zciOCfBlKE5PCDo=
Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1SPR8PMB111.eurprd07.prod.outlook.com (10.163.248.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.5; Wed, 24 Jan 2018 16:25:56 +0000
Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::a946:631c:fa30:cf79]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::a946:631c:fa30:cf79%14]) with mapi id 15.20.0444.008; Wed, 24 Jan 2018 16:25:56 +0000
From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com>
To: Adam Langley <agl@imperialviolet.org>
CC: "tls@ietf.org" <tls@ietf.org>, "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com>
Thread-Topic: [TLS] extended headers for (D)TLS (and their use with connection-id)
Thread-Index: AQHTlSAUob9oS1qMyUeJYNzjTrRhzaODLMSAgAAJAIA=
Date: Wed, 24 Jan 2018 16:25:56 +0000
Message-ID: <07A11133-DD81-458D-A0A6-113CBB25FD55@nokia.com>
References: <5D415FD9-1505-4E03-94DA-BF89B52E7770@nokia.com> <CAMfhd9Um-JfOnurKNokiQDfN7XJsn7vJE+mZjsGKmfsoCZ9czg@mail.gmail.com>
In-Reply-To: <CAMfhd9Um-JfOnurKNokiQDfN7XJsn7vJE+mZjsGKmfsoCZ9czg@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.9.0.180116
x-originating-ip: [88.111.107.3]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1SPR8PMB111; 7:NxglY7oAv/yAzz2BEdQfmUpfuvhPpEEI0VR9Rp9Yo8p083MgmJ586jNdIkBB0kawE/mbrjipRLeP1o8+fe8QjULnXR2u7Zwdu6EBg+v60WIYk0OQr521/hB+gHHJMlWGToSkJeLcKLoRJRi9kwdVa7y/9REIwUctzuUiuPwjMyOhjRwIm7AhoUczxSf2ZktOLu/SUf+cFTsuiBvmFVeySu4YwxI5K4ExK4vxmARXp0lF/ScpxOf7uPOk1fHoc49p
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(376002)(366004)(346002)(39380400002)(396003)(51914003)(189003)(199004)(36756003)(97736004)(316002)(6512007)(83716003)(53936002)(86362001)(6346003)(26005)(229853002)(4326008)(6506007)(53546011)(14454004)(6436002)(99286004)(107886003)(76176011)(83506002)(6246003)(3660700001)(25786009)(3280700002)(82746002)(66066001)(5250100002)(102836004)(59450400001)(2950100002)(2900100001)(6916009)(54906003)(33656002)(6116002)(3846002)(81156014)(81166006)(8676002)(2906002)(105586002)(68736007)(6486002)(106356001)(5660300001)(305945005)(478600001)(58126008)(8936002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1SPR8PMB111; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 203199bb-a517-41f9-8a57-08d563472550
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:VI1SPR8PMB111;
x-ms-traffictypediagnostic: VI1SPR8PMB111:
x-microsoft-antispam-prvs: <VI1SPR8PMB111D0AE66534FA51FA1B30780E20@VI1SPR8PMB111.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(82608151540597)(85827821059158);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231046)(11241501184)(806099)(2400081)(944501161)(6055026)(6041288)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1SPR8PMB111; BCL:0; PCL:0; RULEID:; SRVR:VI1SPR8PMB111;
x-forefront-prvs: 056297E276
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com;
x-microsoft-antispam-message-info: ojGJO7OqSas2+94A+XMDrhlMvkQRUp/3xtoxpVVTZVE2dspbKhh6YVGq6zpT0o7Dm05xU4ZNeb+BtNtMst0ewTtF0BsLTU6FLB5c1ZQ7VxduxBW03OUnRv1aJ1/IMaB3
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <1B3C30FB20A97F4683CA43FFBB4EDF91@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 203199bb-a517-41f9-8a57-08d563472550
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 16:25:56.2031 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1SPR8PMB111
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TeX1cxjQq8FdJLCLLREQE8Go9Hs>
Subject: Re: [TLS] extended headers for (D)TLS (and their use with connection-id)
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, 24 Jan 2018 16:26:02 -0000

On 24/01/2018, 15:53, "alangley@gmail.com on behalf of Adam Langley" <alangley@gmail.com on behalf of agl@imperialviolet.org> wrote:
> On Wed, Jan 24, 2018 at 6:31 AM, Fossati, Thomas (Nokia -
> GB/Cambridge, UK) <thomas.fossati@nokia.com> wrote:
> >
> > A few months ago, Nikos (can't remember if on this list or on a side
> > conversation) came up with this thought of a generic way to extend
> > the TLS/DTLS record header.  So, I've stolen his idea and written it
> > up in [1] with the intention of using it to make room for the
> > connection-id.
> 
> Our experience with middleboxes suggests that this is likely to fault
> afoul of many flaws in these products if deployed with TLS on the
> wider internet.

Thanks for the insight.

I have thought a bit about this possibility when doing the write-up and
the "MUST NOT be used during handshake" was meant exactly to minimise
the possible impact of middle-boxes during session establishment.

So, the chances to survive handshake should be the same as usual.

After session establishment, the only thing that might look suspicious
to an on-path box is the invalid length.

Do you think this is likely to cause havoc?  Or, in your experience,
middle-boxes tend to not interfere after the TLS channel is up?

cheers