Re: [TLS] [tls13-spec] resetting the sequence number to zero for each record key. (#379)
Cedric Fournet <fournet@microsoft.com> Thu, 17 December 2015 20:01 UTC
Return-Path: <fournet@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 E998A1B307A for <tls@ietfa.amsl.com>; Thu, 17 Dec 2015 12:01:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 WuE-8lP8dP_a for <tls@ietfa.amsl.com>; Thu, 17 Dec 2015 12:01:50 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0116.outbound.protection.outlook.com [207.46.100.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DF4D1B3067 for <tls@ietf.org>; Thu, 17 Dec 2015 12:01:23 -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=RJ1qwYgEFuyBLyDcj1bJ4UchXFdwsoC/0/wQoVBFiak=; b=U2RTKfjGh3UEZiDP1lsb/V9Fibiu1xZ96txlGxmlbjN+xCUP/s0OYx0lFJEMO2mLjp4VrQN9tMj1M0uJj+DX9o5M6W6xM85dJK1JBpV2GmLQXiTbff99YMeQptRmnWL1ewxS6wAErPCGzzhXGxWIMrZHaY4VEC/RW6oNglKSqwQ=
Received: from BN3PR0301CA0041.namprd03.prod.outlook.com (10.160.180.179) by BN1PR0301MB0724.namprd03.prod.outlook.com (10.160.78.143) with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 17 Dec 2015 20:01:20 +0000
Received: from BL2FFO11FD044.protection.gbl (2a01:111:f400:7c09::113) by BN3PR0301CA0041.outlook.office365.com (2a01:111:e400:4000::51) with Microsoft SMTP Server (TLS) id 15.1.355.16 via Frontend Transport; Thu, 17 Dec 2015 20:01:20 +0000
Authentication-Results: spf=pass (sender IP is 206.191.249.68) smtp.mailfrom=microsoft.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=microsoft.com;
Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.249.68 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.249.68; helo=064-smtp-out.microsoft.com;
Received: from 064-smtp-out.microsoft.com (206.191.249.68) by BL2FFO11FD044.mail.protection.outlook.com (10.173.161.140) with Microsoft SMTP Server (TLS) id 15.1.355.15 via Frontend Transport; Thu, 17 Dec 2015 20:01:18 +0000
Received: from AM3PR30MB049.064d.mgd.msft.net (141.251.48.82) by AM3PR30MB049.064d.mgd.msft.net (141.251.48.82) with Microsoft SMTP Server (TLS) id 15.1.337.9; Thu, 17 Dec 2015 20:01:16 +0000
Received: from AM3PR30MB049.064d.mgd.msft.net ([141.251.48.82]) by AM3PR30MB049.064d.mgd.msft.net ([141.251.48.82]) with mapi id 15.01.0337.009; Thu, 17 Dec 2015 20:01:16 +0000
From: Cedric Fournet <fournet@microsoft.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Re: [tls13-spec] resetting the sequence number to zero for each record key. (#379)
Thread-Index: AdE5BDjhcI4FV8x0QyKuaccyaVLWlA==
Date: Thu, 17 Dec 2015 20:01:16 +0000
Message-ID: <5e85e3b1a1914ea8bbd5d985c321c119@AM3PR30MB049.064d.mgd.msft.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [141.251.50.132]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD044; 1:F6FfL0o9ocKu9QybLFe8BJ5Ab8pTrgLsuC2eI65SwWiUXLKhOTdMJ0pCHNRpSrzfgTc42OWpaKPF22LC0xIs50sVTFeIM6B0X0LMS3Yrr7QYjE9kEe4FoH1Z2uJWkgTYehLr3fY1TMQXpjpyAje0Vroa66EM9dOpTdYgh6PTLJTVN8q+PaR41h+oHiVufEdiC9p+Gqbjfywa4I4D/k/WTZHWiXcaj4NYxp0lUV9hEG9KVfqge6VLOlpxqWTvff1OkW08teaztkYTNpf/vrdOXzdO+3ZVK2xkPDLWbk/2pBniZlb5HazFYlj9Cv8YB5IJr4dG990Q3Iy/cFZB0L3NBg==
X-Forefront-Antispam-Report: CIP:206.191.249.68; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(189002)(24736003)(16796002)(4001430100002)(6806005)(2501003)(92566002)(54356999)(87936001)(15975445007)(47776003)(1220700001)(6116002)(3846002)(66066001)(1730700002)(102836003)(86146001)(1096002)(189998001)(10400500002)(11100500001)(26826002)(33646002)(107886002)(5005710100001)(106466001)(81156007)(5008740100001)(50986999)(97736004)(5001960100002)(561944003)(5003600100002)(110136002)(5004730100002)(108616004)(10290500002)(86612001)(586003)(23746002)(69596002)(2351001)(10090500001)(19580395003)(50466002)(86362001)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR0301MB0724; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; PTR:ErrorRetry; A:1; MX:1; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; BN1PR0301MB0724; 2:AApIYWDE4UtUR/jDj1kDr5VFgPC12woqFRYGv2gm8cdS2KLbc0VbEAqT4COB7BRnytRwypH5IIwrVfL0/ha5rllmy0IYQrzNvD5lZROM1t1JkJ2uBu26U/CQgewU7vUqRfl5AvQ3jcYvEPgqp7LxFw==; 3:pcmwGbnvmxXX43QphJ+GnrSPRlgdD6QY6qMhZ30EivlHD9auOidqA3t7hqba6AtAfrtErcunQkmUH48OriPpkWoLe4MCeJREzZdDYkUkvGE+BZvhfmzBmZRHYD7Lo5iBk2lrm2nAchpiqda6L42iUTv+Xk6mgTv8+8AAPp7iPHIoTDAExquDCPhK0XZus6btKLYZ87pXG1HgvQFBAHsg/izPsaiKHc01eNkrwvcMFPR+zajD4ziLtA/Vb9P05NCH1lJVs3wBeMcW5hbhdcadCg==; 25:hBiom5UtbZuMfjgLCGXQVpFdrGFblHahZ6O8KD77wKnBxzfVpyBe904WitRFM15QSwhTmbbJNPq/Ckm6aOgqzxb7Y+z/bhJzr+KJeHNlvZY+sbDhMjNVmF2Y3RJccGdchpHTcJtdE4tDQsLJboTXufK80bW8O0qXzDQP+P7hGfiT9nHB/7Xv4SMch1P8yBY95OpJD4vYPyvUa8VDDkEcnIB2t6XCC4+ODGce1Ql0blq//lcU8ZB/5X82UNWKAw1yuZZS6zaGhJQoyRLcb5JrV7jSR4U2k4w1i/OqppSb2SE=
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501001); SRVR:BN1PR0301MB0724;
X-O365EOP-Header: O365_EOP: Allow for Unauthenticated Relay
X-Microsoft-Exchange-Diagnostics: 1; BN1PR0301MB0724; 20:je9osmWp9LI78Xqv+jLS6mZCNY2CUxmKm1Y6BpOJwX79Wc2KOt4lGiwAYvofZvHB9DxSNjwBF3HwGOujggNvsAmlvOkONHQAFHeV3dU+WECWGW6WoPVv4XiywOT1MQKrTBOODwCst50Xta5e3YJkMsYjpH9ybKFes5POWzPNy4TVKWHWAhoZrT3N9BXf0FaoGcg1EY93S2OqfJtua9d9+K3q0EPihCnhpxfwtXIXYSvF1fq4RlhYhbPPE4tyy5eHlJs5FnMKRIdCV7ix7nqurGx71Q9nOBYQ7XCIXxtHdldGHdZ7H0J3HEUQCscbwObMRuVrfSCeCj/3zj6d0a/OACp7UTl4AN3l3yNbKfM6OdaFnqVVvOuD0r+MbPQHOIVAurKRc90By/Hzk2hvjBEZEMutaTa0N4uhEX2vxEB5aJzsxFQfmgsucu+Eh+e/OKMP1tM5AaiK8uqQHblG6bOTMWqcfGauA3EBjCp04vrOb2orGyulGZ8UDHQki1Dadg2IiBrUfDR6iKYMpOT16HV7H/IJKN0U7zw75WKfqc9JdMvZZbEnJd+6pQQ003G/KWEjZ/XSwUOq4R7w2J7Msqhnm9s3JM2lXm8KtDpGjObLlEQ=
X-Microsoft-Antispam-PRVS: <BN1PR0301MB0724B8D1ED93A893E8EB4147B0E00@BN1PR0301MB0724.namprd03.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BN1PR0301MB0724; BCL:0; PCL:0; RULEID:; SRVR:BN1PR0301MB0724;
X-Microsoft-Exchange-Diagnostics: 1; BN1PR0301MB0724; 4:I5YiB3NLkwYn5Q0Dfc74ZZ/8xcKBBDHvihtIS44UGBhzkN1a73Gzn4mMauJL04091bfPi1MlwKEdSb4aC+EnKek4SiMXuf87v1stsJJxQ2BigmMaiXpgQUPI9twHSix3mAIaSQBio/nEIHNGI45Ck5c5TeBJBvXAAMBCQAEgvt9pyl3G63EyoFjHHlqeUCASRueZsI2YcI8W/+X6H88lUshvRJXht3+8xuQ/bFbIm0/ByQXi2Y8DFAMzuFIHeALWwir/ZVvvlbyegz6WQl0tAXjn+oOtlNd2claqMW1jV3mk8tIaStrdDQVu6BecVE8Mzb6NLOhtVNKScMJBVUUZUQdr+bycS+HbCao5Nbm+wk2aqgdrrT3L+dswc/HAD9ZV/ixnn4Dcg50bm6CI2w5blVxZad9mTNPs7iMIf2j1E6m7JZLFmaznj5iMXqqozMuC
X-Forefront-PRVS: 07935ACF08
X-Microsoft-Exchange-Diagnostics: 1; BN1PR0301MB0724; 23:omrYoacUNjAvpN4hLaz7+cWTK8DBwZ2TcWRUCHTdp8pNj7b6z3I1BKJwMg3SbUdyPviWioPXFXRcKtRBfTTAuMJFlWLmwVQO2z5SVmV831xEwp/cVhXaTNQ6KtMsQPSBQOgLOwJOpoiDIvX8G9pgidNVCQfr6SOv6YS2YFuLvq/PEU4Q/97F8OamjZvF7/qkbfxnId2sbPEBFyB1DojRfvH1ZpMR1+FsH0iFhb9ZFSb1CA7tPc61EuBnCwxjw6zZI+z3JwbqT/G5BICPH76lAjDJqtrn/VIj+Iu6cMtYbt97dx196FKfbOuvhgAble/KA+znpyNtNTylsfOXBpy0l7ojCd1v8TciPcHSf0cJaIaQlh/2Z3LL38I3UbDCxUam9aS4PZ5sKGFb48I1l5ODh+LuI3tORrnDRSfjhP8eNBs38oY3EoJJ2rgujhun7CtE5T6ZrfbYDa9xhOjkAva64geu9RQ6x6A9JFDMJRO99+Wg6SBh6896dJevJc3tEhyVpOJFGuqRJIlgmq0Cyx7DoRCza4Fre9zCoraLtiS5qzktFQ7wWDg2ZBeqD0YQS6EC80gDhs24C0L+K3oCc2q2rSjH5xH9sYGhWITtsN8aPqRhgBGoXHkVF4jdUWW6ZtODZBZph9CYPepC9bwWWupngllcGnckU7IWwsJTEWtHuOSNXQRmT4c/OpJqZjjbfEfyyuOci27riEx0a/vGuhUK5A1BoiHZ6UvRRc307pb2P+S3bW/6IyBee3lb82FpdUffS/WfatovQ3UTa0m2ltzqQOWl3EI15v5ssCgDzk0vIikpphVoBBeG6GkqHQv5jzBwpNtjBt/LAP+VUde18GbGf5vm+p9+5NrsJx8Q/ZCNpgGt1dipTkLEAMVu9CFY/4GigHRfuHthJOPv80XG9ZOF2kb8DYZvyQGgUsz3VIDLwmwm5PmAxNy6LNeD4UCI/ZECeMem/b/1SnP5WPuWFJesqmu4LQGekg4/UMbOMmRGIU0hemXCOcEo68/STh44irqxikxrw+BkkLoUAbMzK5SR37Gkx9P/2Bpx4qpyaeEOT/CsQD77cIVTFcROXhfdbxQtUOXwrM8V3TDCYi7n3hCPFUYX5404Z29P2PeeQerl/deGrsnxn/uYAo71ADIH8fYyj2gLng7albIokd1M0vPjUWVmhG+Za6FsIzVp12jrS1eiEcj4BC8xgrLJjlMhW3kEU9C5jqPkHLRXQCupcH8BtJMbW4EI/kOEuaXVVrb4u5lb2BsI9sNQQIgTBTAJTwJPJZRv+fwFeI41kRH3vFQP2tCff6u31i/YfMDc6VTKHVLHjVapcIdqAmpQA7WBh3cC4MkQGGTOjW8Zv3FjuuOvpQ==
X-Microsoft-Exchange-Diagnostics: 1; BN1PR0301MB0724; 5:rLewX4gOlVvFYqFbuICzKDtfzPSPr6KZUeCSGi7PKwURDzapl/8NwupOqlHUWku3h5+BonN4MbB77vBEbQSEB5tGESixCzRVNUopJDqHCvGdBEDAUvJKPhL1GVZQQvNDQEvZBte2Kgfxd6bKagFikg==; 24:u7NqWBGREd2a5lpXXFbhXpGDDnESJW1eYBx34kXQ/HXpbgFJY9BApkxL1swqlFI/HhBt4tr4lFWOIu1Yn7ekCoZmr1P/gi7F7+9eMxzu4S4=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2015 20:01:18.1516 (UTC)
X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.249.68]; Helo=[064-smtp-out.microsoft.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR0301MB0724
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/extoO9ETJLnEm3MRDTO23x70DFM>
Cc: Antoine Delignat-Lavaud <antdl@microsoft.com>, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
Subject: Re: [TLS] [tls13-spec] resetting the sequence number to zero for each record key. (#379)
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: Thu, 17 Dec 2015 20:01:56 -0000
As explained below, we propose that the record-layer sequence numbers be reset to 0 whenever new keys are installed (as in TLS 1.2): https://github.com/tlswg/tls13-spec/pull/379 Cédric Fournet, on behalf of the miTLS team. While working on a formal model of the TLS 1.3 record layer, I bumped into a new weakness due to the chaining of sequence numbers between epochs. In the current draft, the sequence number is not reset when a new key is installed. This is a new mechanism we suggested a while ago: the intent was to prevent suffix truncations of traffic encrypted with the old key by making the first decryption with the new key fail. This mechanism prevents suffix truncations when *both* keys are secure, but it introduces a new weakness when the old key is compromised and the new key is secure. Then, the attacker gains the ability to delete the first few fragments encrypted with the new key, which we think is not acceptable. This is problematic when switching from the 0RTT keys to the handshake keys, then to the application keys, as the whole point of the TLS 1.3 key schedule is to gradually establish stronger keys. We discuss below some of the complications it may cause. PREFIX TRUNCATION: HANDSHAKE ---> APPLICATION This weakness in the transition from the handshake key to the application data key may be exploited as follows: * The client and server complete a 1-RTT handshake, and some implementation bug causes the handshake key to be leaked. * The attacker may play with handshake message fragmentation to artificially increase the sequence number on either side of the channel. The handshake data remains untouched, so the handshake can still be successful. * When the client and server start exchanging application data (using the new, secure key), the attacker can remove as many fragments as he added to truncate application data in both directions! PREFIX TRUNCATION: 0RTT ---> HANDSHAKE A variant may also occurs during the change from the 0-RTT key to the handshake key: * The client first sends 0RTT-encrypted fragments, then handshake-encrypted fragments. * The attacker breaks the 0RTT key, and rewrites 0RTT traffic to insert additional fragments, for instance by fragmenting the 0RTT payload into several fragments. For each additional fragment with the old key, it also deletes a fragment encrypted with the new key, and then forwards the rest of the client traffic unchanged. * The server's sequence number is higher than the client's when it changes key, but nonetheless the server successfully decrypt all received fragments. Similarly, if the server refuses 0RTT but continues the handshake, it is unclear which sequence number the client should use for encrypting handshake traffic. If the client continues with the 0RTT sequence number, then the only way for the server to decrypt the handshake traffic is to count how many 0RTT fragments it discards---and this can be controlled by the attacker, even without breaking the 0RTT key! Although prefix truncations will probably cause the handshake to fail, this complicates the analysis of the record layer, whose security now depends on the details of the handshake protocol. There are also corner cases; for instance, assuming alerts are protected using the current keys (as they are in TLS 1.2), it may be possible to silently delete a warning from the client to the server, or to truncate half of the client certificate and observe whether the second half starts with a well-formed alert fragment. OUR PROPOSAL. In the current draft, the ends of encrypted traffic have now all be made explicit (using end_of_early_data; Finished; and close_notify), so there is no apparent need to chain sequence numbers. We propose to revert this change (that is, to reset the sequence number each time a new key is installed, as in TLS 1.2). If the chaining is still required for some other reason, one could instead include the old sequence number in the new key derivation (or the new key's additional data, but we believe this is no longer an option).
- Re: [TLS] [tls13-spec] resetting the sequence num… Cedric Fournet
- Re: [TLS] [tls13-spec] resetting the sequence num… Martin Thomson
- Re: [TLS] [tls13-spec] resetting the sequence num… Cedric Fournet
- Re: [TLS] [tls13-spec] resetting the sequence num… Eric Rescorla