IETF Logo Mail Archive

[TLS] Application data during renegotiation handshake

Mike Bishop <Michael.Bishop@microsoft.com> Wed, 11 November 2015 18:40 UTC

Return-Path: <Michael.Bishop@microsoft.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EF61B37D7 for <tls@ietfa.amsl.com>; Wed, 11 Nov 2015 10:40:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 sxtZ3gGjlQx8 for <tls@ietfa.amsl.com>; Wed, 11 Nov 2015 10:40:13 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0784.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:784]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A73C1B37DA for <tls@ietf.org>; Wed, 11 Nov 2015 10:40:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0h4g3axNBIziwFa/MjjpAbXzIz9PZYbp6MBgbiVmY6k=; b=Mr0Bf5vk9+Sfg/aATIRHTqn+AH9UuZY74/cXXl+9rlEsgvPNP6Wg413XobcK/e1kyvpm3uvCjw5roPwr5REpMHrmVuenXt2VhCSN8ryLxqCzobB5efRi5iEMK88aN6dHXWhhwZx2P05OTvqfLvauEQqkvcexBSzoRu8L0QGJ1Xc=
Received: from CY1PR03MB1374.namprd03.prod.outlook.com (10.163.16.28) by CY1PR03MB1374.namprd03.prod.outlook.com (10.163.16.28) with Microsoft SMTP Server (TLS) id 15.1.318.15; Wed, 11 Nov 2015 18:39:51 +0000
Received: from CY1PR03MB1374.namprd03.prod.outlook.com ([10.163.16.28]) by CY1PR03MB1374.namprd03.prod.outlook.com ([10.163.16.28]) with mapi id 15.01.0318.003; Wed, 11 Nov 2015 18:39:51 +0000
From: Mike Bishop <Michael.Bishop@microsoft.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Application data during renegotiation handshake
Thread-Index: AdEcrQnuroKmbT4dRXSQtSnp2IGJXA==
Date: Wed, 11 Nov 2015 18:39:51 +0000
Message-ID: <CY1PR03MB13743E3AE466C2F8F7AC140687130@CY1PR03MB1374.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com;
x-originating-ip: [2601:600:8300:3b9a:cc6d:4a41:90f:dfb2]
x-microsoft-exchange-diagnostics: 1; CY1PR03MB1374; 5:8j/YiJvN0fxF+R1fKIP2kerKshslYwznJLskkf2glzNNPYjSFzzLxeE3BJ3lvSd8ROO+GFZFsa28PvvU3IW0sf5PSfQkHl3JXBrVobFlZUwpkDoMzyHMb1Quo1UwWmsXqsK6tMOwHfJRoHdAlmkEKw==; 24:SFft+n6q3aH4dBXDtayKEzN1mAF81k14E5S2rHXnbOD4276tvGAS30dBA5vFPvTt08FTb98MeBWTO7i/BoX+k+47+LbJ11Gr4B88NNv1Jhs=; 20:+8cYRobG2EenszxLh1OoDvR8sW5w8TMSdGRcHilVP5993V/QLhKSrm9bf07klFytTHmW/C8ad9Fg7QV9gTFC0w==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB1374;
x-microsoft-antispam-prvs: <CY1PR03MB1374259DAD9839F8C3D8BF2387130@CY1PR03MB1374.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(108003899814671);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001)(61426024)(61427024); SRVR:CY1PR03MB1374; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB1374;
x-forefront-prvs: 0757EEBDCA
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(92566002)(19625215002)(105586002)(5008740100001)(77096005)(54356999)(101416001)(16236675004)(19300405004)(50986999)(99286002)(87936001)(86362001)(33656002)(19617315012)(74316001)(2351001)(229853001)(86612001)(5007970100001)(189998001)(10290500002)(106356001)(5002640100001)(76576001)(2900100001)(102836002)(19580395003)(5003600100002)(97736004)(81156007)(5004730100002)(8990500004)(2501003)(5001920100001)(107886002)(15975445007)(40100003)(110136002)(5001960100002)(11100500001)(10400500002)(5005710100001)(122556002)(10090500001)(450100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB1374; H:CY1PR03MB1374.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY1PR03MB13743E3AE466C2F8F7AC140687130CY1PR03MB1374namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2015 18:39:51.3396 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB1374
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/QtmRgtoJDOCgPwvH9qYUEmfyQ3U>
X-Mailman-Approved-At: Wed, 11 Nov 2015 17:00:21 -0800
Subject: [TLS] Application data during renegotiation handshake
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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, 11 Nov 2015 18:40:16 -0000

A question for TLS implementation owners:  During the discussion of the TLS 1.2 portion of https://tools.ietf.org/html/draft-thomson-http2-client-certs-00, it was pointed out that HTTP/2 breaks a simplification of the HTTP-TLS interface that some implementations may have assumed.

Since HTTP/1.1 only has one request per connection and that request is waiting on the client certificate to be retrieved via renegotiation, you can assume that the client will not send any application data between the new ClientHello and sending the Finished message.  ("...it is expected that the negotiation will begin before no more than a few records are received from the client.")  Likewise, the server will not emit any application data between sending the HelloRequest and sending its own Finished message.  Since HTTP/2 will have other requests being generated and served in parallel, this is no longer the case.  Per the TLS 1.2 spec, that's permitted, but if it's not been done before, I'm afraid we may be hitting less-tested code paths.

I know that BoringSSL<https://www.imperialviolet.org/2015/10/17/boringssl.html> explicitly requires that application data flow be stopped during renegotiation.  If the HTTP working group adopts this draft, do the owners of other TLS implementations expect this to require changes in their TLS 1.2 implementations?

v2.23.0 | Report a Bug | By Email