Return-Path: 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 0BCC13A1F4A for ; Tue, 31 Mar 2020 03:10:50 -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=2dAW2xji; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=2dAW2xji 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 2E-a2grHp2Yn for ; Tue, 31 Mar 2020 03:10:47 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60049.outbound.protection.outlook.com [40.107.6.49]) (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 541E93A1F47 for ; Tue, 31 Mar 2020 03:10:46 -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=REbfhx39YMdZkqHPDFGKPqAaSTtKxR42tsOEAEqUAZs=; b=2dAW2xjiyH6Ljbsen5oYYzkq9EAX51Krl8LgnQm0HMwL/aW6Kpi6dwTWV6XZ/Ns8+bXUtMXVhdT8xDA0641BzY0qw33+X3p1I8Gf812fC7W+Cg3u4hAZB/YIRn4QETQR+ifJMR2E29AfPuneLqxuYHYxFOqBcLR6k8BRdky4yso= Received: from DB7PR03CA0080.eurprd03.prod.outlook.com (2603:10a6:10:72::21) by AM0PR08MB4163.eurprd08.prod.outlook.com (2603:10a6:208:12e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Tue, 31 Mar 2020 10:10:43 +0000 Received: from DB5EUR03FT060.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:72:cafe::b1) by DB7PR03CA0080.outlook.office365.com (2603:10a6:10:72::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Tue, 31 Mar 2020 10:10:41 +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 DB5EUR03FT060.mail.protection.outlook.com (10.152.21.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Tue, 31 Mar 2020 10:10:41 +0000 Received: ("Tessian outbound 55454527ea3b:v50"); Tue, 31 Mar 2020 10:10:41 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 9255e446b8d0e6dd X-CR-MTA-TID: 64aa7808 Received: from 3332c36c1a19.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A70C3E4A-5770-44D3-9CE8-3CC2E94C5B9F.1; Tue, 31 Mar 2020 10:10:35 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 3332c36c1a19.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 31 Mar 2020 10:10:35 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Qi+XTuwDhJJTmoGgcyygriip5JwavApswGZn8g7C+2aGwz6AWaFzOcYqU3c6UmAjdB567QRwqzQ51K6s7e8eA8Bjkm1vwGjmq3IZ0iELqKzSYyBtOQnpWkiQV9XENJBxNPgy4oPLBw51jCKX1FNRgtfevjRmSLqqmh8Yx9URrbaPJCcx5lGBXafWQlp/1M8m/omyYNx9206krcAW97Fp2hNbdwotcuTY7f9peNodSMSXgJ/DP4yHioDccDFuUoSAIkSP01NAn3v7m7ZXtx++ey7rYFyY3JsAvl0/Vc/uedj/M/C9g7AZFxt7xmJAb0himoEZYopoZSWMKd8exUoijA== 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=REbfhx39YMdZkqHPDFGKPqAaSTtKxR42tsOEAEqUAZs=; b=HS4qv6ErOAOl/ssydmxCGLMcnwzCaFu+INL21H2XlR7UxpiwgmrvDKyKySrJl6MIS65CdWADn9kOC0KExcLBoc3k7tstFCvpUl/53WVyTbRAk26ja4EhD2OPvm8thMsgbX6EZkvbTa7ysQ2pbtaaVk2o/KkJgoqe1hbqOqYTRRbEo9CHt57eqEBLc5PWyOgxFwWXGZqQIXk7pL/Wwgd7PkC/KzOiiemcvmGND65XiEVLgcoBV2/sIdyTjc+oIKQihm7cjruwacUtRWjzYRSS/HMNqIEL/xAzJWQAeTOrWEPEymXeXQWB5aInR2/v256aIjUUIm1qygnnUFvvHRBLBQ== 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=REbfhx39YMdZkqHPDFGKPqAaSTtKxR42tsOEAEqUAZs=; b=2dAW2xjiyH6Ljbsen5oYYzkq9EAX51Krl8LgnQm0HMwL/aW6Kpi6dwTWV6XZ/Ns8+bXUtMXVhdT8xDA0641BzY0qw33+X3p1I8Gf812fC7W+Cg3u4hAZB/YIRn4QETQR+ifJMR2E29AfPuneLqxuYHYxFOqBcLR6k8BRdky4yso= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (52.135.163.143) by AM6PR08MB5029.eurprd08.prod.outlook.com (10.255.121.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.18; Tue, 31 Mar 2020 10:10:34 +0000 Received: from AM6PR08MB3318.eurprd08.prod.outlook.com ([fe80::1579:b7d9:f543:200d]) by AM6PR08MB3318.eurprd08.prod.outlook.com ([fe80::1579:b7d9:f543:200d%5]) with mapi id 15.20.2856.019; Tue, 31 Mar 2020 10:10:34 +0000 From: Hanno Becker To: Hannes Tschofenig , "tls@ietf.org" Thread-Topic: [TLS] Possible deadlock when ACKing KeyUpdate messages? Thread-Index: AQHWBUxJ8anoCpmsBUC57Xe/3C4BZ6hg8CNggAB+9VqAANAfcIAAPaCG Date: Tue, 31 Mar 2020 10:10:34 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; x-originating-ip: [217.140.99.251] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 559475c0-0283-4c94-7fd6-08d7d55bc4ae x-ms-traffictypediagnostic: AM6PR08MB5029:|AM6PR08MB5029:|AM0PR08MB4163: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0359162B6D X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB3318.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(376002)(346002)(136003)(39860400002)(366004)(186003)(19627235002)(86362001)(71200400001)(316002)(110136005)(55016002)(81166006)(8676002)(8936002)(9686003)(81156014)(19627405001)(7696005)(15650500001)(26005)(64756008)(66476007)(66446008)(5660300002)(66556008)(53546011)(478600001)(66946007)(2906002)(33656002)(52536014)(966005)(76116006)(6506007); 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: /BnR145idFSgrAK/rib1BmW1S7RlqeuRk4prc/WUKVvtGcy94kxVrJ9+R9NiN/tZkUOod8geIn7GzlmdWQz7XJRlVRfbhce8zkz9vM8dZAzTL9dn+D5/VfkHDZl4nxbXEuKcs2CzkLSDPbsf+TZW7xt7jEcxfwf2abb/glycdKmKaYQPGOD6Ple3TzsOu6V5dIr+voeTJYQQLSnnayjVKPEgPojBRXj8PboIEczs62kw1F28PyiVPNU253W0foHojJ9Vgwp4hX2TjcW1j6FJLYERmmhLuhFFORjW0WnjfV9V4pQC0zxmI0mvAUSyo4eQRo6FNpSaHr9XLOokDSE085XZyLXGsgKETX20SA0S9ZaTQiulIefvbeMMOp/qM7SZwMe+JfzP64AVj7C08MLQ96oHJe525pgFNbN7+mSPLogUg9ydmBvPLdbJlmJDWdyWJQy16VTVAIfpjqX1ZnI/3ydiXOtrc811k9XEWvQg5+yeRliKTbdgpwW8M5+2magMLX3WlVmp3nGJ9eM/HHmmNw== x-ms-exchange-antispam-messagedata: b1kQwExyEzvL4uQlU7DigpA+joi4KRPdtw7TAsLonz/v13TbAgXC/94Whz8D4yhmyOFdLSHFeGVesmqHxgk8SUK4KbpfpG17muQMlt23os6pYWcI33Q3GJk/LfecYfhIGcdgqBgs9SH3Z4BZlfxogQ== Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3318E2FA31EEF0996CC11CB79BC80AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5029 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT060.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)(39860400002)(396003)(136003)(346002)(376002)(46966005)(478600001)(356004)(19627405001)(26826003)(81156014)(6506007)(53546011)(7696005)(81166006)(8676002)(47076004)(966005)(30864003)(86362001)(82740400003)(9686003)(2906002)(52536014)(110136005)(70206006)(70586007)(19627235002)(55016002)(26005)(186003)(336012)(5660300002)(15650500001)(33656002)(316002)(8936002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 2db4049b-b264-4279-3028-08d7d55bc072 X-Forefront-PRVS: 0359162B6D X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: oAaxOmLR/mPSGrgQPK7cBLpLeCSTk+JicQSIKEOv5yei7EDgEbpzKcYUmuOvMDx3iMtq0cclgIZOJmAloeyucE9Zlx3MFolUPoU+hDBSpbbBn4q/owQ77Kr9H2K0bJ9ltc7+KeQ4Tox/ZosLF+ov5KbLy3h2ObnXVp18/MEJjh5EJTj2npEcInCWE0maxcDoZ7FlZvDLKOmDwLAuc+HHHVzo7T/eBPLnjm6XVA5xFRaK2O5Fu0eFTR/uPK92QsuQ4hQ39Am3l04Guc4XVz3mi7pajgk6uti7hKC4LJS+Wq32Jkz2pC247HzQQ2ZmVnxu3SB3QFTmtbUs4JRzEmSCXVdkHl3GeW1khrGQDQYeOVrk3893RThjgiLyqYQltdZCjGgsTLw/BDm0WRflajliqTrn7CHubv1QIvqAgAvRXZAh5VOJyLZIzLN+ithfrAd0n0F57HS+me9g9+HRPqgXqmJnQfz37WIxsyH5LhnQ4oCHBENZpeiSSgdrWeIq8NvIY/VgfLtDxcuvOiqb9pN4iVEx5XUzedObehPZe8f0nDDLSGsydahECFlfcTU4M9rSB8cMzzGTY+LeDOLQSz6s0w== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Mar 2020 10:10:41.4324 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 559475c0-0283-4c94-7fd6-08d7d55bc4ae 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: AM0PR08MB4163 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2020 10:10:50 -0000 --_000_AM6PR08MB3318E2FA31EEF0996CC11CB79BC80AM6PR08MB3318eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Hannes, Thank for opening a PR! I think the underlying issue here is the conception that all that needs to = be ensured is the ability to ACK retransmissions of the KeyUpdate, and the modified version still gives that= impression. If that was true, the use of 'canned ACKs' as in Draft 37 would be fine. However, the example= shows that there's more to retaining old keying material than just ACKing retransmitted KeyUpdates, an= d I'd therefore opt for a more intrusive change of wording, such as: Due to the possibility of an ACK message for a KeyUpdate being lost and the= reby preventing the sender of the KeyUpdate from updating its keying material, receivers MUST retain the pre-update keying material until receipt and succ= essful decryption of a message using the new keys. Receivers MUST NOT delete the pre-update keying material immediately and use canned ACK messages for retransmitted KeyUpdate messages, since situations can occur in which recei= vers still need to be able to decrypt messages secured with pre-update keying ma= terial. Maybe the second part is better treated as a note or implementation warning= , though. Best, Hanno ________________________________ From: Hannes Tschofenig Sent: Tuesday, March 31, 2020 7:28 AM To: Hanno Becker ; tls@ietf.org Subject: RE: [TLS] Possible deadlock when ACKing KeyUpdate messages? Hi Hanno, I believe the part of the paragraph that talks about =93canned ACKs=94 need= s to be clarified. In https://github.com/tlswg/dtls13-spec/pull/135 I changed the text from =93 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. " To: =93 Although KeyUpdates MUST be acknowledged, it is possible for the ACK to be lost, in which case the sender of the KeyUpdate will retransmit it. The receiver of the KeyUpdate 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 remove the pre-update keying material only upon receipt and successful decryption of a message using the new keys. =93 Ciao Hannes From: Hanno Becker Sent: Monday, March 30, 2020 8:02 PM To: Hannes Tschofenig ; tls@ietf.org Subject: Re: [TLS] Possible deadlock when ACKing KeyUpdate messages? Hi Hannes, > In your example below, the sender of the initial KeyUpdate has to re-sen= d it because of the lost ACK. In order to resubmit it, it has to use the ol= d keying material (or cache the message). The receiver cannot immediately d= elete keying material after processing the initial KeyUpdate message becaus= e it does not know whether the ACK will subsequently get lost. My point is that the paragraph cited at the top of my post appears to say t= hat receivers MAY immediately delete keying material after receiving a KeyUpdate IF they blindly ACK retransmissions of the KeyUpdate = (even though they can't decrypt it anymore). The example shows that this doesn't work, unless I've made a mistake. Best, Hanno ________________________________ From: Hannes Tschofenig > Sent: Monday, March 30, 2020 11:57 AM To: Hanno Becker >; tls@i= etf.org > Subject: RE: [TLS] Possible deadlock when ACKing KeyUpdate messages? Hi Hanno, Hi all, I believe it would be useful to add some extra sentences to the draft to re= taining the old key material. In your example below, the sender of the initial KeyUpdate has to re-send i= t because of the lost ACK. In order to resubmit it, it has to use the old k= eying material (or cache the message). The receiver cannot immediately dele= te keying material after processing the initial KeyUpdate message because i= t does not know whether the ACK will subsequently get lost. Ciao Hannes From: TLS > 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 followin= g 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 upd= ate_requested flag will result in a subsequent KeyUpdate from the other side, and the only unl= ucky thing that needs to happen is for the original ACK to be lost while both KeyUpdate mes= sages 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 s= omething? 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 upo= n receipt and successful decryption of a message using the new keys. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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 confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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. --_000_AM6PR08MB3318E2FA31EEF0996CC11CB79BC80AM6PR08MB3318eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Hannes,

Thank for opening a PR!

I think the underlying issue here is the conception that all that needs to = be ensured is the ability to ACK 
retransmissions of the KeyUpdate, and the modified version still gives that= impression. If that was true, 
the use of 'canned ACKs' as in Draft 37 would be fine. However, the example= shows that there's more to 
retaining old keying material than just ACKing retransmitted KeyUpdates, an= d I'd therefore opt for a more 
intrusive change of wording, such as:
Due t= o the possibility of an ACK message for a KeyUpdate being lost and thereby<= /span>
preve= nting the sender of the KeyUpdate from updating its keying material,
recei= vers MUST retain the pre-update keying material until receipt and successfu= l
decry= ption of a message using the new keys. Receivers MUST NOT delete the
pre-u= pdate keying material immediately and use canned ACK messages for
retra= nsmitted KeyUpdate messages, since situations can occur in which receivers<= /span>
still= need to be able to decrypt messages secured with pre-update keying materia= l.


Maybe = the second part is better treated as a note or implementation warning, thou= gh.

Best,
Hanno
From: Hannes Tschofenig <= ;Hannes.Tschofenig@arm.com>
Sent: Tuesday, March 31, 2020 7:28 AM
To: Hanno Becker <Hanno.Becker@arm.com>; tls@ietf.org <tls@= ietf.org>
Subject: RE: [TLS] Possible deadlock when ACKing KeyUpdate messages?=
 

Hi Hanno,

 

I believe t=
he part of the paragraph that talks about =93canned ACKs=94 needs to be cla=
rified. 
 

In https://github.com/tlswg= /dtls13-spec/pull/135 I changed the text  from 

 
=93<=
span style=3D"color:black">
   Although KeyUpdate MUST be ac=
knowledged, it is possible for the ACK
   to be lost, in which case the=
 sender of the KeyUpdate will retransmit
   it.  Implementations MUS=
T retain the ability to ACK the KeyUpdate for
   up to 2MSL.  It is RECOM=
MENDED that they do so by retaining the pre-
   update keying material, but t=
hey MAY do so by responding to messages
   which appear to be out-of-epo=
ch with a canned ACK message; in this
   case, implementations SHOULD =
rate limit how often they send such
   ACKs.
" 
 
To:<=
/pre>

 


=93


Although KeyUpdates MUST be acknowledged, =
it is possible for the ACK to be


lost, in which case the sender of the KeyU=
pdate will retransmit it.


The receiver of the KeyUpdate 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 r=
emove the pre-update



keying material only upon receipt and succ=
essful decryption of a message



using the new keys.


=93


 


Ciao


Hannes


 


 






From: Hanno Becker <Hanno.Becker@arm.com=
> 

Sent: Monday, March 30, 2020 8:02 PM

To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; tls@ietf.or=
g

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







 




Hi H=
annes,






&nbs=
p;






>=
  In your example below, the sen=
der 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 ke=
ying material after processing the initial KeyUpdate message because it doe=
s not know whether the ACK will subsequently get lost.






&nbs=
p;






My p=
oint is that the paragraph cited at the top of my post appears to say that =
receivers MAY immediately delete keying material after






rece=
iving a KeyUpdate IF they blindly ACK retransmissions of the KeyUpdate (eve=
n though they can't decrypt it anymore). The example 






show=
s that this doesn't work, unless I've made a mistake.






&nbs=
p;






Best=
,






Hann=
o












From: Hannes Tschofenig <Hannes.Tschofenig@arm.com>

Sent: Monday, March 30, 2020 11:57 AM

To: Hanno Becker <Hanno.B=
ecker@arm.com>;
tls@ietf.org <tls@ietf.org>

Subject: RE: [TLS] Possible deadlock when ACKing KeyUpdate messages?=






 










Hi Hanno, Hi all, 


 


I believe it would be useful to add some extra se=
ntences to the draft to
retaining the old key materia=
l. 



&nb=
sp;


In =
your example below, the sender of the initial KeyUpdate has to re-send it b=
ecause of the lost ACK. In order to resubmit it, it has to use the old keyi=
ng material (or cache the message).
 The receiver cannot immediately delete keying material after processing th=
e initial KeyUpdate message because it does not know whether the ACK will s=
ubsequently 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:







&nb=
sp;






&nb=
sp;  Although KeyUpdate MUST be acknowledged, it is possible for the A=
CK






&nb=
sp;  to be lost, in which case the sender of the KeyUpdate will retran=
smit






&nb=
sp;  it.  Implementations MUST retain the ability to ACK the KeyU=
pdate for






&nb=
sp;  up to 2MSL.  It is RECOMMENDED that they do so by retaining =
the pre-






&nb=
sp;  update keying material, but they MAY do so by responding to messa=
ges






&nb=
sp;  which appear to be out-of-epoch with a canned ACK message; in thi=
s






&nb=
sp;  case, implementations SHOULD rate limit how often they send such<=
/span>






&nb=
sp;  ACKs.






&nb=
sp;






Thi=
s seems to allow implementations to remove old incoming keys immediately






aft=
er ACKing the KeyUpdate, which appears to open the door for the following&n=
bsp;






sit=
uation leading to deadlock:






&nb=
sp;






&nb=
sp;






  +-------------------------+=
;






  |   KeyUpdate, epoch N  =
  |-------------> received






  +-------------------------+=
;






           =
                     &nbs=
p;         +------------------------+





           =
                    lost =
x-----|     ACK,   epoch M     |






           =
                     &nbs=
p;         +------------------------+





&nb=
sp;






           =
                     &nbs=
p;         [ new incoming epoch N+1,






           =
                     &nbs=
p;           remove keys for epoch N ]






&nb=
sp;






-           &nbs=
p;                     &n=
bsp;       +------------------------+






           =
       received  <-------------|   KeyUpdate, e=
poch M   |






           =
                     &nbs=
p;         +------------------------+





  +-------------------------+=
;






  |       ACK, e=
poch N      |-------[ irrelevant whether it goes through - s=
ee below ]






  +-------------------------+=
;






&nb=
sp;






  [ new incoming epoch M+1,






    remove keys for epoch M ]






&nb=
sp;






Not=
e: This isn't an entirely unlikely situation, since a KeyUpdate with update=
_requested flag






wil=
l result in a subsequent KeyUpdate from the other side, and the only unluck=
y thing that 






nee=
ds to happen is for the original ACK to be lost while both KeyUpdate messag=
es go through.






&nb=
sp;






At =
this point, both sides have updated their incoming key material but<=
/p>





not=
 their outgoing key material, since they're still awaiting the ACK - <=
/span>






how=
ever, it turns out that they can't actually read those ACKs anymore:=







&nb=
sp;






Aft=
er some time, the peers resend the KeyUpdate messages, which will be=







bli=
ndly ACKed by the peer according to the recommendation in the spec;<=
/p>





how=
ever, the ACKs will be encrypted with the wrong keys and cannot






be =
parsed on either side:






&nb=
sp;






  +---------------------------&#=
43;






  | resent KeyUpdate, epoch N |-----=
--------> received, but can't be read






  +---------------------------&#=
43;               because incoming epoch=
 N+1






 







           =
                     &nbs=
p;               send 'blind' ACK=







&nb=
sp;






  received, but can't be read  =
              +---------------------=
---+






  because incoming epoch M+1 &nb=
sp;<--------------|     ACK,   epoch M     |






           =
                     &nbs=
p;            +------------------------&#=
43;






&nb=
sp;






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





&nb=
sp;




It =
seems that this results in a deadlock. Am I missing / misunderstanding some=
thing?






&nb=
sp;






A p=
ossible mitigation would be to force retaining the old key material for 2MS=
L,






or =
alternatively, to mandate that old key material must only be removed upon






rec=
eipt 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 di=
sclose the contents to any other person,
 use it for any purpose, or store or copy the information in any medium. Th=
ank you.
IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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. --_000_AM6PR08MB3318E2FA31EEF0996CC11CB79BC80AM6PR08MB3318eurp_--