Re: [TLS] DTLS 1.3 epochs vs message_seq overflow
"Tschofenig, Hannes" <hannes.tschofenig@siemens.com> Tue, 16 April 2024 09:16 UTC
Return-Path: <hannes.tschofenig@siemens.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 91768C14F695 for <tls@ietfa.amsl.com>; Tue, 16 Apr 2024 02:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=siemens.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFUBmO7LCZyR for <tls@ietfa.amsl.com>; Tue, 16 Apr 2024 02:16:03 -0700 (PDT)
Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2059.outbound.protection.outlook.com [40.107.22.59]) (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 EAC43C14F68B for <tls@ietf.org>; Tue, 16 Apr 2024 02:16:02 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BE0eYBgMK92yuri++lPsFjQN73+zTIqKNf48PHgRfbtYf/Ak2ZJZPsLFq8ViXqGncfYSGexqRgDldcr0XtY0f/Mv7rEHRsiCDIWHDHTiit0C5uL6oB2AM4Rq2qFMAJhofBcq4XouLzyLJbvV7O+inD7zAw7GdkvKMlpO7p3cYSF9q+SutagdrwDcrfaymqz12/buYkUxXQiZkTcaZJlngTTOT70DGH0TBaj9I1a+3QR88IcuJS1X0+zUZE1JuDkkqgSM62BUSFA9aoz/FXsbjXtgmio0Zvx7yAzBqvso1uvMVCWzMBy7Iw6B+THUypEt6ihHmNo9O4ELmvRVmf9ZrQ==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ZNIheghqU2ebeP3cmVWykHndsD/9DBFgEcl9EdL9BYs=; b=QIqayAEdc4GoDkzVp8uVKs4UFjAAfUR+xyqxVy2XtJk1o17e0AtqCg0K8X/OKv1yq3/iyx9tdJWSme2tWH9LdXUCcS7cv5HyE7903xr8XBRT7YUO1YtIhC1uSDxdgotKgNjLyFqwYH3H1ze2ZAuIueClXonJKv5LWpsgW3kT6X7mma5tNe2aVLswbta7JNsjMZ9H06zBqXPhXRgNjZYhYrmXIznafeLoCkwi4OK6izG5ddADEKsjxw5dbrRBKzVEEcGEIbPtGiMEpWYpARa0qeeLKpA6PkXlqg80REnKYTx+iaj9naFgYHc0K5XTZ/KYmbPAcUr7twes74bF+6mNcQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZNIheghqU2ebeP3cmVWykHndsD/9DBFgEcl9EdL9BYs=; b=xvVA6QlkF3+IP/6d8JCFI7QlmJum6gRdeYS05VwxHgEag247RkUWTicNQ9yj9ZMHiMlLZwAtcDnXTp1Pikpm4J415lPl/9HmjC1Nd8HsQsx3nI6Hieoz2L9PUFTMomUpYY/tVDtTbXlKnyFDQN21liCPkf6CMkhA5f1WE1XRlP6mnyZBLC43LAVba2LBxFkBszF7Fubl3z/EeTHmX3/8xziPA/yaFAPSmR5JnQzGSjnEU0/VlmvLssQ8EyU1gpoAESV3D50STyt9LoFiNk1XTmFLaVtX7w/Iuz2NRCfusn7hq/o51gDJ3CykxV19UhpKPh3g91Yr6ry1L/j3C05eYw==
Received: from AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:5ab::22) by DBAPR10MB4074.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:10:1c9::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7452.50; Tue, 16 Apr 2024 09:15:59 +0000
Received: from AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM ([fe80::9172:20d1:3f36:a3d]) by AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM ([fe80::9172:20d1:3f36:a3d%3]) with mapi id 15.20.7452.049; Tue, 16 Apr 2024 09:15:56 +0000
From: "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
To: David Benjamin <davidben@chromium.org>, "<tls@ietf.org>" <tls@ietf.org>
CC: Nick Harper <nharper@chromium.org>
Thread-Topic: [TLS] DTLS 1.3 epochs vs message_seq overflow
Thread-Index: AQHajGXKsbX1jpp1CUSHdodd9LNg47Fjs4eAgAbuDaA=
Date: Tue, 16 Apr 2024 09:15:56 +0000
Message-ID: <AS8PR10MB7427AE63B48D789CF218A22CEE082@AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM>
References: <CAF8qwaCr=FJU6TbqXscxQ5ezCVxREU_iiSQ5fO+UMsUEV_W1tA@mail.gmail.com> <CAF8qwaB1trnvAX7DXH94QHq9ZjyPz-YpqSgK5Rn9Jq2Qig_CVA@mail.gmail.com>
In-Reply-To: <CAF8qwaB1trnvAX7DXH94QHq9ZjyPz-YpqSgK5Rn9Jq2Qig_CVA@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ActionId=3a6155cd-501d-438d-a481-88ceb4b05689; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_ContentBits=0; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Enabled=true; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Method=Standard; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_Name=restricted; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SetDate=2024-04-16T09:05:11Z; MSIP_Label_9d258917-277f-42cd-a3cd-14c4e9ee58bc_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a;
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=siemens.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: AS8PR10MB7427:EE_|DBAPR10MB4074:EE_
x-ms-office365-filtering-correlation-id: 6064d699-84b2-4f0b-7924-08dc5df5d2bd
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: zpZwLb9Az1z6X4T1A1CZHAVZlVjlCkngBsTzMsDWKlDwWxcBMrQ4FhvyGxrIUd8MUhJEKjhTHRLAFgXJ5DXgsVtdW9MZJ4zt2HV0ClBt7TKcTzLuby2gc5Nj0qM+0KrDKnY+wy4gPhTSIoxgUz6pbZs58N8QHuBelNBWbe5psbsCIGiMU5MJgd2rWO2ZWXlV7qAUInKFGP75CW+avrYMwwIRJsi4bNMEm6IoFnXpl0qzKgna9vaaFdhZ8PK8BWde/J+uiEmv/2k7OLHYlLm8dzSKgO0f8oc8SwyxG7IqQtaUURqR5xkUhU0lqTqPPUiEIZw1+WL64YPCi/e/d5Uq+qjHR8Ox9edqmxIiJbszJtK0Z5raFAyQ0r1TVD26Rnezv2sNhOsjOg5V+ijM3o51LsrOqUiRDtyUJphBR/9R+pWBIhmDQyF1e6Qkf/lBWOdBeSDBACZP+ePGlFUwIRqIPGKsvN6CMmAADXz23yQPWRtqqNIMwcIOn/mZz75ET68XvY5HwX8s2nmuZezc2EgKtsJJOgy4Z9GBytyxViFmuJxphI4Tb1SJRWoK8NUWpGmzqb1SrbiHqevhqQMV9+Q9/3CK7uSLTM7vV+kLkuMRGqyac6tU5EvLOxDrogqaDIJ1J+cZXfRkYIPTJDIOTzu6A8tMxJI7OEg142Himk4mUBfnTrnNUjbaJ4uDcuYppXd1592FExQB10SDnZzd7qTBkZD+WymTflzX032XUzdtluc=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230031)(366007)(376005)(1800799015)(38070700009); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: GPSAKYHiBh/AYXrGCyO9zm2AB0AUJ1fzsfJGZ46Vi4xKBaCBIeI7YrBSpAldlDolhcIf+KnJFU23JR7BJLCWRqVSdyvuerVle5oDMVUO3/dq6Z1P9htMZDJBZe19UGgjEIm3i7iVbOckfzWNogYlpIVK2vaNPaR/c+7rkeT1x8g9tQ+vycthYIODxbJSkpOzwFNmDsUSbG+fKk52DXA1nGoubA0X8G4k9L8oIK+Vzsjq1/8YQPgD/hoADCLF4iOst7QwZtxR4V0WNn7E4fSXXqyfJSpN3NoLov66zVImMS9rf2c76o2cOj7rwi6thuF6UD1XYO/8+o7vgjWme9Oi/oa0bOESStrCDi8mfZk7zr5HCPtaMsVpvwzhRS5SnZxdSTi4rDiTB1aSEeeacfsqvs19bUJN/ISbuvjJmMh7EjQj7OzsM81KkaLdIpIKJTGa7cBU4nGENVkqxeqc+TBWV4gFgEj7T9+JsmpvosROPGG91NEN2q36HdV5AWzUjnKJBsNMnnYnCMPLjceAntXeNLkz6UBoOhSsVode/8SQEQGdDP8ajzSPJd57Y9SXdBbyg/LD9LfLw2Y5ZP6JRdrnY0vwe9aofmpRrW8IXq8T5EaOab6UU33h/8jD3I3yKxOOIlmMp22QFnoblJNBG/EiqdXQ2ATnCzhjV7aZpXG7cav1pJpLOTY+57buVnZ/265gwt1CusKbRoGOIrApvFqqwGhi3FQ9wEHigYrhDyPPBHSkaUWUn/o6C7mUs4kW07giin2Gd5XXZIVRHEMrngVHMiwWdVHMQ4lwuH6IxYtCmWt6V33oeM6zdEwx798BVxciNUR5UvqJiVMhEIdBPjRtHDvUawEJ5mWJomIA2Uh4elXxnbYIJ+wbE1oZ7roW4iVyjGYQX6eiOB9ylyVbIRyt6HOS+3y28JORioLlC43X4oNRni5ktwJDIhiZbHP9SN2I8ZxEAGhs08rgRzYyw9L+fpiOJbwXzOGTrVycsv0NML5tkzN4RREJ/DBpJuM2VMadrc05Sw/bEyGspA3vwdFhBUHUZdW5BSsXvdmzKxHJUG9Gbku1bm2Aiz3MryhDuJW1sSt1cJZLq7KJl/UMmRYE+ouAoRN4XFtINIJFkmhXE8EM1sJqPE6uz7AIzAS9/AgQ7dxxXzafJ581AbKT1mq9zOTrn3I/wtg9rl3jywvZNU6pMZWgpYA6MmAPrlAEaUOo3GgCq9Y97VoUeeEnlvVsaEZRCuErxgsrb5y3ADGSwTK8PW0eS2gh/9lx6U1xXqNO6BrGck4g7+tv2XVTkvy0LatZuOBP0SVvz4peojasKXT++DuDZzrDGOwQ/CjtDZeAS0vP59yvNfn8TkBPVcAJKgTfcHw/P+dEKnLvi6mUH/4opNvAmjLe2cDVF8VR+tlmS6GXzOul1sB5Lq0q7aF5Ento6DDavhus7wuMBmXi1LF4/j/M0HjO+vFKMfAqQQeefT4okrht1fpAMBnKWR1v2Qdvq9g9czy9vbNi3pOUYfYjQ24cQmlmavDa+DRRtop5gGf/DEdMgh46tNmbStmbliglRS2N8H+xBwoCIFlFIo9thO0rw4NitJpCdW7LBBGgM8cWQTqurQzGKwS37FnX9Q==
Content-Type: multipart/alternative; boundary="_000_AS8PR10MB7427AE63B48D789CF218A22CEE082AS8PR10MB7427EURP_"
MIME-Version: 1.0
X-OriginatorOrg: siemens.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 6064d699-84b2-4f0b-7924-08dc5df5d2bd
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2024 09:15:56.3634 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZCDzNgwTJmjX0RFtJY8FhPmOyhpKv5LJq4YLdx9QdNO1gNZUjxlzn9nxqIe/uYUdsjnJcaWgD1mtk6d0kPYe2Gf73OEL83GoXOBwNUZUsVU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBAPR10MB4074
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/g6UWLUy47473OFqHMO8bPenbabM>
Subject: Re: [TLS] DTLS 1.3 epochs vs message_seq overflow
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 16 Apr 2024 09:16:07 -0000
Hi David, thanks for your reviews and the details comments. Let me search for the exchanges that lead to the increase in the epoch space. I recall that this was very late in the process based on feedback from John, who noticed that the smaller epoch space helps IoT communication but not the DTLS use in SCTP. Regarding your statement: “65K epochs should be enough for anybody, perhaps DTLS 1.4 should update the RecordNumber structure accordingly and save a few bytes in the ACKs“. Possibly correct. I am going to ask the SCTP community for feedback to find out whether that is also true for them. Ciao Hannes From: TLS <tls-bounces@ietf.org> On Behalf Of David Benjamin Sent: Friday, April 12, 2024 1:16 AM To: <tls@ietf.org> <tls@ietf.org> Cc: Nick Harper <nharper@chromium.org> Subject: Re: [TLS] DTLS 1.3 epochs vs message_seq overflow On Thu, Apr 11, 2024 at 7:12 PM David Benjamin <davidben@chromium.org<mailto:davidben@chromium.org>> wrote: Hi all, In reviewing RFC 9147, I noticed something a bit funny. DTLS 1.3 changed the epoch number from 16 bits to 64 bits, though with a requirement that you not exceed 2^48-1. I assume this was so that you're able to rekey more than 65K times if you really wanted to. I'm not sure we actually achieved this. In order to change epochs, you need to do a KeyUpdate, which involves sending a handshake message. That means burning a handshake message sequence number. However, section 5.2 says: > Note: In DTLS 1.2, the message_seq was reset to zero in case of a rehandshake (i.e., renegotiation). On the surface, a rehandshake in DTLS 1.2 shares similarities with a post-handshake message exchange in DTLS 1.3. However, in DTLS 1.3 the message_seq is not reset, to allow distinguishing a retransmission from a previously sent post-handshake message from a newly sent post-handshake message. This means that the message_seq space is never reset for the lifetime of the connection. But message_seq is a 16-bit field! So I think you would overflow message_seq before you manage to overflow a 16-bit epoch. Now, I think the change here was correct because DTLS 1.2's resetting on rehandshake was a mistake. In DTLS 1.2, the end of the previous handshake and the start of the next handshake happen in the same epoch, which meant that things were ambiguous and you needed knowledge of the handshake state machine to resolve things. However, given the wider epoch, perhaps we should have said that message_seq resets on each epoch or something. (Too late now, of course... DTLS 1.4 I suppose?) Alternatively, if we think 65K epochs should be enough for anybody, perhaps DTLS 1.4 should update the RecordNumber structure accordingly and save a few bytes in the ACKs. :-) Does all that check out, or did I miss something? David
- [TLS] DTLS 1.3 epochs vs message_seq overflow David Benjamin
- Re: [TLS] DTLS 1.3 epochs vs message_seq overflow David Benjamin
- Re: [TLS] DTLS 1.3 epochs vs message_seq overflow Tschofenig, Hannes
- [TLS]Re: DTLS 1.3 epochs vs message_seq overflow David Benjamin