Return-Path: 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 D4C8C3A18BD for ; Fri, 3 Apr 2020 05:09:04 -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=SkBHqlqS; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=SkBHqlqS 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 7ZBcOJ6NeV3j for ; Fri, 3 Apr 2020 05:09:00 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2087.outbound.protection.outlook.com [40.107.21.87]) (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 70D063A18B4 for ; Fri, 3 Apr 2020 05:08:59 -0700 (PDT) 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=LtnSj7UuPHTIAVYxkTSAsnkBlHytyRb715tWBdcrJik=; b=SkBHqlqSQ7FjvS9R3mOy6kHMOOOsIHhj0FB8Ww1FEBoEHOfxlxf5cm4h+xd+cx+eY8XtaNRTF5hJFY8epvKjvvWubSh30mxdSft5EOxYt27w1NMKWhzTT4hqhp6VxrapTSysP6oe95YDPez15XSFPaoznSBsdnOM0cRTKBjVlSg= Received: from DB7PR05CA0057.eurprd05.prod.outlook.com (2603:10a6:10:2e::34) by DB8PR08MB5467.eurprd08.prod.outlook.com (2603:10a6:10:11b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Fri, 3 Apr 2020 12:08:56 +0000 Received: from DB5EUR03FT048.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:2e:cafe::1c) by DB7PR05CA0057.outlook.office365.com (2603:10a6:10:2e::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20 via Frontend Transport; Fri, 3 Apr 2020 12:08:56 +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 DB5EUR03FT048.mail.protection.outlook.com (10.152.21.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Fri, 3 Apr 2020 12:08:56 +0000 Received: ("Tessian outbound 9e48e1321951:v50"); Fri, 03 Apr 2020 12:08:56 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 3004c57d71e485f7 X-CR-MTA-TID: 64aa7808 Received: from c9e1ab25f8c6.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 7B938931-9D54-4040-9BE0-626AAD44CF94.1; Fri, 03 Apr 2020 12:08:51 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c9e1ab25f8c6.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 03 Apr 2020 12:08:51 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jsxy4P+OgPYQNqdl0xu+oNj2aGWIjPQS2VFvznSyGvojZv/CbMjB38yNee9hpT13MzqKETJuzPGDOQ+ByiKDrvRVkvQu/OR3YNBqqlq4NKz6/I71vJDMXLqNtPKRw9sEMFkepoe/wExlThfnevNlm6+bqI2J+gfQe/K2HMNLkTqGlH/nSdwa2lSO1yQIIkt2ew5+anNNzZC+leaXE49k3sizaqkqiyUcNT+RSKbda/vkoLBnKrdI/k3Z7Y4mmHPdQyyiNss9qZlzNf3bcdNGoZEsHoGNJ5qH9OHwu8ulobvD/ia6OANqVhMdBmqSlA53g113qgk5evUuqzNIKmmZNw== 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=LtnSj7UuPHTIAVYxkTSAsnkBlHytyRb715tWBdcrJik=; b=fqxw/KVRdWs1BNOIhoWb42iQyG+OEje7TwsGT1RNaO8lWuJJZY+XJ+94qGyuKZIZ38gBOQO6MDUJCYa9Xhgir0zL7PRJBCrzy/WXptPkPFPI4pOFQprcWV8i7GDQq+QS5Kl+tbQ/jeOv879y5r4IxGM14BKkDqwuxG/iPgo9XLNVWAoGpwNo1o8U0ntXb1UnMUtv+/ayPsjdaO4XmPqAbjaTSuBQPOPVtpRQvEyhnvE4lngjouGPojJAIMjkRpRU79Q0wVAMZ5pmYBJMrybaAVlG4WBaGTUbFI0An7eNwSHXcmipisV6kzWGM+Vy2KaPyPgg1U53z5JbP8kJv+Ebow== 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=LtnSj7UuPHTIAVYxkTSAsnkBlHytyRb715tWBdcrJik=; b=SkBHqlqSQ7FjvS9R3mOy6kHMOOOsIHhj0FB8Ww1FEBoEHOfxlxf5cm4h+xd+cx+eY8XtaNRTF5hJFY8epvKjvvWubSh30mxdSft5EOxYt27w1NMKWhzTT4hqhp6VxrapTSysP6oe95YDPez15XSFPaoznSBsdnOM0cRTKBjVlSg= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (52.135.163.143) by AM6PR08MB3352.eurprd08.prod.outlook.com (52.135.167.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Fri, 3 Apr 2020 12:08:49 +0000 Received: from AM6PR08MB3318.eurprd08.prod.outlook.com ([fe80::1579:b7d9:f543:200d]) by AM6PR08MB3318.eurprd08.prod.outlook.com ([fe80::1579:b7d9:f543:200d%5]) with mapi id 15.20.2856.019; Fri, 3 Apr 2020 12:08:49 +0000 From: Hanno Becker To: "tls@ietf.org" Thread-Topic: [TLS] On the two types of ACKs in DTLS 1.3 Thread-Index: AQHWCa+c/6zqL3NX202z6YHPiVC69A== Date: Fri, 3 Apr 2020 12:08:49 +0000 Message-ID: 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: [86.181.127.140] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: c1704f37-3d75-41d9-a7bd-08d7d7c7c90b x-ms-traffictypediagnostic: AM6PR08MB3352:|DB8PR08MB5467: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0362BF9FDB X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB3318.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(366004)(39860400002)(396003)(376002)(346002)(64756008)(186003)(6916009)(33656002)(26005)(71200400001)(55016002)(9686003)(86362001)(19627405001)(2906002)(66946007)(81166006)(66556008)(66446008)(66476007)(8936002)(478600001)(5660300002)(81156014)(8676002)(76116006)(6506007)(7696005)(316002)(52536014); DIR:OUT; SFP:1101; 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: U7M67Adwi8dyUxnI/SY9EGXgJoJNmvvuW4FK/2hnvV46WvgH+Tz5pFZKOOvkYNyn5odyWyBU/fZLe1Cxr+UqU5KaASVme1yK7fIY9I0LtbiHdvygJqbUOE/s4buKavfU0afsdlJWpWIk9tiOKUpq8mqJX2fj0WdZ7Wq1RedvDU1Mq2QuiLxzt0VreWoihqgqWYxQGn5EgzCVytBy5kXBdyJ5BiLixO+VoGsRYIQMjZT59caeJl6zMLDaC/lCawHe371txVtcuJpCuNUAx29A6VsYmtxFIZSDc8eoh+GtCYUrffI+A5ewI1RBawa6UkTBMy5srChIsZbeP7Eof1IAIzwXGD6TVQVETp1oLKWIQGvFsE9UgZ+jW/YfokLNF8yd9nKcYAKN+gsP4ssXU1nu0B3HwVYZ2vpjeCbFwj+VdN3GESBW2K0nU0Ne17wqFkx5euNweRapg4vBghUaYdUdjeFpGC08ubFqa4e9lbu8nlYdwrp4DsSFtHg4QZCfUPvEwESLKoH/S2COQHDmCWQbTQ== x-ms-exchange-antispam-messagedata: Yl7O1KtujfG3WGUomwe8VoXrmZhtsvtNhWt7Cjou8r//tzjS6Agb+P0/8mkKHoPs33kOJSvVKvuCaLsBck7wiZKZwkgmfc0+pgnSflbU/fDlTUjDI01VCtv1guQKsXXGCJ8CZba+I1IqJrVfZuFqAg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB33187063CE8ED77847600C709BC70AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3352 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT048.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(346002)(39860400002)(376002)(136003)(46966005)(52536014)(70586007)(6916009)(8936002)(478600001)(8676002)(70206006)(316002)(26826003)(86362001)(81166006)(336012)(81156014)(356004)(7696005)(47076004)(82740400003)(55016002)(9686003)(33656002)(19627405001)(186003)(5660300002)(26005)(2906002)(6506007); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 987ce715-bd86-4602-2717-08d7d7c7c4be X-Forefront-PRVS: 0362BF9FDB X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: pptR+34RnTng1+O1MWzLbQMa+JhtCQs5NCpJHjRkfeSW/03zSBhEI97h39gDNrEH2eaP2XFYES2L+l5lZXsePuWytbJE14IPPnz7s61TkkXiJtazwURvgAhv8nvxzZ7gssWOhYHlowH1vAQJfVmw61TY66tlU4WeGuHt7ltmTkJb/Mpxpa6aQuKsBMDVYHqWz3kvK1qDRE9ocDM1u4Jaiql5V0s/U67dF3+Sjiho6AgmszbY3ENnxsij7hgyTtwkGoAcz3Q7tA0yO1Hv22ugmRJQ3Q8ddExZuk2glJ75pOyBLdugPZ0AsdPBI4eE24RkCAaAoNpxsIqX+rbeUS8nMsKPXlHW/tzXNhS26n5XsFqQYPxhBfN17yI5Q2UBabkbTwhvW46MrS3RrPnMinZ/1X/2uIcaqfcqcQRAGl78Y14YeT+y73wCwoZLpulgCdP4gJ0/rc/mjzyJiCVDcpHRY1m/nzWqd6P9PeiuclPsAIcbrMAy+JRPtQKmAGL/h7vYbklCpfH+3/3VhxUo4A59HHs5VeoOxAcUjIC2WZeFbcAME8FJpKJU5AH7OBpB5TJ6XlBhZZ3TvOaATgAY0LsKhg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2020 12:08:56.7592 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c1704f37-3d75-41d9-a7bd-08d7d7c7c90b 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: DB8PR08MB5467 Archived-At: Subject: [TLS] On the two types of 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 12:09:05 -0000 --_000_AM6PR08MB33187063CE8ED77847600C709BC70AM6PR08MB3318eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I am aware that we're late into the standardization of DTLS 1.3, and likely too late for any intrusive change, but I'd still like to share another comment on the proposed ACKing scheme and its implication on complexity of migration from DTLS 1.2 to DTLS 1.3, in addition to the aspect discussed earlier regarding handshake-level vs. record-level ACKs (https://mailarchive.ietf.org/arch/msg/tls/O0pghTnz_8q1AiHSeMSzxZg30RM/) As it stands, there are two quite different kinds of ACKs sharing the same wire-format: 1. ACKs as 'retransmission requests' Consider the following two excerpts from the draft: A: "When an implementation receives a partial flight, it SHOULD generate an ACK that covers the messages from that flight which it has received so far." B: "Upon receipt of an ACK for only some messages from a flight, an implementation SHOULD retransmit the remaining messages or fragments." This means that ACKs should be sent only on signs of disruption, and that receivers of partial ACKs are supposed to immediately retransmit. In particular, this precludes recurring use of ACKs where an ACK is generated for each message as it comes in and is processed: Indeed, implementations behaving this way would trigger multiple retransmissions on the peer, provided the peer obeys (B), even if there's not a single packet-loss or reordering occurring. In this sense, the above ACKs are 'negative' and should not be seen at all during a disruption-free handshake. Note, also, that handshakes will continue to progress if this kind of ACKs is entirely ignored, which amounts to falling back to how DTLS 1.2 handles retransmissions, purely on the basis of timeouts and implicit acknowledgement. 2. ACKs as 'acknowledgement of completion' In contrast to the previous kind of ACK, those ACKs are 'positive' in that they indicate completion of a handshake, and they are mandatory in that a handshake will not complete unless they are used. In particular, an implementation MUST support those kinds of ACKs. At the moment, both kinds of ACKs are handled in the same way on the wire, and in order to even distinguish them an implementation has to maintain accurate knowledge of the sequence numbers of records it has sent. In particular, even if implementations decide to not make use of type-1 ACKs -- that is, retransmission requests -- it doesn't buy them anything in terms of code-size and simplicity, because they still have to implement type-2 ACKs, and detecting those requires implementing record sequence number bookkeeping. I believe that this will harden migration of DTLS 1.2 stacks to DTLS 1.3, because it makes the minimal difference between a compliant DTLS 1.3 implementation and a pair of "DTLS 1.2 + TLS 1.3 logic" quite large. In contrast, if retransmission requests and completion-ACKs were treated differently, and in particular easily distinguishable on the wire, then migration from a pair of DTLS 1.2 + TLS 1.3 stack to a minimal compliant DTLS 1.3 would only require implementing 'completion-ACKs', which, since they convey only a single bit of information, can in principle have a much simpler wire-format than what we have for ACKs today. I would be interested in comments from implementors, esp. for stacks targeting embedded / constrained environments. Cheers, Hanno IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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. --_000_AM6PR08MB33187063CE8ED77847600C709BC70AM6PR08MB3318eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,

I am = aware that we're late into the standardization of DTLS 1.3, and
likel= y too late for any intrusive change, but I'd still like to share
anoth= er comment on the proposed ACKing scheme and its implication on
compl= exity of migration from DTLS 1.2 to DTLS 1.3, in addition to the
aspec= t discussed earlier regarding handshake-level vs. record-level ACKs

As it= stands, there are two quite different kinds of ACKs sharing
the s= ame wire-format:

1. AC= Ks as 'retransmission requests'

 = ;  Consider the following two excerpts from the draft:

 = ;  A:
 = ;  "When an implementation receives a partial flight, it SHOULD g= enerate
 = ;   an ACK that covers the messages from that flight which it has
 = ;   received so far."

 = ;  B:
 = ;  "Upon receipt
 = ;   of an ACK for only some messages from a flight, an implementation<= /span>
 = ;   SHOULD retransmit the remaining messages or fragments."

 = ;  This means that ACKs should be sent only on signs of disruption,
 = ;  and that receivers of partial ACKs are supposed to immediately
 = ;  retransmit.

 = ;  In particular, this precludes recurring use of ACKs where an ACK
 = ;  is generated for each message as it comes in and is processed:
 = ;  Indeed, implementations behaving this way would trigger multiple
 = ;  retransmissions on the peer, provided the peer obeys (B), even
 = ;  if there's not a single packet-loss or reordering occurring.=

 = ;  In this sense, the above ACKs are 'negative' and should not be
 = ;  seen at all during a disruption-free handshake.

 = ;  Note, also, that handshakes will continue to progress if this
 = ;  kind of ACKs is entirely ignored, which amounts to falling back
 = ;  to how DTLS 1.2 handles retransmissions, purely on the basis=
 = ;  of timeouts and implicit acknowledgement.

2. AC= Ks as 'acknowledgement of completion'

 = ;  In contrast to the previous kind of ACK, those ACKs are 'positive'<= /span>
 = ;  in that they indicate completion of a handshake, and they are
 = ;  mandatory in that a handshake will not complete unless they are
 = ;  used. In particular, an implementation MUST support those kinds
 = ;  of ACKs.

At th= e moment, both kinds of ACKs are handled in the same way on the wire,
and i= n order to even distinguish them an implementation has to maintain
accur= ate knowledge of the sequence numbers of records it has sent.

In pa= rticular, even if implementations decide to not make use of
type-= 1 ACKs -- that is, retransmission requests -- it doesn't buy
them = anything in terms of code-size and simplicity, because they
still= have to implement type-2 ACKs, and detecting those requires
imple= menting record sequence number bookkeeping.

I bel= ieve that this will harden migration of DTLS 1.2 stacks to DTLS 1.3,=
becau= se it makes the minimal difference between a compliant DTLS 1.3
imple= mentation and a pair of "DTLS 1.2 + TLS 1.3 logic" quite larg= e.

In co= ntrast, if retransmission requests and completion-ACKs were treated<= br>
diffe= rently, and in particular easily distinguishable on the wire, then
migra= tion from a pair of DTLS 1.2 + TLS 1.3 stack to a minimal compliant
DTLS = 1.3 would only require implementing 'completion-ACKs', which, since<= br>
they = convey only a single bit of information, can in principle have a
much = simpler wire-format than what we have for ACKs today.

I would be interested in comments from implementors, esp. for stacks
targeting embedded / constrained environments.

Cheer= s,
Hanno=

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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. --_000_AM6PR08MB33187063CE8ED77847600C709BC70AM6PR08MB3318eurp_--