Re: [TLS] Possible deadlock when ACKing KeyUpdate messages?

Hannes Tschofenig <Hannes.Tschofenig@arm.com> Mon, 30 March 2020 10:57 UTC

Return-Path: <Hannes.Tschofenig@arm.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 BEE853A134D for <tls@ietfa.amsl.com>; Mon, 30 Mar 2020 03:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=roTR56C1; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=roTR56C1
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 A5Zq0sanofsL for <tls@ietfa.amsl.com>; Mon, 30 Mar 2020 03:57:23 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130078.outbound.protection.outlook.com [40.107.13.78]) (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 9E92C3A134C for <tls@ietf.org>; Mon, 30 Mar 2020 03:57:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cSOzB1Q8Qwm/Iy6nzpyiFRkkLnhoM2c3GVKlbdnIJ1M=; b=roTR56C1zVe3UxWQUznAidYxl8FfIJzr6/72A2bBCFXye30SQ+8maI9hlMVbi4OeJbUd0TGFLhVYuXBNW/6B12NmsjApAxDQ0jo/UfGQa9Hsq3h3VIB/nA/KrDV/jhHwefIyhkbsz7eofb3n0jQDh015AZypcshfVP8C7qaneOE=
Received: from AM7PR03CA0002.eurprd03.prod.outlook.com (2603:10a6:20b:130::12) by VI1PR08MB3456.eurprd08.prod.outlook.com (2603:10a6:803:7e::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Mon, 30 Mar 2020 10:57:18 +0000
Received: from AM5EUR03FT033.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:130:cafe::2b) by AM7PR03CA0002.outlook.office365.com (2603:10a6:20b:130::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.18 via Frontend Transport; Mon, 30 Mar 2020 10:57:18 +0000
Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com;
Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT033.mail.protection.outlook.com (10.152.16.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Mon, 30 Mar 2020 10:57:18 +0000
Received: ("Tessian outbound 6835489d965f:v48"); Mon, 30 Mar 2020 10:57:18 +0000
X-CR-MTA-TID: 64aa7808
Received: from 6439813e38fa.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id B33842D2-71D1-4289-81E7-E233A7B8D329.1; Mon, 30 Mar 2020 10:57:13 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 6439813e38fa.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 30 Mar 2020 10:57:13 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OAU6xNin4lYcPwHQjUzfE7R70s1KlTu1/tQSbDiATqVQ7ypnsZmuRD892AYVbawAwqqt0cUbFt/gdetFH5BtSP4vsGRupXMErgVTS18KuULbKF0Yutfsop7j+dlCuL3all7s8m1cQ8CmjIYXQGsiiFtiifeAt4BmnC50mkT8PpDpz9FzXbiMA3sTd162jPgiSi2fnTR7WFPrmq5x7EyppO6W2xm8jXoFJgpao20J0R989mIWetobFdkgjZ2elwLoe1qhsniDEvdBhyEzFb3gagtTforgGZk4+Flvn+QeJ14YcH7kxQMbb59rtrd3NMUTQTkY44le3HSCwZJGOJRqaA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cSOzB1Q8Qwm/Iy6nzpyiFRkkLnhoM2c3GVKlbdnIJ1M=; b=N/Pj1UrMnkr/YHXW4HWQj+7jJWMltRZIgecGX5a36iDhYBqz1DLv3iyfVtUXxeoc5GWWcGp+eE6YLZd/uCo0J9y/fUeozOd5wKrKkoRCGl76f7IlL729PmD4QM9fjtVdptOz6K1qde7vd2vruwj1Nwaqm1ZLTxYt+Mmg57Z+a+NYop3ApC5sOnaiK+zOZ+9DfHOJRBe52kSZXuBm1ukzUtOKEADiU6e493Q2UFzEgVdTRjYqwiPlJsbZw25zuWRCn7L/Fsv9emoa8kUfeYT4bLzYtcjORn1An4CL3ZFhkXM4bJLKS1cIfkNLW/cT4NujEeIN6o66cJGnNh47Ln9jxA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=cSOzB1Q8Qwm/Iy6nzpyiFRkkLnhoM2c3GVKlbdnIJ1M=; b=roTR56C1zVe3UxWQUznAidYxl8FfIJzr6/72A2bBCFXye30SQ+8maI9hlMVbi4OeJbUd0TGFLhVYuXBNW/6B12NmsjApAxDQ0jo/UfGQa9Hsq3h3VIB/nA/KrDV/jhHwefIyhkbsz7eofb3n0jQDh015AZypcshfVP8C7qaneOE=
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (20.178.23.205) by AM0PR08MB4484.eurprd08.prod.outlook.com (20.179.32.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Mon, 30 Mar 2020 10:57:06 +0000
Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2856.019; Mon, 30 Mar 2020 10:57:06 +0000
From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
To: Hanno Becker <Hanno.Becker@arm.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Possible deadlock when ACKing KeyUpdate messages?
Thread-Index: AQHWBUxJ8anoCpmsBUC57Xe/3C4BZ6hg8CNg
Date: Mon, 30 Mar 2020 10:57:06 +0000
Message-ID: <AM0PR08MB3716FDD9BA467A7D597DD689FACB0@AM0PR08MB3716.eurprd08.prod.outlook.com>
References: <AM6PR08MB3318966B8BEE7B818D6AB0409BCD0@AM6PR08MB3318.eurprd08.prod.outlook.com>
In-Reply-To: <AM6PR08MB3318966B8BEE7B818D6AB0409BCD0@AM6PR08MB3318.eurprd08.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ts-tracking-id: 2d7c926e-ed06-4a49-8f7e-7cd25d9d9712.0
x-checkrecipientchecked: true
Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
x-originating-ip: [80.92.116.70]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 361d3d69-5092-4c95-131b-08d7d4991d92
x-ms-traffictypediagnostic: AM0PR08MB4484:|AM0PR08MB4484:|VI1PR08MB3456:
x-ms-exchange-transport-forked: True
X-Microsoft-Antispam-PRVS: <VI1PR08MB3456D6659E77D2F6E1C9C8E1FACB0@VI1PR08MB3456.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 0358535363
X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(39860400002)(346002)(376002)(136003)(366004)(5660300002)(7696005)(186003)(81166006)(9686003)(8676002)(2906002)(71200400001)(86362001)(6506007)(53546011)(66446008)(110136005)(66556008)(76116006)(66476007)(64756008)(316002)(478600001)(66946007)(55016002)(81156014)(8936002)(15650500001)(33656002)(26005)(52536014); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam-Untrusted: BCL:0;
X-Microsoft-Antispam-Message-Info-Original: N4RB2SdDNgfiZEYikjJ8jzaul9HZhSKSFmpaIG8OQSI2ZzFoiiwOfbb4YF3u3rHIaj+PW2/nc4PxRMiLAcHzFwT2DsXla+VcCVM+RP9AQ+11gfQWOqU7x8ZdmYjHYiyY28ufjPSRDI97x6OET9wVbSGqEduitL1/6zsffx3RSaiWuwV1oRwG0LGf84oAfXF1ri0hojTF45x2xP0Xa7+SigjGSGXdURCE7Gf7BD2X03yzg2oyarOuhkjvamzSUt2+REgwJiMeSf9pnzTomIkSCL+9osgEoD2CJWhk5w38FFUC4UPAxnWAJKAi2jB8R9T/oHFMzYNfRC5CWi20QvAP09YazHxUeTMofv1GWAjSeqhovxaNY/mW/ASr9YpQ5WTfzqYC33TAFmtMkpsFvNmEcin7Dl2UGPQLDBAxdlwvLudiVL6pxLdW2KhG6VNPaFEx
x-ms-exchange-antispam-messagedata: BtRw3jVVQ0XLcAeERnd1HMeAlJDDiYJNJR7MqlUChoTu9cZJn4jpO0q5qeQfIe1d0qrTLQYW7yzHRWIHxBGz19RnoeZ2zTBAVJxed8wqDvaU/AMS4zFVMCTVIk9pg6Y/8rgCQGiCPc82N3epM3ZXOQ==
Content-Type: multipart/alternative; boundary="_000_AM0PR08MB3716FDD9BA467A7D597DD689FACB0AM0PR08MB3716eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4484
Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT033.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(136003)(39860400002)(346002)(376002)(46966005)(52536014)(5660300002)(70586007)(70206006)(2906002)(336012)(26005)(316002)(15650500001)(186003)(33656002)(110136005)(55016002)(8936002)(36906005)(26826003)(8676002)(478600001)(356004)(81156014)(81166006)(6506007)(82740400003)(53546011)(47076004)(86362001)(7696005)(9686003); DIR:OUT; SFP:1101;
X-MS-Office365-Filtering-Correlation-Id-Prvs: 779e5bb0-484c-455b-130f-08d7d499166d
X-Forefront-PRVS: 0358535363
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: iKown/y3Q5deCXS7c9TVrWJYIwme+8FUq4Ple55BCIKcTKzJOUQuJXQ1eNVfcVF8P4ab/h1Y6yTMczXehBm3mW3sAlTcjRbtUMWkCspqlJ1N8fHOsvjDicE1wTO4E0gyuW5gcMZkR/ZzjMnGyGQ4UDbbG0T+2KlM/5DS7BbGkUQ1hGKY6kQ5xu6+tp7yUgbA/Xv6OfLUj23jjdcStoH+dMNisS6hgI5lxflyQFhqG65TczmXzExqx3InJZQQ91dVse63PE1uVYo7Sx09IuqEqlu9o54fHLZz0wAadYxusarMH2qOHU6DsJCWzdBFCAlCHwtArxPNt9mN6JbbVBOJoD/qC6EUOIJ1wEGpl7oifqLpsCikJTDtX/nbRrz4ve5PZiB48nN6RQuX/hf0l+7gxHaWff432PPUK0rm/zEC8O432gCywHpqKAaHP6IQaRw+aWfC9XoDJ5zQaNj3tERe0HANUNuEQUEvaRgrvvjNrb4IbZ/gl8B3kKSaGYn8clXjUe4Pz9knYNEgO0i2vlQZeQ==
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2020 10:57:18.6821 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 361d3d69-5092-4c95-131b-08d7d4991d92
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB3456
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/REcft9GmQqec_RHYr9xmH4pnNQ0>
Subject: Re: [TLS] Possible deadlock when ACKing KeyUpdate messages?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 30 Mar 2020 10:57:26 -0000

Hi Hanno, Hi all,

I believe it would be useful to add some extra sentences to the draft to retaining the old key material.

In your example below, the sender of the initial KeyUpdate has to re-send it because of the lost ACK. In order to resubmit it, it has to use the old keying material (or cache the message). The receiver cannot immediately delete keying material after processing the initial KeyUpdate message because it does not know whether the ACK will subsequently get lost.

Ciao
Hannes

From: TLS <tls-bounces@ietf.org> On Behalf Of Hanno Becker
Sent: Saturday, March 28, 2020 11:31 PM
To: tls@ietf.org
Subject: [TLS] Possible deadlock when ACKing KeyUpdate messages?

In relation to ACKs for KeyUpdate messages, DTLS 1.3 Draft 37 states:

   Although KeyUpdate MUST be acknowledged, it is possible for the ACK
   to be lost, in which case the sender of the KeyUpdate will retransmit
   it.  Implementations MUST retain the ability to ACK the KeyUpdate for
   up to 2MSL.  It is RECOMMENDED that they do so by retaining the pre-
   update keying material, but they MAY do so by responding to messages
   which appear to be out-of-epoch with a canned ACK message; in this
   case, implementations SHOULD rate limit how often they send such
   ACKs.

This seems to allow implementations to remove old incoming keys immediately
after ACKing the KeyUpdate, which appears to open the door for the following
situation leading to deadlock:


  +-------------------------+
  |   KeyUpdate, epoch N    |-------------> received
  +-------------------------+
                                          +------------------------+
                               lost x-----|     ACK,   epoch M     |
                                          +------------------------+

                                          [ new incoming epoch N+1,
                                            remove keys for epoch N ]

-                                         +------------------------+
                  received  <-------------|   KeyUpdate, epoch M   |
                                          +------------------------+
  +-------------------------+
  |       ACK, epoch N      |-------[ irrelevant whether it goes through - see below ]
  +-------------------------+

  [ new incoming epoch M+1,
    remove keys for epoch M ]

Note: This isn't an entirely unlikely situation, since a KeyUpdate with update_requested flag
will result in a subsequent KeyUpdate from the other side, and the only unlucky thing that
needs to happen is for the original ACK to be lost while both KeyUpdate messages go through.

At this point, both sides have updated their incoming key material but
not their outgoing key material, since they're still awaiting the ACK -
however, it turns out that they can't actually read those ACKs anymore:

After some time, the peers resend the KeyUpdate messages, which will be
blindly ACKed by the peer according to the recommendation in the spec;
however, the ACKs will be encrypted with the wrong keys and cannot
be parsed on either side:

  +---------------------------+
  | resent KeyUpdate, epoch N |-------------> received, but can't be read
  +---------------------------+               because incoming epoch N+1

                                                send 'blind' ACK

  received, but can't be read                +------------------------+
  because incoming epoch M+1  <--------------|     ACK,   epoch M     |
                                             +------------------------+

The same will happen to KeyUpdate retransmission from the other side.

It seems that this results in a deadlock. Am I missing / misunderstanding something?

A possible mitigation would be to force retaining the old key material for 2MSL,
or alternatively, to mandate that old key material must only be removed upon
receipt and successful decryption of a message using the new keys.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.