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 407B43A09F8 for ; Mon, 30 Mar 2020 11:02:06 -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=zxHNL9qU; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=zxHNL9qU 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 o7uQFZ20M2DG for ; Mon, 30 Mar 2020 11:02:03 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on060d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::60d]) (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 BAE353A09E8 for ; Mon, 30 Mar 2020 11:02:02 -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=F2VDpuKsO7YQ1oce2fbn0doOT3A9+ObwPzuFOQU94FQ=; b=zxHNL9qUctAxFizu2SXn2hcDTpN1TA5Z3FTFXR9FBti41v2XymKdo1R/z7P5QvAhwcOYXRvm8qFN2IWVm7oJSJsl26svEaUsJj/ckMOGG6f/uFP0D11gIlSXNxVyjLGLU3/SBKSneHy4Xfn8UwxNXOyVSBvOsxXfqg8rLXwt+l4= Received: from AM6PR08CA0047.eurprd08.prod.outlook.com (2603:10a6:20b:c0::35) by HE1PR0802MB2329.eurprd08.prod.outlook.com (2603:10a6:3:c5::15) 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 18:01:59 +0000 Received: from AM5EUR03FT021.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:c0:cafe::7a) by AM6PR08CA0047.outlook.office365.com (2603:10a6:20b:c0::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20 via Frontend Transport; Mon, 30 Mar 2020 18:01:59 +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 AM5EUR03FT021.mail.protection.outlook.com (10.152.16.105) 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 18:01:59 +0000 Received: ("Tessian outbound 1425309d4c0b:v50"); Mon, 30 Mar 2020 18:01:59 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 7eed5135371864c9 X-CR-MTA-TID: 64aa7808 Received: from a22629097c44.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id AE14453F-80EC-4170-855E-E7B209B403EF.1; Mon, 30 Mar 2020 18:01:54 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a22629097c44.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 30 Mar 2020 18:01:54 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TKA7V46drLs5qtUDYyNYv5OSdOTtPmRL9WoAmV0ecQXkmo4J64sj6v93GIa0MW+5v0tOBnKzuo3+uyTA9O1Pvu0q8sPS72Lo2MeUqTNXK79p9bF2v5aJC1c6vMwXDx2VDr7ICNbrXGy+O+6I0Ac1Xa9C1+vXA34+eBWpYd5RISe60JUyOvvWbVFTxmRasAL5xPO9bqvBBDgcl9aFy+EOPUzRtiif09s0uehBm44C8Rf2jlJqTMISqISfYGkUIE47ohCuuoXoY/pXcWOC36/MXw/vMioXbYw/c+8E3uYCaapp2U3L/DVIy05SxoBVGF3f2870uOF4Mzpg2zhCXasanA== 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=F2VDpuKsO7YQ1oce2fbn0doOT3A9+ObwPzuFOQU94FQ=; b=ntCybbr5fCKXkET3dXMETsX7o9odN2pFNxSZQrrtWWHGceKTMlRoSjS8QK64hgf9VkUb8sbNt4IXpWpkxA1ppq6sPS3Ot80GxYvYferzwtRicbS6lgyvECmOLCOiQVDXzPY6sq/8PsAmm2bpZD4zcPDuN5FtAMWYqdJjUGeEQLfKH3s3aOmaRhj1WyRZHhVFyBs3Y7UNDb7/06DEPBAxCSmQE+QC1UhFYcmQgbiYyKw+5ZRXJ5E0WoV1exRAGXCb588bdfKp6lu0OFIvZskFQu0Lo6eJU4mlOO5baa5B2EjTGrZuwGYRS6Zl1rFqBcwJ2R0xOdkJTagZ41hxCp/qeg== 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=F2VDpuKsO7YQ1oce2fbn0doOT3A9+ObwPzuFOQU94FQ=; b=zxHNL9qUctAxFizu2SXn2hcDTpN1TA5Z3FTFXR9FBti41v2XymKdo1R/z7P5QvAhwcOYXRvm8qFN2IWVm7oJSJsl26svEaUsJj/ckMOGG6f/uFP0D11gIlSXNxVyjLGLU3/SBKSneHy4Xfn8UwxNXOyVSBvOsxXfqg8rLXwt+l4= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (52.135.163.143) by AM6PR08MB3157.eurprd08.prod.outlook.com (52.135.165.24) 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 18:01:53 +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; Mon, 30 Mar 2020 18:01:52 +0000 From: Hanno Becker To: Hannes Tschofenig , "tls@ietf.org" Thread-Topic: [TLS] Possible deadlock when ACKing KeyUpdate messages? Thread-Index: AQHWBUxJ8anoCpmsBUC57Xe/3C4BZ6hg8CNggAB+9Vo= Date: Mon, 30 Mar 2020 18:01:52 +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: [86.181.127.140] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: b55adcf8-8091-452e-153f-08d7d4d47150 x-ms-traffictypediagnostic: AM6PR08MB3157:|AM6PR08MB3157:|HE1PR0802MB2329: 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: 0358535363 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)(376002)(346002)(136003)(39860400002)(366004)(396003)(316002)(478600001)(19627405001)(66946007)(15650500001)(33656002)(71200400001)(66476007)(19627235002)(86362001)(55016002)(76116006)(26005)(91956017)(66556008)(8936002)(81156014)(110136005)(81166006)(2906002)(186003)(9686003)(8676002)(53546011)(52536014)(6506007)(5660300002)(64756008)(66446008)(7696005); 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: Z9TQXs7WRAqusrP/Cdd8tbg/0D1citPh5HrNt2VD1SALwMt0CIiWAgnvciwknC7dMK9HegB428ri4QV0wBVtIMSDbZxoWGKHXSZBrtBVEe1L7oijBNSpZT0EgatIpMxh0aVkmoXH0AbffU0BnRUiyVBDk6a36DaSzLPKxSyih3IPKpkuue99ejJgYsaJLYtLUf0GMu8DA2zmrRC4166PyfbKon80v1EC0VpLbeztNigJcmUKoOCLVFKbjkyvqrckxUBw37GDod8Zmj4ueqysfItt+TpOk4d9vTGCopu1wIdWlWohvQ8/0yyTeny5HGHgFBm78Av97iP7Wfe5zr8ZBy9Mba9+OXAo7hoDtY7R5JoQUCCb9PGI0EIV16o4POJ/512rcU91D8B+JbsCT8XdpY4yTff5PtTJOnY19RtDYpme/JP822NrHOZFWe7MVD55 x-ms-exchange-antispam-messagedata: /cD8TNa53XqOAHZAdjgzTw0nTk+wEqayiJEdYe5AvboKQVFsPSqUAB/rl2TS9SfY9GA2tSGVFmkMwcHSknWgNU1/PT0hzW7hnXHk1vAyqzeSm7vNzEkiSIgtCRzhxGhWyPY6n83t/zSTOuM+dTRcyA== Content-Type: multipart/alternative; boundary="_000_AM6PR08MB33181249201D9E9E43F107229BCB0AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3157 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT021.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)(39860400002)(346002)(376002)(136003)(46966005)(5660300002)(8676002)(9686003)(186003)(7696005)(82740400003)(336012)(356004)(81166006)(47076004)(2906002)(86362001)(70206006)(19627235002)(110136005)(26826003)(316002)(478600001)(70586007)(36906005)(55016002)(81156014)(15650500001)(8936002)(19627405001)(52536014)(26005)(33656002)(53546011)(6506007); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 80c9ec01-07d2-43db-539a-08d7d4d46d39 X-Forefront-PRVS: 0358535363 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0hoy3T2ctVPA8J5dc89Hwkg0XbLx71mVayWahZzyQBvIwP64bQsUhXmgiwR7Oe/5Wx3VhztJXdaHOzqd0Q7oGpIc4lT87oJY5gGF1pVjCTdDi7hgV8Qp12G9re3hs2SMozWeK3bXWzXyOe0MnIA9tCpgstSfLQKqYMVEe392QJboipE5LEP21pwDy6ss+qfQdK8qk3c/YL0YxjS673lAhoR8GGbPQaq0KNZrpLgWArylc+B+FUQgyzs4MVc7whYrs6sXGx+HvdWUZ6eNFbkQZRSUCWdW+cXGRYTIbl2L73uawuvZmPCHgwMlNGCWWcqr5P8aAre3d+rssZ++L3ZTRIWJS1NZUCf9lmHsHcGDWNWimkGuTdwXlVVI9RciHmob2cImW8SohVPyCx5gj6FjibSbpCUrcwCvv6LeWrAm06Mdo6bAaS21ME4D/7zdx0quf7lnBwzEV7lnRMIoDfOwq0DcL2EAFJWYDTEBWMhPEwj/OBC+2f2SWqOGf/rEBqg2Kh/SfDF/WbLSyWXJ1gu8Tg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Mar 2020 18:01:59.4642 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b55adcf8-8091-452e-153f-08d7d4d47150 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: HE1PR0802MB2329 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: Mon, 30 Mar 2020 18:02:11 -0000 --_000_AM6PR08MB33181249201D9E9E43F107229BCB0AM6PR08MB3318eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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@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 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_AM6PR08MB33181249201D9E9E43F107229BCB0AM6PR08MB3318eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Hannes,

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

