Re: [TLS] Gaps in specification of DTLS 1.3 state machine

Hanno Becker <Hanno.Becker@arm.com> Wed, 11 March 2020 14:36 UTC

Return-Path: <Hanno.Becker@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 628613A07A5 for <tls@ietfa.amsl.com>; Wed, 11 Mar 2020 07:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=l0kp3Lj5; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=l0kp3Lj5
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 GqJTa-M1Jypi for <tls@ietfa.amsl.com>; Wed, 11 Mar 2020 07:36:17 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10083.outbound.protection.outlook.com [40.107.1.83]) (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 98F303A07A0 for <tls@ietf.org>; Wed, 11 Mar 2020 07:36:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMe?= =?utf-8?q?ssage-ID=3AContent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCh?= =?utf-8?q?eck=3B_bh=3DPALNGTLT/oHMoU/C5AofNyLN9M2pGreiIoWVGaWlqX0=3D=3B_b?= =?utf-8?q?=3Dl0kp3Lj50cca5mNIerObV8A//2lq6ET1mzVBRxWXg1jM7g3G+QZdjASIqVa2Gl?= =?utf-8?q?spcj8WfnJwTvp5xE/CmviW1svVXiU39AbbKDsgdSdbu253l+tamoOmokWXmp7ZmXM?= =?utf-8?q?/kCw39r3VjUjGFPE7L3FgZyu3RkjM03SMWjGneXx+xTc=3D?=
Received: from AM0PR05CA0033.eurprd05.prod.outlook.com (2603:10a6:208:55::46) by AM6PR08MB4392.eurprd08.prod.outlook.com (2603:10a6:20b:bf::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.17; Wed, 11 Mar 2020 14:36:12 +0000
Received: from VE1EUR03FT064.eop-EUR03.prod.protection.outlook.com (2603:10a6:208:55:cafe::79) by AM0PR05CA0033.outlook.office365.com (2603:10a6:208:55::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.16 via Frontend Transport; Wed, 11 Mar 2020 14:36:12 +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 VE1EUR03FT064.mail.protection.outlook.com (10.152.19.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.13 via Frontend Transport; Wed, 11 Mar 2020 14:36:12 +0000
Received: ("Tessian outbound 62d9cfe08e54:v42"); Wed, 11 Mar 2020 14:36:12 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: 0ef1f50cd1f7d971
X-CR-MTA-TID: 64aa7808
Received: from 83551bd0867d.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6C166BD9-590B-4536-BBA5-E4E6A093D087.1; Wed, 11 Mar 2020 14:36:06 +0000
Received: from EUR02-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 83551bd0867d.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 11 Mar 2020 14:36:06 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; =?utf-8?q?b=3DSR48bMeoNsJI7VururXUn/nskk0HuTnV/wsTpSKk+mn6l7N9a0F9MCNIdrRfk?= =?utf-8?q?zpKPTnzcMTLYi81gct7Qc4EyZwY0t/8QVSGMQ5PX8cPgvi7iiT+QSNn4LeNPFnmVD?= =?utf-8?q?tX3LOhVBCr/KOvc+2TyYIwBL2aRug2sjVDMgPffHJkiRwHQFU047vnNTuGQhFv91T?= =?utf-8?q?bkd3dk6bnWUkYhH5Ds3DBk/spNL4VvbCLqhLCXyShMSjk5Zf3XLSAehdgCDKULxIh?= =?utf-8?q?685clwzcdSkTMkg2bbmEUC8YOOJxIIcp38o8MxNhDSb1CYqpcF0myLu8sQgen87nt?= =?utf-8?q?4SYdSbklBj5pfZijRkKhg=3D=3D?=
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMessage-ID=3ACont?= =?utf-8?q?ent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCheck=3B?= =?utf-8?q?bh=3DPALNGTLT/oHMoU/C5AofNyLN9M2pGreiIoWVGaWlqX0=3D=3B_b=3DMHKjyv?= =?utf-8?q?zvB6a/9/l8fy/KUuvhSKJE6kcwQ3II/AG50PI+FGUIhzUnzvRxSRvaWN3PK17D95p?= =?utf-8?q?7MSvn1uO+LldSLKb0/ozgmT+Oa5Bn0LJHf4sUnqOXBsFpYZLyfEJqo0PddeDtANAB?= =?utf-8?q?OGR25dz09hhVkcAnt1NU/v1/zsvP7LFaqXH4Wm3YZI8Eg+Ar23Rwl76KXfYDpPcDt?= =?utf-8?q?CCR5YqXaN10Ee5wDQvmhaFStD9UOrxsSkuk0c0P17n093wptQ0MluNnPP0yXsWhRC?= =?utf-8?q?fBpngEIT9StsV1wrKyiDu8Ydxwc2Yr7feZ0RiMorjFwHF5vvjDr3qVbuvkdj7Fvcz?= =?utf-8?q?xZAlPyTEdvQ=3D=3D?=
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; =?utf-8?q?h=3DFrom=3ADate=3ASubject=3AMe?= =?utf-8?q?ssage-ID=3AContent-Type=3AMIME-Version=3AX-MS-Exchange-SenderADCh?= =?utf-8?q?eck=3B_bh=3DPALNGTLT/oHMoU/C5AofNyLN9M2pGreiIoWVGaWlqX0=3D=3B_b?= =?utf-8?q?=3Dl0kp3Lj50cca5mNIerObV8A//2lq6ET1mzVBRxWXg1jM7g3G+QZdjASIqVa2Gl?= =?utf-8?q?spcj8WfnJwTvp5xE/CmviW1svVXiU39AbbKDsgdSdbu253l+tamoOmokWXmp7ZmXM?= =?utf-8?q?/kCw39r3VjUjGFPE7L3FgZyu3RkjM03SMWjGneXx+xTc=3D?=
Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (52.135.163.143) by AM6PR08MB4849.eurprd08.prod.outlook.com (10.255.96.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.17; Wed, 11 Mar 2020 14:36:05 +0000
Received: from AM6PR08MB3318.eurprd08.prod.outlook.com ([fe80::d07a:6da4:fdf1:781c]) by AM6PR08MB3318.eurprd08.prod.outlook.com ([fe80::d07a:6da4:fdf1:781c%5]) with mapi id 15.20.2793.013; Wed, 11 Mar 2020 14:36:05 +0000
From: Hanno Becker <Hanno.Becker@arm.com>
To: Christopher Wood <caw@heapingbits.net>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Gaps in specification of DTLS 1.3 state machine
Thread-Index: AQHV8i/kjOxEBgrL9k2vj+OAIfvymqg5FgqAgABtZ86AAJGZAIAJWxuAgAAL1jM=
Date: Wed, 11 Mar 2020 14:36:05 +0000
Message-ID: =?utf-8?q?=3CAM6PR08MB3318CDC2315FC9F074C8906B9BFC0=40AM6PR08MB3?= =?utf-8?q?318=2Eeurprd08=2Eprod=2Eoutlook=2Ecom=3E?=
References: =?utf-8?q?=3CAM6PR08MB331811E58E80173B1D74D8349B1C0=40AM6PR08MB3?= =?utf-8?q?318=2Eeurprd08=2Eprod=2Eoutlook=2Ecom=3E?= =?utf-8?q?=3C0287f75a-015e-49eb-a052-cf7a53f03035=40www=2Efastmail=2Ecom=3E?= =?utf-8?q?_=3CAM6PR08MB33182017F0D9EA53A8B247DF9BE20=40AM6PR08MB3318=2Eeurp?= =?utf-8?q?rd08=2Eprod=2Eoutlook=2Ecom=3E?= <CABcZeBMKAyTBNCpEMZksZxv5PeJZPPQzykhE7ZNeZ366zLYpYw@mail.gmail.com>, <f06035d2-5f46-4eed-95c4-88faf62f4253@www.fastmail.com>
In-Reply-To: <f06035d2-5f46-4eed-95c4-88faf62f4253@www.fastmail.com>
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: eafa624f-3100-4f27-7ad1-08d7c5c98be8
X-MS-TrafficTypeDiagnostic: AM6PR08MB4849:|AM6PR08MB4392:
X-Microsoft-Antispam-PRVS: =?utf-8?q?=3CAM6PR08MB43928EF975EC6A92B4D6C1C29BF?= =?utf-8?q?C0=40AM6PR08MB4392=2Eeurprd08=2Eprod=2Eoutlook=2Ecom=3E?=
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 0339F89554
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; =?utf-8?q?SFS=3A=2810009020?= =?utf-8?b?KSg0NjM2MDA5KSgzOTg2MDQwMDAwMikoMTM2MDAzKSgzOTYwMDMpKDM0NjAwMiko?= =?utf-8?b?Mzc2MDAyKSgzNjYwMDQpKDE5OTAwNCkoMTg2MDAzKSgzMzY1NjAwMikoMTEw?= =?utf-8?q?136005=29=2871200400001=29=2855016002=29=289686003=29=28316002=29?= =?utf-8?q?=2819627405001=29=2853546011=29=288676002=29=2881166006=29=288115?= =?utf-8?b?NjAxNCkoNjUwNjAwNykoMzA4NjQwMDMpKDQ3ODYwMDAwMSkoOTY2MDA1KSg4?= =?utf-8?q?6362001=29=287696005=29=282906002=29=2852536014=29=285660300002?= =?utf-8?b?KSg2Njk0NjAwNykoNjQ3NTYwMDgpKDc2MTE2MDA2KSg5MTk1NjAxNykoNjY0?= =?utf-8?q?76007=29=2866446008=29=288936002=29=2866556008=29=2826005=29=3B?= DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4849; H:AM6PR08MB3318.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1;
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: =?utf-8?q?hos1Oy55OdPHPlRZFTugCY?= =?utf-8?q?zNlg8NdweJWLP8Aov/N6OKN+KdKoF0QDV9d8V2OYKLQrBDWGYSviMrz7cBpEkt33Q?= =?utf-8?q?1Dz6QbtVr0Nv7RJe8llIjFJXJPiv70C3Tr+q6JV4axQu2hu/Euvx8MDAS7Pz9KQu5?= =?utf-8?q?Br4Mqz6yJSZOk8MU0MtxCJEnDkNRXHAtXRSbgzuNqt9jWYK+KeLVj+sJPoZHLf4Nr?= =?utf-8?q?SERIMds2AZAtJnz0i0MwjOQdoJM2zJuT/wE3uQlHaYtstL2TmttnWNFnL1APOkF4m?= =?utf-8?q?e1T/GCF+kjlFQC4U4MPhzRd97m98rf0uDN57/Rwyua/eSKyeKp5HwOx3aTdVDsl7W?= =?utf-8?q?W82jhcuKL2iGKm272BTzQxeoJcklP+ivrmVzLwO+wPWOhJ7bv1riiw9TfloE3zUhh?= =?utf-8?q?yF6QyX9tASOjr1DswreykdqrKXpumXkeBMvQ5W1xUkFD6f/7H2cRkEFqXht4S3M5m?= =?utf-8?q?d9juUlLTPhqiovXRrAJyt5pEjwevBHmqgbh4r+pwdtVQCJTlJxm55JrPA=3D=3D?=
x-ms-exchange-antispam-messagedata: =?utf-8?q?aXyTCkpW+e3KBgJKIhozbbHTT0ywIa?= =?utf-8?q?/pA1pQzHgQsCIExhRz9OOzp7RHyNnluObXrA6CrJaU/nIf6aTRa+4vmB4eD6y0olc?= =?utf-8?q?dvcHuzwtVAxyhKtlzyUWiUIAPjVpWEkOTwMoH3yB9AVGJw9qPxELGGA=3D=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3318CDC2315FC9F074C8906B9BFC0AM6PR08MB3318eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4849
Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT064.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; =?utf-8?b?U0ZTOigxMDAwOTAyMCkoNDYzNjAwOSkoMzc2MDAyKSgz?= =?utf-8?b?NDYwMDIpKDM5ODYwNDAwMDAyKSgzOTYwMDMpKDEzNjAwMykoMTk5MDA0KSgx?= =?utf-8?q?10136005=29=2870586007=29=285660300002=29=2830864003=29=288636200?= =?utf-8?b?MSkoMzM2NTYwMDIpKDUyNTM2MDE0KSg1NTAxNjAwMikoMzM2MDEyKSg1MzU0?= =?utf-8?b?NjAxMSkoNjUwNjAwNykoNzY5NjAwNSkoNzAyMDYwMDYpKDI5MDYwMDIpKDk2?= =?utf-8?q?6005=29=2836906005=29=2881166006=29=289686003=29=28478600001=29?= =?utf-8?q?=2819627405001=29=2881156014=29=288676002=29=2826826003=29=282600?= =?utf-8?b?NSkoMzU2MDA0KSgzMTYwMDIpKDE4NjAwMykoODkzNjAwMikoNTc5MDA0KTs=?= DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4392; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1;
X-MS-Office365-Filtering-Correlation-Id-Prvs: 289f0832-fe9a-4033-45da-08d7c5c987c7
X-Forefront-PRVS: 0339F89554
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: =?utf-8?q?xXbY+/IrEh10jnTjRl2DEPvjmp64Ywt?= =?utf-8?q?lSS62QEE1pCbSUZKaFuX/bYurrchtgW6t+ddLf5bgjzSTXaC7OqQKsW/5QuvLqe9r?= =?utf-8?q?YxETPR9VvNR+91bNnvvMR2rGaVhtlKyE0+3/V4Wz00BVXH1HVWt3IkX5uLCNb/rW8?= =?utf-8?q?O5S8QMH6oTvDc35Gj449kB7ckCbqEb+Az47rZCrv8Fa6Ana5M8BJkK0LHVFtn9mo9?= =?utf-8?q?RdSZNmqwP9OkIJy2wrI6Dgywnz4Julxwya829FVyZRK4Sy4r5cLx4H+qBjWloRUaC?= =?utf-8?q?GbRHANdeGb50KXGvH9WIVE4fKP+hFk1SpRr66zbJXNEg9T3uVt9SYI+bkZq866tCW?= =?utf-8?q?cXQTIeUJqGhEjRd+aGY2sRipgPyjzVpONvKgfvRd0fYm0Rk3SP2rgSlBpVvdWjl+p?= =?utf-8?q?E6enpeflnMyeMwC8ozJwgMqnEK70lHmoDK1FyWu/JLSB2bnaoLoI/A5hsS+D/FiP6?= =?utf-8?q?lyuHuppqtLaK8lrzPOdW/go9c8f0jCxHE3baibMReUfUvUGA=3D=3D?=
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Mar 2020 14:36:12.1170 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: eafa624f-3100-4f27-7ad1-08d7c5c98be8
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: AM6PR08MB4392
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-2mEhtFLF3M-uWi0KxIdN4kAMK0>
Subject: Re: [TLS] Gaps in specification of DTLS 1.3 state machine
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: Wed, 11 Mar 2020 14:36:22 -0000

Thanks Eric, Martin and Chris for your input!

For the record: I withdraw my claim that there's an issue with handshake message reordering
and the transcript, as already pointed out by Eric and Chris. I also don't see any other issues
at the moment with what appears to be the preferred model of duplicated state machines
that would require technical changes to the specification.

However, I do believe that the duplication of state machines is non-trivial enough to merit
explicit mentioning in the specification. In particular, if I understand things correctly, it appears
that it increases the implicit interface between the handshake logic 'layer' (which should be
as similar to that for TLS 1.3 implementations as possible) and the underlying 'messaging' layer,
including the retransmission state machine: For example, the retransmission state machine cannot
infer which handshake message belongs to which state machine on its own on the basis of handshake
metadata. Instead, this information needs to be provided by the handshake logic after inspecting the
message content. As a concrete example, one can consider multiple CertificateRequest messages
being sent from Server to Client. When the Client responds to one of them, it is only on parsing
of the certificate request context that it becomes clear which state machine the message belongs to.
Hence, in a nutshell, while for the main handshake the signaling between handshake logic layer
and messaging layer is confined to indicating when a flight or handshake is over, the duplication
of state machines seems to add complexity by requiring to add a signal indicating which state
machine an incoming message belongs to. Similarly, when sending messages, it needs to be
indicated which state machine they belong to.

Overall, I believe that it would be beneficial if the abstract model for the retransmission state
machine - including the state machine duplication for post-handshake messages - received
some more attention and (potentially formal) analysis.

Cheers,
Hanno
________________________________
From: TLS <tls-bounces@ietf.org> on behalf of Christopher Wood <caw@heapingbits.net>
Sent: Wednesday, March 11, 2020 1:37 PM
To: TLS@ietf.org <tls@ietf.org>
Subject: Re: [TLS] Gaps in specification of DTLS 1.3 state machine

Thanks for raising this issue and for the discussion, folks!

Given that endpoints *process* handshake messages in sequence, thereby preventing any out-of-order processing issues raised earlier on this thread, the chairs think no further action is needed to address this comment.

Thanks,
Chris, on behalf of the chairs

On Thu, Mar 5, 2020, at 6:45 AM, Eric Rescorla wrote:
> Hanno,
>
> I do think you are overcomplicating things somewhat.
>
> You can't process handshake messages out of sequence even if they are
> received out of sequence (this is, of course, also the case in TLS,
> it's just that the resequencing happens at the TCP layer).. You have to
> either drop out of order messages or buffer them. Yes, this is
> somewhat irritating, but as you demonstrate below, it's inherent
> in the design of post-handshake messages even if each side is
> only allowed to initiate one transaction at a time.
>
> It might be useful to explain this in the text, but I don't think
> anything else is needed..
>
> -Ekr
>
> On Wed, Mar 4, 2020 at 11:00 PM Hanno Becker <Hanno.Becker@arm.com> wrote:
> > Thanks Martin for your thoughts.
> >
> > > It's unavoidable in any case. If you generate your own post-handshake message and
> > > then have to respond to post-handshake authentication, there will be two concurrent
> > > exchanges.
> >
> > Yes that's an instance of the second question b) which the post didn't further go into.
> >
> > I'm not yet convinced that this situation unavoidably creates the need for duplicating state machines, though, and think that if possible we should avoid it for the sake of implementation simplicity.
> >
> > Moreover, even if it is acceptable that state machines should be duplicated, it isn't clear (to me) how to logically separate them because they're all tied together by the use of the same global handshake sequence number. This creates non-trivial ambiguities like the following:
> >
> > Imagine after the handshake the server requests post-handshake authentication while, simultaneously, the client initiates a key update. When the server receives the KeyUpdate, it assumes from the handshake sequence number that it is the reply to his CertificateRequest, and only when inspecting the type of the handshake message it'll notice the mismatch. Usually, a type mismatch would be treated as a protocol violation and lead to failure of the connection, while here, we'd need the server to drop the message or notice that it should fork a new state machine.
> >
> > Note that this problem already exists, albeit in less prominent form, in DTLS 1.2, where both sides may simultaneously trigger a renegotiation.
> >
> > Thinking about it, it seems that the way to make this work is to segregate the part of the retransmission state machine which establishes in-order delivery via handshake sequence numbers, and to have the duplicated contexts one level higher. When a handshake message comes in, it would be trial-fed into all existing contexts, either until one of them accepts it after checking type and content, or potentially leading to the forking of a new context.
> >
> > However, this asynchronous nature of handling multiple post-handshake messages is in conflict with the serialized nature of the handshake transcript used e.g. in the CertificateVerify message:
> >
> > Imagine a post-handshake client authentication to happen interwoven with another post-handshake message from client to server. When the client writes the CertificateVerify, that would require the transcript of the entire handshake up until the CertificateVerify message. Assuming this should include all post-handshake messages, not just those belonging to the client authentication, this may lead to the situation where the server receives a CertificateVerify message with a transcript it cannot validate because it hasn't yet received all other authentication-independent post-handshake messages that went into the transcript.
> >
> > Maybe I'm overcomplicating things, but as it stands it seems to me that the above are serious issues to be further discussed and clarified even if we accept state machine duplication.
> >
> > Happy to hear your thoughts.
> >
> > Cheers,
> > Hanno
> > *From:* TLS <tls-bounces@ietf.org> on behalf of Martin Thomson <mt@lowentropy.net>
> > *Sent:* Wednesday, March 4, 2020 11:32 PM
> > *To:* tls@ietf.org <tls@ietf.org>
> > *Subject:* Re: [TLS] Gaps in specification of DTLS 1.3 state machine
> > Option A please. Multiple state machines.
> >
> >  It's unavoidable in any case. If you generate your own post-handshake message and then have to respond to post-handshake authentication, there will be two concurrent exchanges. We already require acknowledgment for both request and response in a two-way exchange. Since 2 is a member of the third class of numbers (0, 1, ∞), we might as well deal with the full implications of that.
> >
> >  Handling this is fairly simple though. We can recommend limiting to only one active transmission at a time. And if implementations have an especially low tolerance for concurrency they can close connections.
> >
> >  On Thu, Mar 5, 2020, at 01:19, Hanno Becker wrote:
> >  > Hi,
> >  >
> >  > [TL;DR]
> >  > The DTLS 1.3 spec (draft 34) doesn't fully describe the retransmission state
> >  > machine in the case of post-handshake messages, which requires clarification.
> >  > For example, is it allowed to send multiple post-handshake messages without
> >  > waiting for ACKs for the previous ones? If so, how is the retransmission
> >  > state machine modeled for sender and receiver in this case?
> >  > I'll describe and assess a few possible options, but I don't know the best
> >  > answer, and so this post is mostly a request for discussion, hopefully
> >  > resulting in some common understanding and clarification of the spec.
> >  >
> >  > Details:
> >  >
> >  > The following cases need addressing:
> >  > a) Is it allowed to send multiple post-handshake messages (e.g.,
> >  > multiple session
> >  > tickets) without waiting for ACKs for the previous ones? If so, how is
> >  > the
> >  > retransmission state machine modeled for sender and receiver in this
> >  > case?
> >  > b) How should simultaneous sending/receiving of post-handshake messages
> >  > be handled?
> >  > The current retransmission state machine doesn't allow sending and
> >  > receiving
> >  > at the same time.
> >  >
> >  > Some thoughts on a) first:
> >  >
> >  > The spec mentions that post-handshake messages are treated as
> >  > single-message flights.
> >  > As such, the sender would enter WAITING state after sending the
> >  > post-handshake message,
> >  > and move to FINISHED on receipt of the corresponding ACK. This,
> >  > however, forbids sending
> >  > another post-handshake message in between, since sending isn't allowed
> >  > in WAITING state.
> >  >
> >  > Option A: Fork state machine
> >  >
> >  > One could circumvent this by 'forking' the retransmission state machine
> >  > for post-handshake
> >  > messages, i.e. declaring their semantics as if there were multiple
> >  > independent state machines
> >  > for each outstanding post-handshake message. This essentially degrades
> >  > the DTLS' ACK scheme
> >  > to a per-message acknowledgement.
> >  >
> >  > I believe that such an approach is not in the spirit of the rest of the
> >  > protocol and moreover
> >  > significantly increases complexity and thereby comes at the danger of
> >  > slower adoption and/or bugs.
> >  > Moreover, it will significantly harden efforts for formal verification,
> >  > which should be considered
> >  > in light of previous efforts on TLS 1.3.
> >  >
> >  > Option B: Don't allow multiple post-handshake messages
> >  >
> >  > Forcing implementations to await an ACK before sending the next
> >  > post-handshake message is a theoretical
> >  > option which would allow to stick to the existing state machine.
> >  > However, this significantly increases
> >  > the latency of, say, the delivery of multiple session tickets, which is
> >  > a valid use case. This is therefore
> >  > not a convincing option, either.
> >  >
> >  > Option C: Merge consecutive post-handshake messages into a single flight.
> >  >
> >  > Another approach would be to treat multiple post-handshake messages as
> >  > a single flight on the sender.
> >  > That is, when the sender is in state WAITING after sending the first
> >  > post-handshake message, and the
> >  > user request to send another one, it moves into SENDING and then back
> >  > into WAITING as usual, appending
> >  > the new post-handshake message to the (so-far single-message) flight.
> >  >
> >  > How would that be handled on the receiver side?
> >  >
> >  > That's not entirely clear because a basic property of the TLS handshake
> >  > that DTLS leverages now no longer
> >  > holds: Namely, that both sides implicitly know and agree on the bounds
> >  > of flights. Here, multiple post-
> >  > handshake messages would be treated as a single flight on the sender,
> >  > but the receiver doesn't know
> >  > when the flight is over. How should this be handled?
> >  >
> >  > This is to be explored further. One way to address this would be the following:
> >  >
> >  > Option D: Add an 'end-of-flight' signal to handshake messages to allow
> >  > dynamic-length flights.
> >  >
> >  > Recall that the handshake logic must inform the retransmission state
> >  > machine about when a flight
> >  > is over in the main handshake, allowing the state machine to transition
> >  > accordingly. This signal,
> >  > however, isn't explicitly conveyed to the receiver, because the
> >  > receiver can figure it out for
> >  > himself.
> >  >
> >  > As mentioned, this isn't true anymore for batched post-handshake messages.
> >  >
> >  > One simple way to deal with is to add an explicit 'end-of-flight' bit
> >  > in the handshake header
> >  > which informs the receiver about when a flight is over, in those
> >  > situations where it's not
> >  > clear from the context.
> >  >
> >  > This would allow to keep a single retransmission state-machine as-is
> >  > while allowing for
> >  > batched post-handshake messages such as multiple session tickets.
> >  > Moreover, such a signal
> >  > would be trivial to implement because it's already implicit in the main
> >  > handshake.
> >  >
> >  > For the wire-format, we can discuss different options, but that's an
> >  > orthogonal question
> >  > to the issue of finding the correct conceptual approach.
> >  >
> >  >
> >  >
> >  > Happy to hear everyone's thoughts. It would be great if we could come
> >  > up with some
> >  > precise description of the state machine evolution for post-handshake
> >  > messages that
> >  > is both simple and supports batched post-handshake messages.
> >  >
> >  > Best,
> >  > Hanno
> >  > 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.
> >  > _______________________________________________
> >  > TLS mailing list
> >  > TLS@ietf.org
> >  > https://www.ietf..org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> >  >
> >
> >  _______________________________________________
> >  TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >  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.
> >  _______________________________________________
> >  TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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.