Re: [TLS] DTLS 1.3 sequence number lengths and lack of ACKs
"Tschofenig, Hannes" <hannes.tschofenig@siemens.com> Tue, 16 April 2024 09:17 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 55DC3C14F68C for <tls@ietfa.amsl.com>; Tue, 16 Apr 2024 02:17:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 BPQ0RGruWlF6 for <tls@ietfa.amsl.com>; Tue, 16 Apr 2024 02:17:34 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on2051.outbound.protection.outlook.com [40.107.7.51]) (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 F409AC14F68B for <tls@ietf.org>; Tue, 16 Apr 2024 02:17:33 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OA/Gxrhs6q4tF3IjiRKP+KleRy8jKThqBwNPAwNeiwMa7BFXlWFKdzpcy3B0O6S12EYssjHWIOrXJYpwFaXa51Aqx21Spw9ZaHFhHBUYt3NvKz08JTuVSVmW2Lu/oERuP95QWcsMRtdtg1C0ZlYawMN+Bh33sApjBJx0qJGO75sp26ivycLXI5fdxNvMBTIM4cTq4yHb+B3yXq0uMeX2Gym+6lMEIHqowUBVhAmar+qifTl0ftbO8kl7w+1ZSkfbbNzIY9cIhJ5LyfyzzdeCt2RHb5xvunsHqXtOSw5SepJwrtDkQlvsf9CQCySz24jC4tqyFnPMwIQAfKoFPd/tdA==
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=rKb7cFQhTV3KHVHVqEAJvx/mtZB8/R14MQPj46+HYxg=; b=hXgdshepemosiQaaWe5xsA7O1WA/BhaTqQYfKJg0pOhn1MV60Lsv9YXoahEC/phxEtZKXiPd6PyKqrrrwNNrIu3brWp78GyvoMSZYc0vo5+UnpdqDos4gtthr6zFISNAhxzDJ0h1J5NODIjoszIg7EoEoPyywQ+iv+CgO4PkpSVg2815SC23hMJnVISf36Givfe/kxnaMic+MEDvwlz5IiTegmp0xvYbxsqUoJXL0CFXajYaGeHdOFBQOBXFL9kzV7xPuah/hFtrXj6VQ8O7vX845QccEX5zc2FKaFymd5wGOqcrn8ZIFfWvh0mAlGlW3E5O5e8D+qKaipSo20C2vw==
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=rKb7cFQhTV3KHVHVqEAJvx/mtZB8/R14MQPj46+HYxg=; b=ieZM6J7iu+68bemVKbXHUmmGfkuIQ3UKB1k8jBPvI3N9xh97hh2GjdaG6K+dAoDLoqOQtopGOA/gIpo0ZH/qRInsxQtjVmAJyZKF0PdZnuKKI7cqT7Bvi93SvwNIpYbZRngN59tAQ6vT8FtGHtqzOjSYSvovKo5NjjAnuCVF2ypXhf75wrhGolX+j6SQU5GJW3Ll7Qsq9S6ZxZC7Bf7DKTgOGYZuBm9H8TtExWcf9m+zli6CGHCqOF0wtFkEPIrzJPku1iEBNamp4wl39mDzCCXZZzoWry81WoL+1+uQZlzomUfYte3oCDWcBWTe4d/hwI9f+aumeJ8rEsGwTnos7g==
Received: from AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:5ab::22) by GV2PR10MB7054.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:150:d1::15) 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:17:30 +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:17:30 +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 sequence number lengths and lack of ACKs
Thread-Index: AQHajSGO/7SfkjgJV0yLdkGl/v/SQbFqoQ1Q
Date: Tue, 16 Apr 2024 09:17:30 +0000
Message-ID: <AS8PR10MB742794893207672B7C0F4079EE082@AS8PR10MB7427.EURPRD10.PROD.OUTLOOK.COM>
References: <CAF8qwaAyDTwdT12zdo=PfRH=zwVU5rJGnsrSgWrk4F1JHyZtDg@mail.gmail.com>
In-Reply-To: <CAF8qwaAyDTwdT12zdo=PfRH=zwVU5rJGnsrSgWrk4F1JHyZtDg@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=e4e4298f-2989-4c05-82e6-f04d885f6805; 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:08:33Z; 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_|GV2PR10MB7054:EE_
x-ms-office365-filtering-correlation-id: 03ccfb5b-0736-49cd-3aec-08dc5df60aed
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: N7f0xwkYnQclW8uRJVIREzXz14A6zGnCBaIxlYBrkl4LFw3LgyGCGQ/vai4Q7CYKdlQrD1n0kCl52u/HLlNTztgX1DYxAoGqtgV3GHrccFGjIf3AlQkqikW5U8MfZaEjOSsjLi7H8f+2LytzmdZ2U6GwLiXYi90JqfyEcnoMXGGHFwQ56yV5cvGgM8MOLYkmnIZNZTr4+sHnwoqTI8w60xbMweBM2WvbFoOn/X8g/t40KIAcsFULgmy5KL7AsfpI+nPQs8E6jZrOrEDS0nUb1WwrxYqX5RDrajw1AYbBd/+tsnHbj1VHMlSYh5sXpR+2D91lnKnQu7alRJF2YRervMVlpFm8I+pK6ecHAf1C3f8vefu2qSYtLM3WXjyMgLGK9PPFyVYOeIjpfEHANebB9LesleSHK5aZYmgqXtsRInU3zqcy//nxyBZmW2rnxhnKIja/S12CM/bjltV5HllTcAXnHwqb9OFqGHibyju0875G4mpiV4FGdTsju8sJEJJgkVb0Xt/MnsSQq83pf2IHCnAYuDisXObm+hWzNTY28tYhDOpUnbLEb1QtQG3lvqeC1bNy5Wuq4crLVZTJgx8zxwu0+lxPjlsWwkF7kn/Uk7NaDYmQqCWZRTneqmNxP/BSd+hllVEKSWuyPZVQ4TTmnw4DDKOC1+8oaAyu/OQK/2U=
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)(1800799015)(376005)(38070700009); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: UgeD5wg9nsnOIeM4T+er6dXcTEP+lVNcYZA4jzJM5hnJyyrwVKA+MbnejgBDwWwNGTk/4ePPRMuUp/y+8chzuE8q6G6g/UQMVPvwpm0vCRyrSpf8TEzCHe3YEGSxe6FMAJrYiJJulFFn6aTqklPTF5VpQLF+/CGwQbrxP6y4oVbP0XySgfzX3gncmjHz5amA1i9kD8HH5klAii8cs9wSZAtFc296Kw8sAhgmqXifS2Z/LPTDACy3LchyC7R7/DduUYNKGbhWszsL7mnnWlB8r5Zdl4+/TnNJoaOq1mTXejsdhhe3wXVtFKYW7hZ9ksNz4SmKBEBmUubFjtE32mRQZScWZd0YKsCzDbMtnZcLyaBM514L4k44qdnBCBpI+eC06PKczBvd5dU7vZ6BkvrOrLnyp+5/11hbIm5vUNufv/59YR9qe+9CF+0AHuX7GsTYtFNAGOKN1xTbd1DUCmjiYjKqYbttt++yelbklk16X55sGos92CbMBCYgumA2+hjLALVTtwXLRKSI/H7FAQuLeaoatA2zP+xYYbjbJmNYCQFzPZzugC4ZNkJhew1umx79f9rpHak0JA2VsobXGUQhi0H+lX2/EA4POvGQnPNeYd3CsyPOMNe+9yehVyq+MMI6vHqzdKLg62M5UB4a0bUE5gRc1/SVbDo18zLcZcUr5cVk1XWSOtahyIzao0gtZeQmhEU0AJV7kSpkZICIvsUrQzYpCcukG47aW7xXfRq6oACGISG7yvn0QQy7iAlyoJv7UFDULiDhGbWDOjkT2IYRj+rCsWYN84ebttV7qE7lSfIOMBV6G2JUbRqig2jieHJUEx0tsvtR+E6h6tfm1YS9aN44dFm5Ruw+901xNx1YeyCF/ijQ36gjIR46RyhkWE3YI0opSeQTY3yN865hGil5NSqnDBjDA4uPlERtd403ceBeAD87bVat/hVn4X3M0TBEuUVqlPG6+PnJ3Mnpwh1UEueXQyQ6q1JcFfFJGozXiP/B6GWIotDcO1FpqACVqWxcJ3IQFdQgIIPDTObgVl8jBxa+4bQ1Xs5mdP3wi3k9vghzecgBlQMho3Ce1d3d4M3pR/wQNopuyPwILYH6x27EqDAFf4EzWKjtfyjM1OMuY2AO3Laj436FUgtb2BPkggAQQK4P9qXEpwfT8D8cJUlK2u1ZOwP5RHOASLVM21PMqco/ncEJuKmbgcI/1fb66WzUbE+k5HQUuJTp8w7ryUZ5yDqBpMmcgpOfm5WdRwdPko4wm2NqCYQnEXy0ZYmM0lH/ZUaI3oZZ9zsDzrHAN4oGZZKgZ5UP3fQ2kyMJgHLJmo58UbIvmKdiI+nR0Jh656czIcy5eAUC/UB0070exJmuud+U3v7y/K+2sqQoWzbldX5Qc8wxYOIHvHOQ29SWsn2IIlty8IokTVcSEZKWFGfMHpqEK7w6ifHXsjKuTDZ1D+CxgGHi9Nc087s5i1aLWuQpl8ZngVsF1+ObOBgOaXn2lwevt6/+1oh3MteNJ0WVH0X4fz45eUCvFQtCEV/nA63IRkfSjREr3Oc5AHxDzyusUVKnCYrjNOfNA+i5nKjL7ZqNRhXDUJL0oLDrtzLDaxoDHcxSYsxv0Lwc/k1ihHOUig==
Content-Type: multipart/alternative; boundary="_000_AS8PR10MB742794893207672B7C0F4079EE082AS8PR10MB7427EURP_"
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: 03ccfb5b-0736-49cd-3aec-08dc5df60aed
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2024 09:17:30.5940 (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: VIGsOPC7t1G/MrQ77ClIIeW4GIpJu3pmkNEs/Cqm7uq5puK2y/EZB9PMlnZEV/8QOGkrMRWn5ml4NB9K0OOUhdRUIon73ampqF7Jg0BngFE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: GV2PR10MB7054
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/LS2yb8CnnxYLkwt9U5_ti4dE80o>
Subject: Re: [TLS] DTLS 1.3 sequence number lengths and lack of ACKs
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:17:38 -0000
Hi David, thanks again for these comments. Speaking for myself, this exchange was not designed based on QUIC. I believe it pre-dated the corresponding work in QUIC. Anyway, there are different usage environments and, as you said, there is a difference in the amount of messages that may be lost. For some environments the loss 255 messages amounts to losing the message exchanges of several days, potentially weeks. As such, for those use cases the shorter sequence number space is perfectly fine. For other environments this is obviously an issue and you have to select the bigger sequence number space. More explanation about this aspect never hurts. Of course, nobody raised the need for such text so far and hence we didn’t add anything. As a way forward, we could add text to the UTA document. In the UTA document(s) we already talk about other configurable parameters, such as the timeout. Ciao Hannes From: TLS <tls-bounces@ietf.org> On Behalf Of David Benjamin Sent: Friday, April 12, 2024 11:36 PM To: <tls@ietf.org> <tls@ietf.org> Cc: Nick Harper <nharper@chromium.org> Subject: [TLS] DTLS 1.3 sequence number lengths and lack of ACKs Hi all, Here's another issue we noticed with RFC 9147: (There's going to be a few of these emails. :-) ) DTLS 1.3 allows senders to pick an 8-bit or 16-bit sequence number. But, unless I missed it, there isn't any discussion or guidance on which to use. The draft simply says: > Implementations MAY mix sequence numbers of different lengths on the same connection I assume this was patterned after QUIC, but looking at QUIC suggests an issue with the DTLS 1.3 formulation. QUIC uses ACKs to pick the minimum number of bytes needed for the peer to recover the sequence number: https://www.rfc-editor.org/rfc/rfc9000.html#packet-encoding But the bulk of DTLS records, app data, are unreliable and not ACKed. DTLS leaves all that to application. This means a DTLS implementation does not have enough information to make this decision. It would need to be integrated into the application-protocol-specific reliability story, if the application protocol even maintains that information. Without ACK feedback, it is hard to size the sequence number safely. Suppose a DTLS 1.3 stack unconditionally picked the 1-byte sequence number because it's smaller, and the draft didn't say not to do it. That means after getting out of sync by 256 records, either via reordering or loss, the connection breaks. For example, if there was a blip in connectivity and you happened to lose 256 records, your connection is stuck and cannot recover. All future records will be at higher and higher sequence numbers. A burst of 256 lost packets seems within the range of situations one would expect an application to handle. (The 2-byte sequence number fails at 65K losses, which is hopefully high enough to be fine? Though it's far far less than what QUIC's 1-4-byte sequence number can accommodate. It was also odd to see no discussion of this anywhere.) David
- [TLS] DTLS 1.3 sequence number lengths and lack o… David Benjamin
- Re: [TLS] DTLS 1.3 sequence number lengths and la… Tschofenig, Hannes
- Re: [TLS] DTLS 1.3 sequence number lengths and la… David Benjamin
- Re: [TLS] DTLS 1.3 sequence number lengths and la… Tschofenig, Hannes
- [TLS]Re: DTLS 1.3 sequence number lengths and lac… David Benjamin