My point is that the paragraph cited at the top of my post app= ears to say that receivers MAY immediately delete keying material after
receiving a KeyUpdate IF they blindly ACK retransmissions of t= he KeyUpdate (even though they can't decrypt it anymore). The example 
shows tha= t this doesn't work, unless I've made a mistake.

Best,
Hanno
From: Hannes Tschofenig <= ;Hannes.Tschofenig@arm.com>
Sent: Monday, March 30, 2020 11:57 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, Hi all,

 

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

&nbs= p;

In y= our example below, the sender of the initial KeyUpdate has to re-send it be= cause of the lost ACK. In order to resubmit it, it has to use the old keyin= g material (or cache the message). The receiver cannot immediately delete keying material after processing the in= itial KeyUpdate message because it does not know whether the ACK will subse= quently get lost.

 

Ciao

Hannes

 

From: TLS <tls-bounces@ietf.org> O= n 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 r= elation to ACKs for KeyUpdate messages, DTLS 1.3 Draft 37 states:

&nbs= p;

&nbs= p;  Although KeyUpdate MUST be acknowledged, it is possible for the AC= K

&nbs= p;  to be lost, in which case the sender of the KeyUpdate will retrans= mit

&nbs= p;  it.  Implementations MUST retain the ability to ACK the KeyUp= date for

&nbs= p;  up to 2MSL.  It is RECOMMENDED that they do so by retaining t= he pre-

&nbs= p;  update keying material, but they MAY do so by responding to messag= es

&nbs= p;  which appear to be out-of-epoch with a canned ACK message; in this=

&nbs= p;  case, implementations SHOULD rate limit how often they send such

&nbs= p;  ACKs.

&nbs= p;

This= seems to allow implementations to remove old incoming keys immediately

afte= r ACKing the KeyUpdate, which appears to open the door for the following&nb= sp;

situ= ation leading to deadlock:

&nbs= p;

&nbs= p;

  +-------------------------+=

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

  +-------------------------+=

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

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

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

&nbs= p;

            =                      = ;         [ new incoming epoch N+1,

            =                      = ;           remove keys for epoch N ]

&nbs= p;

-            = ;                     &nb= sp;       +------------------------+

            =       received  <-------------|   KeyUpdate, ep= och M   |<= /p>

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

  +-------------------------+=

  |       ACK, ep= och N      |-------[ irrelevant whether it goes through - se= e below ]

  +-------------------------+=

&nbs= p;

  [ new incoming epoch M+1,

    remove keys for epoch M ]

&nbs= p;

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 

need= s to happen is for the original ACK to be lost while both KeyUpdate message= s go through.

&nbs= p;

At t= his point, both sides have updated their incoming key material but

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

howe= ver, it turns out that they can't actually read those ACKs anymore:<= /p>

&nbs= p;

Afte= r some time, the peers resend the KeyUpdate messages, which will be<= /p>

blin= dly ACKed by the peer according to the recommendation in the spec;

howe= ver, the ACKs will be encrypted with the wrong keys and cannot

be p= arsed on either side:

&nbs= p;

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

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

  +---------------------------= 3;               because incoming epoch = N+1

 

            =                      = ;               send 'blind' ACK<= span style=3D"font-size:12.0pt; color:black">

&nbs= p;

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

  because incoming epoch M+1 &nbs= p;<--------------|     ACK,   epoch M     |

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

&nbs= p;

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

&nbs= p;

It s= eems that this results in a deadlock. Am I missing / misunderstanding somet= hing?

&nbs= p;

A po= ssible mitigation would be to force retaining the old key material for 2MSL= ,

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

rece= ipt and successful decryption of a message using the new keys.

IMPORTANT NOTICE: The contents of this email and a= ny attachments are confidential and may also be privileged. If you are not = the intended recipient, please notify the sender immediately and do not dis= close 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_AM6PR08MB33181249201D9E9E43F107229BCB0AM6PR08MB3318eurp_--