[TLS] Record-level ACKs in DTLS 1.3
Hanno Becker <Hanno.Becker@arm.com> Fri, 28 February 2020 11:50 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 D64B63A1692 for <tls@ietfa.amsl.com>; Fri, 28 Feb 2020 03:50:29 -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=ekMrwBqo; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=ekMrwBqo
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 jAKZlIGV9AMD for <tls@ietfa.amsl.com>; Fri, 28 Feb 2020 03:50:27 -0800 (PST)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70044.outbound.protection.outlook.com [40.107.7.44]) (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 C01643A168F for <tls@ietf.org>; Fri, 28 Feb 2020 03:50:26 -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=nB/sMnIDmlP0B94QI+fsYX1qtlgf98mvs4urYuAushg=; b=ekMrwBqoWlJ/bO7MyN6UoBCbXMSaQ00NbGpqZbILNd+fuMeCxvWvFRjJUFhAQRUSuJNjnWI3veE1Yl10JVC0OKAgJpBqkZahTn/l+Gzpm7gtznYdKCKx4gbDfZVWjJRW3Z8XjQ2Dhtt6WDEWAwD2JDZvucYMzRHECATitDHGOPs=
Received: from VI1PR0801CA0080.eurprd08.prod.outlook.com (2603:10a6:800:7d::24) by AM7PR08MB5350.eurprd08.prod.outlook.com (2603:10a6:20b:101::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Fri, 28 Feb 2020 11:50:23 +0000
Received: from VE1EUR03FT032.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::206) by VI1PR0801CA0080.outlook.office365.com (2603:10a6:800:7d::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14 via Frontend Transport; Fri, 28 Feb 2020 11:50:23 +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 VE1EUR03FT032.mail.protection.outlook.com (10.152.18.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15 via Frontend Transport; Fri, 28 Feb 2020 11:50:23 +0000
Received: ("Tessian outbound 1f9bda537fdc:v42"); Fri, 28 Feb 2020 11:50:23 +0000
X-CheckRecipientChecked: true
X-CR-MTA-CID: 2902b3e5e1af02cb
X-CR-MTA-TID: 64aa7808
Received: from 69ee9bda03f1.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 764FE611-45E3-4AB3-B315-DE89D4C2B714.1; Fri, 28 Feb 2020 11:50:17 +0000
Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 69ee9bda03f1.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 28 Feb 2020 11:50:17 +0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=judhal980Up4j3wfIsti2taFSR6y8sd9KVt7icVQCaPTjyJp2EP+WchJ6xT8jo0Ai2FOKGbl9VVQjHIBds1eh3/ivhvyrSTu6Bl79Eoz0SoQDqk+kbfm6a87DIfjf57coxOBnTKn5RU7b7U1WvoB5VM4TXGmwtLTWh2hPzflKLF//d4f/I7zfKvftO48OMZRwkb7iYQNEXh12U3uZUWmbYjZ3bfJ0VBNPsOVkAXK3bnUIY6bHNTCrARbwWfPq0khZ655ueX2hmkZ5mYUEg3KV+YkJgmND6TVAcBLTODcsZAVgh7lLnXZjF4Afh+K02xtedmaBkJH3M1BXHmtRO2cug==
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=nB/sMnIDmlP0B94QI+fsYX1qtlgf98mvs4urYuAushg=; b=gRqGcqqWhG839H/fWeHo8UBZmRn94iahzUEF5YHVoIZvjq3aFWW702rd2UgAjBbPXcwK9HdlUX1WohV4ChxAZkesL3cvyXxHoLeID2dl0E2hvxLuvuqjpNrd2AX0TN/MLi3i163g3nuTbLWwLnkSqOdjaVQexDFm9CN/eCGrg9oF6ia90RC518QxP13fGlO6Md2Jv8sw3ZchxkkVcgmHz6UTKwhAMvtXxi/28FLEzr94rf7cPytGvjGbHGyBRltj2CQoVPDK0OZfJWHPbZJT0YB98yWxaZxske2mhE/Oswx6pCAstBDmfGiLwotETkcb6DgHlHl8R0pMB/sPURJ9iw==
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=nB/sMnIDmlP0B94QI+fsYX1qtlgf98mvs4urYuAushg=; b=ekMrwBqoWlJ/bO7MyN6UoBCbXMSaQ00NbGpqZbILNd+fuMeCxvWvFRjJUFhAQRUSuJNjnWI3veE1Yl10JVC0OKAgJpBqkZahTn/l+Gzpm7gtznYdKCKx4gbDfZVWjJRW3Z8XjQ2Dhtt6WDEWAwD2JDZvucYMzRHECATitDHGOPs=
Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (52.135.163.143) by AM6PR08MB4005.eurprd08.prod.outlook.com (20.179.0.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Fri, 28 Feb 2020 11:50:16 +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.2750.021; Fri, 28 Feb 2020 11:50:16 +0000
From: Hanno Becker <Hanno.Becker@arm.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Record-level ACKs in DTLS 1.3
Thread-Index: AQHV7ix8mXje6TWNu0+lhHSpDYxOZA==
Date: Fri, 28 Feb 2020 11:50:16 +0000
Message-ID: <AM6PR08MB3318E5A347314EB509AC91759BE80@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.52]
x-ms-publictraffictype: Email
X-MS-Office365-Filtering-HT: Tenant
X-MS-Office365-Filtering-Correlation-Id: d27e4664-93f1-4e51-1645-08d7bc44650b
X-MS-TrafficTypeDiagnostic: AM6PR08MB4005:|AM7PR08MB5350:
X-Microsoft-Antispam-PRVS: <AM7PR08MB53507B4BD88EF527503CE7719BE80@AM7PR08MB5350.eurprd08.prod.outlook.com>
x-checkrecipientrouted: true
nodisclaimer: true
x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000;
x-forefront-prvs: 0327618309
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(346002)(39860400002)(376002)(366004)(189003)(199004)(81156014)(19627405001)(81166006)(8676002)(52536014)(478600001)(316002)(5660300002)(33656002)(9686003)(2906002)(55016002)(71200400001)(8936002)(86362001)(186003)(6506007)(7696005)(6916009)(64756008)(66556008)(66476007)(66946007)(66446008)(26005)(76116006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4005; H:AM6PR08MB3318.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; 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: tKJKc+rGFfbLptgdSVQnc3ET7P68qCHu9qwoXvGWm3hRGRudA57dhNE4WtYi30hY3gC3yBnu2RcvWd+AnBzShEa8t8Db3EUEzmGZn0FFzDroHgTUUKTU1dNTMdzLz7+fE7Lz5tFXEXFgAbL3y50TBNEZI8UfYPngyCFwoZmv+1bBBt6qDYQ8BCCIWSzMyDynWw4o88B7UDPs9OlN0vcLW4NYBo5/dOw91m4OikG9zBb/L6yDJZEVhxX6iw4/xWsNzdQJpJLf1oEq8BYn8j/pjYyT0fg+BUPw5AVbgS5JawijPQfVaY4sF92Q4lyl3a96DohxAsQ+s9OkacaIaDTCivgBJsoLwvqasIUGjCk80SeHQBL6JGZrXmbsTZNLegg9wU0Sigz1eOAZeno8q3ixNapGpy1q2Jyb3r6od2sRFp0fsVMdv5BQR/SLtNqrlCkF
x-ms-exchange-antispam-messagedata: nmyQQPmaVtiTTNE9rkQgncC6v4zete6SM6E1xPqQyUgeyoQwKKO6/7DjbGx9uJxXjgLbUS5+qH2bD3sJmdXz6XAUEL/29yDLU/X5w/+ZIRDdnm5ASZqXmyx30/3AgfbstOmfIXgyF/ebnBbxTfxVjw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3318E5A347314EB509AC91759BE80AM6PR08MB3318eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4005
Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com;
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT032.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)(336012)(2906002)(81166006)(186003)(70586007)(30864003)(33656002)(6916009)(81156014)(8936002)(26005)(70206006)(8676002)(478600001)(55016002)(36906005)(316002)(356004)(7696005)(5660300002)(52536014)(26826003)(6506007)(86362001)(19627405001)(9686003); DIR:OUT; SFP:1101; SCL:1; SRVR:AM7PR08MB5350; 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: 3ac10e97-daad-429b-a6c1-08d7bc4460d2
X-Forefront-PRVS: 0327618309
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: Rg1ISlH4Ei3x3uT36EkORg2men+BvV5j7dBFZ5NMM/Wra0W6BGN9cV7JtGGJpk3Wi5wgqeX6TjL3+2+aTAgtNi+V/qbUdrv2O/UHjFaEIVpj53HyNmAzcd48EfaBIi+zBhv/Hl1DCOFiS46TgPyF5hQyArSw8JHHP/DM/pfphCwj5Cvfqb3tuZtR0UXVZ6YB+tACQxV4fMAIrdJHCE3DMLY4veuzGCInD7eWqMclihtK0DqfTWu4wUP8mNpWGCdlxJfoB7KxopP1cNV2Wvh1tTsdOXuAWyC4jCLZQJT3+iTdWCokrEibc9Qjbzn4ndrSdwuj5nFM1ygAYo/RzZF4q+s8OXwM6BegRx1d5+IsqoJvZXAwgbM+h5d96GlbIHlHpyHu+xFLWieFgHHta7OVThxag87Ibu4R0Q2qc7/wxzwyODa115WN0k+FZ7PZVNRy
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Feb 2020 11:50:23.3816 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: d27e4664-93f1-4e51-1645-08d7bc44650b
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: AM7PR08MB5350
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FWyqIWYN3rhUL3DUeh65Dd7e0xM>
Subject: [TLS] Record-level ACKs in DTLS 1.3
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: Fri, 28 Feb 2020 11:50:30 -0000
Hi, TL;DR This is all about various aspects of how ACKs work in DTLS 1.3: - The DTLS 1.3 specification requires clarification regarding when ACKs should be sent. - Record-level ACKs make efficient implementations for IoT devices harder. I argue that handshake-level ACKs reduce implementation complexity and allow for optimized implementations. Details: To illustrate, consider the following flight exchange, where the second and third message in the second flight get reordered: Client Server +----------+ | Seq No 1 |--------------------------> Received | Rec No a | +----------+ +---------------+ Received <------------------------| Seq No 1 | | Rec No b | +---------------+ +---------------+ +-------------| Seq No 2 | | | Rec No c | | +---------------+ | | +---------------+ Received <------------------------| Seq No 3 | | | Rec No d | | +---------------+ +-----------+ | | ACK |-------------------------> | RecNo ??? | | +-----------+ | | | | Received <----------+ The specification recommends that the client SHOULD send an ACK when it receives out-of-order handshake message - here message (3,d) while awaiting (2,c). However: Question: Which records does the client acknowledge in the ACK? This is in fact implementation-dependent: The client must only acknowledge record (3,d) if it has buffered it. Implementations which don't implement out of order buffering of handshake messages (to save RAM and ROM) must not acknowledge messages that weren't buffered. The reason is that otherwise the server is mislead in which messages need resending and which don't. Conclusion 1: If ACKs must only be sent for records which contain handshake messages which were actually fed into the flight buffering / reassembly module of the implementation, the specification should clearly say so. I consider this point to be prone to misinterpretation, potentially leading to incompatible implementations, because ACKs acknowledge receipt at record granularity, and yet they must be sent only under some assumptions on how their content was processed. Next, given that the generation of record-ACKs is therefore content-specific, I wonder why ACKs acknowledge records in the first place, and not triples of (handshake seq nr, fragment offset, fragment length). It appears to me that the latter matches their semantics much closer and allows for more simpler and more efficient implementations. I'll elaborate on that in the following. As I understand, the simplest implementation of the retransmission state machine using record-level ACKs works by buffering copies of records sent in a flight and retransmits those that don't get acknowledged. The record sequence numbers of the original and retransmitted records are internally associated with the opaque record content, so that ACKs for both the original and the retransmitted records can be recognized. In this approach, the record contents are opaque to the sender's retransmission state machine, which simplifies the implementation. However, it has major drawbacks: (1) It requires buffering the entire flight, which incurs high memory overhead that can be significant on constrained devices. Implementations should be allowed to not buffer handshake messages but re-generate them on the fly through a callback whenever retransmission is needed. Two examples: - Consider the Certificate message: The raw certificate (chain) must reside in RAM/ROM already, and the Certificate message could easily be re-regenerated from that. Buffering handshake messages instead creates significant and unnecessary overhead. - This is of increasing importance with the advent of post-quantum cryptography, which comes with significantly larger key material. (2) It doesn't allow switching the MTU for retransmission. Once the MTU may change for retransmission, the sender cannot keep track anymore of a single set of record sequence numbers per message such that an ACK for any of them confirms receipt of the message. Of course, no implementation is strictly _forced_ to follow the above approach, but the current record-level ACKs design significantly hardens any other approach: For example, retransmission through callbacks or support for MTU switching requires maintaining the tuples (record seq nr, lists of handshake fragments) for all transmissions of the last flight. (Note that, in particular, just remembering the mapping for the last transmission isn't enough, since an acknowledgement for an earlier transmission might arrive late.) The _sender_ would need to maintain less state, and would have an easier time figuring out what to retransmit, if ACKs acknowledged handshake fragments directly. On the _receiver_ side, there's no benefit of ACKing at the record level, either, because -- as we have just seen -- it is _not_ the case that it can be implemented as an automated mechanism at the record level, but needs to be triggered from the handshake layer, at a point where all information about the handshake content are available. Implementations following the above buffering-based approach don't increase in complexity through a switch to handshake level acknowledgements instead of record level acknowledgements: They can just treat the acknowledged handshake metadata as an _opaque_ identifier, replacing what was previously the record sequence number. Conclusion 2: Handshake-level ACKs simplify the retransmission state machine for non-buffering implementations on constrained devices, while not hardening buffering implementations using record-level ACKs so far. I'm aware of the lateness of this proposal, but would be happy if the group would discuss and consider handshake-level ACKs instead of record-level ACKs. Let me know what you think, Cheers, 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] Record-level ACKs in DTLS 1.3 Hanno Becker
- Re: [TLS] Record-level ACKs in DTLS 1.3 Eric Rescorla
- Re: [TLS] Record-level ACKs in DTLS 1.3 Hanno Becker
- Re: [TLS] Record-level ACKs in DTLS 1.3 Eric Rescorla
- Re: [TLS] Record-level ACKs in DTLS 1.3 Hanno Becker
- Re: [TLS] Record-level ACKs in DTLS 1.3 Christopher Wood