[TLS] Gaps in specification of DTLS 1.3 state machine

Hanno Becker <Hanno.Becker@arm.com> Wed, 04 March 2020 14:19 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 CB4BB3A0FBD for <tls@ietfa.amsl.com>; Wed, 4 Mar 2020 06:19:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=eA/Rfv84; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=eA/Rfv84
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 eudkJrbMdZkO for <tls@ietfa.amsl.com>; Wed, 4 Mar 2020 06:19:33 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20071.outbound.protection.outlook.com [40.107.2.71]) (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 F34C43A0F9D for <tls@ietf.org>; Wed, 4 Mar 2020 06:19:32 -0800 (PST)
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=U4ZQyPFahOm2wrQpMLyWOqL4zbk/FLsNe/EQRYwcUDU=; b=eA/Rfv84K1/C9Vy8U4dBF93VMIgwJGEN6qqrg1kBAphN2k3g7AjThdatmxpf8CGMUYjaIL48EzGfj0OXR01L+h+liRlzog4+W9xYMqPifVm2TFQKm497mr+oC4pmzubGhJdF7yJ9f7G2Ey2Z7X7bVzFU7YiBJiMUbzUpq+bIPpM=
Received: from VI1PR08CA0166.eurprd08.prod.outlook.com (2603:10a6:800:d1::20) by AM0PR08MB4113.eurprd08.prod.outlook.com (2603:10a6:208:129::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.18; Wed, 4 Mar 2020 14:19:29 +0000
Received: from VE1EUR03FT053.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::200) by VI1PR08CA0166.outlook.office365.com (2603:10a6:800:d1::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.18 via Frontend Transport; Wed, 4 Mar 2020 14:19:29 +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 VE1EUR03FT053.mail.protection.outlook.com (10.152.19.198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.11 via Frontend Transport; Wed, 4 Mar 2020 14:19:29 +0000
Received: ("Tessian outbound d1ceabc7047e:v42"); Wed, 04 Mar 2020 14:19:29 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: ed190aa233fca89d
X-CR-MTA-TID: 64aa7808
Received: from 33ab6d3142fb.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id C835BD67-82D7-45D7-B6E9-60D2EB58689B.1; Wed, 04 Mar 2020 14:19:24 +0000
Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 33ab6d3142fb.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 04 Mar 2020 14:19:24 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=odAAWIjYbVGrOB2o7kZj/OQ2R2nJpjKXZRlcgMGbAyzpk04lknDRQM9mDsrbFG818YkJt6EEq5v1b81m232u2xBUNlwTbLcY52OdoRXAQeMJN+Txq1AKrMVFjP2+oXbHW3/dNXuJS35JKQWwuKHnF2HpD0X3WVVmwDPmu9PKCCJaZrF5WVcYzQNeY+rrpJHw7ZyLkzy6L0TcgncB8aXIr5L2nt0nquKMe3JCqg7O+aSk4qB4lDwVvhAzO6FsGaHt0LPNYQb89Z83/a7EjhfXTVmK8bsc3ov4fKL3kVWGonpYFfmUMj6jUPTIJbPrOtMZMfAJDv5eKJa3bn7OY3y55w==
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=U4ZQyPFahOm2wrQpMLyWOqL4zbk/FLsNe/EQRYwcUDU=; b=Up2n9OoBqYchnugKi09cZlS/pBUNr2Rjvoi1db5F6E1bMXEl4C++ctpf8FZQstHpdLWDCKYq2x9Vu75XWaGIoNzFtgCAAKvbm7ffID/nyHyvuf6eUiE6l7MNS7V7PFBK1RgDXJJyP/ijQvq4uFxAABHRAkQbIe6cwM/H888bb2ZEgRbJ2uVjO/xm8D1RM/hHQrKZKMUl0MexLM93XDhGcgGIQAQUxhfDMse/tlvLX5dhZcTGkJYhwLO7wwbpVOUsIiX+3UrcShHoQ6GalLTQgtaPpqBuljplIL2/7YHnlmlaVDz3ekXs3m8hGybAgEAAzl2KKw0PlJ3X7j/KAxWaeQ==
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=U4ZQyPFahOm2wrQpMLyWOqL4zbk/FLsNe/EQRYwcUDU=; b=eA/Rfv84K1/C9Vy8U4dBF93VMIgwJGEN6qqrg1kBAphN2k3g7AjThdatmxpf8CGMUYjaIL48EzGfj0OXR01L+h+liRlzog4+W9xYMqPifVm2TFQKm497mr+oC4pmzubGhJdF7yJ9f7G2Ey2Z7X7bVzFU7YiBJiMUbzUpq+bIPpM=
Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (52.135.163.143) by AM6PR08MB4818.eurprd08.prod.outlook.com (10.255.98.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Wed, 4 Mar 2020 14:19:22 +0000
Received: from AM6PR08MB3318.eurprd08.prod.outlook.com ([fe80::cc7b:fca1:7ea2:9c61]) by AM6PR08MB3318.eurprd08.prod.outlook.com ([fe80::cc7b:fca1:7ea2:9c61%6]) with mapi id 15.20.2772.019; Wed, 4 Mar 2020 14:19:22 +0000
From: Hanno Becker <Hanno.Becker@arm.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Gaps in specification of DTLS 1.3 state machine
Thread-Index: AQHV8i/kjOxEBgrL9k2vj+OAIfvymg==
Date: Wed, 04 Mar 2020 14:19:22 +0000
Message-ID: <AM6PR08MB331811E58E80173B1D74D8349B1C0@AM6PR08MB3318.eurprd08.prod.outlook.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.106.49]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: 1d5031e9-5856-46ca-c367-08d7c0470d7b
X-MS-TrafficTypeDiagnostic: AM6PR08MB4818:|AM0PR08MB4113:
X-Microsoft-Antispam-PRVS: <AM0PR08MB411301D44EBF9003E55116809BE50@AM0PR08MB4113.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 0332AACBC3
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(366004)(346002)(396003)(376002)(199004)(189003)(76116006)(6916009)(26005)(71200400001)(478600001)(81156014)(2906002)(186003)(19627405001)(33656002)(81166006)(7696005)(8676002)(66476007)(5660300002)(66946007)(64756008)(9686003)(8936002)(6506007)(66446008)(52536014)(55016002)(86362001)(316002)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4818; H:AM6PR08MB3318.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: eJ20qlZRstAkWSOjRTztxZ9hdE9yvtYj9Gm/TWiNSVRXGdZ2P2Iwin7qTcAqWRlqssxbvLJ2IR5PM+CtdwJ8vMOK9DG9sCtic+aIPAFm71foZ8/ZExBWLXHEFrVUBYVTZg61mCiDeWcA/tZto/lUR7Y2Ay+9lgfrjVIiEpt8BX7KPn/ACkMQTBCcsLRk/raCZiAyKDFDZckh0bkPNCiDDGfIZBEqKTTGyVjFVPWCNp+eStvGz9XxVdilhjw6+sNAJgyn1NAaiZc8BqF3JlWiUnwykQUGkWEmLCbsI7Y1xABq7UQ4tHjvx2x+SPpArjEWHQIlbmbMmuULXP7rKq94E44cwpFVBhzaC8G+t/r+UVhj1jcTPmGzaLvu+Zyy3V9YNXIPyUboLAsQsY+rNQmGakaLE+29zjlDyCV5qqkIVKuR0Ydg2Z7z/IFMY4NaenOw
x-ms-exchange-antispam-messagedata: 8nKD25F8snsoCu9wtTEoW8Ut1i6ORVvu88qcMYFvc8y1rGGTloXQ8RwxJo1fMDNWMUTHwzLDOQxzLZffxmJutLGrqz4P9EvKKyjBhWdcVm4unQsbgHPTnA5ywgfWb7WzcsZb504Ig1hjSxo10ERr1A==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM6PR08MB331811E58E80173B1D74D8349B1C0AM6PR08MB3318eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4818
Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT053.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; SFS:(10009020)(4636009)(346002)(396003)(136003)(39860400002)(376002)(199004)(189003)(5660300002)(26826003)(186003)(478600001)(336012)(316002)(36906005)(7696005)(2906002)(30864003)(6916009)(86362001)(356004)(9686003)(52536014)(33656002)(26005)(19627405001)(6506007)(81156014)(70586007)(55016002)(8936002)(81166006)(70206006)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR08MB4113; 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; MX:1;
X-MS-Office365-Filtering-Correlation-Id-Prvs: ba22dab3-e888-491e-0cd4-08d7c04708ef
X-Forefront-PRVS: 0332AACBC3
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: PyADoHo1mMF58Lzk5Bu2SK7+dIKviNjjmhhqTIRygismE4MWyA0x2zuHNYZnlEEhCXnUcnL1iMABg4QiHH4QX6A2w2HINEz+1bg5lHWBenyHCj8qA4Nb4lVn8QXmK5PVoNzNVf8yieP1q9d2yRPYtc2yHFGy8Dkkebqgv/q2wtA15q7gDFuMkqdVlN02UWNYl2Ypq6vm+L+8iMnj2nFoUSr9hx719LNfyr2SK0FfpPXbZBHUF2jCRUfmV2D2Yq95GpUx9pGGpOiIXK/sqPN5hj4lTUOWyS9pSlq9eVO8lKNBavmK9J6d3LE7P7s/GebjeasJ0Y2XWHDVQCpVkwCelUZRn/vQX5TyogJKND1EY6dLSNYoVpHyAGDAbbCSh7G7qHtBZs0N9F8pLC0NfrRH+HN3RR1L1r5HUFtidejAkdm3nCjPZ1h7soSHU590rhB1
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Mar 2020 14:19:29.6202 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d5031e9-5856-46ca-c367-08d7c0470d7b
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: AM0PR08MB4113
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5POTK5AMrkZz5VAH3asSCLV35rk>
Subject: [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, 04 Mar 2020 14:19:36 -0000

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.