From nobody Wed Apr 1 21:48:38 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B013A0C49; Wed, 1 Apr 2020 21:48:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Martin Duke via Datatracker To: "The IESG" Cc: tls-chairs@ietf.org, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.123.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <158580291581.30648.9399548144676548534@ietfa.amsl.com> Date: Wed, 01 Apr 2020 21:48:35 -0700 Archived-At: Subject: [TLS] Martin Duke's No Objection on charter-ietf-tls-05-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 02 Apr 2020 04:48:37 -0000 Martin Duke has entered the following ballot position for charter-ietf-tls-05-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-tls/ There are no remarks associated with this position. From nobody Wed Apr 1 23:12:33 2020 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 E07A53A08AC for ; Wed, 1 Apr 2020 23:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=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=alipay.com 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 0y-A3cCfYqJZ for ; Wed, 1 Apr 2020 23:12:29 -0700 (PDT) Received: from out0-142.mail.aliyun.com (out0-142.mail.aliyun.com [140.205.0.142]) (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 1047E3A08AB for ; Wed, 1 Apr 2020 23:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alipay.com; s=default; t=1585807944; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To; bh=6EM2fCKmlKLV1EyoexydqSBRsKZh8MbZ5jOSudZKgIg=; b=QuzuVDA3U4S2v5Jxp80C/Ujlnj7ODUCj+E3F46ZWoVXN9VLgESuE7du/PNRlfX4s43ziUdAALHNAr2+KiKsqo7Y7H5DgRjSe0odqg6qKiELrBAJZjmyfIqfxJ/kB/R96FWAPPpQ6YMvg20C+pWYQTyaVlVMta+QP+IHo86iB5yg= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R111e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e01a16370; MF=kaishen.yy@alipay.com; NM=1; PH=DS; RN=1; SR=0; TI=SMTPD_---.H9LNTWW_1585807941; Received: from 10.15.232.12(mailfrom:kaishen.yy@alipay.com fp:SMTPD_---.H9LNTWW_1585807941) by smtp.aliyun-inc.com(127.0.0.1); Thu, 02 Apr 2020 14:12:21 +0800 From: "Paul Yang" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Message-Id: <3BFEDA02-D5AD-4616-9BA6-7556A6A6049B@alipay.com> Date: Thu, 02 Apr 2020 14:12:21 +0800 To: TLS List X-Mailer: Apple Mail (2.3608.40.2.2.4) Archived-At: Subject: [TLS] Encoding of delegated credential distribution 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: Thu, 02 Apr 2020 06:12:32 -0000 Hi all, When reading the latest draft of delegated credentials, I didn=E2=80=99t = any description about how to distribute a credential from the backend to = frontend. As described in the draft: Delegated credentials: Client Front-End Back-End | |<--DC distribution->| |----ClientHello--->| | |<---ServerHello----| | |<---Certificate----| | |<---CertVerify-----| | | ... | | Do we need to define some sorts of encoding schemes for the part? Regards, Paul Yang From nobody Thu Apr 2 10:59:47 2020 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 AE48B3A0FB4 for ; Thu, 2 Apr 2020 10:59:43 -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=nshPv7Rb; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=nshPv7Rb 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 yP7BPIja0JjK for ; Thu, 2 Apr 2020 10:59:40 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150075.outbound.protection.outlook.com [40.107.15.75]) (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 3C0CC3A0FAC for ; Thu, 2 Apr 2020 10:59:39 -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=aC0g9GuOrrYpfT4s3oIDAfXJHTOXVfQ+1AIMyY5+/C4=; b=nshPv7RbeI/5MTUReVpaxWxfOVUzyQnB6Hkf98L3xgsD8LxPzmQotSNAgDT4rFhwYin5NqtkhAzQ0RUtGKp8HAbdZYo74rwrp9NkEBZO4MEupHNoAX5rJ2wqopIIdoMq4+61jARG7LcWvvH3yayIGlwcQMK2Rw6lC482cmLc28M= Received: from AM0PR0402CA0036.eurprd04.prod.outlook.com (2603:10a6:208:15::49) by HE1PR0801MB1722.eurprd08.prod.outlook.com (2603:10a6:3:87::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Thu, 2 Apr 2020 17:59:37 +0000 Received: from AM5EUR03FT034.eop-EUR03.prod.protection.outlook.com (2603:10a6:208:15:cafe::cd) by AM0PR0402CA0036.outlook.office365.com (2603:10a6:208:15::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Thu, 2 Apr 2020 17:59:37 +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 AM5EUR03FT034.mail.protection.outlook.com (10.152.16.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Thu, 2 Apr 2020 17:59:36 +0000 Received: ("Tessian outbound 4b84da486446:v50"); Thu, 02 Apr 2020 17:59:36 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 7ec6b3f687dd7446 X-CR-MTA-TID: 64aa7808 Received: from 1d208dbe32a3.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 25BA2265-870E-453A-8BE7-22FEE4C58B0C.1; Thu, 02 Apr 2020 17:59:31 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 1d208dbe32a3.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 02 Apr 2020 17:59:31 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GnnQhhQYrWT8wopwEAjMwQL5WCN2hMNlIrcxx2qCFKPKNANMt+elSMfPrO2rR0qwaIHAAxQW9pFZy0shSqrretZ/TTLK2Tvqvaev6TFXlnumU3P9e80k0hiJpzNpxdBXi6nMknzrmjtLOMfM8QGbTAEfDLcnvE7Ljajk/Wh5cRPygpJPfcw36wynQMozbLvPj/CbKbmAnc+USN368bdbhB/VkYnk3rPAREmIcJSjPmPmfHP7gAdMzs7PB6mjCPo7OSk/Z8fNRHdeqBdGfI8WLALH5y7uzLE1mTG8BTUVyto9fIwYho8coyrSvo0yBQFCRwSB7u2GvAcYmzkv5lrtmA== 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=aC0g9GuOrrYpfT4s3oIDAfXJHTOXVfQ+1AIMyY5+/C4=; b=nHqHJCLekGyH70Wqxb3Bw51TKWBS/L1koNwzlJgbJIR0r+o2ED0zb3QLmlryeGOG5o3v6awQ8adEKNj8h737JFhBgk+RT+sTMCzdUg6vUZkYwi5XNLU6MVyZWCvIt5V0/VisTtTNb6jimSX4zUt0KSKzlK0TPwHfyfdC2NLh/vda8R32CNbHnM0ZMYSHS7dJHWPwqgxI4aThJyasmr9EP31J3t7hHoterabz5j+aFC4ckk+wUGXtMPfad8toScIbm7rWz/m8XeMkfdBM2JT34vtcxf+7P2rHodpUcLC+S7IORhD4Zqwb+KBw/iFjjJn3jeroRFT0f6O6tcuy4zl/Yg== 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=aC0g9GuOrrYpfT4s3oIDAfXJHTOXVfQ+1AIMyY5+/C4=; b=nshPv7RbeI/5MTUReVpaxWxfOVUzyQnB6Hkf98L3xgsD8LxPzmQotSNAgDT4rFhwYin5NqtkhAzQ0RUtGKp8HAbdZYo74rwrp9NkEBZO4MEupHNoAX5rJ2wqopIIdoMq4+61jARG7LcWvvH3yayIGlwcQMK2Rw6lC482cmLc28M= Received: from DB7PR08MB3324.eurprd08.prod.outlook.com (52.135.128.161) by DB7PR08MB3084.eurprd08.prod.outlook.com (52.135.128.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Thu, 2 Apr 2020 17:59:30 +0000 Received: from DB7PR08MB3324.eurprd08.prod.outlook.com ([fe80::41f6:faee:c1f4:6abe]) by DB7PR08MB3324.eurprd08.prod.outlook.com ([fe80::41f6:faee:c1f4:6abe%6]) with mapi id 15.20.2856.019; Thu, 2 Apr 2020 17:59:30 +0000 From: Hanno Becker To: Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] [DTLS] ACK's for post-handshake authentication requests Thread-Index: AQHWBEwPb41Ly5OD9EyF9O8aRHZFyqhcoY4AgAmGUJc= Date: Thu, 2 Apr 2020 17:59:30 +0000 Message-ID: References: , In-Reply-To: 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: 3e35220d-7142-403f-771a-08d7d72f9b9f x-ms-traffictypediagnostic: DB7PR08MB3084:|HE1PR0801MB1722: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0361212EA8 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3324.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(346002)(136003)(376002)(39860400002)(366004)(81166006)(33656002)(8936002)(6916009)(4326008)(316002)(19627405001)(81156014)(53546011)(7696005)(6506007)(2906002)(76116006)(478600001)(5660300002)(9686003)(52536014)(66446008)(71200400001)(8676002)(55016002)(66946007)(64756008)(66476007)(186003)(966005)(86362001)(26005)(66556008); 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: qNVPRbuTndyVserdPRIQQ3xkTAS6ik2gfNE3tM7EkGMhJ0JIC+EikW40Kcqi7272YBSgnwlGMV9QvoAP+ZkdPIlierOjUPA+r+hhfUyffg6C2mDty6sEate6Ih2cIo+K5qPgJB2evkoFHr16HmiL8SyqBw9jlPRl73TDneZqgwtrYTyyiUyK7kyCfVYi9EVld5wbrTJ4bMejWJe0c9t4BAMsV2Cq2R7G/6ibkagPpdrI4IlP/JbOghDsF+lug3Ni1uMHlLkCQc5uSkpcI8TAC2sLfO/jAR0JnEWYtatDXk69LLjGAdqTYIhH7RlMJKRuGhZVmjRWRdOZhPLxZRMKvhh3bJiwgHboxvdN7Vf5OTutqJYP8Ib1eQl1nEnrBPapW6ty+xxYuJt3waDSf/8Aqh1GYJCNc7Tibjn3bFmjTrmCQafRl1Q8p7kkE9TsUOHFic1xC2lrOnAcFDbConri4jZfZSkqBKLLJ6c2nUZYycB8cPx3f2iTwfVtM9s0y1ijLs5LVWAv/sYH98C+WbaEBw== x-ms-exchange-antispam-messagedata: 0EGs92M0zBPQj0hEuOI1yka0k08qrHsuyIrWi9NwGjns3yy787sVygUbAnowZuHQMVa62rK25XCYRfKQjrE5X1VsSen8cQzsb46ng+Mid3QzQJ5S89hmVFJppYLlBmdL8j1O77C1BIh+N+W/DLiQXg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DB7PR08MB3324605B40FBB90DD10F3A959BC60DB7PR08MB3324eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3084 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT034.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)(136003)(376002)(39860400002)(396003)(346002)(46966005)(8936002)(86362001)(70206006)(70586007)(6862004)(9686003)(82740400003)(5660300002)(81156014)(55016002)(478600001)(26826003)(336012)(966005)(2906002)(53546011)(52536014)(47076004)(356004)(81166006)(186003)(36906005)(26005)(7696005)(19627405001)(6506007)(316002)(8676002)(33656002)(4326008); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 9af87bb2-c88a-4147-4ee4-08d7d72f97b7 X-Forefront-PRVS: 0361212EA8 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: W8H7sNTEWsPlHha20A6JpXKV3A9dW9gGrCxnJtRw/nbAf4y0/tqrjnkoS3xB416se7LmhBRqNav2lAUNf8HvgyNTUtTWTfyKwRaVhNvCCX34b0Tnp9+HMLSCY6qFOsd0Fuxj8OwHxQzKPKUIgmyb+8wLbQx744DHIQBYjAdTrp/mtEsPa+ZthPcmqQp73IjNpQgeX6ye/HQnuxN6LXzLq+kQMFKzr0sAKIgX0f1qLq45JxjmO4EfhupAzGZiRsvdCIn+hT9z+XQt0y2EIdfwltSiMmhbFq5gPFyEJlIFoAAmYhWiZFJJ/JaF1XYZyTve3Lw1O/v9/AQF5MbDpXwU4LWpw3XsUW77E6e8F76azE8N2o3nl1wnY6Sa2qVSCMLv1m8lK9JWGiS1ZZOJ2CZqqyS0T6+hVB1ZeoDFPSrJ5KKgmVyBh1iTLuPcP/NxXP2cJtEN0kDQb5izeJCiT+QWbTEyMWD6Kle7eu7GCq51rkEyPRmgafRPYvtZqtrcFx/51WjcQXmsOemddkGZpgUyd2RDW7P+JorkD3pxxUAxGgxt1EjxnO+dGPwEDpLxETFWStqao4dFKdqJQVVxbGE2/A== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Apr 2020 17:59:36.9957 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3e35220d-7142-403f-771a-08d7d72f9b9f 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: HE1PR0801MB1722 Archived-At: Subject: Re: [TLS] [DTLS] ACK's for post-handshake authentication requests 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: Thu, 02 Apr 2020 17:59:44 -0000 --_000_DB7PR08MB3324605B40FBB90DD10F3A959BC60DB7PR08MB3324eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Ekr. I have created PR https://github.com/tlswg/dtls13-spec/pull/138= implementing the suggestion. ________________________________ From: Eric Rescorla Sent: Friday, March 27, 2020 4:30 PM To: Hanno Becker Cc: tls@ietf.org Subject: Re: [TLS] [DTLS] ACK's for post-handshake authentication requests Thanks. This seems like a good improvement. I have filed https://github.com= /tlswg/dtls13-spec/issues/128 to track it. On Fri, Mar 27, 2020 at 8:29 AM Hanno Becker > wrote: I have a minor comment on DTLS 1.3 draft 37. On the topic of sending ACKs, the draft recommends: ``` ACKs SHOULD NOT be sent for other complete flights because they are implicitly acknowledged by the receipt of the next flight, which generally immediately follows the flight. ``` I wonder if the case of post-handshake authentication should be explicitly mentioned as a potential exception to this rule, since the TLS 1.3 RFC explicitly mentions that responses to `CertificateRequest` may be delayed in some contexts: ``` Note: Because client authentication could involve prompting the user, servers MUST be prepared for some delay, including receiving an arbitrary number of other messages between sending the CertificateRequest and receiving a response. ``` In this case, it would be beneficial to immediately explicitly ACK the `CertificateRequest` message even though it is also implicitly acked through the eventual response via the `Certificate` message. Regards, 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls 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_DB7PR08MB3324605B40FBB90DD10F3A959BC60DB7PR08MB3324eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks Ekr. I have created PR https://github.com/tlswg/dtls13-spec/pull/138 im= plementing the suggestion.
From: Eric Rescorla <ekr= @rtfm.com>
Sent: Friday, March 27, 2020 4:30 PM
To: Hanno Becker <Hanno.Becker@arm.com>
Cc: tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] [DTLS] ACK's for post-handshake authentication re= quests
 
Thanks. This seems like a good improvement. I have filed <= a href=3D"https://github.com/tlswg/dtls13-spec/issues/128"> https://github.com/tlswg/dtls13-spec/issues/128 to track it.

On Fri, Mar 27, 2020 at 8:29 AM Han= no Becker <Hanno.Becker@arm.com<= /a>> wrote:
I have a minor comment on DTLS 1.3 draft 37.
On the topic of sending ACKs, the draft recommends:

```
ACKs SHOULD NOT be sent for other complete
flights because they are implicitly acknowledged by the receipt of
the next flight, which generally immediately follows the flight.
```

I wonder if the case of post-handshake authentication should be
explicitly mentioned as a potential exception to this rule, since
the TLS 1.3 RFC explicitly mentions that responses to
`CertificateRequest` may be delayed in some contexts:

```
Note: Because client authentication could involve prompting the user,<= br>
servers MUST be prepared for some delay, including receiving an
arbitrary number of other messages between sending the
CertificateRequest and receiving a response.
```

In this case, it would be beneficial to immediately explicitly ACK
the `CertificateRequest` message even though it is also implicitly
acked through the eventual response via the `Certificate` message.

Regards,
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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_DB7PR08MB3324605B40FBB90DD10F3A959BC60DB7PR08MB3324eurp_-- From nobody Thu Apr 2 11:01:21 2020 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 B9FA93A1024 for ; Thu, 2 Apr 2020 11:01:13 -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=PQmd/eH+; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=PQmd/eH+ 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 p6WHR0iw7nK3 for ; Thu, 2 Apr 2020 11:01:09 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50049.outbound.protection.outlook.com [40.107.5.49]) (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 6AE203A101E for ; Thu, 2 Apr 2020 11:01:08 -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=j7s8jSxOXyEEdemFexFokADuXpZi/nk3ZBzDqwxCopY=; b=PQmd/eH+V4QMLv5cImZiyQzOey3Jn1ZUmV6RhZjw5RE7U8PEssJ7Xq8NibPHJ6Jb4hwNOdF+mEe9Fy0UC6J8/4PUW/5sbNgtXnDRKxQN+tY0mdJHAo6eki6U98nIRo+/3BrKaDSVySu5lnoqChOboy7Rv032PRrDRiBNG2Kkf7g= Received: from DB6P191CA0012.EURP191.PROD.OUTLOOK.COM (2603:10a6:6:28::22) by AM0PR08MB3617.eurprd08.prod.outlook.com (2603:10a6:208:db::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Thu, 2 Apr 2020 18:01:04 +0000 Received: from DB5EUR03FT046.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:28:cafe::40) by DB6P191CA0012.outlook.office365.com (2603:10a6:6:28::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Thu, 2 Apr 2020 18:01:04 +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 DB5EUR03FT046.mail.protection.outlook.com (10.152.21.230) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Thu, 2 Apr 2020 18:01:04 +0000 Received: ("Tessian outbound e2c88df8bbbe:v50"); Thu, 02 Apr 2020 18:01:04 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 0b5432c01707f6e2 X-CR-MTA-TID: 64aa7808 Received: from f0c298653308.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id B8890249-B9B3-4A27-AA60-936FE76B5C94.1; Thu, 02 Apr 2020 18:00:59 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f0c298653308.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 02 Apr 2020 18:00:59 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zh3SQGksV+D7ZVia9Rh4e/pRewbIN9p2DtdbT5+p0Rt+fyART0Ld5A0Lxdw7BvC2l5weLT3ALXvS83nytDsrGAESTyAl3X2U0tYF7vqO8IPOgrEsaPhRjDGXwf57SY+HoBAzul5FPXN7fJ3MeOn9x3HZwrYLqE0/0HWNpIXFfA0HNs67cFOld0jg9wHxm4q+SQ+xQdUiK7y++YBbcauVTzXVg21a7WSIiZ22EUB2rFbTaC8QfU/VYhUr3AmHO24L3uqc1CIelgNDfXymwqDS7RZ0yNproYEInLvXNJ/yUsP0qxbZ862w/XqPhXSPbUFqU9/KKjQ+/D0z/bf/rZEGgg== 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=j7s8jSxOXyEEdemFexFokADuXpZi/nk3ZBzDqwxCopY=; b=jp8aKcnj/6Do55ASbd+cm2hCMJ/1Mke9XB1ZKnMR0aaJiG3cc69eceSvX3hLsEo44UPwcyTppWh4X/BG2CA6BQ1WmqzRYdp+J15s8mxWmM8oR6J1H+Wh3Z2vfuMN2xVAqm9zyVGNtuQggpa1rlmg04sTsjSbK9vLraPIkrKYsQFw6yunPZCK6GO91+57ZJnyinz9pV69CAacXOlk2tWA/wb6z23as/oKxURSozrGhlIjb9qo3tPvjSBFyK2y6jTohsr2J0feld4iNzJAcg+ikGSMFRK+4vra/CwQXJg7WTa/yvU5lMBoZ7z02XxKUBv3ear2mLfuoevR9Oi5mvBwlg== 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=j7s8jSxOXyEEdemFexFokADuXpZi/nk3ZBzDqwxCopY=; b=PQmd/eH+V4QMLv5cImZiyQzOey3Jn1ZUmV6RhZjw5RE7U8PEssJ7Xq8NibPHJ6Jb4hwNOdF+mEe9Fy0UC6J8/4PUW/5sbNgtXnDRKxQN+tY0mdJHAo6eki6U98nIRo+/3BrKaDSVySu5lnoqChOboy7Rv032PRrDRiBNG2Kkf7g= Received: from DB7PR08MB3324.eurprd08.prod.outlook.com (52.135.128.161) by DB7PR08MB3084.eurprd08.prod.outlook.com (52.135.128.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.20; Thu, 2 Apr 2020 18:00:57 +0000 Received: from DB7PR08MB3324.eurprd08.prod.outlook.com ([fe80::41f6:faee:c1f4:6abe]) by DB7PR08MB3324.eurprd08.prod.outlook.com ([fe80::41f6:faee:c1f4:6abe%6]) with mapi id 15.20.2856.019; Thu, 2 Apr 2020 18:00:57 +0000 From: Hanno Becker To: Christopher Wood , "tls@ietf.org" Thread-Topic: [TLS] Gaps in specification of DTLS 1.3 state machine Thread-Index: AQHV8i/kjOxEBgrL9k2vj+OAIfvymqg5FgqAgABtZ86AAJGZAIAJWxuAgAAL1jOAItCdUw== Date: Thu, 2 Apr 2020 18:00:57 +0000 Message-ID: References: <0287f75a-015e-49eb-a052-cf7a53f03035@www.fastmail.com> , , In-Reply-To: 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: 32bfb97a-a807-4831-031a-08d7d72fcfdd x-ms-traffictypediagnostic: DB7PR08MB3084:|AM0PR08MB3617: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0361212EA8 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3324.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(346002)(136003)(376002)(39860400002)(366004)(81166006)(110136005)(33656002)(8936002)(316002)(19627405001)(81156014)(53546011)(7696005)(6506007)(2906002)(76116006)(478600001)(5660300002)(9686003)(52536014)(66446008)(71200400001)(8676002)(55016002)(66946007)(64756008)(66476007)(186003)(966005)(86362001)(26005)(30864003)(66556008); 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: UOMc3BRwdrTyxuogrhZDj9QkSU5KWYMHyj5536D4+/PT/DWT3+OyMQdFow+uzlEtct+WoJmmmdhEP0siIUCH8U/0xG+xbsIrZ1dMAInHcbAfovDPJXOq+Cs5fYzK/CQYGDgp0fgne9ZjWf7Nu1eDo0Wa+eRM+wrSDEeHlNcj5tAbobybQhiqv2ADXHVXBVREr1vz9QE4UAKU+GyCHfidSvlVAzyu3VSvCN4PyDddwBgVPnCeppaN2LkZaUD0YDUKuF0xIEx/P2bsFdFJW1jReU0yqJsavBTCZxyHIbTBkO+2UXOKAVP+GoUy3wU8GgbIuB4JB1nBntienwzYdBh9R2EFrLD9DKxQs8yR4p4U5mEOcoapJ8+DI/QTe37DKHq2/Y+GjyHi4KCQdzIvlhK0HgNjDzlP6Ao5DZ47LjbbFeSLc16m8Rl34UTjwbvyWONTkmuTgwjeDOkgTCyPN3Gw8VlYAWzCj9IFf/xEAXWd/COAmTI6k2GnhsLJs2Kg3KTixYYbqGfoA+9LupSAM1XGOA== x-ms-exchange-antispam-messagedata: U/hRBVd4X44jg8NvyZKkHSslL/4E3Y/897VZjFb6sGAmndah6CQn40/8vLZuqmj87f4MuZbsKxaRxtc2peku4pIf01dUA3h0B9NDI7DUo05fhvneEKpbiSQIKdWIxxkznHIWxWOuenS3qtphHZi/dg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DB7PR08MB332445AED53D8473FBAB5A389BC60DB7PR08MB3324eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3084 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT046.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)(39860400002)(136003)(346002)(396003)(376002)(46966005)(186003)(478600001)(53546011)(47076004)(30864003)(5660300002)(81156014)(966005)(8936002)(26826003)(81166006)(110136005)(8676002)(19627405001)(7696005)(33656002)(336012)(6506007)(55016002)(52536014)(26005)(82740400003)(70586007)(70206006)(2906002)(356004)(316002)(9686003)(86362001)(579004); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 4a85f748-88ce-446e-1daa-08d7d72fcb72 X-Forefront-PRVS: 0361212EA8 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZN99kvCG6wgzZ2qjUbUAQTx3ZpU0uR91TgIIe7zzb5R3L7HElWD0qRLjctAj2OupQNt54SW7uOciKHeJZ/cKBjAXSYBeoo0WiNwj1OIcEWtSSEBiKTzEVgkRzsAWrG9J61ZfC6H4SAsvsgGnZMqZnMzd/BYMvM4W3OPumLh5VzrFBByPv53wKE5DVK22YKgASKzCf5jaaMb48NerU9q9CCR4K4U+dcYpuhftOJqgt+663YIP7zkk91CDuZb0/WtATwHhW0YNgd9okCAp+rHxZDVtLfOi9RgW5gN9HdtG4u8iUN10Y5hcZ/hm43SgYnt8K4Yz/XTeVme7nNWHYEXDvIwquamUvBTF3jc8j+mHIOerxTJpyqJiX4L6qjaxe9tbpGCLOAkZ2JOtC8kQbTQ/wtW/6fFMYEny1JhwQISg/UpVm2Q9Cd7kKvSOSutorrG6kNy0VJuXaVuYc5b19yC1/AcM6R1VjHBjvxVWAU+gJ1eLPYThUIPgYG2YJgkymz3jIjdVKSI68mnk1pnFoQ9cR+uH4At3/o2vpxpqTr5K9/jVWe/Y/Ah21fEFo4O/QRJxnRmGBqAEU9+BwLpVXopFjw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Apr 2020 18:01:04.6957 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 32bfb97a-a807-4831-031a-08d7d72fcfdd 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: AM0PR08MB3617 Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2020 18:01:20 -0000 --_000_DB7PR08MB332445AED53D8473FBAB5A389BC60DB7PR08MB3324eurp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Ekr, Martin, Chris, I have created https://github.com/tlswg/dtls13-spec/pull/137 as a first att= empt to explicitly mention that multiple post-handshake messages should be treated via independent sta= te machines. Let me know what you think. ________________________________ From: TLS on behalf of Hanno Becker Sent: Wednesday, March 11, 2020 2:36 PM To: Christopher Wood ; tls@ietf.org Subject: Re: [TLS] Gaps in specification of DTLS 1.3 state machine Thanks Eric, Martin and Chris for your input! For the record: I withdraw my claim that there's an issue with handshake me= ssage 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 sta= te 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 th= ings 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 underly= ing '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 l= ogic after inspecting the message content. As a concrete example, one can consider multiple Certifica= teRequest 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 machin= e the message belongs to. Hence, in a nutshell, while for the main handshake the signaling between ha= ndshake 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 indi= cating which state machine an incoming message belongs to. Similarly, when sending messages, i= t needs to be indicated which state machine they belong to. Overall, I believe that it would be beneficial if the abstract model for th= e retransmission state machine - including the state machine duplication for post-handshake messag= es - received some more attention and (potentially formal) analysis. Cheers, Hanno ________________________________ From: TLS on behalf of Christopher Wood Sent: Wednesday, March 11, 2020 1:37 PM To: 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 prev= enting any out-of-order processing issues raised earlier on this thread, th= e 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 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 shoul= d avoid it for the sake of implementation simplicity. > > > > Moreover, even if it is acceptable that state machines should be duplic= ated, 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 authenti= cation while, simultaneously, the client initiates a key update. When the s= erver receives the KeyUpdate, it assumes from the handshake sequence number= that it is the reply to his CertificateRequest, and only when inspecting t= he 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 t= he connection, while here, we'd need the server to drop the message or noti= ce that it should fork a new state machine. > > > > Note that this problem already exists, albeit in less prominent form, i= n 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 segreg= ate the part of the retransmission state machine which establishes in-order= delivery via handshake sequence numbers, and to have the duplicated contex= ts one level higher. When a handshake message comes in, it would be trial-f= ed into all existing contexts, either until one of them accepts it after ch= ecking type and content, or potentially leading to the forking of a new con= text. > > > > However, this asynchronous nature of handling multiple post-handshake m= essages is in conflict with the serialized nature of the handshake transcri= pt used e.g. in the CertificateVerify message: > > > > Imagine a post-handshake client authentication to happen interwoven wit= h another post-handshake message from client to server. When the client wri= tes the CertificateVerify, that would require the transcript of the entire = handshake up until the CertificateVerify message. Assuming this should incl= ude all post-handshake messages, not just those belonging to the client aut= hentication, this may lead to the situation where the server receives a Cer= tificateVerify message with a transcript it cannot validate because it hasn= 't yet received all other authentication-independent post-handshake message= s 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 on behalf of Martin Thomson > > *Sent:* Wednesday, March 4, 2020 11:32 PM > > *To:* 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 wi= ll 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 thir= d class of numbers (0, 1, =1B$B!g=1B(B), we might as well deal with the ful= l implications of that. > > > > Handling this is fairly simple though. We can recommend limiting to on= ly one active transmission at a time. And if implementations have an especi= ally 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 retransmissi= on state > > > machine in the case of post-handshake messages, which requires clari= fication. > > > For example, is it allowed to send multiple post-handshake messages = without > > > waiting for ACKs for the previous ones? If so, how is the retransmis= sion > > > state machine modeled for sender and receiver in this case? > > > I'll describe and assess a few possible options, but I don't know th= e best > > > answer, and so this post is mostly a request for discussion, hopeful= ly > > > 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 messa= ges > > > 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 allow= ed > > > in WAITING state. > > > > > > Option A: Fork state machine > > > > > > One could circumvent this by 'forking' the retransmission state mach= ine > > > 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 degrad= es > > > 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 o= f > > > slower adoption and/or bugs. > > > Moreover, it will significantly harden efforts for formal verificati= on, > > > 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 fl= ight. > > > > > > 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 bac= k > > > 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 handsh= ake > > > that DTLS leverages now no longer > > > holds: Namely, that both sides implicitly know and agree on the boun= ds > > > 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 all= ow > > > 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 transit= ion > > > 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 mes= sages. > > > > > > One simple way to deal with is to add an explicit 'end-of-flight' bi= t > > > 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 m= ain > > > 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 com= e > > > up with some > > > precise description of the state machine evolution for post-handshak= e > > > 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 co= py > > > 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 > > IMPORTANT NOTICE: The contents of this email and any attachments are c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n 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 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. 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_DB7PR08MB332445AED53D8473FBAB5A389BC60DB7PR08MB3324eurp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable
Hi Ekr, Martin, Chris, 

I have created https://github.com/tlswg/dtls13-spec/pull/137 as a first attemp= t to explicitly mention
that multiple post-handshake messages should be treated via independent sta= te machines. 

Let me know what you think.
From: TLS <tls-bounces@i= etf.org> on behalf of Hanno Becker <Hanno.Becker@arm.com>
Sent: Wednesday, March 11, 2020 2:36 PM
To: Christopher Wood <caw@heapingbits.net>; tls@ietf.org <t= ls@ietf.org>
Subject: Re: [TLS] Gaps in specification of DTLS 1.3 state machine
 
Thanks Eric, Martin and Chris for your input!

For the record: I withdraw my claim that there's an issue with handshake me= ssage 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 th= ings 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, <= span style=3D"color:rgb(0,0,0); font-family:Calibri,Arial,Helvetica,sans-se= rif; font-size:12pt">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 <= span style=3D"color:rgb(0,0,0); font-family:Calibri,Arial,Helvetica,sans-se= rif; font-size:12pt">it becomes clear which state machine the message belongs to.&nb= sp;
Hence, in a nutshell, while for the main handshake the signaling between ha= ndshake 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 indi= cating which state
machine an incoming message belongs to. Similarly, when sending messages, i= t needs to be
indicated which state machine they belong to.

Overall, I believe that it would be beneficial if the abstract model for th= e retransmission state
machine - including the state machine duplication for post-handshake messag= es - 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 discus= sion, folks!

Given that endpoints *process* handshake messages in sequence, thereby prev= enting any out-of-order processing issues raised earlier on this thread, th= e 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<= br> > 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 t= o
> 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&= gt; 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 d= idn'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 t= hey're all tied together by the use of the same global handshake sequence n= umber. This creates non-trivial ambiguities like the following:
> >
> > Imagine after the handshake the server requests post-handshake au= thentication 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 th= e mismatch. Usually, a type mismatch would be treated as a protocol violati= on 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 f= orm, in DTLS 1.2, where both sides may simultaneously trigger a renegotiati= on.
> >
> > 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 potential= ly leading to the forking of a new context.
> >
> > However, this asynchronous nature of handling multiple post-hands= hake messages is in conflict with the serialized nature of the handshake tr= anscript used e.g. in the CertificateVerify message:
> >
> > Imagine a post-handshake client authentication to happen interwov= en with another post-handshake message from client to server. When the clie= nt writes the CertificateVerify, that would require the transcript of the e= ntire handshake up until the CertificateVerify message. Assuming this should include all post-handshake messages, not jus= t those belonging to the client authentication, this may lead to the situat= ion 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 m= e that the above are serious issues to be further discussed and clarified e= ven if we accept state machine duplication.
> >
> > Happy to hear your thoughts.
> >
> > Cheers,
> > Hanno
> > *From:* TLS <tls-bounces@ietf.org> on behalf of Martin Thom= son <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 mach= ine
> > 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 authenticatio= n, there will be two concurrent exchanges. We already require acknowledgmen= t for both request and response in a two-way exchange. Since 2 is a member of the third class of numbers (0, 1, =1B$B!g= =1B(B), we might as well deal with the full implications of that.
> >
> >  Handling this is fairly simple though. We can recommend lim= iting to only one active transmission at a time. And if implementations hav= e 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 th= e retransmission state
> >  > machine in the case of post-handshake messages, which = requires clarification.
> >  > For example, is it allowed to send multiple post-hands= hake 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 discu= ssion, hopefully
> >  > resulting in some common understanding and clarificati= on of the spec.
> >  >
> >  > Details:
> >  >
> >  > The following cases need addressing:
> >  > a) Is it allowed to send multiple post-handshake messa= ges (e.g.,
> >  > multiple session
> >  > tickets) without waiting for ACKs for the previous one= s? If so, how is
> >  > the
> >  > retransmission state machine modeled for sender and re= ceiver in this
> >  > case?
> >  > b) How should simultaneous sending/receiving of post-h= andshake 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 tre= ated as
> >  > single-message flights.
> >  > As such, the sender would enter WAITING state after se= nding the
> >  > post-handshake message,
> >  > and move to FINISHED on receipt of the corresponding A= CK. This,
> >  > however, forbids sending
> >  > another post-handshake message in between, since sendi= ng isn't allowed
> >  > in WAITING state.
> >  >
> >  > Option A: Fork state machine
> >  >
> >  > One could circumvent this by 'forking' the retransmiss= ion state machine
> >  > for post-handshake
> >  > messages, i.e. declaring their semantics as if there w= ere multiple
> >  > independent state machines
> >  > for each outstanding post-handshake message. This esse= ntially degrades
> >  > the DTLS' ACK scheme
> >  > to a per-message acknowledgement.
> >  >
> >  > I believe that such an approach is not in the spirit o= f the rest of the
> >  > protocol and moreover
> >  > significantly increases complexity and thereby comes a= t the danger of
> >  > slower adoption and/or bugs.
> >  > Moreover, it will significantly harden efforts for for= mal 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 stat= e 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 in= to a single flight.
> >  >
> >  > Another approach would be to treat multiple post-hands= hake messages as
> >  > a single flight on the sender.
> >  > That is, when the sender is in state WAITING after sen= ding the first
> >  > post-handshake message, and the
> >  > user request to send another one, it moves into SENDIN= G and then back
> >  > into WAITING as usual, appending
> >  > the new post-handshake message to the (so-far single-m= essage) 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 agr= ee 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 thi= s would be the following:
> >  >
> >  > Option D: Add an 'end-of-flight' signal to handshake m= essages to allow
> >  > dynamic-length flights.
> >  >
> >  > Recall that the handshake logic must inform the retran= smission state
> >  > machine about when a flight
> >  > is over in the main handshake, allowing the state mach= ine to transition
> >  > accordingly. This signal,
> >  > however, isn't explicitly conveyed to the receiver, be= cause 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 sessi= on tickets.
> >  > Moreover, such a signal
> >  > would be trivial to implement because it's already imp= licit 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 approac= h.
> >  >
> >  >
> >  >
> >  > Happy to hear everyone's thoughts. It would be great i= f 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 mes= sages.
> >  >
> >  > Best,
> >  > Hanno
> >  > IMPORTANT NOTICE: The contents of this email and any a= ttachments are
> >  > confidential and may also be privileged. If you are no= t 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 attach= ments are confidential and may also be privileged. If you are not the inten= ded 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 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.
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_DB7PR08MB332445AED53D8473FBAB5A389BC60DB7PR08MB3324eurp_-- From nobody Thu Apr 2 11:03:53 2020 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 D10B63A1071 for ; Thu, 2 Apr 2020 11:03:51 -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=vNNIWp0J; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=vNNIWp0J 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 TsscxGCrZlbB for ; Thu, 2 Apr 2020 11:03:48 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2078.outbound.protection.outlook.com [40.107.20.78]) (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 2B7583A1078 for ; Thu, 2 Apr 2020 11:03:47 -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=8rlOPs2uCBWilQdvKM0amFMpSyfARqmcrW+97ml1AoI=; b=vNNIWp0JfIQ1g0gPsKneJ+Mpo8WiVUGJgSaVSBm3LDjLMWYcfF6fZqdzjlibn5UXgF9thE0f/A+vjKtLcP7o4pOcqMo6YhuxMlSpyKXYTRyh+sqrbDJZ9iN6HGMLUJ2wEY+hdH7x57xK6dz60qvLh2w1DwxegaCyrqOhdC2Szz4= Received: from AM5PR0202CA0009.eurprd02.prod.outlook.com (2603:10a6:203:69::19) by DB6PR0801MB1670.eurprd08.prod.outlook.com (2603:10a6:4:37::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Thu, 2 Apr 2020 18:03:44 +0000 Received: from AM5EUR03FT045.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:69:cafe::5a) by AM5PR0202CA0009.outlook.office365.com (2603:10a6:203:69::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Thu, 2 Apr 2020 18:03:44 +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 AM5EUR03FT045.mail.protection.outlook.com (10.152.17.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Thu, 2 Apr 2020 18:03:43 +0000 Received: ("Tessian outbound 5345ff401cf8:v50"); Thu, 02 Apr 2020 18:03:43 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 4d4c3e27ec41689f X-CR-MTA-TID: 64aa7808 Received: from f6831da1dcea.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 9704F347-DA90-4295-9AAF-01C5C6F43B75.1; Thu, 02 Apr 2020 18:03:38 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f6831da1dcea.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 02 Apr 2020 18:03:38 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GL6YtGKxb8RzQz4qobrMtofm9SIphKLqPPZQvfAD2XIVYm+7W3n3+KoN/DPoM05g/pP8WhSLLY3e09up3aQrNW/dkEeTuC05hW+1CVoexZeTql6nqCFP5xB560RTZY2IaCqtWb13OKVlAJOKFXAJ7A+X3RcUayh6GmXkU971SLRuFeXLXMDbXEPA0haPse2d5qudgUgiknp54antNLTDf8KC2EFsGiFsmcQV0OXaGDSm32H80VlJSx4FALHqSiUYgR/ZgUHSa4uVwlqMyzFPKcF73TUJi+USCC1eTreOHeCJGrQZjlA75I8LEX4mHxpcPQWeIg68QPQodaYLqM+4lw== 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=8rlOPs2uCBWilQdvKM0amFMpSyfARqmcrW+97ml1AoI=; b=jUSvALTwGAtH4OBV841k2sPho10i5cPJLtoR85AtBFgj0nG5Z4Ui3S1T68WPN8yLj3jRO6GpEn/2jpaf+2XR0Vm+nULxuswAONU71K6RWzGspvYMwBYhQk4E6fqALTMoEUGB1eDuschm5lbr7dWOBuMwMs9z8rhZLb2B6R4sea+pSwrqKCBsEityx47+SZJ0qS68CoRLlMBuc3oe75+Yujh1zm9ezI8F+ixIszGtfQga/DmpK1qHhOGTFC/b9GzWeEgXPZ8mMo7jCEoS3Ea/9//lDNrNQSY3YnmzceMMrT6c4I/XkAAImPU0FPY6aFPxsL9WtXQUaSIWsC+OcJ4tag== 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=8rlOPs2uCBWilQdvKM0amFMpSyfARqmcrW+97ml1AoI=; b=vNNIWp0JfIQ1g0gPsKneJ+Mpo8WiVUGJgSaVSBm3LDjLMWYcfF6fZqdzjlibn5UXgF9thE0f/A+vjKtLcP7o4pOcqMo6YhuxMlSpyKXYTRyh+sqrbDJZ9iN6HGMLUJ2wEY+hdH7x57xK6dz60qvLh2w1DwxegaCyrqOhdC2Szz4= Received: from DB7PR08MB3324.eurprd08.prod.outlook.com (52.135.128.161) by DB7PR08MB3916.eurprd08.prod.outlook.com (20.178.47.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Thu, 2 Apr 2020 18:03:36 +0000 Received: from DB7PR08MB3324.eurprd08.prod.outlook.com ([fe80::41f6:faee:c1f4:6abe]) by DB7PR08MB3324.eurprd08.prod.outlook.com ([fe80::41f6:faee:c1f4:6abe%6]) with mapi id 15.20.2856.019; Thu, 2 Apr 2020 18:03:36 +0000 From: Hanno Becker To: Jonathan Hammell CC: Sean Turner , TLS List Thread-Topic: [TLS] 3rd WGLC for draft-ietf-tls-dtls13 Thread-Index: AQHV/sJkDO89hoOQBUezhg8xnSTmm6hct5YAgAMBhF2AAX7WAIAE/AEj Date: Thu, 2 Apr 2020 18:03:35 +0000 Message-ID: References: <150AD400-C080-4676-80DE-7A0EC0ECE7BD@sn3rd.com> , In-Reply-To: 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: 289806fc-5fbe-4379-7245-08d7d7302ec9 x-ms-traffictypediagnostic: DB7PR08MB3916:|DB6PR0801MB1670: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:4941;OLM:4941; x-forefront-prvs: 0361212EA8 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR08MB3324.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(136003)(396003)(346002)(39860400002)(376002)(76116006)(19627405001)(33656002)(54906003)(52536014)(5660300002)(2906002)(4326008)(316002)(26005)(966005)(71200400001)(478600001)(6506007)(8676002)(186003)(6916009)(9686003)(66556008)(64756008)(66946007)(66476007)(8936002)(7696005)(66446008)(53546011)(30864003)(81166006)(55016002)(86362001)(81156014); 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: qdIiKe4RP4f3DZIPHZPLjjlNLnFgigVtD3/mfyPdHvra7GXTO7xlA640THwuFBr4s8Gd4Z1tAnj/8AiGz1KqDzt2sLzOWQwvilLM25Cp4UD3mrF713nU47h9S3gqkg0R3qbyHtai6yYbZYEkunGp/d+jcF6lNKYdW4YHTsMcEiIyzdNuLpY9v9pj3pdMqsZ3jPcW0BdM1lvubCGqm4AeATheHwwXDL2oz9fvqETVy1tJtiexqTQFuW87caWTCy0cJghCRbR9tuVo8NAVUbF+rRPQjynUZhyOTZa09mUcVB7BxHVMxRUFyRDBx+arypuTM299/G7WNfNqgeAT6ZBLgixjV7HwCCSqTLSwwsAxXLlhmxWsYUQIxROisE0KsyzxcGvmZ3w0t+iOt8WI7rjvIsI9u/CpzbTeve8D34TwT1c52S6fQjjQAoITarDFPZzugigI9bCNtyp5vRoBXSLBYlczszROUyH7Un2w7bQombWY8piszpROzmwInPXWgImw6nQzrZNrFmDtKAcNEnyDCQ== x-ms-exchange-antispam-messagedata: 781CWsfJFnKRKTRUTW4kBRZGHZf8+afXM+QAUdFXrT9oPH4GvHT0olU130XfYxIhMOPeqg9eFShBnOqy3egS1K+ZbCDOrK76ZgB1t8W9MOlkeNY8o1PD6LDralCOlIQqEF7HTyhezSYeFZwvAu2KuA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DB7PR08MB33242E140F967FC5BD3C9B579BC60DB7PR08MB3324eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3916 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT045.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)(346002)(136003)(376002)(396003)(39860400002)(46966005)(54906003)(8676002)(81156014)(81166006)(86362001)(186003)(8936002)(6506007)(53546011)(6862004)(19627405001)(4326008)(9686003)(7696005)(55016002)(33656002)(26005)(356004)(30864003)(70206006)(70586007)(966005)(478600001)(26826003)(82740400003)(316002)(52536014)(47076004)(5660300002)(36906005)(2906002)(336012); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 2126aab5-5218-43d5-9b3c-08d7d7302a53 X-Forefront-PRVS: 0361212EA8 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1s7VACwIgkEUIedfbwnCJSrEsb2deE1PDhRR5Xsp1ceJgfmo555R72x8v+7wH9XKfEQkrNCSlbY8KdzIwFGD1MeY9LU1wQ+5gTe2Nkm/Z9Dha661oZZM7t8wx1RVdkoR6gqm5A7NFKGGPz2C/2IbLbjVFA53saIS4qOTSVbYK60b4snJILoElSY/6mt1DcpL3jCFqhdbWL9Kz1a3JFggWPfvmlP8JBAUPIAY8HUvTJGtPrV8XZTEZJPKpBBFDz+v5gUmRsYGFDYlw1mXM6v7Aq+1ZnQptF7BX8CJUT+7ARH97m4O72t5V5vyr0np/3zqTURQ5+eEQv5M0fw/Fx+dp2+5RA2mdb1/bkVftI7IdVk9XNCGXZA+Qg8rkEMdsdmm9wQ38gt3zwV+x7d8oSZbO8CY+5spef5lCCI1Biryb3hj5gEaOSJwBPW40SflJp1izvbAZKRMgjynZjMgRZwiMFKa0CoD9QCXyBcT0iW44r9/TIWT9EfQCERM9ypjO6LmDlOVez17+WhhJvaMHem2AA3zRCfmgsHpe64GjPytaboeCJitkYrXQB/BNZWMxo5RuGvJE0SZgGCZKxT3uwDNmQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Apr 2020 18:03:43.8659 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 289806fc-5fbe-4379-7245-08d7d7302ec9 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: DB6PR0801MB1670 Archived-At: Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13 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: Thu, 02 Apr 2020 18:03:52 -0000 --_000_DB7PR08MB33242E140F967FC5BD3C9B579BC60DB7PR08MB3324eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jonathan, I have created https://github.com/tlswg/dtls13-spec/pull/139/ as an attempt= to clarify the distinction between when to ACK and what to ACK. Let me know what you think. Best, Hanno ________________________________ From: Jonathan Hammell Sent: Monday, March 30, 2020 2:54 PM To: Hanno Becker Cc: Sean Turner ; TLS List Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13 Hi Hanno, Thank you for your clarifications. The example you gave helps a lot. I believe I now understand the text as written in this bullet (first bullet, not second--my bad). I no longer think it needs re-wording. Best regards, Jonathan On Sun, Mar 29, 2020 at 11:07 AM Hanno Becker wrote: > > Hi Jonathan, > > > In Section 7.1, the 2nd bullet following para 1 reads: "When they > > receive a message or fragment which is out of order, either because it > > is not the next expected message or because it is not the next piece > > of the current message. Implementations MUST NOT send ACKs for > > handshake messages which they discard as > > out-of-order, because otherwise those messages will not be retransmitte= d." > > This is confusing as the difference between "out of order" messages > > that require an ACK and those that do not is not quite clear. Also the > > term "out of order" is written in two ways in this paragraph. > > On second read, I agree that this is confusing. The point is that > while, to my understanding, out-of-order messages should trigger > the transmission of an ACK acknowledging what has been processed > so far, the out-of-order messages themselves must not be included > in those ACKs unless they have been buffered. > > In more detail, there are two kinds of feedback signals from the > handshake layer to the record layer: > > 1. Signal whether there is some disruption in the incoming flight > which the peer should be informed about via an ACK of those > messages received and processed so far. > > That's what the first sentence in the above quote is about. > > 2. Signal whether a handshake message has been processed. > > That's what the second sentence in the above quote is about, > which can also be rephased as follows: > An ACK must only be sent for those records which consist of > handshake messages each of which has been signalled as > processed by the handshake layer. > > In particular, in situations where a single record contains > multiple handshake messages/fragments, and the implementation > processes only some of them, the record must not be acknowledged. > A real-world example for this would be an implementation which > supports out-of-order buffering but only contiguous reassembly: > If the initial fragment of a HS message gets sent in one record > which is lost, and the final fragment together with a subsequent > handshake message is sent in another record, then this latter > record must not be ACKed if the stack drops the fragment. > > Unbuffered out-of-order handshake messages do trigger signal 1, > but they don't trigger signal 2. > > At least, that's my understanding. > > Best, > Hanno > ________________________________ > From: TLS on behalf of Jonathan Hammell > Sent: Friday, March 27, 2020 5:10 PM > To: Sean Turner > Cc: TLS List > Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13 > > I know that this WGLC was supposed to focus on the diff between -34 > and -37. I don't have any comments on that diff, but I do have some > comments on the draft following a re-read of the entire document. > > # Minor > > The term "deprotection" is used twice in document but never defined. > > Section 5.11 abandoning vs destroying association. In the document we > see the term "abandon" being used, referring to associations. However > section 5.11 states that a server "MUST NOT destroy the existing > association" and then further along it states that "the server MUST > abandon the previous association". Do abandon and destroy mean the > same thing? > > In Section 7, what does "handshake-containing" mean in the phrase "The > ACK message is used by an endpoint to indicate > handshake-containing..."? > > In Section 7, what does "non-duplicative" mean in phrase > "Implementations MUST NOT acknowledge records containing > non-duplicative handshake messages..."? > > In Section 7.1, the 2nd bullet following para 1 reads: "When they > receive a message or fragment which is out of order, either because it > is not the next expected message or because it is not the next piece > of the current message. Implementations MUST NOT send ACKs for > handshake messages which they discard as > out-of-order, because otherwise those messages will not be retransmitted.= " > This is confusing as the difference between "out of order" messages > that require an ACK and those that do not is not quite clear. Also the > term "out of order" is written in two ways in this paragraph. > > In Figure 10, the edge going from SENDING to FINISHED has no label to > differentiate with edge to WAITING. Should it read: "send last > flight"? > > In Figure 13, why is there no NewConnectionID message in the exchanges > since new CIDs are offered? Also, a short explanation of the CID > negotiation and exchange could be helpful in the text. > > The state machine in Figure 10 is somewhat puzzling. How do we > differentiate between "Receive ACK for last flight" and "Receive last > flight"? According to Figure 7, for example, the last ACK is a flight > itself. Also, with respect to the client, if sending last flight > takes him to finished state, how will he then receive the ACK for his > final flight? > > > # Nits > > Section 3.1 Packet Loss. Figure 1 is a little confusing since it > resembles Figure 5; as each has the server sending a > HelloRetryRequest. Might illustrate the concept better to have the > server send a ServerHello in Figure 1 rather than a HelloRetryRequest? > > Section 5.1. para 3 - Typo. "The DTLS 1.3 specification changes the > way how cookies are exchanged compared to DTLS 1.2. DTLS 1.3 re-uses > the HelloRetryRequest message". The "... the way how cookies..." > either use "how" or "the way" but not both. > > Page 9 last para - Typo. s/assocatiation/association > > In section 3, bullet #3, the term "flight" is used without being > defined; a reference to section 5.6 would be nice. > > MSL is used first in section 4.2.1 but only defined in section 5.7.1 > > In section 5.11 the notion of "CID concept" is mentioned. Might be > nice to refer to section 9.1 where an example of the concept is > presented. Also, section 9.1 never mentions "CID concept"; might be > good to add the term to know that we are talking about the same > thing. > > Figure 11 has no commentary describing the sequence. It would be helpful,= for > example, to add details on why the two ACKs are sent. > > In Section 6.1, the phrase "...loss and re-order an identifier is needed = to > determine..." could use a comma after "re-order" and possibly replace > "re-order" with "re-ordering". > > In Section 6.1, the phrase "In addition to the key derivation steps > described in Section 7 of [TLS13] triggered by the states during the > handshake a sender may want to rekey at any time during the lifetime > of the connection and has to have a way to indicate that it is > updating its sending cryptographic keys" is long and difficult to > follow. It could be rephrased as "In addition to > the key derivation steps described in Section 7 of [TLS13], a sender > may want to rekey at any time during the lifetime of the connection. > The epoch value provides a means to indicate that the sender is > updating its sending cryptographic keys." > > In Section 6.1, replace "For example, client incorrectly uses..." with > "For example, if a client incorrectly uses..." > > In Section 7, the term "current key" is used in the phrase > "Implementations SHOULD simply use the current key." Would it be > clearer to say that "Implementations SHOULD use the key material of > the current epoch"? > > In Section 8, paragraph 3, what does a "canned ACK message" mean? > > Section 11, second para, s/Even with such a test, An/Even with such a tes= t, an > > Section 11, third bullet: the statement "...DTLS 1.3 records > irrespectively of the use of a CID" could be rephrased as "...DTLS 1.3 > records irrespective of whether a CID is used or not." > > On Fri, Mar 20, 2020 at 10:18 AM Sean Turner wrote: > > > > This is the third working group last call for the "The Datagram Transpo= rt > > Layer Security (DTLS) Protocol Version 1.3" draft available at > > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/. Please > > review the document and send your comments to the list by 2359 UTC on > > 27 March 2019. > > > > This is a targeted one-week WGLC intended to focus on the changes from = -34, which was the subject of the second working group last call, and -37. = The diffs between -34 and -37 can be found at: > > https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-dtls13-34&url2=3Ddra= ft-ietf-tls-dtls13-37 > > As you will see in the diffs, the changes include 2119-language related= changes in s5.1 and s7. These two changes were introduced in -35, which wa= s post in November. > > > > Note the the GH repo for this draft can be found at: > > https://github.com/tlswg/dtls13-spec > > > > Thanks, > > Chris, Joe, and Sean > > _______________________________________________ > > 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 conf= idential and may also be privileged. If you are not the intended recipient,= please notify the sender immediately and do not disclose the contents to a= ny other person, use it for any purpose, or store or copy the information i= n any medium. Thank you. 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_DB7PR08MB33242E140F967FC5BD3C9B579BC60DB7PR08MB3324eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Jonathan,

I have created https://github.com/tlswg/dtls13-spec/pull/139/ as an attempt t= o clarify
the distinction between when to ACK and= what to ACK. 

Let me know what you think.

Best,
Hanno
From: Jonathan Hammell <= jfhamme.cccs@gmail.com>
Sent: Monday, March 30, 2020 2:54 PM
To: Hanno Becker <Hanno.Becker@arm.com>
Cc: Sean Turner <sean@sn3rd.com>; TLS List <tls@ietf.org>= ;
Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13
 
Hi Hanno,

Thank you for your clarifications.  The example you gave helps a lot.<= br> I believe I now understand the text as written in this bullet (first
bullet, not second--my bad).  I no longer think it needs re-wording.
Best regards,
Jonathan

On Sun, Mar 29, 2020 at 11:07 AM Hanno Becker <Hanno.Becker@arm.com> = wrote:
>
> Hi Jonathan,
>
> > In Section 7.1, the 2nd bullet following para 1 reads: "When= they
> > receive a message or fragment which is out of order, either becau= se it
> > is not the next expected message or because it is not the next pi= ece
> > of the current message. Implementations MUST NOT send ACKs for > > handshake messages which they discard as
> > out-of-order, because otherwise those messages will not be retran= smitted."
> > This is confusing as the difference between "out of order&qu= ot; messages
> > that require an ACK and those that do not is not quite clear. Als= o the
> > term "out of order" is written in two ways in this para= graph.
>
> On second read, I agree that this is confusing. The point is that
> while, to my understanding, out-of-order messages should trigger
> the transmission of an ACK acknowledging what has been processed
> so far, the out-of-order messages themselves must not be included
> in those ACKs unless they have been buffered.
>
> In more detail, there are two kinds of feedback signals from the
> handshake layer to the record layer:
>
> 1. Signal whether there is some disruption in the incoming flight
>    which the peer should be informed about via an ACK o= f those
>    messages received and processed so far.
>
>    That's what the first sentence in the above quote is= about.
>
> 2. Signal whether a handshake message has been processed.
>
>    That's what the second sentence in the above quote i= s about,
>    which can also be rephased as follows:
>    An ACK must only be sent for those records which con= sist of
>    handshake messages each of which has been signalled = as
>    processed by the handshake layer.
>
>    In particular, in situations where a single record c= ontains
>    multiple handshake messages/fragments, and the imple= mentation
>    processes only some of them, the record must not be = acknowledged.
>    A real-world example for this would be an implementa= tion which
>    supports out-of-order buffering but only contiguous = reassembly:
>    If the initial fragment of a HS message gets sent in= one record
>    which is lost, and the final fragment together with = a subsequent
>    handshake message is sent in another record, then th= is latter
>    record must not be ACKed if the stack drops the frag= ment.
>
> Unbuffered out-of-order handshake messages do trigger signal 1,
> but they don't trigger signal 2.
>
> At least, that's my understanding.
>
> Best,
> Hanno
> ________________________________
> From: TLS <tls-bounces@ietf.org> on behalf of Jonathan Hammell &= lt;jfhamme.cccs@gmail.com>
> Sent: Friday, March 27, 2020 5:10 PM
> To: Sean Turner <sean@sn3rd.com>
> Cc: TLS List <tls@ietf.org>
> Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13
>
> I know that this WGLC was supposed to focus on the diff between -34 > and -37.  I don't have any comments on that diff, but I do have s= ome
> comments on the draft following a re-read of the entire document.
>
> # Minor
>
> The term "deprotection" is used twice in document but never = defined.
>
> Section 5.11 abandoning vs destroying association.  In the docume= nt we
> see the term "abandon" being used, referring to associations= . However
> section 5.11 states that a server "MUST NOT destroy the existing<= br> > association" and then further along it states that "the serv= er MUST
> abandon the previous association". Do abandon and destroy mean th= e
> same thing?
>
> In Section 7, what does "handshake-containing" mean in the p= hrase "The
> ACK message is used by an endpoint to indicate
> handshake-containing..."?
>
> In Section 7, what does "non-duplicative" mean in phrase
> "Implementations MUST NOT acknowledge records containing
> non-duplicative handshake messages..."?
>
> In Section 7.1, the 2nd bullet following para 1 reads: "When they=
> receive a message or fragment which is out of order, either because it=
> is not the next expected message or because it is not the next piece > of the current message. Implementations MUST NOT send ACKs for
> handshake messages which they discard as
> out-of-order, because otherwise those messages will not be retransmitt= ed."
> This is confusing as the difference between "out of order" m= essages
> that require an ACK and those that do not is not quite clear. Also the=
> term "out of order" is written in two ways in this paragraph= .
>
> In Figure 10, the edge going from SENDING to FINISHED has no label to<= br> > differentiate with edge to WAITING. Should it read: "send last > flight"?
>
> In Figure 13, why is there no NewConnectionID message in the exchanges=
> since new CIDs are offered?  Also, a short explanation of the CID=
> negotiation and exchange could be helpful in the text.
>
> The state machine in Figure 10 is somewhat puzzling.  How do we > differentiate between "Receive ACK for last flight" and &quo= t;Receive last
> flight"? According to Figure 7, for example, the last ACK is a fl= ight
> itself.  Also, with respect to the client, if sending last flight=
> takes him to finished state, how will he then receive the ACK for his<= br> > final flight?
>
>
> # Nits
>
> Section 3.1 Packet Loss.  Figure 1 is a little confusing since it=
> resembles Figure 5; as each has the server sending a
> HelloRetryRequest. Might illustrate the concept better to have the
> server send a ServerHello in Figure 1 rather than a HelloRetryRequest?=
>
> Section 5.1. para 3 - Typo.  "The DTLS 1.3 specification cha= nges the
> way how cookies are exchanged compared to DTLS 1.2. DTLS 1.3 re-uses > the HelloRetryRequest message". The "... the way how cookies= ..."
> either use "how" or "the way" but not both.
>
> Page 9 last para - Typo.  s/assocatiation/association
>
> In section 3, bullet #3, the term "flight" is used without b= eing
> defined; a reference to section 5.6 would be nice.
>
> MSL is used first in section 4.2.1 but only defined in section 5.7.1 >
> In section 5.11 the notion of "CID concept" is mentioned. Mi= ght be
> nice to refer to section 9.1 where an example of the concept is
> presented. Also, section 9.1 never mentions "CID concept"; m= ight be
> good to add the term to know that we are talking about the same
> thing.
>
> Figure 11 has no commentary describing the sequence. It would be helpf= ul, for
> example, to add details on why the two ACKs are sent.
>
> In Section 6.1, the phrase "...loss and re-order an identifier is= needed to
> determine..." could use a comma after "re-order" and po= ssibly replace
> "re-order" with "re-ordering".
>
> In Section 6.1, the phrase "In addition to the key derivation ste= ps
> described in Section 7 of [TLS13] triggered by the states during the > handshake a sender may want to rekey at any time during the lifetime > of the connection and has to have a way to indicate that it is
> updating its sending cryptographic keys" is long and difficult to=
> follow.  It could be rephrased as "In addition to
> the key derivation steps described in Section 7 of [TLS13], a sender > may want to rekey at any time during the lifetime of the connection. > The epoch value provides a means to indicate that the sender is
> updating its sending cryptographic keys."
>
> In Section 6.1, replace "For example, client incorrectly uses...&= quot; with
> "For example, if a client incorrectly uses..."
>
> In Section 7, the term "current key" is used in the phrase > "Implementations SHOULD simply use the current key."  W= ould it be
> clearer to say that "Implementations SHOULD use the key material = of
> the current epoch"?
>
> In Section 8, paragraph 3, what does a "canned ACK message" = mean?
>
> Section 11, second para, s/Even with such a test, An/Even with such a = test, an
>
> Section 11, third bullet: the statement "...DTLS 1.3 records
> irrespectively of the use of a CID" could be rephrased as ".= ..DTLS 1.3
> records irrespective of whether a CID is used or not."
>
> On Fri, Mar 20, 2020 at 10:18 AM Sean Turner <sean@sn3rd.com> wr= ote:
> >
> > This is the third working group last call for the "The Datag= ram Transport
> > Layer Security (DTLS) Protocol Version 1.3" draft available = at
> > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/. Please
> > review the document and send your comments to the list by 2359 UT= C on
> > 27 March 2019.
> >
> > This is a targeted one-week WGLC intended to focus on the changes= from -34, which was the subject of the second working group last call, and= -37. The diffs between -34 and -37 can be found at:
> > https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-dtls13-34&url2=3Ddra= ft-ietf-tls-dtls13-37
> > As you will see in the diffs, the changes include 2119-language r= elated changes in s5.1 and s7. These two changes were introduced in -35, wh= ich was post in November.
> >
> > Note the the GH repo for this draft can be found at:
> > https://github.c= om/tlswg/dtls13-spec
> >
> > Thanks,
> > Chris, Joe, and Sean
> > _______________________________________________
> > 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 c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
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_DB7PR08MB33242E140F967FC5BD3C9B579BC60DB7PR08MB3324eurp_-- From nobody Thu Apr 2 13:19:48 2020 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 340B33A159F for ; Thu, 2 Apr 2020 13:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 9MuLAMXo81U4 for ; Thu, 2 Apr 2020 13:19:46 -0700 (PDT) Received: from mail-yb1-xb43.google.com (mail-yb1-xb43.google.com [IPv6:2607:f8b0:4864:20::b43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60123A159D for ; Thu, 2 Apr 2020 13:19:45 -0700 (PDT) Received: by mail-yb1-xb43.google.com with SMTP id l84so2912253ybb.1 for ; Thu, 02 Apr 2020 13:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=00du6o7yTr5EnIbL3e7+mIuMbRx0h+fg/+NS+Bfhefw=; b=bHsTVevfGpXzT2n514PwfjhQn3Ht0CkpAxi7ksMx8AvFYUgb09/ArVK4t2vkrccZ9L Fb48Y6tDQOa6Et4Na1par66Qrlg3pJEB0KT5/fZyemj0HPCLkT8WrpENy+/2m0ML4vG/ fBhMZinZdq5CfHnoJbj3mT2xXK/KWpzYq++FBwFnON3gtgDiYzsYb9r64aC20q/YkhgH hRu5s0ToDwfYjWutCqvB3xAX9I5La7q8xzrHz042f8+9wjiM282y8bKh76olebSVIr1L xo69Tnp5uoy92Hx9dY/xa7jp22hH2681aak9pOLmPdSml1WlDsUrQCsL/hf5i1oA57a9 jL2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=00du6o7yTr5EnIbL3e7+mIuMbRx0h+fg/+NS+Bfhefw=; b=lK0HkdfENLR7ROfck13XLs9Wwnr2MSCSLt371OXWgIbrSeBfv6QSoK01c/4MxcLGNq ltVlj8EdbWy7tQFI8YpUOGW53Tt57MUSI6NrMgFmjCAJrTgHRqpZjpAZpwyxb0XxovP2 8KI1uRxp1+w3JnI1gjkcgBoN+X8Lo5IdAzSYcB57dfnCGqenRZbEAPuHktSLJmlZ/HsD CsIs5ihOJEk2TYtxhhAVzE4aRL4u0Ou1SF69aFMIry3zcPBWEsj8z81v3DOBBAKa+D7h TPwd6qTKrRND6QpUx4o4m0ZMw+JkgU6GlbCSW5MuaRsZyGnvAkludRGdSMIPu8nGxA+M U+TQ== X-Gm-Message-State: AGi0PuYgBTChbhmKvW4v/hj351HoF0catvXLiJ6O5Bsk9pJYRA4ltLP/ jkqPsakctpq40xOnrtCAktbqvkxKFM4Y8PulKUc= X-Google-Smtp-Source: APiQypJ/xVRIXfGrA6oQp4XrBjSOr3axYppeqN7gkp2BzahpHxeeuLMWc2eZ2DjXUl7Nnid9UZsICTynrycDdC/9Ie0= X-Received: by 2002:a25:4d86:: with SMTP id a128mr8008607ybb.495.1585858785088; Thu, 02 Apr 2020 13:19:45 -0700 (PDT) MIME-Version: 1.0 References: <150AD400-C080-4676-80DE-7A0EC0ECE7BD@sn3rd.com> In-Reply-To: From: Jonathan Hammell Date: Thu, 2 Apr 2020 16:19:33 -0400 Message-ID: To: Hanno Becker Cc: Sean Turner , TLS List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13 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: Thu, 02 Apr 2020 20:19:48 -0000 Hi Hanno, This is much clearer to me. I see that you have removed the sentence I was having a problem with in the bullet: "Implementations MUST NOT send ACKs for handshake messages which they discard as out-of-order, because otherwise those messages will not be retransmitted"; logically, I believe you have captured this better by adding "and processed" above in "The ACK message is used by an endpoint to indicate which handshake records it has received and processed from the other side." Best regards, Jonathan On Thu, Apr 2, 2020 at 2:03 PM Hanno Becker wrote: > > Hi Jonathan, > > I have created https://github.com/tlswg/dtls13-spec/pull/139/ as an attem= pt to clarify > the distinction between when to ACK and what to ACK. > > Let me know what you think. > > Best, > Hanno > ________________________________ > From: Jonathan Hammell > Sent: Monday, March 30, 2020 2:54 PM > To: Hanno Becker > Cc: Sean Turner ; TLS List > Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13 > > Hi Hanno, > > Thank you for your clarifications. The example you gave helps a lot. > I believe I now understand the text as written in this bullet (first > bullet, not second--my bad). I no longer think it needs re-wording. > > Best regards, > Jonathan > > On Sun, Mar 29, 2020 at 11:07 AM Hanno Becker wrot= e: > > > > Hi Jonathan, > > > > > In Section 7.1, the 2nd bullet following para 1 reads: "When they > > > receive a message or fragment which is out of order, either because i= t > > > is not the next expected message or because it is not the next piece > > > of the current message. Implementations MUST NOT send ACKs for > > > handshake messages which they discard as > > > out-of-order, because otherwise those messages will not be retransmit= ted." > > > This is confusing as the difference between "out of order" messages > > > that require an ACK and those that do not is not quite clear. Also th= e > > > term "out of order" is written in two ways in this paragraph. > > > > On second read, I agree that this is confusing. The point is that > > while, to my understanding, out-of-order messages should trigger > > the transmission of an ACK acknowledging what has been processed > > so far, the out-of-order messages themselves must not be included > > in those ACKs unless they have been buffered. > > > > In more detail, there are two kinds of feedback signals from the > > handshake layer to the record layer: > > > > 1. Signal whether there is some disruption in the incoming flight > > which the peer should be informed about via an ACK of those > > messages received and processed so far. > > > > That's what the first sentence in the above quote is about. > > > > 2. Signal whether a handshake message has been processed. > > > > That's what the second sentence in the above quote is about, > > which can also be rephased as follows: > > An ACK must only be sent for those records which consist of > > handshake messages each of which has been signalled as > > processed by the handshake layer. > > > > In particular, in situations where a single record contains > > multiple handshake messages/fragments, and the implementation > > processes only some of them, the record must not be acknowledged. > > A real-world example for this would be an implementation which > > supports out-of-order buffering but only contiguous reassembly: > > If the initial fragment of a HS message gets sent in one record > > which is lost, and the final fragment together with a subsequent > > handshake message is sent in another record, then this latter > > record must not be ACKed if the stack drops the fragment. > > > > Unbuffered out-of-order handshake messages do trigger signal 1, > > but they don't trigger signal 2. > > > > At least, that's my understanding. > > > > Best, > > Hanno > > ________________________________ > > From: TLS on behalf of Jonathan Hammell > > Sent: Friday, March 27, 2020 5:10 PM > > To: Sean Turner > > Cc: TLS List > > Subject: Re: [TLS] 3rd WGLC for draft-ietf-tls-dtls13 > > > > I know that this WGLC was supposed to focus on the diff between -34 > > and -37. I don't have any comments on that diff, but I do have some > > comments on the draft following a re-read of the entire document. > > > > # Minor > > > > The term "deprotection" is used twice in document but never defined. > > > > Section 5.11 abandoning vs destroying association. In the document we > > see the term "abandon" being used, referring to associations. However > > section 5.11 states that a server "MUST NOT destroy the existing > > association" and then further along it states that "the server MUST > > abandon the previous association". Do abandon and destroy mean the > > same thing? > > > > In Section 7, what does "handshake-containing" mean in the phrase "The > > ACK message is used by an endpoint to indicate > > handshake-containing..."? > > > > In Section 7, what does "non-duplicative" mean in phrase > > "Implementations MUST NOT acknowledge records containing > > non-duplicative handshake messages..."? > > > > In Section 7.1, the 2nd bullet following para 1 reads: "When they > > receive a message or fragment which is out of order, either because it > > is not the next expected message or because it is not the next piece > > of the current message. Implementations MUST NOT send ACKs for > > handshake messages which they discard as > > out-of-order, because otherwise those messages will not be retransmitte= d." > > This is confusing as the difference between "out of order" messages > > that require an ACK and those that do not is not quite clear. Also the > > term "out of order" is written in two ways in this paragraph. > > > > In Figure 10, the edge going from SENDING to FINISHED has no label to > > differentiate with edge to WAITING. Should it read: "send last > > flight"? > > > > In Figure 13, why is there no NewConnectionID message in the exchanges > > since new CIDs are offered? Also, a short explanation of the CID > > negotiation and exchange could be helpful in the text. > > > > The state machine in Figure 10 is somewhat puzzling. How do we > > differentiate between "Receive ACK for last flight" and "Receive last > > flight"? According to Figure 7, for example, the last ACK is a flight > > itself. Also, with respect to the client, if sending last flight > > takes him to finished state, how will he then receive the ACK for his > > final flight? > > > > > > # Nits > > > > Section 3.1 Packet Loss. Figure 1 is a little confusing since it > > resembles Figure 5; as each has the server sending a > > HelloRetryRequest. Might illustrate the concept better to have the > > server send a ServerHello in Figure 1 rather than a HelloRetryRequest? > > > > Section 5.1. para 3 - Typo. "The DTLS 1.3 specification changes the > > way how cookies are exchanged compared to DTLS 1.2. DTLS 1.3 re-uses > > the HelloRetryRequest message". The "... the way how cookies..." > > either use "how" or "the way" but not both. > > > > Page 9 last para - Typo. s/assocatiation/association > > > > In section 3, bullet #3, the term "flight" is used without being > > defined; a reference to section 5.6 would be nice. > > > > MSL is used first in section 4.2.1 but only defined in section 5.7.1 > > > > In section 5.11 the notion of "CID concept" is mentioned. Might be > > nice to refer to section 9.1 where an example of the concept is > > presented. Also, section 9.1 never mentions "CID concept"; might be > > good to add the term to know that we are talking about the same > > thing. > > > > Figure 11 has no commentary describing the sequence. It would be helpfu= l, for > > example, to add details on why the two ACKs are sent. > > > > In Section 6.1, the phrase "...loss and re-order an identifier is neede= d to > > determine..." could use a comma after "re-order" and possibly replace > > "re-order" with "re-ordering". > > > > In Section 6.1, the phrase "In addition to the key derivation steps > > described in Section 7 of [TLS13] triggered by the states during the > > handshake a sender may want to rekey at any time during the lifetime > > of the connection and has to have a way to indicate that it is > > updating its sending cryptographic keys" is long and difficult to > > follow. It could be rephrased as "In addition to > > the key derivation steps described in Section 7 of [TLS13], a sender > > may want to rekey at any time during the lifetime of the connection. > > The epoch value provides a means to indicate that the sender is > > updating its sending cryptographic keys." > > > > In Section 6.1, replace "For example, client incorrectly uses..." with > > "For example, if a client incorrectly uses..." > > > > In Section 7, the term "current key" is used in the phrase > > "Implementations SHOULD simply use the current key." Would it be > > clearer to say that "Implementations SHOULD use the key material of > > the current epoch"? > > > > In Section 8, paragraph 3, what does a "canned ACK message" mean? > > > > Section 11, second para, s/Even with such a test, An/Even with such a t= est, an > > > > Section 11, third bullet: the statement "...DTLS 1.3 records > > irrespectively of the use of a CID" could be rephrased as "...DTLS 1.3 > > records irrespective of whether a CID is used or not." > > > > On Fri, Mar 20, 2020 at 10:18 AM Sean Turner wrote: > > > > > > This is the third working group last call for the "The Datagram Trans= port > > > Layer Security (DTLS) Protocol Version 1.3" draft available at > > > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/. Please > > > review the document and send your comments to the list by 2359 UTC on > > > 27 March 2019. > > > > > > This is a targeted one-week WGLC intended to focus on the changes fro= m -34, which was the subject of the second working group last call, and -37= . The diffs between -34 and -37 can be found at: > > > https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-tls-dtls13-34&url2=3Dd= raft-ietf-tls-dtls13-37 > > > As you will see in the diffs, the changes include 2119-language relat= ed changes in s5.1 and s7. These two changes were introduced in -35, which = was post in November. > > > > > > Note the the GH repo for this draft can be found at: > > > https://github.com/tlswg/dtls13-spec > > > > > > Thanks, > > > Chris, Joe, and Sean > > > _______________________________________________ > > > 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 co= nfidential and may also be privileged. If you are not the intended recipien= t, 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. > IMPORTANT NOTICE: The contents of this email and any attachments are conf= idential and may also be privileged. If you are not the intended recipient,= please notify the sender immediately and do not disclose the contents to a= ny other person, use it for any purpose, or store or copy the information i= n any medium. Thank you. From nobody Thu Apr 2 18:30:47 2020 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 BF2DD3A0B30 for ; Thu, 2 Apr 2020 18:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 KH6ijVNhr3mZ for ; Thu, 2 Apr 2020 18:30:43 -0700 (PDT) Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540C33A0B36 for ; Thu, 2 Apr 2020 18:30:43 -0700 (PDT) Received: by mail-yb1-xb34.google.com with SMTP id e17so3325644ybq.0 for ; Thu, 02 Apr 2020 18:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=uGuzkqm7MTYQ2Ez0rnIyOu5aZ6n76MN7BSSCPUzCq9I=; b=eD8tYLQOuk+yDs/WBCxKfAjLS9IjHYHi1KQE4ofblzByirdjDFNukOzFGSHRuTYYLs rWDuTGmbNeNcAuuSz9rgf3OTrXA2PDYdwhbEdRxEsy4sy87PniokiGJt8eruvVXU7S7+ kpDHyf8cXDOAFdGxhaXkyPSWat2Uk4EoTCbjpgb2uOwG/MKE+76pNOLdGt3xqG3uo39C bJyd4E90V38cvHwuIIJ2klG9XLBktZ0IwmsVS2l68coh7HKkEDfADyhnGfp2jhGxr39D +3nmsDMdcFuoedUPX7/Hko9AGn5ohQ5ujfZ1e/i/0ur9tdYyCUJsmaPwazhuPyKiXh8S YaBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=uGuzkqm7MTYQ2Ez0rnIyOu5aZ6n76MN7BSSCPUzCq9I=; b=MiqSxyzAK0kdEyBalJUyoqpUdfvD6Dj0daEaeMfE0a619xuhEPBaQiVvfKIeYP8IAm njKu7nYV8+B/g2rfYXVXKMPWE3LSSR0LcNSXXr70R8uDyO79krtN4/Z4oFJGuKnCglJW TfsCskrOZ5fzRjfWYgN45AysFb/CX1RSWiQg6y8hTg1xbnJZBv7M/i6EmKh6gA+T58tV KwChJELVBNRSav4P/QWJ4xmAZs/vSe/38yF5J62yxJobauC552G//wqtXmldI2jiIRDg RJu1R4e/LLlG+6VLqJkwADzcfv3rCpZm2UYqSEgrpn73ht5JSbl6ZD0ZfMKpK5Uve82R bYLA== X-Gm-Message-State: AGi0Pube9QoPhVZ7/EmWe/NFuH6tS1r8sUvMWxx2laZB2xN/ANQAAQG0 IQ8VZc0likiubhEyXwnhaCf+y+1zcmHROy2fyM/ZIqymP5E= X-Google-Smtp-Source: APiQypKICxstwLeKXpQ2BVH1JsCLqcp8x5qURM9e64YWWV/DEPydtn6YVYTqb4jAMLKAmbwIVjK2aEo2IXmAM1Xe130= X-Received: by 2002:a25:b89:: with SMTP id 131mr10607379ybl.113.1585877442140; Thu, 02 Apr 2020 18:30:42 -0700 (PDT) MIME-Version: 1.0 From: Jonathan Hammell Date: Thu, 2 Apr 2020 21:30:30 -0400 Message-ID: To: TLS List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] Review of draft-ietf-tls-subcerts-07 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 01:30:46 -0000 The draft looks good. I have a few minor nits and suggestions. Section 3, Fourth bullet: s/TLS hadshake/TLS handshake Section 3, Fourth bullet: To eliminate possible confusion, what is meant by "certificate=E2=80=99s working key" could be defined more precisel= y. Section 3.2, Last paragraph: s/Automated Certificate Managmeent Encvironment/Automated Certificate Management Environment Section 3.2, Last paragraph: "It is possible to address the short-lived certificate concerns above ..." seems to refer to text in the Introduction. It is a bit far for use of "above" rather than indicating the particular section. Even better would be to add some text regarding the concerns to Section 3 or 3.1. Section 4: The definition of "valid_time" could mention that the value must not exceed 7 days. Section 4: The phrase "Minimizing their semantics in this way is intended to mitigate the risk of cross protocol attacks involving delegated credentials." could be improved by adding at least one way that the minimized semantics mitigate such attacks. Section 6.1: The term "TLS private key" is used for the first time here. In the rest of the document we see the term "delegated private key"; are these the same? Section 6.1: The following phrase describes an important condition for using delegated credentials: "Thus, delegated credentials should not be used to send a delegation to an untrusted party, but is meant to be used between parties that have some trust relationship with each other." I think it is important enough to include a similar statement when describing the solution in Section 3. Section 6.4: s/cache the certificate chain an re-validate it/cache the certificate chain and re-validate it Best regards, Jonathan From nobody Fri Apr 3 00:02:56 2020 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 4194F3A1127; Fri, 3 Apr 2020 00:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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=ericsson.com 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 dThZXXfvT_yb; Fri, 3 Apr 2020 00:02:52 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40087.outbound.protection.outlook.com [40.107.4.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 02AE53A1126; Fri, 3 Apr 2020 00:02:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S9RqDSc/TsVC8nCSEODaJiUZZJvA63QKt6nTzayso4eytEKDhMLVdYNeTjpZiPu3fQHxU9K91OcQoyHT9U+b5qrSLiCZZaNSJGmX7cKnTsWdX+eWoH9+ofM9lB4OuTUaMIhFUGQzsOnf1SdepzuEOtREB9FxmSHnooOru0FTjmR6O6VqUFLugTTqDiV0xHDHwuTAb23/8T/wCzGACA0gxKihNCVP5OVn/sUpLyw44M8UYIGCxL1/wHk8TP+tndI/a9c/7H0mWYAPHhNJxXEW1p7PvZwTLx0EP7oWKWKqMnLtxvz0CO/QLd1SS719wXeaQyY2eZXL3L7+M0KAZjTc6g== 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=vcvZLhFuvJWcSV5TK3KUwTZFXl5Q55J9jhTdmrCdkNg=; b=VVoAkVk1hTWwW2fntzgyYrjpPSI7W1+c6lAlWL9Plz2gD0nWzejj/YtuJVWymqgPbJqKSdFvyFodZq720WxOiufXDOA3S7w3s2NSjgeZb8F4m1Yw/qfe5I8vLs41MBrerM3oPgeyAH1DQkYdbkFpNXQ5AVHIuiESnycOvqhNKtEjEqDWdsBijs/+6OVPJZgrXrQkm1rQUSxUos2JLW99xkSx2Q2IgEvu1DQHpO1qr7EVvm7yTQS1jS2r95EqTvRJvD/miY0POo8KlVI/7aK8rk5vr+LYZHwqa3cHRdiqAYnkxOfGtoD5kz4is4NyEw1Ld0wlSB2Lrrt1J7EoIri3Aw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vcvZLhFuvJWcSV5TK3KUwTZFXl5Q55J9jhTdmrCdkNg=; b=dtjQOJ3W9bxXfmh6HYivwKHf365VrIj7xeyOHSbY7xJFbOGZDHc7dZGjvBeBtSNuMYpl5MCAtVu4yx27TYMFlU7DqAdeZzTr/Ft3S//pbv/35Iu8YhNQ+bSV5r1h/5B/jzdyZ1fUIeytN0ea7VvR8equtn7RgQNxE9s+HrGHD2E= Received: from AM6PR07MB4584.eurprd07.prod.outlook.com (20.177.37.216) by AM6PR07MB6005.eurprd07.prod.outlook.com (20.178.86.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.12; Fri, 3 Apr 2020 07:02:47 +0000 Received: from AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::928:dc19:896b:4b91]) by AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::928:dc19:896b:4b91%6]) with mapi id 15.20.2878.014; Fri, 3 Apr 2020 07:02:47 +0000 From: John Mattsson To: "TLS@ietf.org" , "uta@ietf.org" Thread-Topic: CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS Thread-Index: AQHWCYXhsfDqn9t6CkOccV3/F4Ml8w== Date: Fri, 3 Apr 2020 07:02:47 +0000 Message-ID: <4F3108DB-4D44-481C-807D-D2870ED719DA@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 89637e6a-5419-4118-5877-08d7d79d0426 x-ms-traffictypediagnostic: AM6PR07MB6005: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0362BF9FDB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB4584.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(346002)(39860400002)(396003)(136003)(376002)(81156014)(8936002)(316002)(33656002)(2906002)(478600001)(81166006)(966005)(44832011)(5660300002)(8676002)(110136005)(2616005)(66556008)(86362001)(66476007)(64756008)(66574012)(71200400001)(26005)(91956017)(66946007)(6486002)(450100002)(53546011)(36756003)(186003)(76116006)(6506007)(6512007)(66446008); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5Rj/fq6qtQIwmveKVWBMHcje670ZriRzlah+yiq0y4CgmCs7jFbQe+ARII9V0VVtCzjHzwb19fsVSsZbFDP0woCYZkbHxoiec4ko5TuLW4e2FkME8d4e1/9EpiQ/f5VpJ2W3xOznYq/nytLDTvB0WwdJMYPw+b47T6P/nrHpceVuFdxG12g2HJ+V2VY3Jfvg5hGG4S5MJEOzJg/jk3/4YG30pE3fo1kDqsZOBwLLwOW4w+tMdOo2cotqkAotCpJPligv+XeASvRnAsmeAz46aw5TGszL9agOeldnOEcHStkiFyj9a/mk2fULDrzW+WP95Kh4Ye2QQ0tFRRoC6KZTDQ52Lu+woWUSqv2dA7ytTadeg/DOTDRCeAvEVHeu15brH+yBp8+vJ4swRfRf+NEPxroHzOzUHIXWurRKEYTx+pOD0+rfNH2dKrXFeN+R0n4hLjmpm6UfPUgSqtb3v5GHUd0XwY2UVyfMxZFPYMm7e/v+13IiESiicfZuhYZ2z7MR2vvHQ9lWYgsjCumQ7igA5Q== x-ms-exchange-antispam-messagedata: OaY/rbZ9MmjkpKAA5IN7uNDUnF2RbPQjm/JOZrudSLhX6mv9EeoxvfnlV48VwRAQ14qKKCCL0g78izAFpoZA1VQdGL5fRXg0n2Ajp2Px7t9UQWycwj9rpkeYBAmvWGJX8PoOlUQMZxCTPnJstob02A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <821680FF20F7EC4C956E32E796F7E1DE@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89637e6a-5419-4118-5877-08d7d79d0426 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Apr 2020 07:02:47.4504 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3bVUGab+9FXXEuQz11dE9fjFdNr/hzkZdqIphpOMxx1C/P4T0kPRT4VXS6aQU2WlZ+WmzpssmCyBgeTzdVJu0qgVr0FiyTJWXGLnKHhJiHw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB6005 Archived-At: Subject: [TLS] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS 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 07:02:54 -0000 SGksDQoNCkR1cmluZyB0aGUgQ09TRSB2aXJ0dWFsIGludGVyaW0gbWVldGluZyB5ZXN0ZXJkYXks IHRoZXJlIHdhcyBhZ3JlZW1lbnQgdGhhdCB0aGUgQ09TRSB3b3JraW5nIGdyb3VwIHNob3VsZCB3 b3JrIG9uIENCT1IgY29tcHJlc3Npb24gb2YgUkZDIDc5MjUgcHJvZmlsZWQgWC41MDkgY2VydGlm aWNhdGVzLiBUaGUgd29yayB3aWxsIGJlIGJhc2VkIG9uIGRyYWZ0LXJhemEtYWNlLWNib3ItY2Vy dGlmaWNhdGVzIGFuZCBkcmFmdC1tYXR0c3Nvbi1jb3NlLWNib3ItY2VydC1jb21wcmVzcyBhbmQg dGhlIHR3byBkcmFmdHMgd2lsbCBiZSBtZXJnZWQuIERvaW5nIHRoaXMgd29yayBpbiBhIHNlY3Vy aXR5IGdyb3VwIGZvY3VzZWQgb24gQ0JPUiBtYWtlcyBhIGxvdCBvZiBzZW5zZS4NCg0KaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hdHRzc29uLWNvc2UtY2Jvci1jZXJ0LWNvbXBy ZXNzLTAwDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmF6YS1hY2UtY2Jvci1j ZXJ0aWZpY2F0ZXMtMDQNCg0KVGhlIENPU0UgZHJhZnQgY2hhcnRlciBoYXMgYWxyZWFkeSBiZWVu IHVwZGF0ZWQgdG8gcmVmbGVjdCB0aGlzLg0KIA0KaHR0cHM6Ly9naXRodWIuY29tL2Nvc2Utd2cv Q2hhcnRlci9ibG9iL21hc3Rlci9DaGFydGVyLm1kDQoNCkFzIHRoZSBhbGdvcml0aG0gaXMgZm9j dXNlZCBvbiBjb21wcmVzc2luZyBSRkMgNzkyNSBwcm9maWxlZCBjZXJ0aWZpY2F0ZXMsIEl0IHNl ZW1zIGxpa2UgYSB2ZXJ5IGdvb2QgbWF0Y2ggZm9yIGNUTFMuIFRvIGtlZXAgdGhlIG51bWJlciBv ZiBpbnRlcm5ldC1kcmFmdHMgZG93biwgSSBwbGFuIHRvIGFsc28gaW5jbHVkZSB0aGUgVExTIElB TkEgcmVnaXN0cmF0aW9ucyBpbiB0aGUgbWVyZ2VkIGRyYWZ0IHN1Ym1pdHRlZCB0byB0aGUgQ09T RSBXRyBhbmQgbGV0IGRyYWZ0LW1hdHRzc29uLXRscy1jYm9yLWNlcnQtY29tcHJlc3MtMDAgZXhw aXJlLg0KDQpBbnkgY29tbWVudHMgZnJvbSB0aGUgVExTIFdHIGFyZSB2ZXJ5IHdlbGNvbWUsIGJ1 dCBvdGhlcndpc2UgdGhlc2UgaXMgbm90IHNvIG11Y2ggdG8gZGlzY3VzcywgdGhpcyBpcyBqdXN0 IGFub3RoZXIgY2VydGlmaWNhdGUgY29tcHJlc3Npb24gYWxnb3JpdGhtLiBBbnkgVExTIHJlbGF0 ZWQgZGlzY3Vzc2lvbnMgd291bGQgbGlrZWx5IGJlIHJlZ2FyZGluZyB0aGUgY2VydGlmaWNhdGUg cHJvZmlsZSBpbiBSRkMgNzkyNSBhbmQgaWYgYW55IGNsYXJpZmljYXRpb25zIG9yIHVwZGF0ZXMg YXJlIG5lZWRlZC4gVGhpcyBpcyBsaWtlbHkgYmVzdCBkaXNjdXNzZWQgaW4gVVRBIHdoaWNoIG1h eSB0YWtlIHVwIHdvcmsgb24gYSBUTFMvRFRMUyAxLjMgdXBkYXRlIG9mIFJGQyA3OTI1Lg0KDQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdHNjaG9mZW5pZy11dGEtdGxzMTMtcHJv ZmlsZS0wMQ0KDQpDaGVlcnMsDQpKb2huDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4NCkRhdGU6 IFRodXJzZGF5LCAxMiBNYXJjaCAyMDIwIGF0IDA4OjU4DQpUbzogIlRMU0BpZXRmLm9yZyIgPFRM U0BpZXRmLm9yZz4NCkNjOiAidXRhQGlldGYub3JnIiA8dXRhQGlldGYub3JnPg0KU3ViamVjdDog Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWF0dHNzb24tdGxzLWNib3It Y2VydC1jb21wcmVzcy0wMC50eHQNCg0KICAgIEhpLA0KICAgIA0KICAgIFdlIGhhdmUgc3VibWl0 dGVkIGEgbmV3IGRyYWZ0IHRvIFRMUyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bWF0dHNzb24tdGxzLWNib3ItY2VydC1jb21wcmVzcy0wMCBUaGUgZHJhZnQgcmVnaXN0ZXIgYSBu ZXcgY29tcHJlc3Npb24gYWxnb3JpdGhtcyBmb3IgdXNlIHdpdGggVExTIENlcnRpZmljYXRlIENv bXByZXNzaW9uIGluIFRMUyAxLjMgYW5kIERUTFMgMS4zIChkcmFmdC1pZXRmLXRscy1jZXJ0aWZp Y2F0ZS1jb21wcmVzc2lvbikuDQogICAgDQogICAgVGhlIGRyYWZ0IHVzZXMgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJhemEtYWNlLWNib3ItY2VydGlmaWNhdGVzLTA0IHRvIGNv bXByZXNzIFJGQyA3OTI1IHByb2ZpbGVzIGNlcnRpZmljYXRlcyBieSBlbmNvZGluZyB0aGVtIGZy b20gREVSIHRvIENCT1IuIFRoZSBhaW0gaXMgdG8gYmUgY29tcGF0aWJsZSB3aXRoIGFsbCBSRkMg NzkyNSBwcm9maWxlZCBjZXJ0aWZpY2F0ZXMuIFdpdGggdGhlIGluY2x1ZGVkIGV4YW1wbGUgREVS IGVuY29kZWQgUkZDIDc5MjUgY2VydGlmaWNhdGUgdG8gY2VydGlmaWNhdGUgaXMgY29tcHJlc3Nl ZCBmcm9tIDMxNCB0byAxMzYgYnl0ZXMsIGEgY29tcHJlc3Npb24gcmF0ZSBvZiA1NyUuDQogICAg DQogICAgVGhlIGdlbmVyYWwgcHVycG9zZSBjb21wcmVzc2lvbiBhbGdvcml0aG1zIGRlZmluZWQg aW4gZHJhZnQtaWV0Zi10bHMtY2VydGlmaWNhdGUtY29tcHJlc3Npb24gZG8gbm90IHNlZW0gYWJs ZSB0byBjb21wcmVzcyBwcm9maWxlZCBSRkMgNzkyNSBYLjUwOSBjZXJ0aWZpY2F0ZXMgbXVjaCBh dCBhbGwuIHpsaWIgY29tcHJlc3NlZCB0aGUgZXhhbXBsZSBjZXJ0IDklLCBidXQgZm9yIG90aGVy IGNlcnRpZmljYXRlcyB3ZSB0ZXN0ZWQsIHpsaWIgZGlkIGluIG1hbnkgY2FzZXMgbm90IHByb3Zp ZGUgYW55IGNvbXByZXNzaW9uIGF0IGFsbC4NCiAgICANCiAgICBXZSBoYXZlIHN1Ym1pdHRlZCBh IHNpbWlsYXIgZHJhZnQgdG8gdGhlIENPU0UgV0cgcmVnaXN0ZXJpbmcgYSBuZXcgYWxnb3JpdGht cyBmb3IgdGhlIFRMUyAxLjMgY2VydGlmaWNhdGUgY29tcHJlc3Npb24gZXh0ZW5zaW9uLg0KICAg IA0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0c3Nvbi10bHMtY2Jv ci1jZXJ0LWNvbXByZXNzLTAwDQogICAgDQogICAgQ2hlZXJzLA0KICAgIEpvaG4NCiAgICANCiAg ICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206ICJpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmciIDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQogICAgRGF0ZTogTW9uZGF5LCA5 IE1hcmNoIDIwMjAgYXQgMjE6MTkNCiAgICBUbzogSm9obiBNYXR0c3NvbiA8am9obi5tYXR0c3Nv bkBlcmljc3Nvbi5jb20+LCBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNv bT4sIEpvZWwgSMO2Z2x1bmQgPGpvZWwuaG9nbHVuZEByaS5zZT4sIEpvZWwgSG9nbHVuZCA8am9l bC5ob2dsdW5kQHJpLnNlPiwgR8O2cmFuIFNlbGFuZGVyIDxnb3Jhbi5zZWxhbmRlckBlcmljc3Nv bi5jb20+LCBNYXJ0aW4gRnVydWhlZCA8bWFydGluLmZ1cnVoZWRAbmV4dXNncm91cC5jb20+LCBH w7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNvbT4sIFNoYWhpZCBSYXph IDxzaGFoaWQucmF6YUByaS5zZT4NCiAgICBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LW1hdHRzc29uLXRscy1jYm9yLWNlcnQtY29tcHJlc3MtMDAudHh0DQogICAg DQogICAgICAgIA0KICAgICAgICBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbWF0dHNzb24t dGxzLWNib3ItY2VydC1jb21wcmVzcy0wMC50eHQNCiAgICAgICAgaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBKb2huIFByZXVzcyBNYXR0c3NvbiBhbmQgcG9zdGVkIHRvIHRoZQ0K ICAgICAgICBJRVRGIHJlcG9zaXRvcnkuDQogICAgICAgIA0KICAgICAgICBOYW1lOgkJZHJhZnQt bWF0dHNzb24tdGxzLWNib3ItY2VydC1jb21wcmVzcw0KICAgICAgICBSZXZpc2lvbjoJMDANCiAg ICAgICAgVGl0bGU6CQlDQk9SIENlcnRpZmljYXRlIEFsZ29yaXRobSBmb3IgVExTIENlcnRpZmlj YXRlIENvbXByZXNzaW9uDQogICAgICAgIERvY3VtZW50IGRhdGU6CTIwMjAtMDMtMDkNCiAgICAg ICAgR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCiAgICAgICAgUGFnZXM6CQk2DQogICAg ICAgIFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtbWF0dHNzb24tdGxzLWNib3ItY2VydC1jb21wcmVzcy0wMC50eHQNCiAgICAgICAgU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1hdHRz c29uLXRscy1jYm9yLWNlcnQtY29tcHJlc3MvDQogICAgICAgIEh0bWxpemVkOiAgICAgICBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWF0dHNzb24tdGxzLWNib3ItY2VydC1jb21w cmVzcy0wMA0KICAgICAgICBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1tYXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNvbXByZXNzDQogICAg ICAgIA0KICAgICAgICANCiAgICAgICAgQWJzdHJhY3Q6DQogICAgICAgICAgIENlcnRpZmljYXRl IGNoYWlucyBvZnRlbiB0YWtlIHVwIHRoZSBtYWpvcml0eSBvZiB0aGUgYnl0ZXMNCiAgICAgICAg ICAgdHJhbnNtaXR0ZWQgaW4gVExTIGhhbmRzaGFrZXMuICBMYXJnZSBoYW5kc2hha2VzIGNhbiBj YXVzZSBwcm9ibGVtcywNCiAgICAgICAgICAgcGFydGljdWxhcmx5IGluIGNvbnN0cmFpbmVkIElv VCBlbnZpcm9ubWVudHMuICBSRkMgNzkyNSBkZWZpbmVzIGEgVExTDQogICAgICAgICAgIGNlcnRp ZmljYXRlIHByb2ZpbGUgZm9yIGNvbnN0cmFpbmVkIElvVC4gIEdlbmVyYWwgcHVycG9zZSBjb21w cmVzc2lvbg0KICAgICAgICAgICBhbGdvcml0aG1zIGNhbiBpbiBtYW55IGNhc2VzIG5vdCBjb21w cmVzcyBSRkMgNzkyNSBwcm9maWxlZA0KICAgICAgICAgICBjZXJ0aWZpY2F0ZXMgYXQgYWxsLiAg QnkgdXNpbmcgdGhlIGZhY3QgdGhhdCB0aGUgY2VydGlmaWNhdGVzIGFyZQ0KICAgICAgICAgICBw cm9maWxlZCwgdGhlIENCT1IgY2VydGlmaWNhdGUgY29tcHJlc3Npb24gYWxnb3JpdGhtcyBjYW4g aW4gbWFueQ0KICAgICAgICAgICBjYXNlcyBjb21wcmVzcyBSRkMgNzkyNSBwcm9maWxlZCBjZXJ0 aWZpY2F0ZXMgd2l0aCBvdmVyIDUwJS4gVGhpcw0KICAgICAgICAgICBkb2N1bWVudCBzcGVjaWZp ZXMgdGhlIENCT1IgY2VydGlmaWNhdGUgY29tcHJlc3Npb24gYWxnb3JpdGhtIGZvciB1c2UNCiAg ICAgICAgICAgd2l0aCBUTFMgQ2VydGlmaWNhdGUgQ29tcHJlc3Npb24gaW4gVExTIDEuMyBhbmQg RFRMUyAxLjMuDQogICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQog ICAgICAgIA0KICAgICAgICANCiAgICAgICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgICAgICB1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KICAgICAgICANCiAgICAgICAgVGhlIElFVEYgU2VjcmV0YXJpYXQNCiAgICAg ICAgDQogICAgICAgIA0KICAgICAgICANCiAgICANCiAgICANCg0K From nobody Fri Apr 3 05:09:06 2020 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_-- From nobody Fri Apr 3 05:19:45 2020 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 CE5553A18DA; Fri, 3 Apr 2020 05:19:43 -0700 (PDT) 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, 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=u35qFZSv; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=u35qFZSv 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 8R3hXxm9uuZM; Fri, 3 Apr 2020 05:19:39 -0700 (PDT) Received: from FRA01-PR2-obe.outbound.protection.outlook.com (mail-eopbgr120059.outbound.protection.outlook.com [40.107.12.59]) (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 389AD3A18DD; Fri, 3 Apr 2020 05:19:37 -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=16/Cje2iiAK95Tt3hj0SNP0uGvtyfcy8h+1RDjMTwwM=; b=u35qFZSvyXa+8uDdCMLnhmBIrqgH9z/V0RrqAlkQ4kAX7nXq6ohfd7SGw1Oybr4traVRki7SpbS0Au49HV/qLU3RrPG6r7cPXJe3rKBMAdm5XTEYoMwGmAQzE2kJsRAJdwbO25u5/GYiLOio/EfYQf0Eh/8k9l1OGRdP4ZFzjqM= Received: from AM6P191CA0027.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:8b::40) by PR2PR08MB4700.eurprd08.prod.outlook.com (2603:10a6:101:1b::10) 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:19:33 +0000 Received: from AM5EUR03FT044.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8b:cafe::28) by AM6P191CA0027.outlook.office365.com (2603:10a6:209:8b::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16 via Frontend Transport; Fri, 3 Apr 2020 12:19:33 +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 AM5EUR03FT044.mail.protection.outlook.com (10.152.17.56) 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:19:33 +0000 Received: ("Tessian outbound af37c2b81632:v50"); Fri, 03 Apr 2020 12:19:33 +0000 X-CR-MTA-TID: 64aa7808 Received: from 2202c02c40ec.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 17786EDC-F065-4318-B203-9633D4847A52.1; Fri, 03 Apr 2020 12:19:28 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 2202c02c40ec.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 03 Apr 2020 12:19:28 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TUqeZdeFht5f9HU30MLX9WYYhpXV4u09NA0lLwTrqxtHitYs44hrt+1/e7LP+3xOG6F5rH+UJAUsBf23JUwue2LKjOyXZzwaKDfsJaYwHUrw7kAtqp6nA50heORPSpMQviLQ3g1XpuF2KQYka0dEXKSnLWj59OOWfaPLIfCfe7adLgVe7BU9qKPplCyK+aWhFQNhsmNoSaSBk2rFVpapRFV86EoxbuBF3dklthwDbSvpl/0BxlbPBW92WtwJsMQi3FOGqCtWSpCe+1kZGxMAt7yqkMUum9lnSNK3BSWEYBvM/2+7eroNdC4f4FB1CafbX2dOWSwGQSCW+cTmJ2WeBA== 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=16/Cje2iiAK95Tt3hj0SNP0uGvtyfcy8h+1RDjMTwwM=; b=UX2Pb8kuTo/vf/4kommwS/y2RN5B7+AOSuGzVC1iIOzrxfUQbRM1wcXUw26Lr1uBaWRh/r/4kj5BiIwby99cIhs6gIaD5UY2qYr1Q+jxxxcl3HvjcxxbBvG+hmekUBN4GSOeiUB2tAJx1DWYCKx/DSSebgzpPGcGqpmUoYeWv9CW5aw+O8Houm3PUAFVQAQ6+XKOlUtlGarbtlfHv1+icWiX+OIXz1Q/44Vuv5iGpau10AUvP0nE1QLj2uRHIsO20LY2yphvczJ7pwkA2xUVkzz8HinVo43mDsRmkSD8NDE3kNtiLlc8GhmMbAaeS57gAsXExKx2ujyeGvjBA+Ef4A== 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=16/Cje2iiAK95Tt3hj0SNP0uGvtyfcy8h+1RDjMTwwM=; b=u35qFZSvyXa+8uDdCMLnhmBIrqgH9z/V0RrqAlkQ4kAX7nXq6ohfd7SGw1Oybr4traVRki7SpbS0Au49HV/qLU3RrPG6r7cPXJe3rKBMAdm5XTEYoMwGmAQzE2kJsRAJdwbO25u5/GYiLOio/EfYQf0Eh/8k9l1OGRdP4ZFzjqM= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (20.178.23.205) by AM0PR08MB3396.eurprd08.prod.outlook.com (20.177.109.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.19; Fri, 3 Apr 2020 12:18:12 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2878.018; Fri, 3 Apr 2020 12:18:09 +0000 From: Hannes Tschofenig To: John Mattsson , "TLS@ietf.org" , "uta@ietf.org" Thread-Topic: CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS Thread-Index: AQHWCYXhsfDqn9t6CkOccV3/F4Ml86hnSa2g Date: Fri, 3 Apr 2020 12:18:09 +0000 Message-ID: References: <4F3108DB-4D44-481C-807D-D2870ED719DA@ericsson.com> In-Reply-To: <4F3108DB-4D44-481C-807D-D2870ED719DA@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 0cfb56a3-d870-4479-86bd-7d29d817b6a4.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.214] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 26f899d4-2381-4b44-79bd-08d7d7c944c4 x-ms-traffictypediagnostic: AM0PR08MB3396:|PR2PR08MB4700: 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:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(186003)(81156014)(55016002)(81166006)(86362001)(7696005)(66574012)(9686003)(33656002)(8936002)(71200400001)(76116006)(66946007)(64756008)(8676002)(53546011)(52536014)(2906002)(66446008)(966005)(66556008)(26005)(66476007)(498600001)(5660300002)(6506007)(110136005); 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: ZzahnF/wop2LeLpfHZn3Inq3M9f0/VILW+4aipTA7m+NtMYJ4YWajNll91ncHaWgNCbMMldSclvTxkpaS28cumCtO0ep0Ydqbal+TgOVjq4Vy+Fgg+SUPP0IRToRzlk6htdc4UsSiczDB5i7gGvWj/FMLRaXI5tJJuwXUj26O6T6Xy9F4r+oVYjPRVYAxX4P4QoNX5mk9O9eQudI8Etn2XhHZcmm26/UwxHxxaac9otMrkDUd3p0bCznSS4l1P83kA2YKYGjSbnGExS5VN9XTh0K44z7z3HraPd5j0MockVP6IdT5CBgByuuN7zkRVVfFn4iEPF9i2qHZ8wBpD4b5ACz0bppBqLSvRZ+sZgQPySdWzGXX0JedhceUrEc6I2ERRu2GHpRa60X9//NrMAtkeI6xZ1/JdHkd790FNSzxyKR9/UqF37pOsBEGeOE3YEsvCpNJfbw58A4UgJVxvB0nHw+VATds57YwPuxVXjBhgZWjaKCNUtWNDAqG/4kkKJHOV9AjQx7f3UlxyFuzA6Vhg== x-ms-exchange-antispam-messagedata: wxhe8IVFKFc2gYCpnLhRXn4dVNkenXcqp4USfCw1ugVD8O0PUUoCGRrLAz7WPtZhFfJcyoEifZ9obF0WIpid4Kj5BpKYpf9QhSuvx+utHXtefE+pXbt/mtmkP82s+EYFmPgXD+9EqJNVath9sOdXxw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3396 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT044.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)(136003)(376002)(346002)(39860400002)(396003)(46966005)(81166006)(86362001)(52536014)(81156014)(70586007)(70206006)(316002)(8936002)(356004)(2906002)(966005)(478600001)(9686003)(82740400003)(36906005)(6506007)(66574012)(33656002)(8676002)(55016002)(186003)(47076004)(336012)(450100002)(110136005)(53546011)(26826003)(7696005)(26005)(5660300002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: c18fc632-41b4-48c5-489e-08d7d7c9128a X-Forefront-PRVS: 0362BF9FDB X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: VjlVxODHLIQb6fzNe9ablZzn/0CMkfulg5Z8Fj7Q3RgnCy/L/75ATPvvnFFlJFwH22byT6eaCx57Y2tol8bB0jbhQEyaP95SsY/UqKczLlERbj+ReSAi/Mw8OwGLEqcKLEmxOb4TlTR5td6jjBL/JMZZrecFL4Pn9ugoojhihOMCLdFEODosvjnzBwbdXJjjvi0m2A+HYweZTGQ+fOut2b2qXFu93o9blImjRY+eI2WO/4DPdzr62SOr+W26x1NTaB1ab07l6udL0mukqLtFiUuAQXYC8dUkQy6ZTp4hdFho7PqFk+nZv9j+E52slja+Q5XcEko3WayTAYTglX8yvKJVowMFb4zJmiTGoWJlIqjhm1jzsUF990DPbXd+Kx7++4AiMntKXbdJ+SM03coKKZfgRF7D3yPJtLLANZmcf9WtvjCsFr1vh9ewGRRcJDkwqlMwROW3mkE6ql5GOe+n8P6Hq41GwRYlJoXRQn4oDDDZWqf1gZ+wpqZxxGkCkR/UqCWKIa5BqAzDhFTddh80V9jNrmzlm3gfg69R2A4JwmvIuEarvIbiqC4YTI/F20+Ec/u0q/fISz/pGiBL4Fs7Rw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2020 12:19:33.7579 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 26f899d4-2381-4b44-79bd-08d7d7c944c4 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: PR2PR08MB4700 Archived-At: Subject: Re: [TLS] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS 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:19:44 -0000 SGkgSm9obiwNCg0KVGhhbmtzIGZvciB0aGUgaGVhZHMtdXAuDQoNCkRpc2N1c3NpbmcgdGhpcyBh c3BlY3QgaW4gZHJhZnQtdHNjaG9mZW5pZy11dGEtdGxzMTMtcHJvZmlsZS0wMSBtYWtlcyBzZW5z ZS4NCg0KSSB3YXMgd29uZGVyaW5nIHdoZXRoZXIgeW91IGhhdmUgYmVlbiB3b3JraW5nIG9uIGFu IGltcGxlbWVudGF0aW9uIG9mIGRyYWZ0LW1hdHRzc29uLWNvc2UtY2Jvci1jZXJ0LWNvbXByZXNz LTAwIC8gZHJhZnQtcmF6YS1hY2UtY2Jvci1jZXJ0aWZpY2F0ZXMtMDQuDQoNCkNpYW8NCkhhbm5l cw0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVExTIDx0bHMtYm91bmNlc0Bp ZXRmLm9yZz4gT24gQmVoYWxmIE9mIEpvaG4gTWF0dHNzb24NClNlbnQ6IEZyaWRheSwgQXByaWwg MywgMjAyMCA5OjAzIEFNDQpUbzogVExTQGlldGYub3JnOyB1dGFAaWV0Zi5vcmcNClN1YmplY3Q6 IFtUTFNdIENCT1IgQ2VydGlmaWNhdGUgQ29tcHJlc3Npb24gb2YgUkZDIDc5MjUgY2VydGlmaWNh dGVzIHN1aXRhYmxlIGZvciBjVExTDQoNCkhpLA0KDQpEdXJpbmcgdGhlIENPU0UgdmlydHVhbCBp bnRlcmltIG1lZXRpbmcgeWVzdGVyZGF5LCB0aGVyZSB3YXMgYWdyZWVtZW50IHRoYXQgdGhlIENP U0Ugd29ya2luZyBncm91cCBzaG91bGQgd29yayBvbiBDQk9SIGNvbXByZXNzaW9uIG9mIFJGQyA3 OTI1IHByb2ZpbGVkIFguNTA5IGNlcnRpZmljYXRlcy4gVGhlIHdvcmsgd2lsbCBiZSBiYXNlZCBv biBkcmFmdC1yYXphLWFjZS1jYm9yLWNlcnRpZmljYXRlcyBhbmQgZHJhZnQtbWF0dHNzb24tY29z ZS1jYm9yLWNlcnQtY29tcHJlc3MgYW5kIHRoZSB0d28gZHJhZnRzIHdpbGwgYmUgbWVyZ2VkLiBE b2luZyB0aGlzIHdvcmsgaW4gYSBzZWN1cml0eSBncm91cCBmb2N1c2VkIG9uIENCT1IgbWFrZXMg YSBsb3Qgb2Ygc2Vuc2UuDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0 c3Nvbi1jb3NlLWNib3ItY2VydC1jb21wcmVzcy0wMA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXJhemEtYWNlLWNib3ItY2VydGlmaWNhdGVzLTA0DQoNClRoZSBDT1NFIGRyYWZ0 IGNoYXJ0ZXIgaGFzIGFscmVhZHkgYmVlbiB1cGRhdGVkIHRvIHJlZmxlY3QgdGhpcy4NCg0KaHR0 cHM6Ly9naXRodWIuY29tL2Nvc2Utd2cvQ2hhcnRlci9ibG9iL21hc3Rlci9DaGFydGVyLm1kDQoN CkFzIHRoZSBhbGdvcml0aG0gaXMgZm9jdXNlZCBvbiBjb21wcmVzc2luZyBSRkMgNzkyNSBwcm9m aWxlZCBjZXJ0aWZpY2F0ZXMsIEl0IHNlZW1zIGxpa2UgYSB2ZXJ5IGdvb2QgbWF0Y2ggZm9yIGNU TFMuIFRvIGtlZXAgdGhlIG51bWJlciBvZiBpbnRlcm5ldC1kcmFmdHMgZG93biwgSSBwbGFuIHRv IGFsc28gaW5jbHVkZSB0aGUgVExTIElBTkEgcmVnaXN0cmF0aW9ucyBpbiB0aGUgbWVyZ2VkIGRy YWZ0IHN1Ym1pdHRlZCB0byB0aGUgQ09TRSBXRyBhbmQgbGV0IGRyYWZ0LW1hdHRzc29uLXRscy1j Ym9yLWNlcnQtY29tcHJlc3MtMDAgZXhwaXJlLg0KDQpBbnkgY29tbWVudHMgZnJvbSB0aGUgVExT IFdHIGFyZSB2ZXJ5IHdlbGNvbWUsIGJ1dCBvdGhlcndpc2UgdGhlc2UgaXMgbm90IHNvIG11Y2gg dG8gZGlzY3VzcywgdGhpcyBpcyBqdXN0IGFub3RoZXIgY2VydGlmaWNhdGUgY29tcHJlc3Npb24g YWxnb3JpdGhtLiBBbnkgVExTIHJlbGF0ZWQgZGlzY3Vzc2lvbnMgd291bGQgbGlrZWx5IGJlIHJl Z2FyZGluZyB0aGUgY2VydGlmaWNhdGUgcHJvZmlsZSBpbiBSRkMgNzkyNSBhbmQgaWYgYW55IGNs YXJpZmljYXRpb25zIG9yIHVwZGF0ZXMgYXJlIG5lZWRlZC4gVGhpcyBpcyBsaWtlbHkgYmVzdCBk aXNjdXNzZWQgaW4gVVRBIHdoaWNoIG1heSB0YWtlIHVwIHdvcmsgb24gYSBUTFMvRFRMUyAxLjMg dXBkYXRlIG9mIFJGQyA3OTI1Lg0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt dHNjaG9mZW5pZy11dGEtdGxzMTMtcHJvZmlsZS0wMQ0KDQpDaGVlcnMsDQpKb2huDQoNCu+7vy0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRz c29uQGVyaWNzc29uLmNvbT4NCkRhdGU6IFRodXJzZGF5LCAxMiBNYXJjaCAyMDIwIGF0IDA4OjU4 DQpUbzogIlRMU0BpZXRmLm9yZyIgPFRMU0BpZXRmLm9yZz4NCkNjOiAidXRhQGlldGYub3JnIiA8 dXRhQGlldGYub3JnPg0KU3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtbWF0dHNzb24tdGxzLWNib3ItY2VydC1jb21wcmVzcy0wMC50eHQNCg0KICAgIEhpLA0K DQogICAgV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgdG8gVExTIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNvbXByZXNzLTAwIFRo ZSBkcmFmdCByZWdpc3RlciBhIG5ldyBjb21wcmVzc2lvbiBhbGdvcml0aG1zIGZvciB1c2Ugd2l0 aCBUTFMgQ2VydGlmaWNhdGUgQ29tcHJlc3Npb24gaW4gVExTIDEuMyBhbmQgRFRMUyAxLjMgKGRy YWZ0LWlldGYtdGxzLWNlcnRpZmljYXRlLWNvbXByZXNzaW9uKS4NCg0KICAgIFRoZSBkcmFmdCB1 c2VzIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yYXphLWFjZS1jYm9yLWNlcnRp ZmljYXRlcy0wNCB0byBjb21wcmVzcyBSRkMgNzkyNSBwcm9maWxlcyBjZXJ0aWZpY2F0ZXMgYnkg ZW5jb2RpbmcgdGhlbSBmcm9tIERFUiB0byBDQk9SLiBUaGUgYWltIGlzIHRvIGJlIGNvbXBhdGli bGUgd2l0aCBhbGwgUkZDIDc5MjUgcHJvZmlsZWQgY2VydGlmaWNhdGVzLiBXaXRoIHRoZSBpbmNs dWRlZCBleGFtcGxlIERFUiBlbmNvZGVkIFJGQyA3OTI1IGNlcnRpZmljYXRlIHRvIGNlcnRpZmlj YXRlIGlzIGNvbXByZXNzZWQgZnJvbSAzMTQgdG8gMTM2IGJ5dGVzLCBhIGNvbXByZXNzaW9uIHJh dGUgb2YgNTclLg0KDQogICAgVGhlIGdlbmVyYWwgcHVycG9zZSBjb21wcmVzc2lvbiBhbGdvcml0 aG1zIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi10bHMtY2VydGlmaWNhdGUtY29tcHJlc3Npb24gZG8g bm90IHNlZW0gYWJsZSB0byBjb21wcmVzcyBwcm9maWxlZCBSRkMgNzkyNSBYLjUwOSBjZXJ0aWZp Y2F0ZXMgbXVjaCBhdCBhbGwuIHpsaWIgY29tcHJlc3NlZCB0aGUgZXhhbXBsZSBjZXJ0IDklLCBi dXQgZm9yIG90aGVyIGNlcnRpZmljYXRlcyB3ZSB0ZXN0ZWQsIHpsaWIgZGlkIGluIG1hbnkgY2Fz ZXMgbm90IHByb3ZpZGUgYW55IGNvbXByZXNzaW9uIGF0IGFsbC4NCg0KICAgIFdlIGhhdmUgc3Vi bWl0dGVkIGEgc2ltaWxhciBkcmFmdCB0byB0aGUgQ09TRSBXRyByZWdpc3RlcmluZyBhIG5ldyBh bGdvcml0aG1zIGZvciB0aGUgVExTIDEuMyBjZXJ0aWZpY2F0ZSBjb21wcmVzc2lvbiBleHRlbnNp b24uDQoNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWF0dHNzb24tdGxz LWNib3ItY2VydC1jb21wcmVzcy0wMA0KDQogICAgQ2hlZXJzLA0KICAgIEpvaG4NCg0KICAgIC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTogImludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCiAgICBEYXRlOiBNb25kYXksIDkgTWFy Y2ggMjAyMCBhdCAyMToxOQ0KICAgIFRvOiBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVy aWNzc29uLmNvbT4sIEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPiwg Sm9lbCBIw7ZnbHVuZCA8am9lbC5ob2dsdW5kQHJpLnNlPiwgSm9lbCBIb2dsdW5kIDxqb2VsLmhv Z2x1bmRAcmkuc2U+LCBHw7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNv bT4sIE1hcnRpbiBGdXJ1aGVkIDxtYXJ0aW4uZnVydWhlZEBuZXh1c2dyb3VwLmNvbT4sIEfDtnJh biBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPiwgU2hhaGlkIFJhemEgPHNo YWhpZC5yYXphQHJpLnNlPg0KICAgIFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBm b3IgZHJhZnQtbWF0dHNzb24tdGxzLWNib3ItY2VydC1jb21wcmVzcy0wMC50eHQNCg0KDQogICAg ICAgIEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tYXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNv bXByZXNzLTAwLnR4dA0KICAgICAgICBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IEpvaG4gUHJldXNzIE1hdHRzc29uIGFuZCBwb3N0ZWQgdG8gdGhlDQogICAgICAgIElFVEYgcmVw b3NpdG9yeS4NCg0KICAgICAgICBOYW1lOmRyYWZ0LW1hdHRzc29uLXRscy1jYm9yLWNlcnQtY29t cHJlc3MNCiAgICAgICAgUmV2aXNpb246MDANCiAgICAgICAgVGl0bGU6Q0JPUiBDZXJ0aWZpY2F0 ZSBBbGdvcml0aG0gZm9yIFRMUyBDZXJ0aWZpY2F0ZSBDb21wcmVzc2lvbg0KICAgICAgICBEb2N1 bWVudCBkYXRlOjIwMjAtMDMtMDkNCiAgICAgICAgR3JvdXA6SW5kaXZpZHVhbCBTdWJtaXNzaW9u DQogICAgICAgIFBhZ2VzOjYNCiAgICAgICAgVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNvbXBy ZXNzLTAwLnR4dA0KICAgICAgICBTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtbWF0dHNzb24tdGxzLWNib3ItY2VydC1jb21wcmVzcy8NCiAgICAg ICAgSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0 c3Nvbi10bHMtY2Jvci1jZXJ0LWNvbXByZXNzLTAwDQogICAgICAgIEh0bWxpemVkOiAgICAgICBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1hdHRzc29uLXRscy1j Ym9yLWNlcnQtY29tcHJlc3MNCg0KDQogICAgICAgIEFic3RyYWN0Og0KICAgICAgICAgICBDZXJ0 aWZpY2F0ZSBjaGFpbnMgb2Z0ZW4gdGFrZSB1cCB0aGUgbWFqb3JpdHkgb2YgdGhlIGJ5dGVzDQog ICAgICAgICAgIHRyYW5zbWl0dGVkIGluIFRMUyBoYW5kc2hha2VzLiAgTGFyZ2UgaGFuZHNoYWtl cyBjYW4gY2F1c2UgcHJvYmxlbXMsDQogICAgICAgICAgIHBhcnRpY3VsYXJseSBpbiBjb25zdHJh aW5lZCBJb1QgZW52aXJvbm1lbnRzLiAgUkZDIDc5MjUgZGVmaW5lcyBhIFRMUw0KICAgICAgICAg ICBjZXJ0aWZpY2F0ZSBwcm9maWxlIGZvciBjb25zdHJhaW5lZCBJb1QuICBHZW5lcmFsIHB1cnBv c2UgY29tcHJlc3Npb24NCiAgICAgICAgICAgYWxnb3JpdGhtcyBjYW4gaW4gbWFueSBjYXNlcyBu b3QgY29tcHJlc3MgUkZDIDc5MjUgcHJvZmlsZWQNCiAgICAgICAgICAgY2VydGlmaWNhdGVzIGF0 IGFsbC4gIEJ5IHVzaW5nIHRoZSBmYWN0IHRoYXQgdGhlIGNlcnRpZmljYXRlcyBhcmUNCiAgICAg ICAgICAgcHJvZmlsZWQsIHRoZSBDQk9SIGNlcnRpZmljYXRlIGNvbXByZXNzaW9uIGFsZ29yaXRo bXMgY2FuIGluIG1hbnkNCiAgICAgICAgICAgY2FzZXMgY29tcHJlc3MgUkZDIDc5MjUgcHJvZmls ZWQgY2VydGlmaWNhdGVzIHdpdGggb3ZlciA1MCUuIFRoaXMNCiAgICAgICAgICAgZG9jdW1lbnQg c3BlY2lmaWVzIHRoZSBDQk9SIGNlcnRpZmljYXRlIGNvbXByZXNzaW9uIGFsZ29yaXRobSBmb3Ig dXNlDQogICAgICAgICAgIHdpdGggVExTIENlcnRpZmljYXRlIENvbXByZXNzaW9uIGluIFRMUyAx LjMgYW5kIERUTFMgMS4zLg0KDQoNCg0KDQogICAgICAgIFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCiAg ICAgICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCB0b29scy5pZXRmLm9yZy4NCg0KICAgICAgICBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0K DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRM UyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90bHMNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVt YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUg cHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0 b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Fri Apr 3 09:35:40 2020 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 71D9D3A1B36 for ; Fri, 3 Apr 2020 09:35:38 -0700 (PDT) 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=FCvJq5e1; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=FCvJq5e1 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 NxRyp8bPmupH for ; Fri, 3 Apr 2020 09:35:36 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-db5eur03on0629.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0a::629]) (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 416C23A1B38 for ; Fri, 3 Apr 2020 09:35:33 -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=743t75m2/DajIOXom8e1k/rdZBmgW6vuJApIuhgHMVQ=; b=FCvJq5e1wJhHddTtc7QVojRjMydtF4opM4e/yuY4TL0n2b+GUDVYkSalC4shxyBjI292Inr+KvwzFeUhAc0M1tuuR0eZrKFVAmOSBQVqmQDK5tVprkRFWtR18++AmDkQ1LbAQCfpHO0ABu7qS79JfuaLTjj2AECuq1KfZTjP5fE= Received: from DB3PR0102CA0030.eurprd01.prod.exchangelabs.com (2603:10a6:8::43) by AM5PR0802MB2593.eurprd08.prod.outlook.com (2603:10a6:203:94::15) 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 16:35:30 +0000 Received: from DB5EUR03FT016.eop-EUR03.prod.protection.outlook.com (2603:10a6:8:0:cafe::83) by DB3PR0102CA0030.outlook.office365.com (2603:10a6:8::43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16 via Frontend Transport; Fri, 3 Apr 2020 16:35:30 +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 DB5EUR03FT016.mail.protection.outlook.com (10.152.20.141) 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 16:35:30 +0000 Received: ("Tessian outbound eadf07c3b4bb:v50"); Fri, 03 Apr 2020 16:35:30 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: c6706894008c0688 X-CR-MTA-TID: 64aa7808 Received: from cb8e20d6c1a8.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D16BC64C-FFC0-4932-B0C4-6284080091D4.1; Fri, 03 Apr 2020 16:35:25 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id cb8e20d6c1a8.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 03 Apr 2020 16:35:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=O954zfjaRDZceTU3J0Z0A8dfA4cobfvHnn8Fq+4UCzCjFeb6+dmvOUvu9cDKs03fon8IPQI3frtCmdGRqYwcgiXB3u455J5tviivqhua0Gdbr7tUFoYE2suaiV/GhzH78jvQllAH98LsUDYR+V7ramPh5JT8JRXCgPYM1PhYbYotzrsps6uCSc0czr4P1mXm7F79cXNQ5ZVRZYIS2uj9It6gSVN1MP1wGx6JstGqgTu/miFV69DmGUqO0NLu3GKqbfXyqvsViedZiO1xu2kD9WQ6GUCul9T+pC7sE0QcEIHl+MPF9hlev05ynbl6Slu2dS0MLNYlhIh9iYBbWLm+zA== 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=743t75m2/DajIOXom8e1k/rdZBmgW6vuJApIuhgHMVQ=; b=Hh86kRjjYaxSaHLxutVI/YbLB7YH5AJsvDKkXvUHwOzPdOD42mhGdhC279xfCi8+5H9PC7vLOgb3L3YcDSgKl6HptCMJXubfZGfiXsMk/rXKRwywN1A2XbnypbHqPpyp0tS59BEoMNDONWEDM9mkDkILZfkenriH2RKL/eV7PTkcJ4CqhZ91XIr7lNgvOKY5KrjlvsNhkXl/3a+lk5FpVdqW9Q3Snp7SqH0SBt13KPg6nU8EYKyhYNxZ8GKknB5Eh/3Mw206DyhZRkTvJ6mYyBCkwgEvE7AN3nvKrk/AaGJB8Ke5sOerTLbtp5OoRgXzuH+YMpmsrEI3V0rVPSdflg== 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=743t75m2/DajIOXom8e1k/rdZBmgW6vuJApIuhgHMVQ=; b=FCvJq5e1wJhHddTtc7QVojRjMydtF4opM4e/yuY4TL0n2b+GUDVYkSalC4shxyBjI292Inr+KvwzFeUhAc0M1tuuR0eZrKFVAmOSBQVqmQDK5tVprkRFWtR18++AmDkQ1LbAQCfpHO0ABu7qS79JfuaLTjj2AECuq1KfZTjP5fE= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (52.135.163.143) by AM6PR08MB5048.eurprd08.prod.outlook.com (10.255.123.95) 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 16:35:23 +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 16:35:23 +0000 From: Hanno Becker To: "tls@ietf.org" Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlQ== Date: Fri, 3 Apr 2020 16:35:23 +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: c97e4ef3-4ec4-4d00-8507-08d7d7ed0606 x-ms-traffictypediagnostic: AM6PR08MB5048:|AM5PR0802MB2593: 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)(39860400002)(396003)(136003)(346002)(376002)(366004)(66476007)(2906002)(81156014)(81166006)(55016002)(5660300002)(26005)(76116006)(66946007)(66446008)(9686003)(66556008)(316002)(71200400001)(7696005)(8936002)(64756008)(186003)(86362001)(8676002)(478600001)(6506007)(33656002)(6916009)(52536014)(19627405001); 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: dv7KhW5gg31WHWhnrKbPxjdTUW1cmpjoQ8o9VrO78hhmtKju/Lrg8VN4QRCKHnq697hX5eMGPpRvWTw81E6W6YiYJrUv0sXQXRCsQV4ooJuf9N12cKWO0k2sl8X9CC2lYV2MKmwt7dco84GPifDESjayclzrub7u9hkSrW2OzFtj0tiKctnAuSfXld2nI40ZKKaqyyK1y3wH8kTmFHymizZadTO3T1stzFevWsXjdzYX118QWgI45RZHdJDmRhsg6/rjW6ESaiPwlHZ2i9vcnPrF8FKhii26Wn8wPzjuiio5hORH9DeQiKiRJiso8+J/cQth8vp+SbyzKDhhbCWX0OhOh5gGwxciUiVt8UymqWYVIuFX/aeTl8CxFG5OTgK9R+F7sVVyUrAiU04rEsOMZyCPPhrwvnzkqDABhV6S1xAcT/Dq6tWghETjraoaPJZS x-ms-exchange-antispam-messagedata: hmAuap2jq0C2E/Oq+83P1Ruy2S+TYRKXGaltNZ/1dbSrp7+AZzywfRZ9rVdTQJI8XFcXec5G3MZ5qa9/Ck30GChDwnIAvdbUBggGhJ2qhuCYomND9kjFidiE+QymfJ9DWxXUCWC4wcUW0b1VQ9T00g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB331820C710440F07055382739BC70AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5048 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT016.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)(136003)(346002)(376002)(396003)(39860400002)(46966005)(336012)(316002)(356004)(186003)(33656002)(82740400003)(6916009)(2906002)(86362001)(26005)(47076004)(55016002)(19627405001)(9686003)(478600001)(30864003)(26826003)(70206006)(70586007)(52536014)(5660300002)(8676002)(81166006)(7696005)(6506007)(8936002)(81156014); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 936f869c-db30-46e5-ddce-08d7d7ed01c1 X-Forefront-PRVS: 0362BF9FDB X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: TVEw+DQTvOPj6g1tKvOWw1Hm21xQbCEIa9MMhXcd3D7Rshl+V1wif8tI7M0MXym36d//DxGboESdn9w5JYSmFeFTGzE8zxaS/cG7/U0P4Fs0q8PouyQ7xUuI3PMeYKntamOyv4GVZZxajEe5aX1pv2cp008m9TrP+O1oMvZLZvJ5MqB4fVAXh1oqCZ1bZPyE2tXV7LM1pJL8FJG1vuJgYd68nNQff76bpfQtC2XtbGJnnqefIw51XMd6qOOUHB00ZNYqtrJjRaLD29t4ncJMCIIsgp2dTTm92//b0KJgubwo/P7eEkpTYReLRz/XNg8hRkWQir2MxXAV6CDSZ6FV//zKEkyZqF+OKWTYwRi9USILIm+aU8Fltadwb4LEqM9DBxx2OJT4kogNy8uoUzEye8NZFIvUr9Z/LCtxJ34oPWjffRwgNN//m1qgyMKQFRNUSOEDlzq99KTV7FNmB4G91UwDnpnubj0milsHHnh/gOdgMrKFQcsYAGLDK63IgF7eFmsujuquA5dGgcvm7IFynw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2020 16:35:30.4446 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: c97e4ef3-4ec4-4d00-8507-08d7d7ed0606 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: AM5PR0802MB2593 Archived-At: Subject: [TLS] Efficiency of ACKing scheme 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 16:35:39 -0000 --_000_AM6PR08MB331820C710440F07055382739BC70AM6PR08MB3318eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi again, The DTLS 1.3 ACKing scheme seems to be quite inefficient as it is written, and I wonder if the current spec matches the authors' intentions. Example: Consider a flight broken down as sequence of records 1, 2, .., N. Assume record 2 gets dropped, while all other records go through without reordering, corruption or loss; hence, the record sequence observed on the receiver is 1, 3, 4, ..., N. Then, according to the spec, the following SHOULD happen: On the receiver-side, we have the following from Section 7.1: ``` 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. Implementations have some discretion about when to generate ACKs, but it is RECOMMENDED that they do so under two circumstances: * When they receive a message or fragment which is out of order, either because it is not the next expected message or because it is not the next piece of the current message. ``` So, when the receiver receives records 1 and 3, it notices that 2 is missin= g and immediately sends an ACK for { 1, 3 }. On the sender-side, we have the following from Section 7.2: ``` 7.2. Receiving ACKs When an implementation receives an ACK, it SHOULD record that the messages or message fragments sent in the records being ACKed were received and omit them from any future retransmissions. Upon receipt of an ACK for only some messages from a flight, an implementation SHOULD retransmit the remaining messages or fragments. ``` So, when the receiver receives the ACK for { 1, 3 }, it resends records 2, 4, 5, .., N. That's obviously not optimal, and probably not what was intended, but what unambiguously appears to be the recommended behavior according to the spec. How should this be resolved? I see two similar and comparably unintrusive options: 1) Send ACKs only after period of inactivity Instead of sending ACKs straight away when something hints at something going wrong (such as an out-of-order receipt), as currently stated in Section 7.1, only send ACKs after a period of time where no further messages has been received. That is, replace the current version ``` 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. Implementations have some discretion about when to generate ACKs, but it is RECOMMENDED that they do so under two circumstances: * When they receive a message or fragment which is out of order, either because it is not the next expected message or because it is not the next piece of the current message. Implementations MUST NOT send ACKs for handshake messages which they discard as out-of-order, because otherwise those messages will not be retransmitted. * When they have received part of a flight and do not immediately receive the rest of the flight (which may be in the same UDP datagram). A reasonable approach here is to set a timer for 1/4 the current retransmit timer value when the first record in the flight is received and then send an ACK when that timer expires. In addition, implementations MUST send ACKs upon receiving all of any flight which they do not respond to with their own messages. ``` by something along the following lines: ``` As long as implementation has received some but not all of the next inco= ming flight, it SHOULD send an ACK message after an implementation-defined pe= riod a time during which no further messages are received. A reasonable appro= ach here is to reset a timer to 1/4 the current retransmission timer with ev= ery record received in the current flight, and send an ACK when that timer e= xpires. ``` In the above example, this would mean that as long as records 3,4,..,N a= rrive in close succession, it will only once send an ACK for {1,3,4,...,N} in = the end, triggering retransmission of record 2 only, which is optimal. The drawback of this is that the receiver of a flight does not inform a = peer about a gap in a flight as soon as it notices it. For this to work, the = content of an ACK would need to be what's missing instead of what's present, whi= ch appears to be a too intrusive change to be considered at this stage. The benefit of this approach is that it leads to very good retransmission ba= ndwidth. 2. Essentially same as option 1., but 'mirrored': Allow the receiver of a f= light to send ACKs recurringly (though preferably still bunched, i.e. using so= me timer for the bunching), and replace the part of Section 7.2: ``` 7.2. Receiving ACKs When an implementation receives an ACK, it SHOULD record that the messages or message fragments sent in the records being ACKed were received and omit them from any future retransmissions. Upon receipt of an ACK for only some messages from a flight, an implementation SHOULD retransmit the remaining messages or fragments. ``` by something along the lines of ``` 7.2. Receiving ACKs If an implementation receives an ACK for parts of a flight, but doesn't immediately receive ACKs for the rest of the flight, it SHOULD retransmi= t the messages that have not been ACKed. A reasonable approach here is to reset a timer to 1/4 the current retransmission timer with every ACK rec= ord received, and retransmit the last outgoing flight when that timer expire= s. ``` Let me know what you think and which option (if not a completely different = one) you'd prefer. 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_AM6PR08MB331820C710440F07055382739BC70AM6PR08MB3318eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi again,<= /span>

The D= TLS 1.3 ACKing scheme seems to be quite inefficient as it is written,
and I= wonder if the current spec matches the authors' intentions.

Examp= le:

Consi= der a flight broken down as sequence of records 1, 2, .., N.
Assum= e record 2 gets dropped, while all other records go through
witho= ut reordering, corruption or loss; hence, the record sequence
obser= ved on the receiver is 1, 3, 4, ..., N.

Then,= according to the spec, the following SHOULD happen:

On th= e receiver-side, we have the following from Section 7.1:

```
 = ;  When an implementation receives a partial flight, it SHOULD generat= e
 = ;  an ACK that covers the messages from that flight which it has
 = ;  received so far.  Implementations have some discretion about w= hen to
 = ;  generate ACKs, but it is RECOMMENDED that they do so under two
 = ;  circumstances:
 = ;  *  When they receive a message or fragment which is out of ord= er,
 = ;     either because it is not the next expected message or becau= se it
 = ;     is not the next piece of the current message.
```

So, w= hen the receiver receives records 1 and 3, it notices that 2 is missing
and i= mmediately sends an ACK for { 1, 3 }.

On th= e sender-side, we have the following from Section 7.2:

```
7.2. =  Receiving ACKs
 = ;  When an implementation receives an ACK, it SHOULD record that the
 = ;  messages or message fragments sent in the records being ACKed were<= /span>
 = ;  received and omit them from any future retransmissions.  Upon = receipt
 = ;  of an ACK for only some messages from a flight, an implementation
 = ;  SHOULD retransmit the remaining messages or fragments.
```

So, w= hen the receiver receives the ACK for { 1, 3 }, it resends records
2, 4,= 5, .., N.

That'= s obviously not optimal, and probably not what was intended, but what
unamb= iguously appears to be the recommended behavior according to the spec.

How s= hould this be resolved?

I see= two similar and comparably unintrusive options:

1) Se= nd ACKs only after period of inactivity

 = ;  Instead of sending ACKs straight away when something hints at
 = ;  something going wrong (such as an out-of-order receipt), as<= br>
 = ;  currently stated in Section 7.1, only send ACKs after a period
 = ;  of time where no further messages has been received.

 = ;  That is, replace the current version

```
 = ;  When an implementation receives a partial flight, it SHOULD generat= e
 = ;  an ACK that covers the messages from that flight which it has
 = ;  received so far.  Implementations have some discretion about w= hen to
 = ;  generate ACKs, but it is RECOMMENDED that they do so under two
 = ;  circumstances:
 = ;  *  When they receive a message or fragment which is out of ord= er,
 = ;     either because it is not the next expected message or becau= se it
 = ;     is not the next piece of the current message.  Impleme= ntations
 = ;     MUST NOT send ACKs for handshake messages which they discar= d as
 = ;     out-of-order, because otherwise those messages will not be<= /span>
 = ;     retransmitted.
 = ;  *  When they have received part of a flight and do not immedia= tely
 = ;     receive the rest of the flight (which may be in the same UD= P
 = ;     datagram).  A reasonable approach here is to set a tim= er for 1/4
 = ;     the current retransmit timer value when the first record in= the
 = ;     flight is received and then send an ACK when that timer exp= ires.
 = ;  In addition, implementations MUST send ACKs upon receiving all of a= ny
 = ;  flight which they do not respond to with their own messages.=
```

 = ;  by something along the following lines:

```
 = ;  As long as implementation has received some but not all of the next= incoming
 = ;  flight, it SHOULD send an ACK message after an implementation-defin= ed period
 = ;  a time during which no further messages are received. A reasonable = approach
 = ;  here is to reset a timer to 1/4 the current retransmission timer wi= th every
 = ;  record received in the current flight, and send an ACK when that ti= mer expires.
```

 = ;  In the above example, this would mean that as long as records 3,4,.= .,N arrive
 = ;  in close succession, it will only once send an ACK for {1,3,4,...,N= } in the end,
 = ;  triggering retransmission of record 2 only, which is optimal.

 = ;  The drawback of this is that the receiver of a flight does not info= rm a peer
 = ;  about a gap in a flight as soon as it notices it. For this to work,= the content
 = ;  of an ACK would need to be what's missing instead of what's present= , which
 = ;  appears to be a too intrusive change to be considered at this stage= . The
 = ;  benefit of this approach is that it leads to very good retransmissi= on bandwidth.

2. Es= sentially same as option 1., but 'mirrored': Allow the receiver of a flight=
 = ;  to send ACKs recurringly (though preferably still bunched, i.e. usi= ng some timer
 = ;  for the bunching), and replace the part of Section 7.2:

```
7.2. =  Receiving ACKs
 = ;  When an implementation receives an ACK, it SHOULD record that the
 = ;  messages or message fragments sent in the records being ACKed were<= /span>
 = ;  received and omit them from any future retransmissions.  Upon = receipt
 = ;  of an ACK for only some messages from a flight, an implementation
 = ;  SHOULD retransmit the remaining messages or fragments.
```

 = ;  by something along the lines of

```
7.2. =  Receiving ACKs
 = ;  If an implementation receives an ACK for parts of a flight, but doe= sn't
 = ;  immediately receive ACKs for the rest of the flight, it SHOULD retr= ansmit
 = ;  the messages that have not been ACKed. A reasonable approach here i= s to
 = ;  reset a timer to 1/4 the current retransmission timer with every AC= K record
 = ;  received, and retransmit the last outgoing flight when that timer e= xpires.
```

Let m= e know what you think and which option (if not a completely different one)<= /span>
you'd= prefer.

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_AM6PR08MB331820C710440F07055382739BC70AM6PR08MB3318eurp_-- From nobody Fri Apr 3 10:00:16 2020 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 BDEB73A0832 for ; Fri, 3 Apr 2020 10:00:15 -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=O5hCoGvg; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=O5hCoGvg 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 Fi1KnTF0aDyT for ; Fri, 3 Apr 2020 10:00:13 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10043.outbound.protection.outlook.com [40.107.1.43]) (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 814CB3A082E for ; Fri, 3 Apr 2020 10:00:12 -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=3wXcXRph9N0rZEUOLQDAN4uoUE5M38/pKHRSieLx6Ck=; b=O5hCoGvgAAtngIwaIrNKYP9kuYWFVQ0Gaw8YVimdY/+qFcW8GZZXy3XyrvE8yKYeY/C3XxgFptx8dcTeV6lUdNPBFsQZsfMfmgKFLJLaSS7NMFQkqK3dh2XX2MpKzzlNImk0FBq2qsGWFVnMRbiatraumgocFp6Z0oAidATtGx4= Received: from VI1PR0701CA0035.eurprd07.prod.outlook.com (2603:10a6:800:90::21) by AM0PR08MB3027.eurprd08.prod.outlook.com (2603:10a6:208:61::26) 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 17:00:08 +0000 Received: from VE1EUR03FT040.eop-EUR03.prod.protection.outlook.com (2603:10a6:800:90:cafe::f6) by VI1PR0701CA0035.outlook.office365.com (2603:10a6:800:90::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.12 via Frontend Transport; Fri, 3 Apr 2020 17:00:08 +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 VE1EUR03FT040.mail.protection.outlook.com (10.152.18.210) 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 17:00:07 +0000 Received: ("Tessian outbound 5345ff401cf8:v50"); Fri, 03 Apr 2020 17:00:07 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 9de29acbe45d3f3d X-CR-MTA-TID: 64aa7808 Received: from 9c4322501f4a.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id C558B1CD-4E99-474C-80C5-A1B2F9AA2BB0.1; Fri, 03 Apr 2020 17:00:02 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 9c4322501f4a.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 03 Apr 2020 17:00:02 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LWG/uA87ZxCSsGcbBb3knpgv5v55eIXmazX6wIL0j/LIDaHTREF8kwxYFaruFiHjDRVqCi0rD4X0+MABzhI//T2mJ0UizPpk1iTsGTRqK0JTDX9pc83IYF43ndEWlLQyBkNZHPNYy6KMKfMQdp3blhv1gX3HPhLeTY76+Ok1DGpQP8SzJddKlE/Cw6yPYwAUUosyBarTklxYUc26Qc5dcrtiP1/XHpQ1GqpKntq2QwxHRpK9DUUo0GwYfMYTRPaoMMFD/pzzOUrUbQwV+ZuYLCLo37lwr0Tl0z63QzFC4ZsT+q127/teReFK9POv+B+UfetGPf4qUl0x7CEfI25Obg== 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=3wXcXRph9N0rZEUOLQDAN4uoUE5M38/pKHRSieLx6Ck=; b=TskNIhpfJo1Qx/wtGTy3ZaPh+HzSjjAAycwrTh2uOkDbsksKt0xuaFwhh7VxA0C9JohKy+oVSIyj1UDlvQo46cOtJd2RMTJSBjqfu/wZBHOtaFOea520x6g0ywoeXoGbW7li+Zi1jHCJ5nD/KkQP5enpQ7usKWV0p6kjMSmyL/dcwAh6cs7v/zayii6RQV9aM0seC+G1obC09tskiOO9OMrRpehqDrWZoXdFQkRepIU06REA7qTEXrUJoMCibm8ATiUcyxw9qxCS2fStaXlUn2pkpEKMiiANDceObDjpfdaA7X+1FXnbnl0SFGtRxYC+VeOZ8LsykAYh7jR2ptojeQ== 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=3wXcXRph9N0rZEUOLQDAN4uoUE5M38/pKHRSieLx6Ck=; b=O5hCoGvgAAtngIwaIrNKYP9kuYWFVQ0Gaw8YVimdY/+qFcW8GZZXy3XyrvE8yKYeY/C3XxgFptx8dcTeV6lUdNPBFsQZsfMfmgKFLJLaSS7NMFQkqK3dh2XX2MpKzzlNImk0FBq2qsGWFVnMRbiatraumgocFp6Z0oAidATtGx4= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (52.135.163.143) by AM6PR08MB3909.eurprd08.prod.outlook.com (20.178.91.78) 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 17:00:00 +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 17:00:00 +0000 From: Hanno Becker To: "tls@ietf.org" Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQ Date: Fri, 3 Apr 2020 17:00:00 +0000 Message-ID: References: In-Reply-To: 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: 8b73ab27-e647-4df7-4fc3-08d7d7f076b7 x-ms-traffictypediagnostic: AM6PR08MB3909:|AM0PR08MB3027: 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)(39860400002)(366004)(376002)(396003)(346002)(26005)(86362001)(8936002)(186003)(8676002)(7696005)(71200400001)(316002)(81166006)(81156014)(2940100002)(6506007)(76116006)(55016002)(66476007)(66446008)(64756008)(66946007)(66556008)(33656002)(53546011)(19627405001)(5660300002)(478600001)(52536014)(9686003)(2906002)(6916009); 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: 1lSZu7XzyqQfcphDGSQlsZ7ALjOMh/hSszs6+BwGg0LX3hBxLX3gPlqEyu6OrCHpe1H3BCyruYw0rE8J/9+/4NJJ3M1KliKEFYjrIFD6aZavEBjgFzVYUi1C9re4m9hhaBRvEaWJHZow1Jg8fcs6Jc41bLXRzDdGD0M9vxnF65AaoUR/WdWRVve1ku/ZhOcba8uH1Iq02fTFs4xWfnJ8BA2b/GX/l60e2aAJkU+Ryjzrds0WOEMNo6zUpH4y5Kp1bU0vTCkrb3JoAKwVCLRSwvmu41oAHnaHj5fItV88pUpKRpZdvhq3sYuacm9ohXMw0WGNOHLmgSNLyY2205dpMSuOsc1MXfFI6rfczb971/1nQ7j8FjRpM7a8RqYylSQabyAi+DzfFFyt5Fll8RmRfZVuxbrWxA7NYpLtaEOtTapjykCHFFQbzSUk26/Bv7RX x-ms-exchange-antispam-messagedata: 3JgTfcbrH0htYdF4apQBGrdmIYzx8QVt6bNpzcQ8RcjF4U3IHxDvq9ECZo8+YWOPGnd1kNqyoDeR50kTTgat6Pf1DxHkHjvyrT1MErFduRKECdo5To5A8IeIMLpZaFkH7vx9EY8NPGPRfCChE5MhRw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB331832C84A0E5D04AA5612A99BC70AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3909 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT040.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)(376002)(346002)(136003)(39860400002)(396003)(46966005)(81156014)(81166006)(19627405001)(47076004)(86362001)(2906002)(186003)(6916009)(8676002)(53546011)(55016002)(26826003)(70206006)(82740400003)(70586007)(26005)(30864003)(478600001)(6506007)(36906005)(7696005)(33656002)(52536014)(8936002)(5660300002)(356004)(2940100002)(316002)(9686003)(336012); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: bb01e634-92ce-4720-f00d-08d7d7f0724c X-Forefront-PRVS: 0362BF9FDB X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: j4k5hQOM/oVGXHNJF/Bbjpvxo+g25rBvBxMrfbkmDmXfhsY8f+FYZU7RYL1neav/PDjFxUHhjP3OtQzDchU6kyMbfNY+ElszRY0pnGerkJiJ3admxpQaQMezxYS4E1ypr6P5EBG/q/q+thN7SK8Hwdv6AfEMlLg3lTZRvYVACdW6muIEBd/CrdCnNNtdAZXAx3kDXX5M8IllR36zb0Q+Pj0i2+Py0os6+ipZ68IkezIcGbga2gOSbZ2HuGj6iahrFCW3hadONOoRuntud+rmHB75AsXS8gGt/G0FQ2eF3qt6cL8n1oi1otrW2v1BO0kBxT51JPSRHprmbGM8G0wvA/afpQRXEXZlC/0QS+zgfBsz+wAaCuwHR+uKNblZ8Dw0m5mA1sEuPC20LvzUiyGHYvHduV1uVMWyCi3o//rFBq/E0bssCgpS+491ewC7jfQ2CR4eOHf9WiYeeppwA1D+iFEOWG/3OXEWaBHmMm/la2Xf5hd824mhQWZ9VkpDDEKBj7HCxlb8MR1gt0Er2g+EIQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Apr 2020 17:00:07.8741 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8b73ab27-e647-4df7-4fc3-08d7d7f076b7 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: AM0PR08MB3027 Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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 17:00:16 -0000 --_000_AM6PR08MB331832C84A0E5D04AA5612A99BC70AM6PR08MB3318eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An additional note: All solutions which retain the paragraph Upon receipt of an ACK for only some messages from a flight, an implementation SHOULD retransmit the remaining messages or fragments. and hence trigger retransmission immediately upon receiving a partial ACK, suffer from the following problem: On Low-MTU networks, and looking ahead at the use of Post-Quantum Cryptogra= phy, it might happen that a single ACK is too small to hold the entire list of r= ecord sequence numbers of the flight being ACKed. Doing the math in an example: If the maximum plaintext size is, say, 512 By= tes, then a single ACK can not ACK more than 64 Records, each of which contains = at most 512 Bytes of handshake data. Hence, we've got a theoretical max of ~32= Kb flight length we can ACK in a single ACK message. While this seems a lot, some PQC schemes go beyond that. For example, the S= PHINCS signature scheme has 41Kb signature size. To avoid this problem, it appears beneficial to go for option 2., that is, = don't retransmit immediately upon receiving an ACK, but accumulate some ACKs firs= t. This allows to split ACKing a very large flight into multiple ACKs. ________________________________ From: TLS on behalf of Hanno Becker Sent: Friday, April 3, 2020 5:35 PM To: tls@ietf.org Subject: [TLS] Efficiency of ACKing scheme Hi again, The DTLS 1.3 ACKing scheme seems to be quite inefficient as it is written, and I wonder if the current spec matches the authors' intentions. Example: Consider a flight broken down as sequence of records 1, 2, .., N. Assume record 2 gets dropped, while all other records go through without reordering, corruption or loss; hence, the record sequence observed on the receiver is 1, 3, 4, ..., N. Then, according to the spec, the following SHOULD happen: On the receiver-side, we have the following from Section 7.1: ``` 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. Implementations have some discretion about when to generate ACKs, but it is RECOMMENDED that they do so under two circumstances: * When they receive a message or fragment which is out of order, either because it is not the next expected message or because it is not the next piece of the current message. ``` So, when the receiver receives records 1 and 3, it notices that 2 is missin= g and immediately sends an ACK for { 1, 3 }. On the sender-side, we have the following from Section 7.2: ``` 7.2. Receiving ACKs When an implementation receives an ACK, it SHOULD record that the messages or message fragments sent in the records being ACKed were received and omit them from any future retransmissions. Upon receipt of an ACK for only some messages from a flight, an implementation SHOULD retransmit the remaining messages or fragments. ``` So, when the receiver receives the ACK for { 1, 3 }, it resends records 2, 4, 5, .., N. That's obviously not optimal, and probably not what was intended, but what unambiguously appears to be the recommended behavior according to the spec. How should this be resolved? I see two similar and comparably unintrusive options: 1) Send ACKs only after period of inactivity Instead of sending ACKs straight away when something hints at something going wrong (such as an out-of-order receipt), as currently stated in Section 7.1, only send ACKs after a period of time where no further messages has been received. That is, replace the current version ``` 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. Implementations have some discretion about when to generate ACKs, but it is RECOMMENDED that they do so under two circumstances: * When they receive a message or fragment which is out of order, either because it is not the next expected message or because it is not the next piece of the current message. Implementations MUST NOT send ACKs for handshake messages which they discard as out-of-order, because otherwise those messages will not be retransmitted. * When they have received part of a flight and do not immediately receive the rest of the flight (which may be in the same UDP datagram). A reasonable approach here is to set a timer for 1/4 the current retransmit timer value when the first record in the flight is received and then send an ACK when that timer expires. In addition, implementations MUST send ACKs upon receiving all of any flight which they do not respond to with their own messages. ``` by something along the following lines: ``` As long as implementation has received some but not all of the next inco= ming flight, it SHOULD send an ACK message after an implementation-defined pe= riod a time during which no further messages are received. A reasonable appro= ach here is to reset a timer to 1/4 the current retransmission timer with ev= ery record received in the current flight, and send an ACK when that timer e= xpires. ``` In the above example, this would mean that as long as records 3,4,...,N = arrive in close succession, it will only once send an ACK for {1,3,4,...,N} in = the end, triggering retransmission of record 2 only, which is optimal. The drawback of this is that the receiver of a flight does not inform a = peer about a gap in a flight as soon as it notices it. For this to work, the = content of an ACK would need to be what's missing instead of what's present, whi= ch appears to be a too intrusive change to be considered at this stage.. Th= e benefit of this approach is that it leads to very good retransmission ba= ndwidth. 2. Essentially same as option 1., but 'mirrored': Allow the receiver of a f= light to send ACKs recurringly (though preferably still bunched, i.e. using so= me timer for the bunching), and replace the part of Section 7.2: ``` 7.2. Receiving ACKs When an implementation receives an ACK, it SHOULD record that the messages or message fragments sent in the records being ACKed were received and omit them from any future retransmissions. Upon receipt of an ACK for only some messages from a flight, an implementation SHOULD retransmit the remaining messages or fragments. ``` by something along the lines of ``` 7.2. Receiving ACKs If an implementation receives an ACK for parts of a flight, but doesn't immediately receive ACKs for the rest of the flight, it SHOULD retransmi= t the messages that have not been ACKed. A reasonable approach here is to reset a timer to 1/4 the current retransmission timer with every ACK rec= ord received, and retransmit the last outgoing flight when that timer expire= s. ``` Let me know what you think and which option (if not a completely different = one) you'd prefer. 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. 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_AM6PR08MB331832C84A0E5D04AA5612A99BC70AM6PR08MB3318eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
An additio= nal note: All solutions which retain the paragraph

   Upon receipt=0A=
   of an ACK for only some messages from a flight, an implementation=0A=
   SHOULD retransmit the remaining messages or fragments.

and hence = trigger retransmission immediately upon receiving a partial ACK,
suffer fro= m the following problem: 

On Low-MTU= networks, and looking ahead at the use of Post-Quantum Cryptography,
it might h= appen that a single ACK is too small to hold the entire list of record
sequence n= umbers of the flight being ACKed.

Doing the math in an example: If the maximum plaintext size= is, say, 512 Bytes,
then a single ACK can not ACK more than 64 Records, each of= which contains at
most 512 Bytes of handshake data. Hence, we've got a theore= tical max of ~32Kb
flight length we can ACK in a single ACK message.

While this seems a lot, some PQC schemes go beyond that. Fo= r example, the SPHINCS
signature scheme has 41Kb signature size.

To avoid this problem, it appears beneficial to go for opti= on 2., that is, don't
retransmit immediately upon receiving an ACK, but accumulat= e some ACKs first. This
allows to split ACKing a very large flight into multiple AC= Ks.
From: TLS <tls-bounces@i= etf.org> on behalf of Hanno Becker <Hanno.Becker@arm.com>
Sent: Friday, April 3, 2020 5:35 PM
To: tls@ietf.org <tls@ietf.org>
Subject: [TLS] Efficiency of ACKing scheme
 
Hi again,

The DTLS= 1.3 ACKing scheme seems to be quite inefficient as it is written,
and I wo= nder if the current spec matches the authors' intentions.

Example:=

Consider= a flight broken down as sequence of records 1, 2, .., N.
Assume r= ecord 2 gets dropped, while all other records go through
without = reordering, corruption or loss; hence, the record sequence
observed= on the receiver is 1, 3, 4, ..., N.

Then, ac= cording to the spec, the following SHOULD happen:

On the r= eceiver-side, we have the following from Section 7.1:

```
  &= nbsp;When an implementation receives a partial flight, it SHOULD generate
  &= nbsp;an ACK that covers the messages from that flight which it has
  &= nbsp;received so far.  Implementations have some discretion about when= to
  &= nbsp;generate ACKs, but it is RECOMMENDED that they do so under two<= br>
  &= nbsp;circumstances:
  &= nbsp;*  When they receive a message or fragment which is out of order,=
  &= nbsp;   either because it is not the next expected message or because = it
  &= nbsp;   is not the next piece of the current message.
```

So, when= the receiver receives records 1 and 3, it notices that 2 is missing=
and imme= diately sends an ACK for { 1, 3 }.

On the s= ender-side, we have the following from Section 7.2:

```
7.2. &nb= sp;Receiving ACKs
  &= nbsp;When an implementation receives an ACK, it SHOULD record that the
  &= nbsp;messages or message fragments sent in the records being ACKed were
  &= nbsp;received and omit them from any future retransmissions.  Upon rec= eipt
  &= nbsp;of an ACK for only some messages from a flight, an implementation
  &= nbsp;SHOULD retransmit the remaining messages or fragments.
```

So, when= the receiver receives the ACK for { 1, 3 }, it resends records
2, 4, 5,= .., N.

That's o= bviously not optimal, and probably not what was intended, but what
unambigu= ously appears to be the recommended behavior according to the spec.<= br>

How shou= ld this be resolved?

I see tw= o similar and comparably unintrusive options:

1) Send = ACKs only after period of inactivity

  &= nbsp;Instead of sending ACKs straight away when something hints at
  &= nbsp;something going wrong (such as an out-of-order receipt), as
  &= nbsp;currently stated in Section 7.1, only send ACKs after a period<= br>
  &= nbsp;of time where no further messages has been received.

  &= nbsp;That is, replace the current version

```
  &= nbsp;When an implementation receives a partial flight, it SHOULD generate
  &= nbsp;an ACK that covers the messages from that flight which it has
  &= nbsp;received so far.  Implementations have some discretion about when= to
  &= nbsp;generate ACKs, but it is RECOMMENDED that they do so under two<= br>
  &= nbsp;circumstances:
  &= nbsp;*  When they receive a message or fragment which is out of order,=
  &= nbsp;   either because it is not the next expected message or because = it
  &= nbsp;   is not the next piece of the current message.  Implementa= tions
  &= nbsp;   MUST NOT send ACKs for handshake messages which they discard a= s
  &= nbsp;   out-of-order, because otherwise those messages will not be
  &= nbsp;   retransmitted.
  &= nbsp;*  When they have received part of a flight and do not immediatel= y
  &= nbsp;   receive the rest of the flight (which may be in the same UDP
  &= nbsp;   datagram).  A reasonable approach here is to set a timer = for 1/4
  &= nbsp;   the current retransmit timer value when the first record in th= e
  &= nbsp;   flight is received and then send an ACK when that timer expire= s.
  &= nbsp;In addition, implementations MUST send ACKs upon receiving all of any<= /span>
  &= nbsp;flight which they do not respond to with their own messages.
```

  &= nbsp;by something along the following lines:

```
  &= nbsp;As long as implementation has received some but not all of the next in= coming
  &= nbsp;flight, it SHOULD send an ACK message after an implementation-defined = period
  &= nbsp;a time during which no further messages are received. A reasonable app= roach
  &= nbsp;here is to reset a timer to 1/4 the current retransmission timer with = every
  &= nbsp;record received in the current flight, and send an ACK when that timer= expires.
```

  &= nbsp;In the above example, this would mean that as long as records 3,4,...,= N arrive
  &= nbsp;in close succession, it will only once send an ACK for {1,3,4,...,N} i= n the end,
  &= nbsp;triggering retransmission of record 2 only, which is optimal.

  &= nbsp;The drawback of this is that the receiver of a flight does not inform = a peer
  &= nbsp;about a gap in a flight as soon as it notices it. For this to work, th= e content
  &= nbsp;of an ACK would need to be what's missing instead of what's present, w= hich
  &= nbsp;appears to be a too intrusive change to be considered at this stage.. = The
  &= nbsp;benefit of this approach is that it leads to very good retransmission = bandwidth.

2. Essen= tially same as option 1., but 'mirrored': Allow the receiver of a flight
  &= nbsp;to send ACKs recurringly (though preferably still bunched, i.e. using = some timer
  &= nbsp;for the bunching), and replace the part of Section 7.2:

```
7.2. &nb= sp;Receiving ACKs
  &= nbsp;When an implementation receives an ACK, it SHOULD record that the
  &= nbsp;messages or message fragments sent in the records being ACKed were
  &= nbsp;received and omit them from any future retransmissions.  Upon rec= eipt
  &= nbsp;of an ACK for only some messages from a flight, an implementation
  &= nbsp;SHOULD retransmit the remaining messages or fragments.
```

  &= nbsp;by something along the lines of

```
7.2. &nb= sp;Receiving ACKs
  &= nbsp;If an implementation receives an ACK for parts of a flight, but doesn'= t
  &= nbsp;immediately receive ACKs for the rest of the flight, it SHOULD retrans= mit
  &= nbsp;the messages that have not been ACKed. A reasonable approach here is t= o
  &= nbsp;reset a timer to 1/4 the current retransmission timer with every ACK r= ecord
  &= nbsp;received, and retransmit the last outgoing flight when that timer expi= res.
```

Let me k= now what you think and which option (if not a completely different one)
you'd pr= efer.

Cheers,<= /span>
Hanno<= br>
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.
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_AM6PR08MB331832C84A0E5D04AA5612A99BC70AM6PR08MB3318eurp_-- From nobody Fri Apr 3 10:16:18 2020 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 617B43A0928 for ; Fri, 3 Apr 2020 10:16:16 -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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com 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 qnbqSWfDuPqO for ; Fri, 3 Apr 2020 10:16:12 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE933A092D for ; Fri, 3 Apr 2020 10:16:11 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id 71so252076qtc.12 for ; Fri, 03 Apr 2020 10:16:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=nOqbqU0oBxZtxLqSqeJB6ISqgAC/xBDYPfYSobh/+34=; b=t6R9a0T4PLuhdP/bMhHAHNud8LcNVHb0t6HUHxBJDMy0L1B+9g54XBI4/jQPHupakg +XPogfp1VLr9UMVQP/y1Za4EKHsMUdM6KeKxxMNGRzC1Jtm8tFKeZ33BW+Vk7vQuPslK ExgqE1zml8G+IJMK1OJPl/Z/mr83I+DN6ltVmqrQfd71/RsnMrRQevXhd7e++5i3L+Sm LLlGq4iQvIp25FMZt5mXJc4R0X32X23+4YdqczgPl4/1TG99sqf/qknsgL48/g+4jHEI g18mtAH+YoEgI5AeKY2QLixY/yK8sn3RnQ9lLsjKOaxWo+U2hOIvLOmFiVH/FjCjeY+E 7axQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=nOqbqU0oBxZtxLqSqeJB6ISqgAC/xBDYPfYSobh/+34=; b=NwCtDsp9CYXZY/04DtLJf1zwTFPasTxQ0Hhc1HAO43JI3clDLmbhznCGNN551/t/en +RfqfWVh3LWZleBMvmKbrWAZe6xGd0voViPynZNYRnuJLfh0AT6c8TgAE81REKEcwKi0 OWNeEBecQke2FX8xfe7JUBhhpgDTgoJ5x5NVjhbXAt3Um8nfXP3uNphkLrXpssxURFaj tbzxZgYa0J3G5gB734Z7OscnwHZMpeOe0vhVCN+ftvMpWpCxHPmtmHBOGqtcpPmsrNFU DNMCHBbRVxmo2F/Mn9TXVU3xg0F4TxnktF/2TLEJwIQm86Ple49R9S1EFDACLrfntsmb oRIg== X-Gm-Message-State: AGi0PuYed5+uSDszz6o2KAfULThPMNULsbk8lPcM7uTKhsoYFi2Yvd/r mUngnPkjD4WL+CVu4uYGESzsSlCTWzhvQFrL2mxbcBAt X-Google-Smtp-Source: APiQypLcT672kBnezqEykMKxX2FQugbh/iJjpS0hv6bxcwpRVc3HW83YRJPXmarLYhT8jpWrK6eBGgsp8UjUj/QHakU= X-Received: by 2002:ac8:2f17:: with SMTP id j23mr9476725qta.249.1585934170439; Fri, 03 Apr 2020 10:16:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Joseph Salowey Date: Fri, 3 Apr 2020 10:15:59 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000ddda3105a26612b0" Archived-At: Subject: Re: [TLS] Virtual TLS Interim Meeting 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 17:16:16 -0000 --000000000000ddda3105a26612b0 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 24, 2020 at 7:54 PM Joseph Salowey wrote: > The chairs think it would be good to schedule a virtual TLS interim > focused on ECHO and also have a readout from the PSK design team. We have > some dates that the IESG has recommended for us. The proposal is: > > 1900 - 2100 UTC April 27 > > Please use the following form to let us know if you can attend: > > https://forms.gle/Wkk7dsx9q1ipmi2B9 > > [Joe] Of the 26 responses only 1 indicated that the time did not work so we are moving forward with requesting this meeting time. More details will follow once the meeting is scheduled. > Thanks, > > Chris, Joe, and Sean > --000000000000ddda3105a26612b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Mar 24, 2020 at 7:54 PM Joseph Sa= lowey <joe@salowey.net> wrote:=
The chairs think it would be good to schedule a virtual TLS interim focus= ed on ECHO and also have a readout from the PSK design team.=C2=A0 We have = some dates that the IESG has recommended for us.=C2=A0 The proposal is:
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 1900 - 2100 UTC =C2=A0April 27

Pleas= e use the following form to let us know if you can attend:

=C2=A0 = =C2=A0 =C2=A0 =C2=A0https://forms.gle/Wkk7dsx9q1ipmi2B9


[Joe] Of the 26 respons= es only 1 indicated that the time did not work so we are moving forward wit= h requesting this meeting time.=C2=A0 More details=C2=A0will follow once th= e meeting is scheduled.=C2=A0
=C2=A0
Thanks,

C= hris, Joe, and Sean
--000000000000ddda3105a26612b0-- From nobody Fri Apr 3 10:17:41 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5705B3A08E1; Fri, 3 Apr 2020 10:17:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: tls@ietf.org, tls-chairs@ietf.org, joe@salowey.net, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158593425844.23443.12033233213727142148@ietfa.amsl.com> Date: Fri, 03 Apr 2020 10:17:39 -0700 Archived-At: Subject: [TLS] tls - New Interim Meeting Request X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 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 17:17:39 -0000 A new interim meeting request has just been submitted by Joseph Salowey. This request requires approval by the Area Director of the Security Area The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2020-tls-01 --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Joseph Salowey Meeting Type: Virtual Meeting Session 1: Date: 2020-04-27 Start Time: 12:00 America/Los_Angeles Duration: 02:00 Remote Participation Information: Remote participation information will be obtained at the time of approval Agenda Note: --------------------------------------------------------- From nobody Fri Apr 3 12:05:20 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 637523A0041; Fri, 3 Apr 2020 12:05:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158594070326.23574.18238375166865820757@ietfa.amsl.com> Date: Fri, 03 Apr 2020 12:05:03 -0700 Archived-At: Subject: [TLS] Transport Layer Security (tls) WG Virtual Meeting: 2020-04-27 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 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 19:05:04 -0000 The Transport Layer Security (tls) Working Group will hold a virtual interim meeting on 2020-04-27 from 12:00 to 14:00 America/Los_Angeles (19:00 to 21:00 UTC). Agenda: 1. Administrivia and agenda bashing 2. ECHO 3. PSK design team readout Information about remote participation: Remote participation information will be obtained at the time of approval From nobody Fri Apr 3 12:50:13 2020 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 85C7B3A0921 for ; Fri, 3 Apr 2020 12:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=cs.tcd.ie 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 0HaZL12e-Dxe for ; Fri, 3 Apr 2020 12:50:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE953A093E for ; Fri, 3 Apr 2020 12:50:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E6341BE20; Fri, 3 Apr 2020 20:50:04 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vik527z47j10; Fri, 3 Apr 2020 20:50:02 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id AEECEBDCF; Fri, 3 Apr 2020 20:50:02 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1585943402; bh=xr7+qLu9G4Q+NkOHo4nqhZww4cPUVq/i7Pv+1aINQ6k=; h=Subject:To:References:From:Date:In-Reply-To:From; b=K/XHuXcgjdXxznBe3xIfzSwGqU8d9ZOVeUfchDahrxvNHXz3Pb71AdBGd5iUquDpd 7dM/AFLT4y4+Ia5/sbRSGh5iDlUPEKPVLOh2n/LZ1KaJe7hB1vTFbeLbUnJFV0JOaV akLYAAXsgt8alZiWvDfyh70nCBCqEu+C9PQ8R/JY= To: Joseph Salowey , "" References: From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Fri, 3 Apr 2020 20:50:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1GREdIqSZLvJBHZL2fj8aLFwtI9l4gQxu" Archived-At: Subject: Re: [TLS] Virtual TLS Interim Meeting 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 19:50:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1GREdIqSZLvJBHZL2fj8aLFwtI9l4gQxu Content-Type: multipart/mixed; boundary="rviWEbU5SOniwSB1qSFjwa3eunPjHKLZg"; protected-headers="v1" From: Stephen Farrell To: Joseph Salowey , "" Message-ID: Subject: Re: [TLS] Virtual TLS Interim Meeting References: In-Reply-To: --rviWEbU5SOniwSB1qSFjwa3eunPjHKLZg Content-Type: multipart/mixed; boundary="------------41AB3CDD0EC88CA7CA5607EC" Content-Language: en-US This is a multi-part message in MIME format. --------------41AB3CDD0EC88CA7CA5607EC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Joe, Pre-agenda bashing question for chairs and authors of the ESNI/ECHO draft... I'd like to try again to suggest simplifications for ECHOConfig (e.g. no extensions, just one public key per RR VALUE etc.) and perhaps also some more rules constraining inner/outer CH variances. How would you prefer those be raised? As issues in GH or threads on the list and would you rather I try group 'em as much as possible or make each issue as fine-grained as possible? Optimistically, this meeting might be the one where we mostly tie this stuff down, so I hope it's ok that some of these issues have been raised before in one form or another. The move from ESNI->ECHO and to HTTPSSVC and the goal to get to WGLC I think justifies re-checking if we really need the current level of (what I claim is too much:-) complexity in ECHO. Ta, S. On 03/04/2020 18:15, Joseph Salowey wrote: > On Tue, Mar 24, 2020 at 7:54 PM Joseph Salowey wrote:= >=20 >> The chairs think it would be good to schedule a virtual TLS interim >> focused on ECHO and also have a readout from the PSK design team. We = have >> some dates that the IESG has recommended for us. The proposal is: >> >> 1900 - 2100 UTC April 27 >> >> Please use the following form to let us know if you can attend: >> >> https://forms.gle/Wkk7dsx9q1ipmi2B9 >> >> > [Joe] Of the 26 responses only 1 indicated that the time did not work s= o we > are moving forward with requesting this meeting time. More details wil= l > follow once the meeting is scheduled. >=20 >=20 >> Thanks, >> >> Chris, Joe, and Sean >> >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------41AB3CDD0EC88CA7CA5607EC Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------41AB3CDD0EC88CA7CA5607EC-- --rviWEbU5SOniwSB1qSFjwa3eunPjHKLZg-- --1GREdIqSZLvJBHZL2fj8aLFwtI9l4gQxu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6Hk2kACgkQWrL68XsX K+reexAAsPt3bCGNpC9E914G4flcgNKzTeXM1fFpkaAqBLfapdd1+FaAFVc8bvr/ AGrvmbrmMAtrFH+n5J/jZyT7ppPBEwSNh7jgKhqrv+yfHee+O3AtsMU7kUgrwg99 EEjFdrn9u75mhJYGR1ZlJpfUVF9L6nbiM3Yo8ML5fSjGWXtf3QdVc8Y2DC4bZeqb iuvtKacHZuVLUziH5F24r5laOe1S0nwzCKAleISXthjyrguYRB7V6y3FTgJY8c9Q aLQWV7o9OYo5+dfQ4NSxOzKlp3vvPnQIhnD/9ucNriJ+Du9xBnDOoQiT9gi8Jygg okgdWiKNJ8+0ByyYoYXbdXlHrdpo3xXE9SO8+rC9x7OkOB5WuU9jhRG+/20tJ4gm YcMsZRHozdJY6KRBPZ277IRaZcrlcPMftYMRqGjLr5MTDnaaVtijcvefm2/zxt8v JG4nZ7f3P+6uFUOQw2FhPBfvzrW/k9yYwpGZ++++FxTy0QU+6NA8vLf5B3cZ0Lhq dPujpfKPIMJhJxTg/5uJAYuOka38TgnvArJu/rfwQrVAHZdWVdRP1PV7HOTj92GG n+74b2ceOFllHYyE3f4OLD0tdefjidJA2QYwML/JXDT2vIfPYGa9Q0VFnt2vHHoS +sFbwJvGC72ncuTim4ASk4c1XdJdLe5/BifPUX5HpnrZzt5YPoI= =d1ao -----END PGP SIGNATURE----- --1GREdIqSZLvJBHZL2fj8aLFwtI9l4gQxu-- From nobody Sat Apr 4 07:37:02 2020 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 A78CA3A0DCF for ; Sat, 4 Apr 2020 07:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=Nw7XzUVi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aeVyNTOe 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 WhBAIQpAKjeR for ; Sat, 4 Apr 2020 07:36:58 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4898D3A0DCD for ; Sat, 4 Apr 2020 07:36:58 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 662885C0257 for ; Sat, 4 Apr 2020 10:36:57 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Sat, 04 Apr 2020 10:36:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=xoR6H5NE8jD2BcHpZ4/wWjpXH5A26gd juF+lrk+2+/k=; b=Nw7XzUVivh1InsVFpbVXMQ7s+LX9qYrrDdhWXaNRP3FFW5w iX8BO2NCI/C9cBqWC4GLN9WVruR+fob7L4vI6g120xcIdFF8mANBnvwg4xruLMyr 6vV86O5bUe4ZVZmVuWJicoF6rLwotn+toP/aRE7DSCUNxeHUGr3kF4zcou1B92WO CNlZgMHddEzwnoM9YCivOQpHNHhWucunaeDkNtA2n34bRHFrhz6y5/TNe4dedv5I nzrZdE8VhHwUw8IbyQusWcn/OMvb58TDSRTvM/dlU8sF830DFcDKtU7We5bn2A9E nLE8aKgY7TT2B1qMN2bV/bj5rJsjHtG16tXkf5A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=xoR6H5 NE8jD2BcHpZ4/wWjpXH5A26gdjuF+lrk+2+/k=; b=aeVyNTOeG3H/uEDAELhfUM s7J1bgFNhzyExVBTolEWygGg+/XL6H+8Z+q74b1QqmEXDrsFt9Gc7hkgAgnxmem/ AdbvdHuFpmbOPLmlk1DW3gpWBCnz4amoJO+rybL+wQYrM7rkkpe4Egf/mVjrSC03 yRicVWdhDwCFRnNCIL9bfqEtCLP9Fb0+p8WgWnb08M+8LxMiCmzdg/yDKNMteD4+ W0tL+JTmwaRR1H2DPbgZhvM9SinqHx7GG3hayOrgHyGQDtQev2KcdJNbHVOiu0zk Xfa7jQeCh0qIxba/no7K8nX3Xv7qCPiWdNp+/9zBkpFbalqV+5Tqzaj9eYoHAVCg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtdekgdejjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 21B3B3C00A1; Sat, 4 Apr 2020 10:36:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1082-g13d7805-fmstable-20200403v1 Mime-Version: 1.0 Message-Id: <1ee2c071-12c4-4717-b43e-a5d246f86058@www.fastmail.com> In-Reply-To: References: Date: Sat, 04 Apr 2020 07:36:36 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Virtual TLS Interim Meeting 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: Sat, 04 Apr 2020 14:37:00 -0000 On Fri, Apr 3, 2020, at 12:50 PM, Stephen Farrell wrote: > > Hi Joe, > > Pre-agenda bashing question for chairs and authors of > the ESNI/ECHO draft... > > I'd like to try again to suggest simplifications for > ECHOConfig (e.g. no extensions, just one public key > per RR VALUE etc.) and perhaps also some more rules > constraining inner/outer CH variances. > > How would you prefer those be raised? As issues in GH > or threads on the list and would you rather I try group > 'em as much as possible or make each issue as fine-grained > as possible? Fine-grained issues on GitHub would be my preference! Thanks in advance for filing them. > Optimistically, this meeting might be the one where we > mostly tie this stuff down, so I hope it's ok that some > of these issues have been raised before in one form or > another. The move from ESNI->ECHO and to HTTPSSVC and > the goal to get to WGLC I think justifies re-checking > if we really need the current level of (what I claim is > too much:-) complexity in ECHO. Hmm... the issues you note above seem somewhat orthogonal to these two changes. The ESNI->ECHO change doesn't seem to affect ECHOConfig contents or extensibility. (We effectively renamed the struct while making the change.) Similarly, HTTPSSVC has more or less the same extensibility properties as the old ESNI RR. That said, I think if there's new data or information that suggests we collectively made poor design decisions, raising them would be helpful. I'll leave it to Sean and Joe to determine whether or not re-hashing some of these issues is appropriate. Rules around inner/outer CH variance are ripe for discussion, though! Best, Chris (no hat) From nobody Sat Apr 4 08:22:10 2020 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 8A2BC3A0EB7 for ; Sat, 4 Apr 2020 08:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=cs.tcd.ie 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 SkoRDK1r-fOm for ; Sat, 4 Apr 2020 08:22:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C5D3A0EC0 for ; Sat, 4 Apr 2020 08:22:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 28DCCBE2E; Sat, 4 Apr 2020 16:22:01 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BScPOD9PS1Fw; Sat, 4 Apr 2020 16:21:59 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 823BCBE20; Sat, 4 Apr 2020 16:21:59 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1586013719; bh=ZL9evbZdNAHfr5+eUj35S+Wb8B/3oXlMGm1G4qcyc60=; h=Subject:To:References:From:Date:In-Reply-To:From; b=xJ36PnZkTl2M0korE4oLlXNCfPNnSXdt1slKUB9zcSCpK66k05BolN9Aa8v5xuIA5 fK6tSekzFog+aQLQ4IJzTwG0WUwSR3eoKVoGDI/oSG2mcPLzDyi909/2ZvfgPtIHMu p6Ll/iZxdtm2yWXhSX/dMLpHjwMsPfgOA5Uba59A= To: Christopher Wood , "TLS@ietf.org" References: <1ee2c071-12c4-4717-b43e-a5d246f86058@www.fastmail.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Sat, 4 Apr 2020 16:21:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <1ee2c071-12c4-4717-b43e-a5d246f86058@www.fastmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1TpOGoJtUNKQ4LI31o2a4yR00APJUJd3e" Archived-At: Subject: Re: [TLS] Virtual TLS Interim Meeting 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: Sat, 04 Apr 2020 15:22:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1TpOGoJtUNKQ4LI31o2a4yR00APJUJd3e Content-Type: multipart/mixed; boundary="WCOJDOhIeNsQezoRZzzOkFM7ms6188Mpc"; protected-headers="v1" From: Stephen Farrell To: Christopher Wood , "TLS@ietf.org" Message-ID: Subject: Re: [TLS] Virtual TLS Interim Meeting References: <1ee2c071-12c4-4717-b43e-a5d246f86058@www.fastmail.com> In-Reply-To: <1ee2c071-12c4-4717-b43e-a5d246f86058@www.fastmail.com> --WCOJDOhIeNsQezoRZzzOkFM7ms6188Mpc Content-Type: multipart/mixed; boundary="------------52C80504E942F11046117CB7" Content-Language: en-US This is a multi-part message in MIME format. --------------52C80504E942F11046117CB7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Ack wrt fine-grained issues. If nobody says otherwise I'll do that. On 04/04/2020 15:36, Christopher Wood wrote: > I'll leave it to Sean and Joe to determine whether or not re-hashing > some of these issues is appropriate. Yeah, I figured asking would be best. For a bunch of these issues, there were mail threads that were (I think, but I'm biased:-) inconclusive. So in one sense no harm to bottom out on 'em, but I don't wanna rehash if the chairs figure things are settled enough. How about: I'll create GH issues, but I'll not whine if, as chairs, you decide to just zap some of 'em as repetitive? Cheers, S. --------------52C80504E942F11046117CB7 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------52C80504E942F11046117CB7-- --WCOJDOhIeNsQezoRZzzOkFM7ms6188Mpc-- --1TpOGoJtUNKQ4LI31o2a4yR00APJUJd3e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6IphYACgkQWrL68XsX K+p89Q//RObLBN7+GZiPOYdIkOZmzE54omZlpGUtqfVsHE5LqUU8LoUFBwcqpQt6 KpRpPbVpa+g0qgTuU0Gi6EtCf16HPj1TS81sHhV3Z6FSgq4yjfvWdlo6O9vd9QPm tHjt3ZJk9+u48FlsM1ovBWCMqV9uriZThSVdQQEzVwL8rg80xrkFVQi+94/85ahT EVksrtXfjFC/ekKRqvmJVgKQcPtKf0gKigZPtkaYfaP4RnwZ+lHL5lbqxUuQQnv6 XRwiGp2K9a6Txy+rQoIF6eqlBoU9QnC7BR1K6j1vB6jtkmHOI9gCzOyRv5CkYXv/ ot8YEERpWgCSj3G0PSDUgHI591OrINmjZ5i4dbRELcpgMrxvHdzvtSiaXtQNc2tl TZWN+KMShfFog0yPRjv4gjfaviLYhTanxQinyun2U4Km1eqyy5juk/Om6NIU5Uvk eU0A4kG482tVSdeKbKbNz2VhzeMdn1+pCdaEfezpHUj7PQzCon11Lh352O96qx1G 2x8qLouEapppuamcBZrYgWtXTSghIqvGhynMu86S3AunGUauz50LmORL9IfrHuuW kXlO++ZyTPEXwotcWK2FexWN/Fgl2Vqorwl/IuU6sw1bUdHkOPqlmTqpsy1WtKc3 4FcMUzL7fm9pvYSO6J3+N6yYLmLQbRkqostFIwWoAq4bJqG1PDY= =DW40 -----END PGP SIGNATURE----- --1TpOGoJtUNKQ4LI31o2a4yR00APJUJd3e-- From nobody Sun Apr 5 00:32:32 2020 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 B62283A1609 for ; Sun, 5 Apr 2020 00:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=DqL0P/4X; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NMz0Gk8b 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 sfeAYc4RJ5-h for ; Sun, 5 Apr 2020 00:32:21 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209613A15E9 for ; Sun, 5 Apr 2020 00:32:20 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4B1CE5C01A4 for ; Sun, 5 Apr 2020 03:32:20 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 05 Apr 2020 03:32:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=ulm0fTkHL6li9PCXW0ajrBhGiA13OgFUzeMppb7Tqew=; b=DqL0P/4X XzNovlfYjRdcLgIPP/sLnmiFUnDQ2jJJfUuU2/3vqgza8mgHzlSUL+7ixu83zxaI f0WcaUi7G6n3Ii1PC79qwv9LeE71jyeF4fFyKhAC3vR6YAqmC9whejGtBVzne4vs OkmzMGMaf4guHNxxOCPT+/OfzdjbXKpvwlmJu/Hlw3lBXqFQ2I5PbZ3Z6RpqT6gL H2Vv1hzhlvLuOsIIiqIKmm/J/6unAd2KjyPjLbmri9uL9Mi6xXomOovUESXJvmfR 8zWugGDT245/2Z4MEwCpvOgd/GfYISp4vdri45LQpmLXtv0E4hgS4VS4IxEcsCC8 IapFJRNK0r2zpQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=ulm0fTkHL6li9PCXW0ajrBhGiA13O gFUzeMppb7Tqew=; b=NMz0Gk8beWcZ14XtDwbPEVZ4NaDdhDeleJChNUYj6EMJZ KGBT3ThGkBL6i3PPHEOvbY0aWn3nnCiIyYatqCn/vGM9Xy1AicZRvFuap3zbeLcF iBr5iJjEz7Jr4OtaxhjTLZt/u87u+7plgEMHah5dDvCscO41Oj+OkZF9BVUrP7Ky MAHbvAdqMG/j88h5K+Zo2C3I+q5+CI46FEarHQRy9/Ywujkb8EdcQIudd9iAUtGl M3XIXYzVsEFzkkJfbqJOC8O9QD+ZgsEH57xtCcfWfMxn/DDBajxvwXnLmN3gb0X7 5rZu7fxceDVeTBNRc2wVpA8qPVV5JDMI8KSlEg4dA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddtgddvgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecukfhppeehvddrudejjedrhedrheenucevlhhushhtvghrufhi iigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhiesmh hnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [52.177.5.5]) by mail.messagingengine.com (Postfix) with ESMTPA id 0163A306D1E1 for ; Sun, 5 Apr 2020 03:32:19 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3799664347446800443==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: tls@ietf.org Message-Id: <20200405073220.0163A306D1E1@mailuser.nyi.internal> Date: Sun, 5 Apr 2020 03:32:19 -0400 (EDT) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) 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: Sun, 05 Apr 2020 07:32:30 -0000 --===============3799664347446800443== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/dtls13-spec (+0/-0/=F0=9F=92=AC1) 1 issues received 1 new comments: - #128 Improve ACK advice (1 by Kxuan) https://github.com/tlswg/dtls13-spec/issues/128=20 Pull requests ------------- * tlswg/draft-ietf-tls-esni (+0/-0/=F0=9F=92=AC4) 1 pull requests received 4 new comments: - #209 padding scheme text (4 by chris-wood, sayrer, sftcd) https://github.com/tlswg/draft-ietf-tls-esni/pull/209=20 * tlswg/dtls13-spec (+12/-0/=F0=9F=92=AC4) 12 pull requests submitted: - Providing an informational design rational for the ACK message (by hann= estschofenig) https://github.com/tlswg/dtls13-spec/pull/140=20 - Clarify when to ACK and what to ACK (by hanno-arm) https://github.com/tlswg/dtls13-spec/pull/139=20 - Allow ACKing non-terminal complete flights if response takes time (by h= anno-arm) https://github.com/tlswg/dtls13-spec/pull/138=20 - Describe duplication of state machines for post-handshake messages (by = hanno-arm) https://github.com/tlswg/dtls13-spec/pull/137=20 - Remove SENDING->FINISHED transition in state machine (by hanno-arm) https://github.com/tlswg/dtls13-spec/pull/136=20 - KeyUpdate Clarification (by hannestschofenig) https://github.com/tlswg/dtls13-spec/pull/135=20 - Draft -37 changes not uploaded to repo (?) (by hannestschofenig) https://github.com/tlswg/dtls13-spec/pull/134=20 - Indicate to remove Working Group Info Section (by hannestschofenig) https://github.com/tlswg/dtls13-spec/pull/133=20 - Adding Acknowledgements Section (by hannestschofenig) https://github.com/tlswg/dtls13-spec/pull/132=20 - Nits and wording improvements. (by hannestschofenig) https://github.com/tlswg/dtls13-spec/pull/131=20 - Update to Figure 1 (by hannestschofenig) https://github.com/tlswg/dtls13-spec/pull/130=20 - Removed term "deprotection" (by hannestschofenig) https://github.com/tlswg/dtls13-spec/pull/129=20 3 pull requests received 4 new comments: - #139 Clarify when to ACK and what to ACK (1 by thomas-fossati) https://github.com/tlswg/dtls13-spec/pull/139=20 - #137 Describe duplication of state machines for post-handshake messages= (1 by hanno-arm) https://github.com/tlswg/dtls13-spec/pull/137=20 - #129 Removed term "deprotection" (2 by ekr, hannestschofenig) https://github.com/tlswg/dtls13-spec/pull/129=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============3799664347446800443== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday April 05, 2020

Issues

tlswg/dtls13-spec (+0/-0/=F0=9F=92=AC1)

1 issues received 1 new comments:

Pull requests

tlswg/draft-ietf-tls-esni (+0/-0/=F0=9F=92=AC4)

1 pull requests received 4 new comments:

tlswg/dtls13-spec (+12/-0/=F0=9F=92=AC4)

12 pull requests submitted:

3 pull requests received 4 new comments:

Repositories tracked by this digest:

--===============3799664347446800443==-- From nobody Sun Apr 5 18:49:29 2020 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 6CC533A0B35 for ; Sun, 5 Apr 2020 18:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=lmo/XV7l; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fHNjUm5L 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 XXSbwXREHgYy for ; Sun, 5 Apr 2020 18:49:22 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB9E3A0B33 for ; Sun, 5 Apr 2020 18:49:22 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id B7B775C00B1 for ; Sun, 5 Apr 2020 21:49:21 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Sun, 05 Apr 2020 21:49:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=DORJq9ETdcsxaJYmKD7DQOrRcxYeFYc eOZUsP3TGPlg=; b=lmo/XV7lb8Wur+iNFWRVZZhfHeVFK/ocnb2n613BhiQlP2D q3ZR0IIW0zezpnBvsKnPoMZxT567ZEeUptD+e3ycz2hQtOtdz7x7sx1bxDE4c6SA Ac9wiEiIannT6x1hKiED42haWfwt9IYyzEY26hzJPouESN7tMGiMbC1lBbNhqLtk bNknw65SG4tOGDW7WVbLZ/Hrr+DP/ltSLlpzWn3SrasaYh3Y5V/NfuN+8uC+3dGK ir90/8WsQ2jJe+JnPMyeRw9FPcJfhewZVCIwiY/78DwyDsGK/++R2SQmPyG5EhoT F7DIe6RcJSiITOCfK5d+OcTtJiNHPHGSrbq/Aqg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=DORJq9 ETdcsxaJYmKD7DQOrRcxYeFYceOZUsP3TGPlg=; b=fHNjUm5LJ2mMpXsgXlBqeb +eiD8E3Oxa7JQqoW0RVT9GfMRK024Mku4kl1HBv5hTytcPOb8O11Eq87fK4MT91/ wsOIZXjqpqKtjmB/Wf3IdfJV8aGgOAL7m063GoY72X5Y+7Vvrr3WKvp8t9dP/c2X K749IkxZd1lwFsVWL4WDnRLqoVolP+DMEziUDeL+IvX31PBVSGgMsFHr+X1x/SCa gfIEpyc3xKCL7OabIcJZZFiRjkMNmek+PHudJm0Uvaxpn/NuVrouq0VWHFNsL4xZ JXRP+lyr+Tuju2CKig/+ukLt879C29h561IRHY3Ujx8v8kJ60nEafRp1CJONQ3lQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedruddvgdehvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhht rhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 358C4E00B1; Sun, 5 Apr 2020 21:49:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1082-g13d7805-fmstable-20200403v1 Mime-Version: 1.0 Message-Id: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> In-Reply-To: References: Date: Mon, 06 Apr 2020 11:49:03 +1000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Mon, 06 Apr 2020 01:49:27 -0000 Hi Hanno, I think that you are assuming a lot about how the loss recovery part of the sender is operating here. If you receive ACK { 1, 3 }, then it might be reasonable to assume that 2 got lost, but it seems to me that assuming anything about 4 is premature. As you say, delaying ACKs is a good way to ensure that you capture all incoming data, but it also affects overall latency. The trade-offs are complex. The sender can also make some adjustments, without necessarily adhering to a strict interpretation of the recommendations in the spec. The draft is imprecise about this logic intentionally. It recommends that the sender send missing data, which will likely work, and be fast. For large flights, yes, this will be suboptimal, but we are also assuming that this data is not subject to congestion control limits. If we go to PQ schemes with large amounts of data, then that requires a different set of assumptions. It might also require that implementations take extra steps to avoid the resulting inefficiencies. On Sat, Apr 4, 2020, at 04:00, Hanno Becker wrote: > An additional note: All solutions which retain the paragraph > > Upon receipt > of an ACK for only some messages from a flight, an implementation > SHOULD retransmit the remaining messages or fragments. > and hence trigger retransmission immediately upon receiving a partial ACK, > suffer from the following problem: > > On Low-MTU networks, and looking ahead at the use of Post-Quantum Cryptography, > it might happen that a single ACK is too small to hold the entire list of record > sequence numbers of the flight being ACKed. > > Doing the math in an example: If the maximum plaintext size is, say, 512 Bytes, > then a single ACK can not ACK more than 64 Records, each of which contains at > most 512 Bytes of handshake data. Hence, we've got a theoretical max of ~32Kb > flight length we can ACK in a single ACK message. > > While this seems a lot, some PQC schemes go beyond that. For example, > the SPHINCS > signature scheme has 41Kb signature size. > > To avoid this problem, it appears beneficial to go for option 2., that > is, don't > retransmit immediately upon receiving an ACK, but accumulate some ACKs > first. This > allows to split ACKing a very large flight into multiple ACKs. > *From:* TLS on behalf of Hanno Becker > > *Sent:* Friday, April 3, 2020 5:35 PM > *To:* tls@ietf.org > *Subject:* [TLS] Efficiency of ACKing scheme > Hi again, > > The DTLS 1.3 ACKing scheme seems to be quite inefficient as it is written, > and I wonder if the current spec matches the authors' intentions. > > Example: > > Consider a flight broken down as sequence of records 1, 2, .., N. > Assume record 2 gets dropped, while all other records go through > without reordering, corruption or loss; hence, the record sequence > observed on the receiver is 1, 3, 4, ..., N. > > Then, according to the spec, the following SHOULD happen: > > On the receiver-side, we have the following from Section 7.1: > > ``` > 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. Implementations have some discretion about when to > generate ACKs, but it is RECOMMENDED that they do so under two > circumstances: > * When they receive a message or fragment which is out of order, > either because it is not the next expected message or because it > is not the next piece of the current message. > ``` > > So, when the receiver receives records 1 and 3, it notices that 2 is missing > and immediately sends an ACK for { 1, 3 }. > > On the sender-side, we have the following from Section 7.2: > > ``` > 7.2. Receiving ACKs > When an implementation receives an ACK, it SHOULD record that the > messages or message fragments sent in the records being ACKed were > received and omit them from any future retransmissions. Upon receipt > of an ACK for only some messages from a flight, an implementation > SHOULD retransmit the remaining messages or fragments. > ``` > > So, when the receiver receives the ACK for { 1, 3 }, it resends records > 2, 4, 5, .., N. > > That's obviously not optimal, and probably not what was intended, but what > unambiguously appears to be the recommended behavior according to the spec. > > How should this be resolved? > > I see two similar and comparably unintrusive options: > > 1) Send ACKs only after period of inactivity > > Instead of sending ACKs straight away when something hints at > something going wrong (such as an out-of-order receipt), as > currently stated in Section 7.1, only send ACKs after a period > of time where no further messages has been received. > > That is, replace the current version > > ``` > 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. Implementations have some discretion about when to > generate ACKs, but it is RECOMMENDED that they do so under two > circumstances: > * When they receive a message or fragment which is out of order, > either because it is not the next expected message or because it > is not the next piece of the current message. Implementations > MUST NOT send ACKs for handshake messages which they discard as > out-of-order, because otherwise those messages will not be > retransmitted. > * When they have received part of a flight and do not immediately > receive the rest of the flight (which may be in the same UDP > datagram). A reasonable approach here is to set a timer for 1/4 > the current retransmit timer value when the first record in the > flight is received and then send an ACK when that timer expires. > In addition, implementations MUST send ACKs upon receiving all of any > flight which they do not respond to with their own messages. > ``` > > by something along the following lines: > > ``` > As long as implementation has received some but not all of the next incoming > flight, it SHOULD send an ACK message after an implementation-defined period > a time during which no further messages are received. A reasonable approach > here is to reset a timer to 1/4 the current retransmission timer with every > record received in the current flight, and send an ACK when that timer expires. > ``` > > In the above example, this would mean that as long as records > 3,4,...,N arrive > in close succession, it will only once send an ACK for {1,3,4,...,N} > in the end, > triggering retransmission of record 2 only, which is optimal. > > The drawback of this is that the receiver of a flight does not inform > a peer > about a gap in a flight as soon as it notices it. For this to work, > the content > of an ACK would need to be what's missing instead of what's present, > which > appears to be a too intrusive change to be considered at this stage.. > The > benefit of this approach is that it leads to very good retransmission > bandwidth. > > 2. Essentially same as option 1., but 'mirrored': Allow the receiver of > a flight > to send ACKs recurringly (though preferably still bunched, i.e. using > some timer > for the bunching), and replace the part of Section 7.2: > > ``` > 7.2. Receiving ACKs > When an implementation receives an ACK, it SHOULD record that the > messages or message fragments sent in the records being ACKed were > received and omit them from any future retransmissions. Upon receipt > of an ACK for only some messages from a flight, an implementation > SHOULD retransmit the remaining messages or fragments. > ``` > > by something along the lines of > > ``` > 7.2. Receiving ACKs > If an implementation receives an ACK for parts of a flight, but doesn't > immediately receive ACKs for the rest of the flight, it SHOULD retransmit > the messages that have not been ACKed. A reasonable approach here is to > reset a timer to 1/4 the current retransmission timer with every ACK record > received, and retransmit the last outgoing flight when that timer expires. > ``` > > Let me know what you think and which option (if not a completely different one) > you'd prefer. > > 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. > 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 > From nobody Mon Apr 6 04:02:10 2020 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 602C23A0E62 for ; Mon, 6 Apr 2020 04:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-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=2a6+UmMV; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=2a6+UmMV 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 hJvVn0Zl74a8 for ; Mon, 6 Apr 2020 04:02:06 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80053.outbound.protection.outlook.com [40.107.8.53]) (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 E1F913A0F80 for ; Mon, 6 Apr 2020 04:01:48 -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=N0leA3yCtAJuV68NDWADXd5aAKObG0TeifCpDc24NK0=; b=2a6+UmMVrnJ0MSiUONDxcnZYLJoRo38qWh741XlOHszbVXlj9mwTZtv1PDlINh3YqWoUAGuX6ThHSLbaDItoex/nq5XtNMWXTiACS8u87XReZ/ohaI3aztz/5nnvxJN2MLDPaG0LCilsJXMOO/Usfs7RvoCweT0AopMKM5GyrRE= Received: from AM5P194CA0014.EURP194.PROD.OUTLOOK.COM (2603:10a6:203:8f::24) by VI1PR08MB3005.eurprd08.prod.outlook.com (2603:10a6:803:44::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Mon, 6 Apr 2020 11:01:46 +0000 Received: from VE1EUR03FT003.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:8f:cafe::69) by AM5P194CA0014.outlook.office365.com (2603:10a6:203:8f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19 via Frontend Transport; Mon, 6 Apr 2020 11:01:46 +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 VE1EUR03FT003.mail.protection.outlook.com (10.152.18.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Mon, 6 Apr 2020 11:01:45 +0000 Received: ("Tessian outbound 4b84da486446:v50"); Mon, 06 Apr 2020 11:01:45 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 87a1952992f2990d X-CR-MTA-TID: 64aa7808 Received: from 039768e03302.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 6DBC0E12-0806-40A0-9E37-C1768BD7C921.1; Mon, 06 Apr 2020 11:01:39 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 039768e03302.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 06 Apr 2020 11:01:39 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L4kN+QP0riir4HNpPp8EmSOpqMNEgyPE5StpkrDUCD1AhS0r48myIwVlrdvTLNRLxbASG/dOPBjRI8PEisUx5SVbliQXIaqSZOPZYLx7ljAQ78kMCqhLcW/eRygfXNMrPqRNkkn80JZeEQpCXjYERWadIgD65rTnyLt0kyRtZJZZh4jGALeu05Et0rYxe3EFxj6KBVcaVCpfBK2oeEgDcEGhsp8ojeBdfvjkO5LQPMOarTKQ+9qZVVlVIyjoGq/emO6hLWQ14XjCXPhpY4Kqc2Zij0TWx/oMNfOduMWhyfYp2QLEcwxZDX3LpnNnPt6dMbK8NR3rHNJZVwyi+E/fTg== 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=N0leA3yCtAJuV68NDWADXd5aAKObG0TeifCpDc24NK0=; b=GUh2no6vyvfIAOx8IdT4tZinyD9ila1p6Eo0QLA18O1feKVX1kYbtRTyIaCma//QbcCEclIz1rsnpf7vlp6lDV0sVpiPuVqmqd8kpW8QNjYt9ITvyLyXi9beDXtk6/Wcl4hCsN+Jpf8lJQUBqt8yRb09liwYMwuQIaD3Sn+XCHV32Wd2CA4LMbdMQ8YnA6FF7/z7/HMUZyk3WEYvVYlY7HDu/q8WlYjTx344Rq+sn7InSPnCLffMli6mnlVP4bwBSvxWUVibLAF50TCdwnfzjzxhj91UbQhQzPEtgEPpx7s8Ll1qA4zZssvEjABn7aMN/fI+olBAalk7yAIjXfXm5Q== 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=N0leA3yCtAJuV68NDWADXd5aAKObG0TeifCpDc24NK0=; b=2a6+UmMVrnJ0MSiUONDxcnZYLJoRo38qWh741XlOHszbVXlj9mwTZtv1PDlINh3YqWoUAGuX6ThHSLbaDItoex/nq5XtNMWXTiACS8u87XReZ/ohaI3aztz/5nnvxJN2MLDPaG0LCilsJXMOO/Usfs7RvoCweT0AopMKM5GyrRE= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (20.179.18.151) by AM6PR08MB3192.eurprd08.prod.outlook.com (52.135.166.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19; Mon, 6 Apr 2020 11:01:38 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f%7]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 11:01:38 +0000 From: Thomas Fossati To: Martin Thomson , "tls@ietf.org" Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQgAO7OoCAAKsoAA== Date: Mon, 6 Apr 2020 11:01:38 +0000 Message-ID: <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> In-Reply-To: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 552dc490-a0c0-4756-f45a-08d7da19e57d x-ms-traffictypediagnostic: AM6PR08MB3192:|AM6PR08MB3192:|VI1PR08MB3005: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:2276;OLM:4125; x-forefront-prvs: 0365C0E14B X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(366004)(136003)(396003)(39860400002)(376002)(346002)(478600001)(8936002)(33656002)(71200400001)(36756003)(76116006)(66946007)(81166006)(64756008)(110136005)(66556008)(8676002)(26005)(91956017)(81156014)(186003)(53546011)(66446008)(316002)(86362001)(6512007)(2906002)(2616005)(6486002)(4326008)(5660300002)(6506007)(66476007); 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: zUNx7YdJUjgZWV/nFAQYgqho+qsDE+iSlpthUxRx0IMJ7LD4VOihrDUXet9AugDz36uEAlOiScOEPwL9GulnjTXWmOsKufUxCppSBQt9Wd5Rq7mOG6HlkbA9J6+M1z6Zd5YyGPtiQpl8sXrvwW9PCBFrG74sqsDBzOLZ8unO4nmTe6to/wYB5C7oz/8v5uwqxvk2spV9ReSeILwCzvxYXAOkql0Q0NTY4q+oOqJcgW7werrXCt1qWbySfmw8bBOouG2coeec+J4nDzZ0myu3WJlYbdxBkTsieUhNQCvFX3pZsU8E7k91Dnm/N51D/byVZl7ZEmG+7qMXbA5Lu6eR/RwHgPpP84Q6mn14uH6grj8YHXTTB4QaFXwL3+0QvboyX5g5j5pY5bz9cwiwoNo7AmhtWbq5+z3ApkLXzO9OGkNqEcPBP7eBybcd7oimuOgv x-ms-exchange-antispam-messagedata: WDgZNKK1XSKsgkzsCd9IWUdZ0XtfXlWcWrd5Xx+cesP3MOYA38ffGY93FBbvsb8l5Aa2I03zmCoKw8nK2j13hePxcuETywRjG/hStrVXPx7BXIbzwykziVx5cCSB7tS5N5uYaa94/E5sW2qrHEOonw== Content-Type: text/plain; charset="utf-8" Content-ID: <742D8A8C2AE16A448EF541042E3630FB@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3192 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT003.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)(136003)(376002)(39860400002)(346002)(396003)(46966005)(8676002)(82740400003)(26826003)(5660300002)(26005)(86362001)(36906005)(186003)(110136005)(33656002)(81156014)(47076004)(478600001)(6506007)(6512007)(70206006)(70586007)(2906002)(316002)(81166006)(356004)(2616005)(36756003)(6486002)(8936002)(53546011)(336012)(4326008); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 86edbb11-aff7-4365-d4ed-08d7da19e16e X-Forefront-PRVS: 0365C0E14B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: I6WGe/VG/u3tR8Orf8XQgUImEZRP5eX5RrbkDt/DsKECivURmBpOJiOLA4QKR3omXxkppst3M5klywyYhmKnRL4/O7daP2iqTCOzT00uj4P17pkoa7WJn5jdvNLOIHy5AwcIx3oPZs3kq0CZp2QtbWMWuidJ9DQTVcXru3G6PmzgYGSGIwg+e8qBPhQSAVU7bc805c62gHk/rIcCc59FbW5LtsWkfc246pNDNW4Ru1soATTi2wU6biLNBx1pylQAn9nMFwHpkeJZheVH1esMhLi6QFy+Hq1cmbyQwjdKhhUJPOHwvG2rf3WEIVC5EHjZtkOh15BGrgK7DTMp0qf5aSLobiI26UpNZf3Dg9IJvhxVAERx4NZZHhLFELyLne3E12H7MvQBfZ+aKIAF9hRBA5xN4OiXvYEXOI00jaQOU4nOJ4gmxhKFPytTBen8v+PU9ln3mm/M0qFWQSl5tSKvmNLHIt06q5w2kho46TAlUVd3UqGXKgsv7ywmW566fpKswh/hCXjjRwO/+KFKRhkEHw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 11:01:45.4478 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 552dc490-a0c0-4756-f45a-08d7da19e57d 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: VI1PR08MB3005 Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Mon, 06 Apr 2020 11:02:09 -0000 T24gMDYvMDQvMjAyMCwgMDI6NDksIE1hcnRpbiBUaG9tc29uIDxtdEBsb3dlbnRyb3B5Lm5ldD4g d3JvdGU6DQo+IEkgdGhpbmsgdGhhdCB5b3UgYXJlIGFzc3VtaW5nIGEgbG90IGFib3V0IGhvdyB0 aGUgbG9zcyByZWNvdmVyeSBwYXJ0DQo+IG9mIHRoZSBzZW5kZXIgaXMgb3BlcmF0aW5nIGhlcmUu DQo+DQo+IElmIHlvdSByZWNlaXZlIEFDSyB7IDEsIDMgfSwgdGhlbiBpdCBtaWdodCBiZSByZWFz b25hYmxlIHRvIGFzc3VtZQ0KPiB0aGF0IDIgZ290IGxvc3QsIGJ1dCBpdCBzZWVtcyB0byBtZSB0 aGF0IGFzc3VtaW5nIGFueXRoaW5nIGFib3V0IDQgaXMNCj4gcHJlbWF0dXJlLg0KDQpUaGUgc3Bl YyBhcyBjdXJyZW50bHkgd3JpdHRlbiBzYXlzIHRoYXQgdGhlIHNpZ25hbCAiQUNLIHsxLCAzfSIg bWVhbnMNCiJyZXRyYW5zbWl0IHsyLCAoMywgZW5kXX0iOg0KDQogICBVcG9uIHJlY2VpcHQgb2Yg YW4gQUNLIGZvciBvbmx5IHNvbWUgbWVzc2FnZXMgZnJvbSBhIGZsaWdodCwgYW4NCiAgIGltcGxl bWVudGF0aW9uIFNIT1VMRCByZXRyYW5zbWl0IHRoZSByZW1haW5pbmcgbWVzc2FnZXMgb3INCiAg IGZyYWdtZW50cy4NCg0KVGhpcyB3b3JrcyBhcyBleHBlY3RlZCBvbmx5IGlmIHRoZSBzZW5kZXIg Y2FuIGFzc3VtZSB0aGF0IHRoZSByZWNlaXZlcg0KaGFzIGxldCBlbm91Z2ggdGltZSBwYXNzIGJl Zm9yZSBnZW5lcmF0aW5nIEFDSyB7MSwgM30sIGJ1dCB0aGlzIGlzIG5vdA0Kc3Ryb25nbHkgc3Rh dGVkIGluIHRoZSBkZXNjcmlwdGlvbiBvZiByZWNlaXZlciBiZWhhdmlvdXIuDQoNCldlIHNob3Vs ZCBrZWVwIGluIG1pbmQgdGhhdCBEVExTIGltcGxlbWVudGVycyBhcmUgbm90IG5lY2Vzc2FyaWx5 DQp0cmFuc3BvcnQgZXhwZXJ0cywgYW5kIHRoYXQgd2FycmFudHMgYSBiaXQgbW9yZSBjYXJlIGlu IHdoYXQgd2Ugc2F5IGFzDQp3ZWxsIGFzIHdoYXQgd2UgZG9uJ3Qgc2F5LiAgSW4gcGFydGljdWxh ciwgd2Ugc2hvdWxkIHRyeSBoYXJkIHRvIGF2b2lkDQpleHBlcnQgYmlhcy4NCg0KT25lIGV4YW1w bGUgd2hlcmUgd2UgY2FuIGltcHJvdmU6IHdlIGhhdmUgYSBuaWNlIHNlbnRlbmNlIGFib3V0IGJ1 bmNoaW5nDQpBQ0tzIGF0IDI1JSBvZiBjdXJyZW50IFJUTyBoYWxmd2F5IHRocm91Z2ggYnVsbGV0 IDIgb2YgU2VjdGlvbiA3LjEuICBJbg0KZmFjdCwgYXZvaWRpbmcga25lZS1qZXJrIEFDS2luZyBp cyBvbmUgb2YgdGhlIGJhc2ljIHRoaW5ncyB0byB1bmRlcnN0YW5kDQpoZXJlLiAgSW5jaWRlbnRh bGx5LCB0aGlzIGlzIGhvdyBvbmUncyBzb2x2ZXMgSGFubm8ncyBjb251bmRydW0gYWJvdmUNCihh dCBsZWFzdCBpbiBub24tcGF0aG9sb2dpY2FsIGNhc2VzKSBiZWNhdXNlICJyZXRyYW5zbWl0IHsy LCAoMywgZW5kXX0iDQp3b3VsZCBiZSBnZW5lcmF0ZWQgd2hlbiB0aGUgcmVjZWl2ZXIgaGFzIGdv dCBzb21lIGNvbmZpZGVuY2UgYWJvdXQgNCAmDQpjby4gYmVpbmcgYWN0dWFsbHkgbG9zdC4gIFVu Zm9ydHVuYXRlbHksIHRoZSBzZW50ZW5jZSBpcyBvZGRseSBwbGFjZWQNCmFuZCBvbmUgdGVuZHMg dG8gb3Zlcmxvb2sgaXQgYW5kIG5vdCBnaXZpbmcgaXQgdGhlIGhpZ2ggYW5kIGdlbmVyYWwNCnJl bGV2YW5jZSBpdCBhY3R1YWxseSBoYXMuDQoNCj4gVGhlIHNlbmRlciBjYW4gYWxzbyBtYWtlIHNv bWUgYWRqdXN0bWVudHMsIHdpdGhvdXQgbmVjZXNzYXJpbHkNCj4gYWRoZXJpbmcgdG8gYSBzdHJp Y3QgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHJlY29tbWVuZGF0aW9ucyBpbiB0aGUNCj4gc3BlYy4N Cg0KQWdyZWUgYWdhaW4sIGJ1dCBkZWNpZGluZyB0byB2aW9sYXRlIGEgU0hPVUxEIHNob3VsZCBi ZSBhbiBleGNlcHRpb24sDQpub3QgdGhlIHJ1bGUuICBJZiBJIGhhdmUgdG8gaW1wbGVtZW50IHRo aXMsIGVzcGVjaWFsbHkgb24gdmVyeQ0KbG93LWJhbmR3aWR0aCBwYXRocyB0aGF0IGZyYWdtZW50 IGEgbG90LCBJIHByb2JhYmx5IHdvdWxkIG5ldmVyIGZvbGxvdw0KdGhlIHJlY29tbWVuZGF0aW9u OiBJJ2QgZmlyc3QgcmUtc2VuZCAzIGFuZCBzaXQgYmFjayBmb3IgYSB3aGlsZSB3YWl0aW5nDQpm b3IgZnVydGhlciBBQ0tzIGJlZm9yZSByZXNlbmRpbmcgKDMsIGVuZF0uDQoNCj4gVGhlIGRyYWZ0 IGlzIGltcHJlY2lzZSBhYm91dCB0aGlzIGxvZ2ljIGludGVudGlvbmFsbHkuICBJdCByZWNvbW1l bmRzDQo+IHRoYXQgdGhlIHNlbmRlciBzZW5kIG1pc3NpbmcgZGF0YSwgd2hpY2ggd2lsbCBsaWtl bHkgd29yaywgYW5kIGJlDQo+IGZhc3QuICBGb3IgbGFyZ2UgZmxpZ2h0cywgeWVzLCB0aGlzIHdp bGwgYmUgc3Vib3B0aW1hbCwgYnV0IHdlIGFyZQ0KPiBhbHNvIGFzc3VtaW5nIHRoYXQgdGhpcyBk YXRhIGlzIG5vdCBzdWJqZWN0IHRvIGNvbmdlc3Rpb24gY29udHJvbA0KPiBsaW1pdHMuDQoNCkp1 c3QgYSBub3RlOiAibGFyZ2UgZmxpZ2h0cyIgaXMgcmVsYXRpdmUgdG8gdGhlIGF2YWlsYWJsZSBi YW5kd2lkdGggc28NCih2ZXJ5KSBsb3ctYmFuZHdpZHRoIHdvdWxkIGFsd2F5cyBoYXZlIHN1Ym9w dGltYWwgcmVjb3ZlcnkgZXZlbiBpZiBIUw0KZGF0YSBpcyBub3QgY29uZ2VzdGlvbiBjb250cm9s bGVkLiAgQW5kIHRoYXQncyB0aGUgZW52aXJvbm1lbnQgd2hlcmUgeW91DQphYnNvbHV0ZWx5IHdh bnQgdG8gaGF2ZSBhIHJlbGlhYmlsaXR5IHNjaGVtZSB0aGF0IGlzIGJhbmR3aWR0aA0KZWZmaWNp ZW50Lg0KDQo+IElmIHdlIGdvIHRvIFBRIHNjaGVtZXMgd2l0aCBsYXJnZSBhbW91bnRzIG9mIGRh dGEsIHRoZW4gdGhhdCByZXF1aXJlcw0KPiBhIGRpZmZlcmVudCBzZXQgb2YgYXNzdW1wdGlvbnMu ICBJdCBtaWdodCBhbHNvIHJlcXVpcmUgdGhhdA0KPiBpbXBsZW1lbnRhdGlvbnMgdGFrZSBleHRy YSBzdGVwcyB0byBhdm9pZCB0aGUgcmVzdWx0aW5nDQo+IGluZWZmaWNpZW5jaWVzLg0KDQpUcnVl IHRoYXQuDQoNCkNoZWVycyENCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0 aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwg b3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91 Lg0K From nobody Mon Apr 6 04:17:45 2020 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 64EF03A0EB8 for ; Mon, 6 Apr 2020 04:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 oZ8o8mzM9P2K for ; Mon, 6 Apr 2020 04:17:42 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C99F3A0EB6 for ; Mon, 6 Apr 2020 04:17:42 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id j69so14203531ila.11 for ; Mon, 06 Apr 2020 04:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LNMta9mAw4PNDqjRHihLkg9M74MFhw1Zgk/WTvumXrc=; b=DTMPg8i4Nny20a43ge0r11QJ3k7dzkoyDaYL4y4vYK2/Fi+IMzqMPt8u3zFMytx6V+ B60pHceK5Ms4fVGLC1dfxlYP/hm6b78r9UY4wrleQMlf+U+9i7SWBpjpJQf3h4yOOBgZ kWCgNbrrOAtz30/lzixH2vBf/DLliz7AXVjscUazTqk6KmtoxhwzQkJot1494t/7O76I NFRgBUOHzWDlKxwqhaLhVCJeK6Y7CYy30voUwW+7QXxGiMRvV2O2d63vvfufqMysdEK6 5yZ9jxIl2F6VaG45s0WdxmwHsj7tCP9fXrPLCc0QXUGL/QJRJFPbP7/MttgtR9Z0R/H8 wigQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LNMta9mAw4PNDqjRHihLkg9M74MFhw1Zgk/WTvumXrc=; b=c3HtB/fW8rpfDlEJXd/6v8rAoz644mNn4OiCgKQXtDqZZ2u9cP709S9MTqyOZu+pgq DfUQIs9q+nkk867W3QO3nb2NNIMmY7E4/MT4BZsmIdKEcILh5lQaCJ/gbVL2S4IvROUI DFZLklJ09HuRPCOxPPQpXFFqmnkMZYsMSOZYnmfGXBS7ynIrJD8kQCdzeO9TMtuixT4M REHD0KLyy7ZFR/YILaOShJE1jqgPIN9NLnRMbxCnC5CrKGEXvaLSM6YvgP4vd42NIibo QDHRzofqAUIwW9R5VPaugMaPhI6+PtdrnDD7dAIYLmA7Cd1jyiYwjspvc9hdCkMzjMAc qgRg== X-Gm-Message-State: AGi0PuaUbhFxn9El+weGMHgGTX+IBR00n3MZ+eS100DxIOKyR+NtzhVv O5fdJtZiUxzzs8CkU94KRBpr7zoqBOGL/SyMjsY= X-Google-Smtp-Source: APiQypIwHXSy4r5/4IbLDB2MQZAHCpe7Glq+vm5l6bDgfuzwROUQ9y5NHuvl4WmxNS9IRr4/hqO2RcWZ9CTV9670QZw= X-Received: by 2002:a92:c910:: with SMTP id t16mr20497994ilp.254.1586171861427; Mon, 06 Apr 2020 04:17:41 -0700 (PDT) MIME-Version: 1.0 References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> In-Reply-To: <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> From: Rob Sayre Date: Mon, 6 Apr 2020 04:17:28 -0700 Message-ID: To: Thomas Fossati Cc: Martin Thomson , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005a6d7305a29d6ab5" Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Mon, 06 Apr 2020 11:17:44 -0000 --0000000000005a6d7305a29d6ab5 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 6, 2020 at 4:02 AM Thomas Fossati wrote: > > We should keep in mind that DTLS implementers are not necessarily > transport experts, > Well, so-called "transport experts" have made many mistakes in the past. Are there decisions here that will be difficult to reverse? thanks, Rob --0000000000005a6d7305a29d6ab5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
--0000000000005a6d7305a29d6ab5-- From nobody Mon Apr 6 04:19:32 2020 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 97D373A0EDC for ; Mon, 6 Apr 2020 04:19:29 -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=2S5Jc/bV; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=2S5Jc/bV 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 PzBYp_xFbJTV for ; Mon, 6 Apr 2020 04:19:26 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30085.outbound.protection.outlook.com [40.107.3.85]) (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 99C863A0EDE for ; Mon, 6 Apr 2020 04:19:25 -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=TAxw/tvhUpA+5tGfvTROtEZTI8kOXstLkcLs01X2d4U=; b=2S5Jc/bV3kg0pHlO1i5Oq7JFFxyARpSo4UHIadvENgVghNmxuJ2NTekLOcpd0KYNEz6Y3b4unxSW6prgNXvRdhPZc1oBVkg7NTV5bmulAYblT91yzNALSyLCaXn1plIvpUxbaQz3Kc98L/blcqaLzgE28K/rZVocN9rWzjrL5kk= Received: from DB8PR03CA0032.eurprd03.prod.outlook.com (2603:10a6:10:be::45) by AM6PR08MB4341.eurprd08.prod.outlook.com (2603:10a6:20b:b9::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Mon, 6 Apr 2020 11:19:22 +0000 Received: from DB5EUR03FT041.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:be:cafe::e4) by DB8PR03CA0032.outlook.office365.com (2603:10a6:10:be::45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Mon, 6 Apr 2020 11:19:22 +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 DB5EUR03FT041.mail.protection.outlook.com (10.152.21.4) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Mon, 6 Apr 2020 11:19:22 +0000 Received: ("Tessian outbound 4b84da486446:v50"); Mon, 06 Apr 2020 11:19:22 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 0e530980c0d8b779 X-CR-MTA-TID: 64aa7808 Received: from 02d8de94bb98.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A82F90FA-52B8-4B76-A6C5-B838447362FA.1; Mon, 06 Apr 2020 11:19:17 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 02d8de94bb98.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 06 Apr 2020 11:19:17 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mamw7SgKRZ91aem94uHHmYMl+T4InWyxxYv00l27L5w/No6/98+cOJ8IFrer9qAUXYEfNHABZidSawGiAqRwdz5S13gOkp7Q2Tl8SZARDRxqbvcJAsBTOLtQz36HQimEUJVNFVsBUbVMZIWyK+YTOVnZR6wYwX/E3KvO8PbICvP+RN/Mw1pU7SDd/XSH5oWrcqhYdIycS1YKQ9bZEyaJQ860lJvJYGvSaBN2NfEmigTtz7OANlgpGI+LqwGU0et4yNczV8tPiBHF1uTXP+x4yeAK1UKhJfBZHtRxxhoPTvgSAxriteB9KyMyQuEgjlJ2mef4mhH0gJxc7wckqlURdg== 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=TAxw/tvhUpA+5tGfvTROtEZTI8kOXstLkcLs01X2d4U=; b=Hj6UR6uxE8eP+And/T3PV4t5SLTI9DawBeVnMGAATcfMrw/VqSET0/5k/ZW2w3sG7g7Yqml6peRcQd2icypxREq1rFHoMLYitT52BnFDfbX5qNATCd7rWPGsHoXjzaK12LT8a3OzO2jf0HNwUWRgFEh8q16ymw1C+UfRLgCWkstqWzBnMyFr6XhfCkdB/O5zPbsXLnLVcg/OZ8Wa4CVKWEWY8ZlMwGQbWerk6uEFFG73MCLX2z1bOu5HHYGDeG3Npfv+09dLinfkxFuKwRkd0/Wv6brkogvx/7Kayqv2XvCl7YvoIs6jxt3i7u2up+A1T/BwWXWYb7iO8F5VaVo7vg== 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=TAxw/tvhUpA+5tGfvTROtEZTI8kOXstLkcLs01X2d4U=; b=2S5Jc/bV3kg0pHlO1i5Oq7JFFxyARpSo4UHIadvENgVghNmxuJ2NTekLOcpd0KYNEz6Y3b4unxSW6prgNXvRdhPZc1oBVkg7NTV5bmulAYblT91yzNALSyLCaXn1plIvpUxbaQz3Kc98L/blcqaLzgE28K/rZVocN9rWzjrL5kk= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (52.135.163.143) by AM6PR08MB5031.eurprd08.prod.outlook.com (10.255.123.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Mon, 6 Apr 2020 11:19:15 +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.2878.021; Mon, 6 Apr 2020 11:19:15 +0000 From: Hanno Becker To: Thomas Fossati , Martin Thomson , "tls@ietf.org" Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQgAO7OoCAAKsoAP//8Q2h Date: Mon, 6 Apr 2020 11:19:15 +0000 Message-ID: References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com>, <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> In-Reply-To: <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.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: [2a00:23c5:ee06:1300:652b:aa23:b6e3:8afc] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 2dab4602-d489-4b52-939b-08d7da1c5bc1 x-ms-traffictypediagnostic: AM6PR08MB5031:|AM6PR08MB5031:|AM6PR08MB4341: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:3968;OLM:3968; x-forefront-prvs: 0365C0E14B 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)(39860400002)(346002)(376002)(396003)(366004)(55016002)(33656002)(966005)(478600001)(9686003)(5660300002)(2906002)(53546011)(110136005)(6506007)(316002)(66476007)(66556008)(64756008)(66446008)(52536014)(8676002)(81156014)(71200400001)(186003)(8936002)(81166006)(86362001)(76116006)(7696005)(66946007); 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: CGyvoXGlfKDW0nCKd+C2eel8m9MOqbiiO0NHwYJWQ+7mbkvqkXajIbFIg0PW77GmkrS7aO6GnUJ0LnIF2aoC8cRVsXtn5qzlav2nldfqAksMed7inSdkslu69pIAplE0rCNMEVFoM4cuqMduCGh3yAbWQo7XpxYbmHR5VbC6mYrRzgYy6VkRvrJAVEoZH46YISUw9UvY6ack3/5mwtSgVToFGi5ag6omuUFj/kbFxZzW+mdld93SH4C0ng7autFVWF9gyIh0/vVoTBSNRIaUyqDXAs4HLML+6bEbcVdbdH5i4SWaDu3kS0D7hmQtICg5I+NNI6KmDurW4xZ9/hF/MMvkxUmkfiHuvaxp0WWlzGw4i64L6b1IbfcxEQwJL788g/2l4LbLZ5/VobEDd6cgplU487sy2GuwH1zqjfJNGKb3u3ve0BjT1VSUzlPw5bYOL3Mcr02rxTamFhRtpSVtIVnP8Wktv33qnh7g8PdOlqArp4frTdilRvihoyM4FL1irEb0C/Vrm9fTOkybFVcGVQ== x-ms-exchange-antispam-messagedata: gpRqZd9skPnMvlAcKiUju365zzukTtUcebbupLjVFRbCs1+VDzf2Ox1jcKxNFR+ZBvuMPJWt8TSohfY1mI3Mpgycwl/zd6+R+UWbeBGlXMXfkDu0nVS9WbK5bMmBvMX8i3h4JKboncVKOXTF8XkSS/cSY2YHDVtgmPMMuxjPQDRmm11J6dt1pYml41swJM+gGh5OSqMv7Pjl4ZKkQ1OIYQ== Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3318E464EE47713AF7F481E09BC20AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5031 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT041.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)(39860400002)(346002)(376002)(136003)(46966005)(55016002)(966005)(336012)(478600001)(86362001)(82740400003)(30864003)(110136005)(316002)(33656002)(356004)(7696005)(186003)(5660300002)(9686003)(26826003)(47076004)(26005)(8936002)(6506007)(53546011)(2906002)(52536014)(70586007)(8676002)(81156014)(81166006)(70206006); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 49baf3b9-9d57-44cc-55db-08d7da1c573c X-Forefront-PRVS: 0365C0E14B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: v6wXzKpZpZgAGMKo3AYJLfQd8CwOt01/fBjbD9JzTnrwN9vqQAdOUxL0/kxL3gGUbJtdRdBoAAbbLX/M5x3zZDlEjQBDttCKnYLN3d5ndfpihGIEZ669DUAqSw7LksgHHYgQm9ix5OFFflKJK22Y0b1QOnjxFfLY+le0xTE8+a7MIFANhVmy3lqH6Ke/v2k+l5IvXz8TH/XSuQjr9qcHiONUy26TeSaSkPIT6wylSlRa/Rwde5ey0vBDgVMV7pXL5cHWMqwkOFgd822CGEU3Fr3We7gF89kb2HHx9NcSLHYbB950/K+zc7hSH303DKrXaHq7oEJCzaL/y7H9wGTI3C3voPAUffOGrMIFiX1jN6Qhai1Hn+CUepRS9YH80f6it5NPXbQJ/F2A0c8lPkEbaaoMg+AxjZp/rpKeS+Bqh05/Wy3hWhHnYRx7m9rb1EjnXOiGjwaT+HJCMxwLQZZLYQYE7+k09YUUBFiGTqZO1PV00h24m3ZzNeD0XEprhBgOeW/lswpNjE/H259ggIUBbEcse5csClLBdDtdtAO5VOm7veLVbLNxIutlH4tVZ3fmMUCKw/VOoRbcY/lnFPOxug== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 11:19:22.9476 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2dab4602-d489-4b52-939b-08d7da1c5bc1 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: AM6PR08MB4341 Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Mon, 06 Apr 2020 11:19:30 -0000 --_000_AM6PR08MB3318E464EE47713AF7F481E09BC20AM6PR08MB3318eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey Martin, Thanks a lot for your reply! > I think that you are assuming a lot about how the loss recovery part of t= he sender is operating here My assumptions follow what the spec says SHOULD be done, though - nothing m= ore and nothing less. > If you receive ACK { 1, 3 }, then it might be > reasonable to assume that 2 got lost, but it seems > to me that assuming anything about 4 is premature I agree, but again this is what the spec unambiguously does by saying imple= mentations SHOULD resend the complement of what was ACKed. I think in principle we agree on reasonable measures for improving the ACK = efficiency. However, I disagree with the assessment that the scheme as-desc= ribed provides sufficient efficiency for common uses, since large fragmenta= tion and low MTU networks will be a common characteristic for IoT deploymen= ts, and DTLS 1.3 'out of the box' implementations should suite these, where= by out of the box I mean implementations that do precisely what the spec s= ays they SHOULD do. On first sight, an easy improvement seems to be mentioning/recommending imp= lementations to buffer ACKs for some time, but we have to be careful with t= his since it affects the semantics of ACKs in a major way which may lead to= interoperability issues: If ACKs are buffered on the receiver, they can be= sent recurringly, and also be split. This way, they are no longer 'negativ= e' in the sense that they indicate a disruption, as is the case now. If, in= turn, ACKs are not necessarily buffered but trigger immediate retransmissi= on, implementations should not use them recurringly. Thus, in a nutshell, leaving the question of whether ACKs should be buffere= d or not on the receiver to the implementor, leads to interoperability issu= es. Cheers, Hanno ________________________________ From: TLS on behalf of Thomas Fossati Sent: Monday, April 6, 2020 12:01 PM To: Martin Thomson ; tls@ietf.org Subject: Re: [TLS] Efficiency of ACKing scheme On 06/04/2020, 02:49, Martin Thomson wrote: > I think that you are assuming a lot about how the loss recovery part > of the sender is operating here. > > If you receive ACK { 1, 3 }, then it might be reasonable to assume > that 2 got lost, but it seems to me that assuming anything about 4 is > premature. The spec as currently written says that the signal "ACK {1, 3}" means "retransmit {2, (3, end]}": Upon receipt of an ACK for only some messages from a flight, an implementation SHOULD retransmit the remaining messages or fragments. This works as expected only if the sender can assume that the receiver has let enough time pass before generating ACK {1, 3}, but this is not strongly stated in the description of receiver behaviour. We should keep in mind that DTLS implementers are not necessarily transport experts, and that warrants a bit more care in what we say as well as what we don't say. In particular, we should try hard to avoid expert bias. One example where we can improve: we have a nice sentence about bunching ACKs at 25% of current RTO halfway through bullet 2 of Section 7.1. In fact, avoiding knee-jerk ACKing is one of the basic things to understand here. Incidentally, this is how one's solves Hanno's conundrum above (at least in non-pathological cases) because "retransmit {2, (3, end]}" would be generated when the receiver has got some confidence about 4 & co. being actually lost. Unfortunately, the sentence is oddly placed and one tends to overlook it and not giving it the high and general relevance it actually has. > The sender can also make some adjustments, without necessarily > adhering to a strict interpretation of the recommendations in the > spec. Agree again, but deciding to violate a SHOULD should be an exception, not the rule. If I have to implement this, especially on very low-bandwidth paths that fragment a lot, I probably would never follow the recommendation: I'd first re-send 3 and sit back for a while waiting for further ACKs before resending (3, end]. > The draft is imprecise about this logic intentionally. It recommends > that the sender send missing data, which will likely work, and be > fast. For large flights, yes, this will be suboptimal, but we are > also assuming that this data is not subject to congestion control > limits. Just a note: "large flights" is relative to the available bandwidth so (very) low-bandwidth would always have suboptimal recovery even if HS data is not congestion controlled. And that's the environment where you absolutely want to have a reliability scheme that is bandwidth efficient. > If we go to PQ schemes with large amounts of data, then that requires > a different set of assumptions. It might also require that > implementations take extra steps to avoid the resulting > inefficiencies. True that. Cheers! 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls 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_AM6PR08MB3318E464EE47713AF7F481E09BC20AM6PR08MB3318eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hey Martin,

Thanks a lot for your reply!

> I think that you are assuming a lot about how the loss recovery p= art of the sender is operating here

My assumptions follow what the spec says SHOULD be done, though - noth= ing more and nothing less. 

> If you receive ACK { 1, 3 }, then it might be 
> reasonable to assume that 2 got lost, but it seems
> to me that assuming anything about 4 is premature

I agree, but again this is what the spec unambiguously does by saying = implementations SHOULD resend the complement of what was ACKed.

I think in principle we agree on reasonable measures for improving the= ACK efficiency. However, I disagree with the assessment that the scheme as= -described provides sufficient efficiency for common uses, since large frag= mentation and low MTU networks will be a common characteristic for IoT deployments, and DTLS 1.3 'out of the b= ox' implementations should suite these, where by out of the box I mean impl= ementations that do precisely what the spec says they SHOULD do. 

On first sight, an easy improvement seems to be mentioning/recommendin= g implementations to buffer ACKs for some time, but we have to be careful w= ith this since it affects the semantics of ACKs in a major way which may le= ad to interoperability issues: If ACKs are buffered on the receiver, they can be sent recurringly, and also = be split. This way, they are no longer 'negative' in the sense that they in= dicate a disruption, as is the case now. If, in turn, ACKs are not necessar= ily buffered but trigger immediate retransmission, implementations should not use them recurringly. 

Thus, in a nutshell, leaving the question of whether ACKs should be bu= ffered or not on the receiver to the implementor, leads to interoperability= issues.

Cheers,
Hanno
From: TLS <tls-bounces@i= etf.org> on behalf of Thomas Fossati <Thomas.Fossati@arm.com>
Sent: Monday, April 6, 2020 12:01 PM
To: Martin Thomson <mt@lowentropy.net>; tls@ietf.org <tls@i= etf.org>
Subject: Re: [TLS] Efficiency of ACKing scheme
 
On 06/04/2020, 02:49, Martin Thomson <mt@lowent= ropy.net> wrote:
> I think that you are assuming a lot about how the loss recovery part > of the sender is operating here.
>
> If you receive ACK { 1, 3 }, then it might be reasonable to assume
> that 2 got lost, but it seems to me that assuming anything about 4 is<= br> > premature.

The spec as currently written says that the signal "ACK {1, 3}" m= eans
"retransmit {2, (3, end]}":

   Upon receipt of an ACK for only some messages from a flight, a= n
   implementation SHOULD retransmit the remaining messages or
   fragments.

This works as expected only if the sender can assume that the receiver
has let enough time pass before generating ACK {1, 3}, but this is not
strongly stated in the description of receiver behaviour.

We should keep in mind that DTLS implementers are not necessarily
transport experts, and that warrants a bit more care in what we say as
well as what we don't say.  In particular, we should try hard to avoid=
expert bias.

One example where we can improve: we have a nice sentence about bunching ACKs at 25% of current RTO halfway through bullet 2 of Section 7.1.  I= n
fact, avoiding knee-jerk ACKing is one of the basic things to understand here.  Incidentally, this is how one's solves Hanno's conundrum above<= br> (at least in non-pathological cases) because "retransmit {2, (3, end]}= "
would be generated when the receiver has got some confidence about 4 &<= br> co. being actually lost.  Unfortunately, the sentence is oddly placed<= br> and one tends to overlook it and not giving it the high and general
relevance it actually has.

> The sender can also make some adjustments, without necessarily
> adhering to a strict interpretation of the recommendations in the
> spec.

Agree again, but deciding to violate a SHOULD should be an exception,
not the rule.  If I have to implement this, especially on very
low-bandwidth paths that fragment a lot, I probably would never follow
the recommendation: I'd first re-send 3 and sit back for a while waiting for further ACKs before resending (3, end].

> The draft is imprecise about this logic intentionally.  It recomm= ends
> that the sender send missing data, which will likely work, and be
> fast.  For large flights, yes, this will be suboptimal, but we ar= e
> also assuming that this data is not subject to congestion control
> limits.

Just a note: "large flights" is relative to the available bandwid= th so
(very) low-bandwidth would always have suboptimal recovery even if HS
data is not congestion controlled.  And that's the environment where y= ou
absolutely want to have a reliability scheme that is bandwidth
efficient.

> If we go to PQ schemes with large amounts of data, then that requires<= br> > a different set of assumptions.  It might also require that
> implementations take extra steps to avoid the resulting
> inefficiencies.

True that.

Cheers!

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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls
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_AM6PR08MB3318E464EE47713AF7F481E09BC20AM6PR08MB3318eurp_-- From nobody Mon Apr 6 05:03:55 2020 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 E02E13A0FAC for ; Mon, 6 Apr 2020 05:03:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-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=UMFXpDjT; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=UMFXpDjT 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 EyWb40bomNJN for ; Mon, 6 Apr 2020 05:03:50 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80071.outbound.protection.outlook.com [40.107.8.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 A353C3A0FA7 for ; Mon, 6 Apr 2020 05:03:49 -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=RNVvV94HzsGbt+CLtfVCpSwdlwFg4SI5RmPsn/vKueM=; b=UMFXpDjTJKFVuQ/GGgyxMnxci8So30IHJApnWBhElrcTAQXsFvVn/sb6p2w2PzPObPdA+YiUGusDEAT0AepzxpAbKqsLYNUuz4VzEl540Cimf2NSYKPhLAvmBYuvUjy7xU1eTaVpRzA5ouXosgtat/hK6zwFBLJTbM6Trr4+uo0= Received: from DB8PR06CA0061.eurprd06.prod.outlook.com (2603:10a6:10:120::35) by VI1PR08MB3006.eurprd08.prod.outlook.com (2603:10a6:803:40::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Mon, 6 Apr 2020 12:03:46 +0000 Received: from DB5EUR03FT004.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:120:cafe::43) by DB8PR06CA0061.outlook.office365.com (2603:10a6:10:120::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15 via Frontend Transport; Mon, 6 Apr 2020 12:03:46 +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 DB5EUR03FT004.mail.protection.outlook.com (10.152.20.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Mon, 6 Apr 2020 12:03:46 +0000 Received: ("Tessian outbound 55454527ea3b:v50"); Mon, 06 Apr 2020 12:03:46 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: d473419f85a2392a X-CR-MTA-TID: 64aa7808 Received: from dc6c6475e4a4.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 0C2878DD-7DA0-4D3E-ACDC-1E8251330FB1.1; Mon, 06 Apr 2020 12:03:41 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id dc6c6475e4a4.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 06 Apr 2020 12:03:41 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Jz/J87KuEeaIF01gcPJMWrZLwguFk6HdU/KbuK/jvS1c47eOhKm0J8RVQz2e43ZBIzT2PEVZTIjOBvQwQfXU3zYdXIR/vgcUMT6zuGcnsWOiAyUCMpgg0WFhzlyWEeWxFskWsv0nmBX0OhwzC+2EYSeFwGFwR3wKbqWsd7z/vUhgNTZelJxjb5r8YwMnWjeAYoH0sqo3aSTquYXzGEXsLkhEwnp6VWq0Ofv68gHPhyk3wiZl7DkBKu1NzY8af+Z8X9Eibd9BlT1aAaYfwQWI1vN8q0gFrlte56SidXWyCFVAk1vrXT1slejXCp+f+sJJfj6NXNO298amBfC6odZpIg== 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=RNVvV94HzsGbt+CLtfVCpSwdlwFg4SI5RmPsn/vKueM=; b=JanAZ0pzXIPmi0wix4va1pjol6zbIs0EqZKKok+Tq+VWOqqkHblSpTiWIMWMAY3VpuSNEzTDUC8go/okUuNQnxH0IG/AwcgxdF+zv8zhK8AkB401DD6uSmYjAw8TRaebK+9/X/cs0s6V68Ptm637pdQRBOeELAv24ijcv3DgFa/nPzEKX2fnBUB4bEuQJyfnahfWlEk/zDWyRqWRtuWn5y/bfj8exwcolOWYSGoRxHLk9NsKOlZ7BE8CMVLj7/ONeRft5sNK12L9znnt/+/appTb+G9ZujYKymfLSvWw8c5z8J3aO9gukOd4kc2pzXd6oc7snYMQ9kDWD10WOdPPPA== 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=RNVvV94HzsGbt+CLtfVCpSwdlwFg4SI5RmPsn/vKueM=; b=UMFXpDjTJKFVuQ/GGgyxMnxci8So30IHJApnWBhElrcTAQXsFvVn/sb6p2w2PzPObPdA+YiUGusDEAT0AepzxpAbKqsLYNUuz4VzEl540Cimf2NSYKPhLAvmBYuvUjy7xU1eTaVpRzA5ouXosgtat/hK6zwFBLJTbM6Trr4+uo0= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (20.179.18.151) by AM6PR08MB4037.eurprd08.prod.outlook.com (20.179.1.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.17; Mon, 6 Apr 2020 12:03:39 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f%7]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 12:03:39 +0000 From: Thomas Fossati To: Rob Sayre CC: Martin Thomson , "tls@ietf.org" , Thomas Fossati Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQgAO7OoCAAKsoAP//86kAgAAdq4A= Date: Mon, 6 Apr 2020 12:03:39 +0000 Message-ID: <03849701-1A14-4E1A-8298-D483E74E380C@arm.com> References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 8e8426b3-91c6-4732-382d-08d7da228f7a x-ms-traffictypediagnostic: AM6PR08MB4037:|AM6PR08MB4037:|VI1PR08MB3006: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 0365C0E14B X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(346002)(366004)(376002)(396003)(136003)(81156014)(6512007)(81166006)(4326008)(54906003)(53546011)(6486002)(8936002)(478600001)(316002)(26005)(6506007)(186003)(2906002)(8676002)(33656002)(66556008)(91956017)(64756008)(76116006)(66946007)(66476007)(71200400001)(66446008)(6916009)(86362001)(2616005)(36756003)(5660300002); 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: dZVEsiVdVHGBCDICFMkhjBXq83ssBgR5yy2r0Phs2B+gfwdTJDus3uNQK8WGMkTqvJROUXxqXef6RRFpday7aUL4CNgMxHIqbU0rbmzKoqFEo1KN5lfO11V4uA/ET+evkR2k3k2CI42nEi3Qzy+y9la9p3b85Cqg40JtpGFAbnEA6IP6aM1d4VYh1anvloEx4+zqcPXhJdWkEg5EK0z9Q+R1Rvz8kCjpCLjHAR9ukS8KrYZGvqSWlSObpaVWFMu0TDwMkwipmEvGgZ3KBrILzMc8N0vds6Fw390d288ksnE1oE70bi607on0gGKxnsaozmDksx3KaSN2yPbItIFoX38J81C6JGhKXoBs3y1+9NwBQCqL75kulYtUcmvrOcAI/0Guk1C3hBtFen8c+GaD8+OBUaKovRUfMttSLJmqAGA9r8mxjj1JxsY1EB9SXOWd x-ms-exchange-antispam-messagedata: NSKtnU7oLtm8DRqOP+TSl8PtawwN4dpI1hSg9ZcWkGV471yCIdQ2esArfoSv1fGefmMeivZNL7xFk+75WXEZ9ndRkH4TU+o4z7rWQhFn6vW4BStb/1ENGvfoIEn4orNpYP+/KlmdMd7eyEHvHDLWbA== Content-Type: text/plain; charset="utf-8" Content-ID: <430C6B54653779468CD5FDB72843AC71@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4037 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT004.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)(376002)(136003)(39860400002)(46966005)(8676002)(81166006)(47076004)(26826003)(316002)(6486002)(70206006)(478600001)(86362001)(36756003)(70586007)(81156014)(186003)(26005)(2906002)(5660300002)(33656002)(82740400003)(6862004)(8936002)(53546011)(356004)(336012)(54906003)(2616005)(4326008)(6506007)(6512007); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 19827951-19cc-4fea-9076-08d7da228b74 X-Forefront-PRVS: 0365C0E14B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: XIF9cO/jwXCLA6HAkCjeUvlNSFfxY0PgZV15dC4jOi70y5aMVPH0hy9s/gpmyzmt+Hmrm1PfkEEs3gAqvXfOx/qIU78LD9OQYy41KbZllMIfQaKQBlsonQ22FynIlhWRjE83mW/dTM0sTuSUjrlsXPLEvIyXRC8TqObHKNPS8zes/deGvPQlb23eDn46YCK5HlMY2pBKCWG0ZK8lZgWJiK7LRgZR/uHQenx+XjmooptIUcy6kzhOI06RBCXxDFx4gLBKPzPX07Ukr7C8qJLBxS4YzIw33GeNjLBmJhcqSZYi8IiPBFJ/6zW+VJHvIjG9aesVeCl0ljFbl3tYKWI/QxSfvAstE+JbJgzSRHhZlk77YGtxDCQqXhd6Sera39pzNnb8ERpN1Rm1S2Xxdg60rvjbrjfZPI+CPePiVF8S4jLFaJaS9aoFBxHiQFoHHUePTUKETgxvcgLSBa7Hncjr2kSGQ9BvUt03aR4UxESOdKZUFrKMPLtWtOf0oPxh9W3SppILePnncl0+9tc4OkXNnQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 12:03:46.7039 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8e8426b3-91c6-4732-382d-08d7da228f7a 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: VI1PR08MB3006 Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Mon, 06 Apr 2020 12:03:53 -0000 T24gMDYvMDQvMjAyMCwgMTI6MTcsICJSb2IgU2F5cmUiIDxzYXlyZXJAZ21haWwuY29tPiB3cm90 ZToNCj4gQXJlIHRoZXJlIGRlY2lzaW9ucyBoZXJlIHRoYXQgd2lsbCBiZSBkaWZmaWN1bHQgdG8g cmV2ZXJzZT8NCg0KQXQgYSBmaXJzdCBnbGFuY2UgaXQgZG9lc24ndCBzZWVtIGxpa2VseS4gIFRo ZSBzcGVjIGlzIHF1aXRlIG1hbGxlYWJsZQ0KYW5kIGdpdmVzIGltcGxlbWVudGF0aW9ucyBhIGxv dCBvZiBsZWV3YXkuDQoNClRoYXQgc2FpZCwgYXMgY3VycmVudGx5IHdyaXR0ZW4sIHRoaXMgZG9l c24ndCBzZWVtIHRvIHdvcmsgcGFydGljdWxhcmx5DQp3ZWxsIG9uIHBhdGhzIHRoYXQgYXJlIGxv c3N5LCBzbG93LCBhbmQgd2l0aCBzbWFsbCBNVFVzIChvciBhDQpjb21iaW5hdGlvbiB0aGVyZW9m KSwgd2hpY2ggd2UgbmVlZCB0byBtYWtlIHN1cmUgaXQncyByZWFzb25hYmx5IHdlbGwNCmNvdmVy ZWQgYXMgaXQgaGFwcGVucyB0byBiZSBvbmUgb2Ygb3VyIG1haW4gdXNlIGNhc2VzLg0KDQpJJ20g aW5jbGluZWQgdG8gc2F5IHRoaXMgY291bGQgYmUgc29sdmVkIGJ5IHByb2ZpbGluZyB0aGUgcmVs aWFiaWxpdHkNCnNjaGVtZSBmb3IgY29uc3RyYWluZWQgbmV0d29ya3MgKGluIEktRC50c2Nob2Zl bmlnLXV0YS10bHMxMy1wcm9maWxlKSwNCmJ1dCB0aGVyZSBzdGlsbCB0aGluZ3MgdGhhdCBjYW4g YmUgc2FpZCB3cnQgQUNLIHRpbWluZyBoZXJlIHRoYXQgY2FuDQppbXByb3ZlIGltcGxlbWVudGF0 aW9ucyBpbiB0aGUgZ2VuZXJhbCBjYXNlLCBJIHRoaW5rLg0KDQpDaGVlcnMNCg0KSU1QT1JUQU5U IE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh cmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv biwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRp b24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Mon Apr 6 05:19:16 2020 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 1A56D3A0AE1 for ; Mon, 6 Apr 2020 05:19:15 -0700 (PDT) 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, 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=DwY81iy6; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=DwY81iy6 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 GOFSlNB_iiRY for ; Mon, 6 Apr 2020 05:19:12 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70074.outbound.protection.outlook.com [40.107.7.74]) (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 CDD843A10B9 for ; Mon, 6 Apr 2020 05:18:57 -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=Wh1WLl3R0p0BVDvDlGKhjDTgdufMZKrsJr8kqc/ps1Y=; b=DwY81iy6mRPGuchgeI53mg2y9n8Xsfqs0QqE8q9wrUBqLyS8A9fyxHzUyg8yoNcRC/EIirUcLoiwTfVjKJQQkKPWGjU+ojE0O6hIc+ZvMuySgJOaR+yN3cIsVaLUCRzXUg7SgSkT8hqS9agMaMF1RXL3w+SbZoEsIb8dMovnJhI= Received: from AM6PR04CA0014.eurprd04.prod.outlook.com (2603:10a6:20b:92::27) by AM0PR08MB5122.eurprd08.prod.outlook.com (2603:10a6:208:160::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Mon, 6 Apr 2020 12:18:55 +0000 Received: from VE1EUR03FT004.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:92:cafe::e3) by AM6PR04CA0014.outlook.office365.com (2603:10a6:20b:92::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16 via Frontend Transport; Mon, 6 Apr 2020 12:18:54 +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 VE1EUR03FT004.mail.protection.outlook.com (10.152.18.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Mon, 6 Apr 2020 12:18:54 +0000 Received: ("Tessian outbound e2c88df8bbbe:v50"); Mon, 06 Apr 2020 12:18:54 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: b4f50126357b28c7 X-CR-MTA-TID: 64aa7808 Received: from 4f3b05b0b7d5.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id EC49E8FE-5989-4278-9EA4-DE375638F09F.1; Mon, 06 Apr 2020 12:18:49 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 4f3b05b0b7d5.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 06 Apr 2020 12:18:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VchbvFJrWMoCvpIX9ChgkLEtmkByZ/p2Q2KZxLPa+N9MTQIDWYQf1uS2hZetb5wGA4Lt966dd+EhGJNZf8ybNPhw8opun73QRFeYhJ6x5XddOGnoUGZMN0jH8AKSHTEI2Z00Ep2RJdRibMhlIr8DtD3hQ2r83IQWFtqhgoX/PAPcAUcI1s54Hima0ehyUq3l/muAMudXYQYnErbW+Gb25M3rZM8LVv+5hifIOa1DEhyLeAEt+3V7snMap6lDllLr5BNJA56gtl8A0vo+sHSE3p0ecx94MkHlmRxyGq9GRBX8Ajaj95WEYoN4FYHWNhIwTYrSmbxCUYXv18a1l4pTEA== 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=Wh1WLl3R0p0BVDvDlGKhjDTgdufMZKrsJr8kqc/ps1Y=; b=Z8OpZADzGUzCdxcoITx3Re2+9mUCgX5AfgAgRfXr31mN+27P8Ghn9YzGc9kcq7dER6UNdaqCk44Ati1Jh4f7C3+QRdHl89AIEAV2J8YtPNh5HQJtEf6OgOZVMHmYPKUrlDtJe3/a/zzRHKVyc4JEheUOeAN9kaJzxHXwW7vnY+GaXssaZ6Xln2A09i28njUFWsJjekyvRrKAWZ+ki2NVO5+1uwFMqhC9z58m9qkECZLc+R4RKiTJBxr3Fce7UzRjRVeWPneeQ1XPAzJVNUpPNoW+i0pKQiil70OmYf7ZpQTxQo/OtYokyUmAS+03snfG191/HvVF1xJrgeG+gNaQ2w== 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=Wh1WLl3R0p0BVDvDlGKhjDTgdufMZKrsJr8kqc/ps1Y=; b=DwY81iy6mRPGuchgeI53mg2y9n8Xsfqs0QqE8q9wrUBqLyS8A9fyxHzUyg8yoNcRC/EIirUcLoiwTfVjKJQQkKPWGjU+ojE0O6hIc+ZvMuySgJOaR+yN3cIsVaLUCRzXUg7SgSkT8hqS9agMaMF1RXL3w+SbZoEsIb8dMovnJhI= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (20.179.18.151) by AM6PR08MB2965.eurprd08.prod.outlook.com (52.135.165.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Mon, 6 Apr 2020 12:18:48 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f%7]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 12:18:48 +0000 From: Thomas Fossati To: Hanno Becker , Martin Thomson , "tls@ietf.org" Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQgAO7OoCAAKsoAP//8Q2hgAAkgYA= Date: Mon, 6 Apr 2020 12:18:47 +0000 Message-ID: <36746849-C59B-4037-A8D3-39E4F7DB8658@arm.com> References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 2e01f453-a142-4caf-b6f5-08d7da24acc0 x-ms-traffictypediagnostic: AM6PR08MB2965:|AM6PR08MB2965:|AM0PR08MB5122: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 0365C0E14B X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(396003)(366004)(136003)(346002)(39860400002)(91956017)(8676002)(6512007)(36756003)(76116006)(66946007)(66446008)(64756008)(66556008)(66476007)(316002)(33656002)(478600001)(4326008)(110136005)(6486002)(26005)(8936002)(186003)(5660300002)(2616005)(81166006)(71200400001)(86362001)(81156014)(6506007)(2906002)(53546011); 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: KRzdGP/fHK+3GCsy7MhvXuf9+OCrWVCdB4J6SDUxThUBTTKBNpSDOd1sidnc+mAoC4cazMqU8hH/yleFEJYB7MaU44GbCtGmZ8v7h9wtCBiblIXJB73ASF5hgohOdEebz1WahKcHRhjFvKFqGQk58RDHz/wu1Jz1dYBBPLG2bDjnam5ILHYGvRfbjJs5nhhIOMrmM77WEfAZNGD04U025QrqgQ0BaobG00PSZsnhTJthDHnnl73tyo1h4spi9PSjqN5ErqheDPagDsPyZgCrjIoaVrbRMkLksF+tgTlcLsvp//Ud+tib+fCl8ZQNqXmnQtrQVptwJEa0ys98RE1Xy8mo0rLYJzic1OYVIiJ67Ermor/VCMD3aOW+ybq04Kjkwo0o6C3PeBiIhiN2rOmgQupT78jmvyihpBY5ZBKLOP8yWTJNCrgITdls/S/vuOL1 x-ms-exchange-antispam-messagedata: wwdaueSxOyhNzFUCbY3AGyTnIuY3HBPaj+VkA5Zg3K/jaCtjOy8BD6Pukxmfw9/gc7N9o7yj8+Nmv1Ncy/Ifxgkt6Acniy1spfQ+9sCOQqJp+Uaqgi9zpWPKjvFyqcjSA4TTsc+43ApzFu6qS+5iDA== Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB2965 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT004.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)(136003)(376002)(39860400002)(396003)(346002)(46966005)(478600001)(110136005)(2616005)(47076004)(53546011)(6506007)(186003)(86362001)(316002)(70586007)(36906005)(33656002)(4326008)(82740400003)(70206006)(6512007)(356004)(6486002)(336012)(36756003)(26005)(5660300002)(81166006)(81156014)(26826003)(8936002)(8676002)(2906002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 42b34cda-71d2-410e-739e-08d7da24a8b2 X-Forefront-PRVS: 0365C0E14B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: oYk+o2/e2iEu8yLvFmmnlpO2yxs4HbTkBotMrpYY9nQwQLS8KRFJVlmxChs1gLRuR79jbVssopWNoyRQDd7aBh7BwcCizOEhXMn//ZI/HiWgSt0HfUQmyiZTHudtDraKQOz+vuuEFieigOQc0lR+/Nrki/w7P+ljjdikhr5Y+KPCyaQpH/XQx3Zb5iu47DewORD0veZQbSbcjBDTd/TulNvEHH1e9fKT6UrMr0opgpyEEtyWUsQW62gQzEEreLhHjJJylHydTKB0EcA2sWIV9mVqyCNSVABPP//y7mpkbBkUlMouLGo85cAdwFm0wuVVRwt7ZXaGwIuGkMuS3KCWXhlUAavLSscXDik/t0RnYcyeq3lRtnhR82lejz50379nvG5JCIPNn6IBSb6wmYl2iSmeGXbfb07IxBZoPr09X2662FgqfIjvP+PF+JtUYpbOobsSlsZXD1SMcN01c6MnizEzNRM9T8Qk1KWGsGa2/ml1635aTziac/JAoiPceHK3yJGHxmF6WHXilfVtmhmsJw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 12:18:54.7132 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2e01f453-a142-4caf-b6f5-08d7da24acc0 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: AM0PR08MB5122 Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Mon, 06 Apr 2020 12:19:15 -0000 SGkgSGFubm8sDQoNCk9uIDA2LzA0LzIwMjAsIDEyOjE5LCAiSGFubm8gQmVja2VyIiA8SGFubm8u QmVja2VyQGFybS5jb20+IHdyb3RlOg0KPiBUaHVzLCBpbiBhIG51dHNoZWxsLCBsZWF2aW5nIHRo ZSBxdWVzdGlvbiBvZiB3aGV0aGVyIEFDS3Mgc2hvdWxkIGJlDQo+IGJ1ZmZlcmVkIG9yIG5vdCBv biB0aGUgcmVjZWl2ZXIgdG8gdGhlIGltcGxlbWVudG9yLCBsZWFkcyB0bw0KPiBpbnRlcm9wZXJh YmlsaXR5IGlzc3Vlcy4NCg0KSSdtIG5vdCBzdXJlIHRoaXMgc3RyaWN0bHkgcXVhbGlmaWVzIGFz IGFuIGludGVyb3AgaXNzdWUuDQoNCkF0IGEgc3VidGxlIGxldmVsIGl0IGlzLCBpbiB0aGUgc2Vu c2UgdGhhdCB0aGUgc2lnbmFscyBjb21pbmcgZnJvbSBvbmUNCnNpZGUgZG9uJ3QgdGhlIHNhbWUg ZXhhY3Qgc2VtYW50aWNzIHdoZW4gb2JzZXJ2ZWQgZnJvbSB0aGUgcGVlciBwb2ludCBvZg0Kdmll dywgYnV0IHRoYXQgZG9lc24ndCByZXN1bHQgaW4gYW4gaW50ZXJvcCBwcm9ibGVtIGF0IHRoZSBt YWNybyBsZXZlbC4NCkl0IGRvZXMgbWFrZSB0aGUgcmVsaWFiaWxpdHkgc2NoZW1lIHN1Ym9wdGlt YWwgYW5kIG1heWJlIGV2ZW4gZ3Jvc3NseQ0KaW5lZmZpY2llbnQgaW4gc29tZSBjYXNlcyBhbmQg bWF5IGhhdmUgZGlzcnVwdGl2ZSBwb3RlbnRpYWwgb24gdGhlDQpuZXR3b3JrLCBhZ3JlZWQuICBC dXQgdGhlIG92ZXJhbGwgImxvc3QgaW4gdHJhbnNsYXRpb24iIGVmZmVjdCBkZXBlbmRzDQpncmVh dGx5IG9uIHRoZSByZXNvdXJjZXMgYXZhaWxhYmxlIHRvIHRoZSBlbmRwb2ludHMgYXMgd2VsbCBh cyB0aGUNCm5ldHdvcmsgcGF0aCByYXRoZXIgdGhhbiB0aGUgaW5uZXIgbG9naWNzIG9mIHRoZSBB Q0tpbmcgc2NoZW1lLg0KDQpjaGVlcnMNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRz IG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBt YXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNj bG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVy cG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhh bmsgeW91Lg0K From nobody Mon Apr 6 07:17:11 2020 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 3EA6F3A0593 for ; Mon, 6 Apr 2020 07:17:05 -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=exxsIbZn; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=exxsIbZn 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 1-9hJGwpz_pQ for ; Mon, 6 Apr 2020 07:17:00 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60086.outbound.protection.outlook.com [40.107.6.86]) (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 AAB373A060A for ; Mon, 6 Apr 2020 07:16: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=BeN1TBShU0ZfW8eb/HUrCqVDWPLbICgQvm2RiP7Z9pQ=; b=exxsIbZnYrWrs6WpO7iEBkkubayfNBfIjOw7W48lSt4eyLBdoVexhxkOBdnfcyVSGPPEiiX6APCNy3JkMMlrkaQm/Yy1Pyu8vvadJK4nqUdmzLsXk+ZK5tyDdglCX0nht456HS1Eeeka+4IcJ1K6xv6mmFqpeA/MVvT3qDgm0yA= Received: from DB6PR0402CA0007.eurprd04.prod.outlook.com (2603:10a6:4:91::17) by DB7SPR01MB5.eurprd08.prod.outlook.com (2603:10a6:5:12::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Mon, 6 Apr 2020 14:16:56 +0000 Received: from DB5EUR03FT006.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:91:cafe::3d) by DB6PR0402CA0007.outlook.office365.com (2603:10a6:4:91::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20 via Frontend Transport; Mon, 6 Apr 2020 14:16: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 DB5EUR03FT006.mail.protection.outlook.com (10.152.20.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Mon, 6 Apr 2020 14:16:56 +0000 Received: ("Tessian outbound 4b84da486446:v50"); Mon, 06 Apr 2020 14:16:56 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 66ac854792b5957d X-CR-MTA-TID: 64aa7808 Received: from 6ad1e0e6927d.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id AE675B1F-B9B3-417F-8F3A-4F9BEC551D6F.1; Mon, 06 Apr 2020 14:16:50 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 6ad1e0e6927d.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 06 Apr 2020 14:16:50 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WW89/E9Joc+J/5WzR3IIEz1wc8CVNPvOgEYIyNC8L/Pf2RVBM7dQO3iCL1zjLL9PF3Wgqw9u4ejUUJVo+Rkym/ogY/mlZ2TwIOL7+DmIfqkTAfnEDyOUdTY2XnJrRcnOKRWT91tItHga5MCVOXr3+vdfreWYWt9mZuGmi0rqpM6lKvSH17tzwl3GzY/3QG0nENbLEIpsLsRgEAfbAGQC+kB+AKGDnuu+Iq9rrwpYfUIfFIhB5mT8kMKLstMB9Sfjvvb14co4dv85kVWcwVZBA43MfW9DzOnCJFUZmJJacYlatV0KRPFfGwvGoFuWwREJq1cZ2HpKwO+F+ws+nXF5ug== 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=BeN1TBShU0ZfW8eb/HUrCqVDWPLbICgQvm2RiP7Z9pQ=; b=Dp6zo5OJ6/s8ioc0+5gBZRg1TGcDdU1PZGxVDjjTNmbOTJzhZ4URzo1ApLBtcLdCeqUiirXhfifW+iPaR6xW4xnO5pqRskeWjXZcRX4DT8obY0hXO7ZhyeyAvsTl6YUOXSQlh8t8VwkeQ4Iu9EOV6QkEcZwLjMc3l5vvvRD1LzjUqIkF7HNVctOhXZs12M0nfvwaK1fEu6LyMnIJxJologpcHRKoQ5D6tECq1jUe5QqwyHCSEdbVLTTlLAEu844kWMG/VxmUxszAZZCetb3014k1fE0o3LKWMQRWXHWar0HUi1V4LUjdyWCM/2WkfwVjiFqpFwtBMLkqZKhT3EYyaA== 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=BeN1TBShU0ZfW8eb/HUrCqVDWPLbICgQvm2RiP7Z9pQ=; b=exxsIbZnYrWrs6WpO7iEBkkubayfNBfIjOw7W48lSt4eyLBdoVexhxkOBdnfcyVSGPPEiiX6APCNy3JkMMlrkaQm/Yy1Pyu8vvadJK4nqUdmzLsXk+ZK5tyDdglCX0nht456HS1Eeeka+4IcJ1K6xv6mmFqpeA/MVvT3qDgm0yA= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (52.135.163.143) by AM6PR08MB4850.eurprd08.prod.outlook.com (10.255.22.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Mon, 6 Apr 2020 14:16: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.2878.021; Mon, 6 Apr 2020 14:16:49 +0000 From: Hanno Becker To: Thomas Fossati , Rob Sayre CC: "tls@ietf.org" Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQgAO7OoCAAKsoAP//86kAgAAdq4D///6F3Q== Date: Mon, 6 Apr 2020 14:16:49 +0000 Message-ID: References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> , <03849701-1A14-4E1A-8298-D483E74E380C@arm.com> In-Reply-To: <03849701-1A14-4E1A-8298-D483E74E380C@arm.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: [82.132.243.166] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: d1c8d491-529d-40a8-362f-08d7da3529d0 x-ms-traffictypediagnostic: AM6PR08MB4850:|AM6PR08MB4850:|DB7SPR01MB5: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 0365C0E14B 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)(366004)(396003)(136003)(376002)(346002)(39860400002)(7696005)(66946007)(4326008)(966005)(26005)(52536014)(71200400001)(478600001)(33656002)(76116006)(55016002)(66476007)(316002)(81166006)(6506007)(186003)(9686003)(2906002)(66556008)(81156014)(8676002)(86362001)(110136005)(66446008)(64756008)(5660300002)(8936002); 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: q542A4aVoiW4oVqavvzzG5KJyRB3fbkr47V3y+i91ZQB7jE0j49MTGsBbUQVod5nRS5Zvj3Sz6K86Cs7bMGhk+4pCpSMAhCppuUq9vSF2vUThe1uPh8/GdfUwx1NymWttu0gRwUdDASBjVhSlfFSHhSyLcqFvatKRyi3iSpz78NfPNMLJc5ahD42RbOM4D29pDdh7cX2uNEbDHZaZzSkb1MziZT9sOXDrxKxCVk/5WPbYFlZTYuNK+/6FtLeeQWjSy/7oQZXy1UtDyBliPcMfS1xveb1LCjZVyMqgfMGzoCAcAthgwJNcKAlHZYhMoM71i/0k1ohQkrtgFApjpFy59aXiPTSDV93ggToOlAZXotno17KnpN7Dm1Ch4O5ZV15z5q8RFmPFVKsuEKgxplqZPHm4SefX8zkyRslqcP9F3a7Tu8blIYXt/SfRwv8ncgOE7t4INuj916Z0c6uadTdmP54LDZ8TRscObOq+XOArBosG5u3h391XRetkVzDF12eF64sehx1A3UmxoxSgRY4LA== x-ms-exchange-antispam-messagedata: 6BOEo+yokTwX3a89MUFdDSwpzc8T5y5GhVmb3G/bC1ME3NwgO8x0MHTprad8lwLYMwfOxeUs5uN7vu99RwgK8C/4Q7A8hMqqTxVXfNfmS8Ontat2z8NQVJGkQChKcuHW8i3lv15pVeOl6hOLhPQtKA== Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3318181A1F2C5B19E9392F849BC20AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4850 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT006.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)(346002)(396003)(136003)(376002)(39860400002)(46966005)(26005)(70206006)(186003)(81166006)(86362001)(70586007)(8676002)(336012)(5660300002)(8936002)(47076004)(81156014)(82740400003)(7696005)(26826003)(2906002)(356004)(52536014)(110136005)(316002)(478600001)(966005)(9686003)(4326008)(33656002)(6506007)(55016002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: c6307565-3af8-4d34-cad0-08d7da3525ba X-Forefront-PRVS: 0365C0E14B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 0as37b6/fFawYo1N0FuBJuTOqUeyKvv21AW7DlL4UbM+hmaYFcgCze2mnkp60QmQOAFKCs5vcpCOIpSy9Zj2g1ZNQww6Ofgmz6uCnb7ML7tMk5CjHFAF9i6mq8vQ+cno6SLTBBu3Ki9K+Yj8AIAKvJ7U8G6jYGuVRiVfWskpP5ostnR1gXGN41Wm29gRDlf7+tEpwmb1VcAQUKREKNDaApaSzdhcQ5ZraSpYjG+tw34g7UFeLYVfqnWCnj+oZ3agdGGp7SVqfBE4MaodwvHN0576pfh3+b3qUnLMzwEX5WNdNC7RcS8gMFP08uSq1YasAfFL35qlLugQpQrV2KSAzARAWkrPDWrfSGuwsxFZVCk3rIWSQCH0pXnp59DQRIhrPsKf3tc4aJYLI4xfUd+W0PPUsdeGX9yaDMDpClcaZirVrM0LCTCDbZVxkkdqGu0KEKf5kKi0G2MPMC1683SPf2PvJay2G6roUK+STaiBKfi1NVFQ2OgK3OsCHXvogVlbLw3qajSq4YUbBfnvQ4WrDQuMCe72f6MZxHUlaT2DGGwBLTTftsoZ+s4G0w5apanc+QEMTF6eDLODNS/5XtqC2Q== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 14:16:56.5777 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d1c8d491-529d-40a8-362f-08d7da3529d0 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: DB7SPR01MB5 Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Mon, 06 Apr 2020 14:17:09 -0000 --_000_AM6PR08MB3318181A1F2C5B19E9392F849BC20AM6PR08MB3318eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thomas! > That said, as currently written, this doesn't seem to work particularly well on paths that are lossy, slow, and with small MTUs (or a combination thereof), which we need to make sure it's reasonably well covered as it happens to be one of our main use cases. > I'm inclined to say this could be solved by profiling the reliability scheme for constrained networks (in I-D.tschofenig-uta-tls13-profile), Given we agree that there is a significant inefficiency in the ACKing schem= e as stated, I'd prefer we try to improve the spec now provided we find a n= ot too intrusive way to do so, and not postpone the problem. After all, it seems that there isn't much to be changed if we go for option= 2 from the original post, which perhaps isn't far off from the original in= tention anyway: * Sending ACKs: ACKs may be sent for any record immediately, but it is reco= mmended to bunch ACKs and in particular send them on any sign of disruption= . * Receiving ACKs: Upon receipt of an ACK, implementations should note which= messages have been received and omit them from future retransmissions. It = is up to the implementation to decide when to retransmit and what to retran= smit, but it is recommended they retransmit after a period of time during w= hich no further ACK messages have been received. They may also proactively = retransmit parts of a flight early if an ACK message indicates a gap (note,= though, that in this example one would only retransmit the gap, not the ga= p + tail as before). The decisive difference to the current draft is that this takes away the ch= aracter of ACKs as retransmission requests (resulting from the recommendati= on of immediate retransmission upon receipt of a partial ACK), while it ret= ains flexibility as to how exactly the scheme is implemented. Cheers, Hanno Cheers 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls 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_AM6PR08MB3318181A1F2C5B19E9392F849BC20AM6PR08MB3318eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Thomas!

> That said, as currently written, this doesn't= seem to work particularly
well on paths that are lossy, slow, and with small MTUs (or a
combination thereof), which we need to make sure it's reasonably well
covered as it happens to be one of our main use cases.
> I'm inclined to say this could be solved by profiling the reliability<= br> scheme for constrained networks (in I-D.tschofenig-uta-tls13-profile),

Given we agree that there is a significant inefficiency in the ACKing scheme as stated, I'd prefer we try to improve the spec now provided we find a not too intrus= ive way to do so, and not postpone the problem.

After all, it seems that there isn't much to be ch= anged if we go for option 2 from the original post, which perhaps isn't far= off from the original intention anyway:
 
* Sending ACKs: ACKs may be sent for any record im= mediately, but it is recommended to bunch ACKs and in particular send them = on any sign of disruption.

* Receiving ACKs: Upon receipt of an ACK, implemen= tations should note which messages have been received and omit them from fu= ture retransmissions. It is up to the implementation to decide when to retr= ansmit and what to retransmit, but it is recommended they retransmit after a period of time during which no f= urther ACK messages have been received. They may also proactively retransmi= t parts of a flight early if an ACK message indicates a gap (note, though, = that in this example one would only retransmit the gap, not the gap + tail as before).

The decisive difference to the current draft is th= at this takes away the character of ACKs as retransmission requests (result= ing from the recommendation of immediate retransmission upon receipt of a p= artial ACK), while it retains flexibility as to how exactly the scheme is implemented.

Cheers,
Hanno


Cheers

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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls
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_AM6PR08MB3318181A1F2C5B19E9392F849BC20AM6PR08MB3318eurp_-- From nobody Mon Apr 6 07:20:42 2020 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 72CB43A060A for ; Mon, 6 Apr 2020 07:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=LLBCePvf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=h5z5HCOV 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 cXSIkZH2XVbH for ; Mon, 6 Apr 2020 07:20:30 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 948593A0BE7 for ; Mon, 6 Apr 2020 07:19:37 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id DC68095B for ; Mon, 6 Apr 2020 10:19:36 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Mon, 06 Apr 2020 10:19:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=XYn7hVOrDHcWAmy4DshXvgEEhNpExz/BViB8LqahOtM=; b=LLBCePvf u+v3mDJRsZRWfuS4xZcVgsrORyzCvwEL30S+jXqwgSs7bY7ne0hjMnoSpAFO3FPP maoqAjQSaUZl0HCiCKyf9ZQJHtHrLZ/XDVn1SfsMV1WafCPiwXM3+UicOwu8ikX4 w2rJDNtmqWH5oDAb36H8UGgRBqcpXhHi+BbUIhJxfTUCbv4F6RJgQEdb0F9z2DVx k3q0s3lnLcWJkDUmxbY5/U8TSQQXY+GWjaRJNdUfD7QdtXS+ImWaLCFCk553AOgv y3BQqwGTfK8t8pqjdpRmc8gl5jDe7wPIjsJYsiE4mXllKZsXuDg9X5/xz4+etT57 dnK8TEirhL8eCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=XYn7hVOrDHcWAmy4DshXvgEEhNpEx z/BViB8LqahOtM=; b=h5z5HCOV+Ph/q9Z6wvw4clN9kIKTw5YDCKptD9T4BvyWR dGpamA+jGI1k9oMJLkI1+ys75o7+bO12JJrmTKxHoKn/rLVODDiril3BjhStYQji lyAVEQSqfgfTbrmVRub+sdksYfRZeBAZ8M7CaRW1ctm1dOhTKuQZcR9sorV6FHBo z0R5cCLiwASYgQXAXrxS/oCEVXfxsmf/pHsNAwGMuhyjss9glMvBpck/rMNnc/pg 2VAMn7fG/xaw+FpWHTebu0VkTficPwXdSxJaDHVBu/enK+QQh8SXrKi3AyYwbnSS 3WNf1fPTtaTopsGaUmehNePkSWcGB875hKRSKK6Vw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudefgdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre erjeenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfieshhgv rghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpih gvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 047793C00A1; Mon, 6 Apr 2020 10:19:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1084-gdc5e709-fmstable-20200406v2 Mime-Version: 1.0 x-forwarded-message-id: <158618248979.31470.12389360935004839324@ietfa.amsl.com> Message-Id: <96117077-caeb-44ea-9e68-75007e39e69f@www.fastmail.com> Date: Mon, 06 Apr 2020 07:19:14 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: [TLS] =?utf-8?q?Fwd=3A_New_Version_Notification_for_draft-dt-tls?= =?utf-8?q?-external-psk-guidance-01=2Etxt?= 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: Mon, 06 Apr 2020 14:20:40 -0000 This update includes guidance clarification, use case expansion, and more text around PSK identity management. At this point, we're seeking any and all feedback from the WG on the current draft. What's missing, misleading, wrong, etc? Please feel free to raise issues here or on the GitHub repository [1]. Thanks! Chris [1] https://github.com/tlswg/external-psk-design-team ----- Original message ----- From: internet-drafts@ietf.org To: Jonathan Hoyland , Mohit Sethi , Christopher Wood , Russ Housley , "Christopher A. Wood" Subject: New Version Notification for draft-dt-tls-external-psk-guidance-01.txt Date: Monday, April 06, 2020 7:14 AM A new version of I-D, draft-dt-tls-external-psk-guidance-01.txt has been successfully submitted by Christopher A. Wood and posted to the IETF repository. Name: draft-dt-tls-external-psk-guidance Revision: 01 Title: Guidance for External PSK Usage in TLS Document date: 2020-04-06 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-dt-tls-external-psk-guidance-01.txt Status: https://datatracker.ietf.org/doc/draft-dt-tls-external-psk-guidance/ Htmlized: https://tools.ietf.org/html/draft-dt-tls-external-psk-guidance-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-dt-tls-external-psk-guidance Diff: https://www.ietf.org/rfcdiff?url2=draft-dt-tls-external-psk-guidance-01 Abstract: This document provides usage guidance for external Pre-Shared Keys (PSKs) in TLS. It lists TLS security properties provided by PSKs under certain assumptions and demonstrates how violations of these assumptions lead to attacks. This document also discusses PSK use cases, provisioning processes, and TLS stack implementation support in the context of these assumptions. It provides advice for applications in various use cases to help meet these assumptions. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Apr 6 07:55:26 2020 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 AC83A3A0946 for ; Mon, 6 Apr 2020 07:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=Kw/PUmf7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=0LlXWMHg 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 LPalxAfiFfyF for ; Mon, 6 Apr 2020 07:55:02 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7CE03A0942 for ; Mon, 6 Apr 2020 07:54:49 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 3044B92F for ; Mon, 6 Apr 2020 10:54:48 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Mon, 06 Apr 2020 10:54:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=oE7R86Y4ZsGTNZbmiWkEX5hdkHjAOs/+fPDutxDlExY=; b=Kw/PUmf7 ZYqZnVNqwnH+peMdGKY8c8NgStO7/fSzmIqzWx+VRhmu/I9ygoiO7/WCDf2EeurR I8H+LtyPnW5AP2iiTzXZyPU5mNIrX69AjqpiNZ0LN+j0HropaEQlcVInsrOcoYti 8EaSLeWpSOxQMPvje5+iypj1TaN6DMNeNWw6Vuhe+/iklIGHkwZ6ciuyDxoxoL1a FxhDmI8k2jHdQ1e+5V1rPP5u7jy4jYGcX2sN3Y5h+PM8w4JS2vPB3sB2fiyn3A7w DrTwdezVl4StHp5b20Y2dbbjjgFOoinOz+Lg6N0ANnqPI3TLk4OONePI/vVqcsjY TXZ320wqN+8YLQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=oE7R86Y4ZsGTNZbmiWkEX5hdkHjAO s/+fPDutxDlExY=; b=0LlXWMHg3o3YfH29E12CsDjwdgyIYW/Eeo47bvaRc+X71 Q1TLi2oGMUAkSgplhoThW/1JqHpAs2x6Nh8W0BQmbNbp1Q94iyl5Y3TeYPsvyCwU oFJQxb1kNi0GxjzGWdFIs9e1rpvmImpNjKhLDjca8upi4MtGBB057VCS++psvw2P Z4xo4Uzkmx2VnnGoh/UhRDGgJSPP9ztdHdsVNqBR/XIlcVuan+gzVd1RJ9zWEF75 VFIBgSeqGK0pX15WoSrOlZgmnzaF3tqRHfwJZyVW2frGj+C011QESkuYmq6QZehk VXdEWPnelJVDe12m5mTmDKFpQbpeAxJb69xyx4gnQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudefgdejiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfieshhgv rghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpghhith hhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7313B3C00A1; Mon, 6 Apr 2020 10:54:47 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1084-gdc5e709-fmstable-20200406v2 Mime-Version: 1.0 Message-Id: Date: Mon, 06 Apr 2020 07:53:25 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: [TLS] WGLC for "A Flags Extension for TLS 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: Mon, 06 Apr 2020 14:55:04 -0000 This is the working group last call for the "A Flags Extension for TLS 1.3" draft, available at: https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ Please review the document and send your comments to the list by April 20, 2020. The GitHub repository for this draft is available at: https://github.com/tlswg/tls-flags Thanks, Chris, on behalf of the chairs From nobody Mon Apr 6 08:20:48 2020 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 AE9923A09FB for ; Mon, 6 Apr 2020 08:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 1_hdmyb4YGGH for ; Mon, 6 Apr 2020 08:20:26 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB8F03A0A31 for ; Mon, 6 Apr 2020 08:20:18 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id k28so52413lfe.10 for ; Mon, 06 Apr 2020 08:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FDXuHIHCrHQUWyk19n7wueF4o/tEl9wW6JxKgF2tRRs=; b=O2sluAsE3hCE61oJlx7d2doL5Uy4QBibg6iAJ5DpOq1pd5xo1C4aeRC0IyOdNMXO/T dMD7raKR6TPYckf56zymtX4WY6r/pYuqOV8rUbphZxXo7x6LKiVb4Aq86JWQtOVrTpCP wmY/fOe1eOJUtgcGlodVl/SpGsyBaEdnAIcdysvSLJbsCtto+DwW7lmyBR0DiswtoNDy ue/L5klWrJRgFEj1lTkBSONdD+H8oord1QA03Q1tFz0D7WuZpBsn/w03eQ8fzC2mSrH+ KVzM5Ws4bZQ1PIAsDrAcRLtQZ/g8GIrzuNYzDLXzTiBlSqaMieWQ2K3B5mqgWN1DSp0l oHLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FDXuHIHCrHQUWyk19n7wueF4o/tEl9wW6JxKgF2tRRs=; b=EoCAwN9NHSZ32LdL6Q3Vr77XPUYg6aqMFML9Pw+pnURdVh8TejK1E9izm65KgHld44 sokpFiTYk7m+zOVIlT2/kSNVlUHWnsSOLbTKuiUdZphk3Bo6U8UMRk1Uvb1ceThy08DQ 63vXiwdtawK8MZN73VztCKef1BjQWt6sHJW821D7yNTDp22Y/Ac660U2ITDO92cvI6n8 MmqJDjHz0UGsmRlbFD+E9tqIdyTqnTpDN8mMkcKw4ln5hmLTYtttaEyKigYQ7UuGjRQ0 5Jf7UqwEn04S2SvCXEaB897gs3Vaufd140LAigpiNMLWg42y6sbhrp63A/ws5JBjIkxD SyIg== X-Gm-Message-State: AGi0PuZJqJ6nfo8cWooCBYLZc8jxazI1imeF+dYKItYCnvutDwjSjGWR DKw5WXob27zUv6VoTnCvNz8pkZ3joEMibROj+gcp8g== X-Google-Smtp-Source: APiQypJQWQH8Q8QnWVDOecM5MMczAw7E2RPHtbuEK0oV2biRbFtb7oH0wQewTP5ilF3uC/WeyowVFxun8P0FpKG/Hzk= X-Received: by 2002:a19:f10f:: with SMTP id p15mr13407929lfh.14.1586186417100; Mon, 06 Apr 2020 08:20:17 -0700 (PDT) MIME-Version: 1.0 References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> <03849701-1A14-4E1A-8298-D483E74E380C@arm.com> In-Reply-To: From: Eric Rescorla Date: Mon, 6 Apr 2020 08:19:40 -0700 Message-ID: To: Hanno Becker Cc: Thomas Fossati , Rob Sayre , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f0723005a2a0cd67" Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Mon, 06 Apr 2020 15:20:29 -0000 --000000000000f0723005a2a0cd67 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 6, 2020 at 7:17 AM Hanno Becker wrote: > Hi Thomas! > > > That said, as currently written, this doesn't seem to work particularly > well on paths that are lossy, slow, and with small MTUs (or a > combination thereof), which we need to make sure it's reasonably well > covered as it happens to be one of our main use cases. > > I'm inclined to say this could be solved by profiling the reliability > scheme for constrained networks (in I-D.tschofenig-uta-tls13-profile), > > Given we agree that there is a significant inefficiency in the ACKing > scheme as stated, I'd prefer we try to improve the spec now provided we > find a not too intrusive way to do so, and not postpone the problem. > > After all, it seems that there isn't much to be changed if we go for > option 2 from the original post, which perhaps isn't far off from the > original intention anyway: > > * Sending ACKs: ACKs may be sent for any record immediately, but it is > recommended to bunch ACKs and in particular send them on any sign of > disruption. > > * Receiving ACKs: Upon receipt of an ACK, implementations should note > which messages have been received and omit them from future > retransmissions. It is up to the implementation to decide when to > retransmit and what to retransmit, but it is recommended they retransmit > after a period of time during which no further ACK messages have been > received. They may also proactively retransmit parts of a flight early if > an ACK message indicates a gap (note, though, that in this example one > would only retransmit the gap, not the gap + tail as before). > > The decisive difference to the current draft is that this takes away the > character of ACKs as retransmission requests (resulting from the > recommendation of immediate retransmission upon receipt of a partial ACK), > while it retains flexibility as to how exactly the scheme is implemented. > First, let me say that in scenarios like the one you posit we have other problems besides ACK inefficiency. Specifically, DTLS doesn't do any real congestion control and so your initial window will be way too big if you broadcast a 40K message at once. So I don't think a huge amount of optimization is in order here. By contrast. we do know that DTLS retransmission is too slow and given that small flights are common, losing the ability to indicate that you lost a tail seems undesirable. ISTM that the easiest way to deal with this is to have the sender treat the current ACK state as the union of the states it has received and permit receivers to only ACK each packet once (while encouraging them to fill the ACK packet). Then you would retransmit if your new ACK state was partial rather than if the ACK was partial. -Ekr --000000000000f0723005a2a0cd67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 6, 2020 at 7:17 AM Hanno = Becker <Hanno.Becker@arm.com= > wrote:
Hi Thomas!

> That said, as currently written, this doesn't seem to work pa= rticularly
well on paths that are lossy, slow, and with small MTUs (or a
combination thereof), which we need to make sure it's reasonably well covered as it happens to be one of our main use cases.
> I'm inclined to say this could be solved by profiling the reliabil= ity
scheme for constrained networks (in I-D.tschofenig-uta-tls13-profile),

Given=C2=A0we agree that there is a significant inefficiency in the ACKing scheme as stated, I'd=C2= =A0prefer we try to improve the spec now provided we find a not too = intrusive way to do so, and not postpone the problem.

After all, it seems that there isn't much to be changed if we go f= or option 2 from the original post, which perhaps isn't far off from th= e original intention anyway:
=C2=A0
* Sending ACKs: ACKs may be sent for any record immediately, but it is= recommended to bunch ACKs and in particular send them on any sign of disru= ption.

* Receiving ACKs: Upon receipt of an ACK, implementations should note = which messages have been received and omit them from future retransmissions= . It is up to the implementation to decide when to retransmit and what to r= etransmit, but it is recommended they retransmit after a period of time during which no f= urther ACK messages have been received. They may also proactively retransmi= t parts of a flight early if an ACK message indicates a gap (note, though, = that in this example one would only retransmit the gap, not the gap + tail as before).

The decisive difference to the current draft is that this takes away t= he character of ACKs as retransmission requests (resulting from the recomme= ndation of immediate retransmission upon receipt of a partial ACK), while i= t retains flexibility as to how exactly the scheme is implemented.

First, let me say that = in scenarios like the one you posit we have other problems besides ACK inef= ficiency. Specifically, DTLS doesn't do any real congestion control and= so your initial window will be way too big if you broadcast a 40K message = at once. So I don't think a huge amount of optimization is in order her= e. By contrast. we do know that DTLS retransmission is too slow and given t= hat small flights are common, losing the ability to indicate that you lost = a tail seems undesirable.

ISTM that the easiest way to deal with this is= to have the sender treat the current ACK state as the union of the states = it has received and permit receivers to only ACK each packet once (while en= couraging them to fill the ACK packet). Then you would retransmit if your n= ew ACK state was partial rather than if the ACK was partial.

-Ekr

--000000000000f0723005a2a0cd67-- From nobody Mon Apr 6 08:22:07 2020 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 9E8593A0BCC for ; Mon, 6 Apr 2020 08:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 picjerlcyOKn for ; Mon, 6 Apr 2020 08:21:42 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 956F83A0CB0 for ; Mon, 6 Apr 2020 08:21:06 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 036FIONo031670; Mon, 6 Apr 2020 16:21:03 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=NalSKvlUXZIhj4e7m/yi+FLdAK90ITgyuqI3r2Baows=; b=kRnspYSJ0ENH3zmzrNvGWQnD00aqVt7ysyljI5h/DeozdrOhzgrN1aRuQoiBIAYN1wxQ PgvGHGMxJYEkyZwEkFsAI7Ls1rbmIyXa0JHbCQGVAscWLiBg0AHUU6PRz1s+BUdXE+UD ISi7/1ugb4cDBVWP4waSDuq4lFPT58nxRzSHM0QcLJqaWRH2WHqoXWOgHdyByAkIPK7q UKi7YlrT8tHcH3Q4eX1hxX89IkgS7EAXd9Q81elfp7WX87c7UerwbW4n8jdPJBrtPtgk PUF2y1q+MSWzmde6e0u1aRE52EmLoVD/ANEyAWty780YilWjxx1GyLExe8JJuvY4S2gp aw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 306hvwsrfv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 06 Apr 2020 16:21:03 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 036FGtD4010481; Mon, 6 Apr 2020 11:21:03 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint1.akamai.com with ESMTP id 306njvcka3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 06 Apr 2020 11:21:02 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 6 Apr 2020 10:21:01 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.006; Mon, 6 Apr 2020 10:21:01 -0500 From: "Salz, Rich" To: Christopher Wood , "TLS@ietf.org" Thread-Topic: [TLS] WGLC for "A Flags Extension for TLS 1.3" Thread-Index: AQHWDCNy3p1Qr9GHpECqx2WsJUrD8KhsRnEA Date: Mon, 6 Apr 2020 15:21:00 +0000 Message-ID: <9DEA5D84-F8F0-4BA9-B00B-A5E8134A49B8@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.114.9] Content-Type: text/plain; charset="utf-8" Content-ID: <1E8E5580A130F449BE12129312B327AF@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-06_08:2020-04-06, 2020-04-06 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=660 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2004060126 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-06_08:2020-04-06, 2020-04-06 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=669 adultscore=0 mlxscore=0 phishscore=0 priorityscore=1501 bulkscore=0 malwarescore=0 impostorscore=0 lowpriorityscore=0 clxscore=1015 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004060125 Archived-At: Subject: Re: [TLS] WGLC for "A Flags Extension for TLS 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: Mon, 06 Apr 2020 15:21:48 -0000 SSByZS1yZWFkIGl0LiAgU2hpcCBpdC4NCiANCg0K From nobody Mon Apr 6 09:03:20 2020 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 9606A3A0B80 for ; Mon, 6 Apr 2020 09:03:02 -0700 (PDT) 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, 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=bQwLlrGS; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=bQwLlrGS 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 srEW2xYwu5X6 for ; Mon, 6 Apr 2020 09:03:00 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40060.outbound.protection.outlook.com [40.107.4.60]) (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 949B43A0B6D for ; Mon, 6 Apr 2020 09:02:58 -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=UpFSjF/50PFrW3VhbdphsZtLUNK/TXqj2YIZICqdXVc=; b=bQwLlrGSi69xz0h2iqZyP4hdWaVPO72G/c8iNEg3CiC+JkGlXiWozux4JANZf/8RORrQnHtrbto6SwsQeVUle57gdX7JcbzFDkn1jZsK+xuQuSZMWVUR5ya3lyIUTRVcnw/nc5Cg7Oyo5Pj4kzlJiPnJpTsEf1u+GaDciLXU2yk= Received: from DB8PR03CA0012.eurprd03.prod.outlook.com (2603:10a6:10:be::25) by VI1PR08MB3471.eurprd08.prod.outlook.com (2603:10a6:803:7d::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.21; Mon, 6 Apr 2020 16:02:55 +0000 Received: from DB5EUR03FT009.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:be:cafe::d3) by DB8PR03CA0012.outlook.office365.com (2603:10a6:10:be::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16 via Frontend Transport; Mon, 6 Apr 2020 16:02:55 +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 DB5EUR03FT009.mail.protection.outlook.com (10.152.20.117) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Mon, 6 Apr 2020 16:02:55 +0000 Received: ("Tessian outbound 1425309d4c0b:v50"); Mon, 06 Apr 2020 16:02:55 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 1ddf49143f92ecc1 X-CR-MTA-TID: 64aa7808 Received: from 3b23b66c13d2.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 84C0CEAC-8B08-401E-A74B-D9CA4E6B3E00.1; Mon, 06 Apr 2020 16:02:50 +0000 Received: from EUR03-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 3b23b66c13d2.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 06 Apr 2020 16:02:50 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L5HF3HonC3xt3T7EaAAn9poVwpJJiuy02tB1wmMmbfzGK8O8O7cvR8CEjzwSLMCCnEYkS0vZnxVRDFxtzoK8fRWnWGLkq5Yk4ahTGutHlnaN4LBscB6QJVV3f0k753nmouectR8TVBcpiNoOf6Uc1NtIvuRr7vt3d/J/7lswZ4zWSfy/Dj3g/h0TWwNSp9Sat16e5TJZ7gEEby31xhSvmaX1LOFImBnbRWGiwjIc0H9TyLmoyoiSOtfDcHSavayi3OeQglr++x33hciORds0nEdfP5dtJkP7B/1JuHD2R3PazAsoR1NkgnFG4ZBlbosOBaC395ZUAa1w2HkW0sifAw== 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=UpFSjF/50PFrW3VhbdphsZtLUNK/TXqj2YIZICqdXVc=; b=UNNH1vBXAYPKYjBzcA/BLpGEmR6v8ggTIAxaSkCyu1Pdr5Hc2N7QClxikwzGLO+5STubaz/jAXu5XJioCxIFYDznMTaVq98gCmYIiyZk3K+7vPMY1i3RDWMFVgjHZj68lvqHOa1EJBArXkiH2VZx362hN3GatcFI1CAycHbc0h1Jc64WrD8ymY7hmwNcO8NTyvzMTknt51lp4FvBaG6KBblZSCvyUj2N7b9cHH6zgwwpIYywudPirqGwK0j8rN9u6ps3y3IJMMdszxhmQUtnSlVB+HIEMpMEJLSBijipM7YzzcutAkBpeCvPdVFkRLSw1Ta9kIDE2sq1E0HGjKT3Ow== 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=UpFSjF/50PFrW3VhbdphsZtLUNK/TXqj2YIZICqdXVc=; b=bQwLlrGSi69xz0h2iqZyP4hdWaVPO72G/c8iNEg3CiC+JkGlXiWozux4JANZf/8RORrQnHtrbto6SwsQeVUle57gdX7JcbzFDkn1jZsK+xuQuSZMWVUR5ya3lyIUTRVcnw/nc5Cg7Oyo5Pj4kzlJiPnJpTsEf1u+GaDciLXU2yk= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (20.179.18.151) by AM6PR08MB3064.eurprd08.prod.outlook.com (52.135.165.31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Mon, 6 Apr 2020 16:02:48 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f%7]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 16:02:48 +0000 From: Thomas Fossati To: Hanno Becker , Rob Sayre CC: "tls@ietf.org" , Thomas Fossati Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQgAO7OoCAAKsoAP//86kAgAAdq4D///6F3YAAREwA Date: Mon, 6 Apr 2020 16:02:48 +0000 Message-ID: References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> <03849701-1A14-4E1A-8298-D483E74E380C@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 0d7a8ab7-dda9-4fd9-e2f3-08d7da43f838 x-ms-traffictypediagnostic: AM6PR08MB3064:|AM6PR08MB3064:|VI1PR08MB3471: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8273;OLM:9508; x-forefront-prvs: 0365C0E14B X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(366004)(396003)(376002)(346002)(39860400002)(6486002)(33656002)(36756003)(478600001)(54906003)(6512007)(5660300002)(26005)(2906002)(53546011)(110136005)(6506007)(2616005)(316002)(66476007)(66556008)(64756008)(66446008)(8676002)(81156014)(71200400001)(4326008)(91956017)(186003)(8936002)(81166006)(86362001)(76116006)(66946007); 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: LRM9zEvFFY2h9XS4H/Im/W1YVsd/gQpPxPM/ferH+b1htt8ZdR9z3gOAJU3wGwu4bDwAcfUx/MfvwJlEx3EnnRUATOAHPmE7dTGnrchh2LeTB4czkuyTctsicTu5857fu3LZIqJwrFa2lGyfM9cAIPSjT8dhMSA4foEANP92SYWvbgTPfwtclFJDVgbo81I7Ix8F71QJ47PFJoguqnMQG4xz6GzbHjC098Hqmyc3QNdhaa3C+LHzGqwS4qtju2IvcgiD6yjGAop2M5pcLeV13jJaBGcK7RKHkuGP+dHcpi7NkW6E+GTTgkFli2v4hFfE6LtNJ6HEReVPeY2cyhKw/6xJUiP//tSuAWFHeinxf4cu6kORVl4ObWn9KwZHcmdwP+9XkGoiz7czirTuPrqupdfo4VXvUnVk9ffsjgfI8rvF9VbmJTy5zcMDbI97M2tt x-ms-exchange-antispam-messagedata: 7AwutRCfFw5pqll3rWVs8jRxQvAOIgN4YHJtQ8NuEZoySAqSGrJKepF/4v8n7WNmrEIX4zhL8p2Oh5sPwgcc4L6kuiMHSsn8JyfCgMxlhkHrh5YbExrAIIYWtFbL0jyaJh+4YzeBcCXJ2ZgyfA2mbQ== Content-Type: text/plain; charset="utf-8" Content-ID: <359AE84FFB5FCF41B66FF3B0CF180A53@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3064 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT009.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)(376002)(39860400002)(346002)(396003)(136003)(46966005)(36756003)(81156014)(6486002)(478600001)(26826003)(2616005)(186003)(26005)(47076004)(82740400003)(336012)(356004)(53546011)(316002)(8936002)(6506007)(81166006)(5660300002)(2906002)(6512007)(4326008)(110136005)(70586007)(33656002)(54906003)(86362001)(8676002)(70206006); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 6e4f4c82-0ceb-45aa-e964-08d7da43f3e9 X-Forefront-PRVS: 0365C0E14B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: v7eDDHbY3M9ENqU06XX36TetP1thv2qCGp1ikStjBpnwvlYtGwfUM2Qb4b3Uoursb7dAxHO8sHuu7GXaTKGjOLoDJLaDocRZ468Nra6gUFQAHkIZub64z064yBoLUr2/6LZJF1pgJibhGQSq0LEtGxuQbEvU00CJwz3tQQBApxf2g2tlQpRwnZ5oRThE7e+Vk6fILllioykFF6OqyymsX+u/ExlnTeNamKCpCeYkhFajEMaqGjQhTFiTuKoJ2zqTfFhgdSBJYWJv0WrflLYsosZ4PLPOSGSdAHEdYAhGaVSBH9hoBF29ul45r/JptWM4c7fY1L3mnD5kunCkPQLufXIKe5RTb/pSxx66Jk1VGDY9HhM0fagaUCpuW3J9IHRJXyRA+V1ncDRxghtIq6ri/NQql4KC6f0TiafKMn4+dO/tu0WooLrC72QKL2LTBVEYb4iqdUXqyW7QNh6ECby1aTl43VDIpr9VqfuUgcFSF3bv2BS6p2O/an70tWlClzy9Mgz9FxmJu9Q/1GZgCZO7vQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 16:02:55.8296 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0d7a8ab7-dda9-4fd9-e2f3-08d7da43f838 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: VI1PR08MB3471 Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Mon, 06 Apr 2020 16:03:03 -0000 T24gMDYvMDQvMjAyMCwgMTU6MTYsICJIYW5ubyBCZWNrZXIiIDxIYW5uby5CZWNrZXJAYXJtLmNv bT4gd3JvdGU6DQo+IEdpdmVuIHdlIGFncmVlIHRoYXQgdGhlcmUgaXMgYSBzaWduaWZpY2FudCBp bmVmZmljaWVuY3kgaW4gdGhlIEFDS2luZw0KPiBzY2hlbWUgYXMgc3RhdGVkLCBJJ2QgcHJlZmVy IHdlIHRyeSB0byBpbXByb3ZlIHRoZSBzcGVjIG5vdyBwcm92aWRlZA0KPiB3ZSBmaW5kIGEgbm90 IHRvbyBpbnRydXNpdmUgd2F5IHRvIGRvIHNvLCBhbmQgbm90IHBvc3Rwb25lIHRoZQ0KPiBwcm9i bGVtLg0KPg0KPiBBZnRlciBhbGwsIGl0IHNlZW1zIHRoYXQgdGhlcmUgaXNuJ3QgbXVjaCB0byBi ZSBjaGFuZ2VkIGlmIHdlIGdvIGZvcg0KPiBvcHRpb24gMiBmcm9tIHRoZSBvcmlnaW5hbCBwb3N0 LCB3aGljaCBwZXJoYXBzIGlzbid0IGZhciBvZmYgZnJvbSB0aGUNCj4gb3JpZ2luYWwgaW50ZW50 aW9uIGFueXdheToNCj4NCj4gKiBTZW5kaW5nIEFDS3M6IEFDS3MgbWF5IGJlIHNlbnQgZm9yIGFu eSByZWNvcmQgaW1tZWRpYXRlbHksIGJ1dCBpdCBpcw0KPiByZWNvbW1lbmRlZCB0byBidW5jaCBB Q0tzIGFuZCBpbiBwYXJ0aWN1bGFyIHNlbmQgdGhlbSBvbiBhbnkgc2lnbiBvZg0KPiBkaXNydXB0 aW9uLg0KPg0KPiAqIFJlY2VpdmluZyBBQ0tzOiBVcG9uIHJlY2VpcHQgb2YgYW4gQUNLLCBpbXBs ZW1lbnRhdGlvbnMgc2hvdWxkIG5vdGUNCj4gd2hpY2ggbWVzc2FnZXMgaGF2ZSBiZWVuIHJlY2Vp dmVkIGFuZCBvbWl0IHRoZW0gZnJvbSBmdXR1cmUNCj4gcmV0cmFuc21pc3Npb25zLiBJdCBpcyB1 cCB0byB0aGUgaW1wbGVtZW50YXRpb24gdG8gZGVjaWRlIHdoZW4gdG8NCj4gcmV0cmFuc21pdCBh bmQgd2hhdCB0byByZXRyYW5zbWl0LCBidXQgaXQgaXMgcmVjb21tZW5kZWQgdGhleQ0KPiByZXRy YW5zbWl0IGFmdGVyIGEgcGVyaW9kIG9mIHRpbWUgZHVyaW5nIHdoaWNoIG5vIGZ1cnRoZXIgQUNL IG1lc3NhZ2VzDQo+IGhhdmUgYmVlbiByZWNlaXZlZC4gVGhleSBtYXkgYWxzbyBwcm9hY3RpdmVs eSByZXRyYW5zbWl0IHBhcnRzIG9mIGENCj4gZmxpZ2h0IGVhcmx5IGlmIGFuIEFDSyBtZXNzYWdl IGluZGljYXRlcyBhIGdhcCAobm90ZSwgdGhvdWdoLCB0aGF0IGluDQo+IHRoaXMgZXhhbXBsZSBv bmUgd291bGQgb25seSByZXRyYW5zbWl0IHRoZSBnYXAsIG5vdCB0aGUgZ2FwICsgdGFpbCBhcw0K PiBiZWZvcmUpLg0KDQpMb29rcyBsaWtlIGEgc291bmQgcHJvcG9zYWwgdG8gbWUuICBUaGUgb25s eSBwcm9ibGVtIEkgc2VlIHdpdGggdGhpcyBpcw0KdGhhdCByZWNvdmVyeSBmcm9tIHRhaWwgbG9z cyBpcyBub3QgZWZmaWNpZW50LCB3aGljaCBtaWdodCBvciBtaWdodCBub3QNCmJlIGEgcHJvYmxl bSwgZGVwZW5kaW5nIG9uIHRoZSBsb3NzIHBhdHRlcm4gb2YgeW91ciBwYXRoLg0KDQpjaGVlcnMh DQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkg YXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFu eSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkg dGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Mon Apr 6 09:03:59 2020 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 8FBEF3A0C9A for ; Mon, 6 Apr 2020 09:03:34 -0700 (PDT) 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, 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=5Y8NGSgz; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=5Y8NGSgz 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 dkugqgEguxY5 for ; Mon, 6 Apr 2020 09:03:32 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2060c.outbound.protection.outlook.com [IPv6:2a01:111:f400:7d00::60c]) (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 3B3203A0C47 for ; Mon, 6 Apr 2020 09:03:29 -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=rOXrFTgba6Az/T7NjuY8LGZJCpT30srh29joG679bqQ=; b=5Y8NGSgzdut8wcYfv2eaRp4vasnScPDM9WLqy3khLZ8Q0WpZo3zgcJS4ox0vD7WeTKekTvdhcILHXMQGucxr2MoEtxgQBY67vCE3YZXvMpCuIoj/EiSXltcTWCGVkQgoPpb/nwBUOSAoKGX8PzElL/VtF5hmHpbbRECukD3RuFk= Received: from AM6PR10CA0017.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:89::30) by VI1PR08MB4223.eurprd08.prod.outlook.com (2603:10a6:803:b5::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Mon, 6 Apr 2020 16:03:26 +0000 Received: from AM5EUR03FT041.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:89:cafe::9) by AM6PR10CA0017.outlook.office365.com (2603:10a6:209:89::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19 via Frontend Transport; Mon, 6 Apr 2020 16:03:26 +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 AM5EUR03FT041.mail.protection.outlook.com (10.152.17.186) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Mon, 6 Apr 2020 16:03:26 +0000 Received: ("Tessian outbound 4b84da486446:v50"); Mon, 06 Apr 2020 16:03:26 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 43a79f47f97b3d3e X-CR-MTA-TID: 64aa7808 Received: from 468e60a641ed.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 1CF79A38-59E6-436E-A30F-6D1EA8EAEA95.1; Mon, 06 Apr 2020 16:03:20 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 468e60a641ed.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 06 Apr 2020 16:03:20 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nA+BHxjyisWHbJ0jgnDX22MwteXgVab6ZDD7sJ+fMlOpLOrcAcSjIjeDvJPd24tLMnEhIiPidHAgS28yGVq+gtv1Pufc9xeCVAPMGv/vm6oXXjjjxep2u7fDH0PpGT8FgS7yxua6lYD4qBM6Xuj0M38URTKd2LtojrZ+0wZ/fPd13DRlKrjrruLP6WyGXgs8EOd7agGXCkgz8EhfoTJZVyXjmhdx7gaRw7yrdwCkFvTywXSqJGAuATHJdVT524PTOIa53pjqXuKBIsYK8rWPBzRhFI/X1TUyRbus4KTG6XeGP+LaoMiw0pl1fSejBP3+XhOp9/Ondx6JWCB7BJHm4g== 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=rOXrFTgba6Az/T7NjuY8LGZJCpT30srh29joG679bqQ=; b=lXgbUTrr/JFGdp0gkg3OaNf+La6wqu9lqkCTLsw/mYn0KF3rjYGkKiGCwftVQMZoqn1/mMmKPc92iHG9ziOxl+UE+kfxgDqqL73NYZ7L5iG8dhssBIXc+ciLwQ+8mlraaJmvtAcwQbzvZkzWG7Y1vKuXM12BkyLxnDCx0RdnNZ/vYkU7dNqK8oByiIIPX5LRCZX0aIv2YCMwQQSmHZeZc/tWJ2ZuqX/LKlfoZcCBPmocFPLC5GWtXYq1UAPQhU2aAS17hnVB51jj9xU1Isuj9wXQppGpt2GC9Wgcoaym7mDSquEMGDR91INFkUEAqQUGA0R341VVK8s6bk7i3R9bcg== 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=rOXrFTgba6Az/T7NjuY8LGZJCpT30srh29joG679bqQ=; b=5Y8NGSgzdut8wcYfv2eaRp4vasnScPDM9WLqy3khLZ8Q0WpZo3zgcJS4ox0vD7WeTKekTvdhcILHXMQGucxr2MoEtxgQBY67vCE3YZXvMpCuIoj/EiSXltcTWCGVkQgoPpb/nwBUOSAoKGX8PzElL/VtF5hmHpbbRECukD3RuFk= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (20.179.18.151) by AM6PR08MB4598.eurprd08.prod.outlook.com (20.178.88.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Mon, 6 Apr 2020 16:03:19 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::9807:78f0:434f:2b9f%7]) with mapi id 15.20.2878.018; Mon, 6 Apr 2020 16:03:19 +0000 From: Thomas Fossati To: Eric Rescorla , Hanno Becker CC: Rob Sayre , "tls@ietf.org" , Thomas Fossati Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQgAO7OoCAAKsoAP//86kAgAAdq4D///6F3YAAJ3sAgAAc9QA= Date: Mon, 6 Apr 2020 16:03:19 +0000 Message-ID: References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> <03849701-1A14-4E1A-8298-D483E74E380C@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 47683e95-c892-494b-669b-08d7da440a93 x-ms-traffictypediagnostic: AM6PR08MB4598:|AM6PR08MB4598:|VI1PR08MB4223: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:7691;OLM:9508; x-forefront-prvs: 0365C0E14B X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(39860400002)(376002)(366004)(136003)(346002)(8676002)(4326008)(81156014)(71200400001)(2616005)(316002)(66476007)(66556008)(64756008)(66446008)(66946007)(8936002)(81166006)(86362001)(76116006)(91956017)(186003)(36756003)(54906003)(478600001)(6486002)(33656002)(2906002)(26005)(6636002)(6506007)(53546011)(110136005)(6512007)(5660300002)(87944003); 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: NZ3PRixL+EFFzC2Y+5V89FBWRngoe3ykV+rzr1pTrrnNzp2mVhEJq8yCwKwgfB8kcITP9tKGZ2qDC4/+GZmdWhjbZXKuJkJz1GbDJ4VtO4QH7s91UWrZvwiRQnvMjosbBOvu5H17cITgVsWDu7aSmnMoeLbBEiK1Suqxweh1kzGHj3b9aHEk8rVvRI0MZDzTleCncUKI8jb3wQbL+3s8nS/v+rgHEorNx7Fi4c3n34Voz9w88VEnbY2Ih09CtIFM/dSOYzeGxu23bRH+J3ii+VIH5+wwQtGTsihQfFTJmEHhHHkwxzBlm2QogAzAuo2jjtiG12ODx28rAwPsal7WRvxL8Wsa8uAcjpGJT5E7f/mffWFYpOuZd5U4CpC6cwHzW7IeSfMJwITHUE4IbQqk3ucgwMw33eGNxSvCyIC8lRKsg6hC4PotWKd99rQWxGIUQMW/00QYwneSsVKPjKt27Bm9KUzuD7KFG4muRCoWdx64txJD5PhIonZG7q1G2idX x-ms-exchange-antispam-messagedata: Ra/48O8fqjx5KGSE1DfPCU1/uG1BMG5/EdzdEi8gnJPpwTlKRIy8s7eiAyHfzI9JFT06fiz5ZApmiv9G/fdiOdGDs5VOMPp5+VWOH8gPhqfylMSXZQGODZGZURgzhV6NhhYfuIiXbCwzGS39+e7a1g== Content-Type: text/plain; charset="utf-8" Content-ID: <5F9ECE35BA83AB49850E38099379287D@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4598 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT041.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)(346002)(39860400002)(136003)(376002)(396003)(46966005)(33656002)(336012)(4326008)(54906003)(6512007)(26005)(53546011)(81166006)(110136005)(81156014)(6506007)(356004)(8936002)(2906002)(8676002)(6636002)(2616005)(70206006)(316002)(478600001)(36756003)(82740400003)(86362001)(47076004)(6486002)(5660300002)(36906005)(186003)(26826003)(70586007)(87944003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: aa47ead6-a9b7-4b8a-dc7c-08d7da44063b X-Forefront-PRVS: 0365C0E14B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YwHenE80GTVLKO0I7rvdpJl6Gmg7B0TlvrKHEw4IY++xQJaX44rFsp+w/vL9tZGazZZPuRaON/3i8f5a/cHko3ytSeXMggyJhs2DX6olY6mflqYoDJUuNlHMMSG96RVEWD885hgY9rHxvAGi0u6L5xdwqcJ3c765yZOdhfd43AiMCoIqGiQHhZsucL6A/p0mVvKNg66+9GjkhqCQNBIROO/i0XZveUDkp54AB449A0TwyoiHmFAF6rtqzVA9a93oxcrfaifu+C0kaQknWOplQWNLFvapwenxgcYOfHz59A5jobzNQ+OGZnQr3GQwlHGYrSXM13ywGhi6XHbcB1R3TeRLsNWhJm+Kldt1aUIkodO7tv/E6guZwjS1gIOSQDUNcFRCKgFrNjFKC/8gpbeVCnDh9rN0qYJ/s0bv93ojF3DpqtiALw1iBSC942SNlppweKr3woNARhuAUek7qaxiWeMacJM9V8UCDxUBEP6YGjxaw9T2JSi2vShHmsE5KzfQ7TGiqJqM8VThhsPwjaa4ep8GlVofSA9wFQ9+YYJICFk= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Apr 2020 16:03:26.5487 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 47683e95-c892-494b-669b-08d7da440a93 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: VI1PR08MB4223 Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Mon, 06 Apr 2020 16:03:39 -0000 T24gMDYvMDQvMjAyMCwgMTY6MjAsICJFcmljIFJlc2NvcmxhIiA8ZWtyQHJ0Zm0uY29tPiB3cm90 ZToNCj4gRmlyc3QsIGxldCBtZSBzYXkgdGhhdCBpbiBzY2VuYXJpb3MgbGlrZSB0aGUgb25lIHlv dSBwb3NpdCB3ZSBoYXZlDQo+IG90aGVyIHByb2JsZW1zIGJlc2lkZXMgQUNLIGluZWZmaWNpZW5j eS4gU3BlY2lmaWNhbGx5LCBEVExTIGRvZXNuJ3QgZG8NCj4gYW55IHJlYWwgY29uZ2VzdGlvbiBj b250cm9sIGFuZCBzbyB5b3VyIGluaXRpYWwgd2luZG93IHdpbGwgYmUgd2F5IHRvbw0KPiBiaWcg aWYgeW91IGJyb2FkY2FzdCBhIDQwSyBtZXNzYWdlIGF0IG9uY2UuIFNvIEkgZG9uJ3QgdGhpbmsg YSBodWdlDQo+IGFtb3VudCBvZiBvcHRpbWl6YXRpb24gaXMgaW4gb3JkZXIgaGVyZS4NCg0KV2hp bGUgaXQgaXMgdHJ1ZSB0aGF0IHRoZXJlJ3Mgbm8gZXhwbGljaXQgY29uZ2VzdGlvbiBjb250cm9s LCB0aGF0DQpkb2Vzbid0IHByZXZlbnQgYW4gaW1wbGVtZW50YXRpb24gdG8gY29uc2VydmF0aXZl bHkgcGFjZSB0aGUgc2VuZA0KaW5zdGVhZCBvZiBmaXJpbmcgb2ZmIHRoZSB3aG9sZSA0MEsgd29y dGggb2YgcGF5bG9hZCBhdCBsaW5lIHJhdGUuDQoNCj4gQnkgY29udHJhc3QuIHdlIGRvIGtub3cg dGhhdCBEVExTIHJldHJhbnNtaXNzaW9uIGlzIHRvbyBzbG93IGFuZCBnaXZlbg0KPiB0aGF0IHNt YWxsIGZsaWdodHMgYXJlIGNvbW1vbiwgbG9zaW5nIHRoZSBhYmlsaXR5IHRvIGluZGljYXRlIHRo YXQgeW91DQo+IGxvc3QgYSB0YWlsIHNlZW1zIHVuZGVzaXJhYmxlLg0KDQpJIGFncmVlIHRoaXMg c2hvdWxkIGJlIGF2b2lkZWQgaWYgcG9zc2libGUuDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBj b250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlh bCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBu b3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3Ig YW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRp dW0uIFRoYW5rIHlvdS4NCg== From nobody Mon Apr 6 15:39:31 2020 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 EDE093A0DE0 for ; Mon, 6 Apr 2020 15:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=SkMyOm+i; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ED9ZT3qw 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 KfBdiQdQxtS8 for ; Mon, 6 Apr 2020 15:39:28 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 600C53A0DDF for ; Mon, 6 Apr 2020 15:39:28 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 693AA68B for ; Mon, 6 Apr 2020 18:39:27 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 06 Apr 2020 18:39:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=MZ0//S9d0UyFZj+d2w//c63x+Ql8eaw q06Ym0P0zt3A=; b=SkMyOm+isjhc/U+uFiS1F4ZPbm5sxx+uTkLMdU8DT/99vIa qGiRxoH0MUEBZ98V0pvuQxaMyiHaAulC82U6OovF3HjwJ8PrT+a2acreHZY1ZXj8 eS7Vv1NABGE/6AWEhcFtLAAVepL0vUlvelgx+OHeyZSAc7dcWpOzy7JhuJtSdh4x fmrf/0NsMYw/BjeKGr089k4gjOJMUh7aRWqtL1H0JGX8ros8jtUPlBJcrX8txHpV EqK6xC7dcixDPrjfNsJf7i1utyuNMEbKSy4C2hvzjiIB+UiEKczzyPlHDiiJa4xN JbiDCi+BoFZm1P4qiAFTUc0EzjMjsb9/CGC0t3Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=MZ0//S 9d0UyFZj+d2w//c63x+Ql8eawq06Ym0P0zt3A=; b=ED9ZT3qwcuod4vW4WJhRYZ o/ggQGJ00E9/DBz64GWrlHGflCdGQHtLVGC8IkUCsSxhxetNKyvWH4g9vl/Hh4kG Hps5SX7GoH9SNEs+7mVuyKSSEkw46hhfncd09uEu1+ii4BxSMcZffWmwTbadV5kR 5Pj7thKngAVj5+wj4zSl5gcrzBlEDGIl+oGGnWoZNAWzUoMXm7vEekUOT7JY0s5q uPJuv3+PrEwLfTWBZi2af73lu8AksFaIrfoc6YQUycQw6aMeNHZQ9xFB8EY5UIY6 vhlUX/UEe0+51XV8TTWCew3xkTiqdlLcWJOjQ7p2djoPIXsPGuKdyQpV05JHXo7Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeggdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpghhithhhuh gsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C17AEE00B1; Mon, 6 Apr 2020 18:39:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1084-gdc5e709-fmstable-20200406v2 Mime-Version: 1.0 Message-Id: <3aab08b9-d979-4952-85f6-62e993f6fb4b@www.fastmail.com> In-Reply-To: References: Date: Tue, 07 Apr 2020 08:39:06 +1000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] WGLC for "A Flags Extension for TLS 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: Mon, 06 Apr 2020 22:39:30 -0000 I like this work, but I don't believe this to be ready yet. S1 None of the current proposed extensions are such that the server indicates support without the client first indicating support. So as not to preclude future extensions that are so defined, this specification allows the client to send an empty extension, indicating support for TLS flags in general (and presumably some unspecified features in particular). First, for clarification, the distinction between empty and all-zero-valued is perhaps worth drawing on. Second, more seriously, if this is the goal, the text needs to acknowledge that the possibility exists on a *per-flag* basis. Third, more substantially, and invalidating the above, I don't think that we should make flags introduce a new style of negotiation just because it can. I would strongly prefer that this function as close as possible to "empty ClientHello extension; empty EncryptedExtensions extension". Aside from that, the utility of an advertisement from the server that a client cannot respond to is pretty marginal. Fourth, this conflicts with the following text in S2: A server that supports this extension and also supports at least one of the flag-type features that use this extension and that were declared by the ClientHello extension SHALL send this extension with the intersection of the flags it supports with the flags declared by the client. Nit here: this isn't about support alone, it is the flags that the server *chooses* to support. S2 The server may need to send two tls_flags extensions, one in the ServerHello and the other in the EncryptedExtensions message. Are we confident that sending the same extension in both places is safe? I know that clients have to implement this and so should be able to test that this works, but it seems awkward. And it might not be necessary. It's also not sufficient, as we currently allow responses to ClientHello extensions to appear in Certificate (and for CertificateRequest to carry "requests" in the other direction). Perhaps we might avoid this problem entirely. ServerHello extensions are limited to key exchange. If we say that flags are limited (today) to functional properties that don't affect key exchange, my thought is that we don't lose much (if anything) by only allowing this extension in EncryptedExtensions. I don't know what I think about Certificate extensions. This seems to have a clear use there. Editorial: S1 It might be better to draw examples from the canon of published RFCs than to refer to things that might not get published. On Tue, Apr 7, 2020, at 00:53, Christopher Wood wrote: > This is the working group last call for the "A Flags Extension for TLS > 1.3" draft, available at: > > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ > > Please review the document and send your comments to the list by April > 20, 2020. The GitHub repository for this draft is available at: > > https://github.com/tlswg/tls-flags > > Thanks, > Chris, on behalf of the chairs > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Apr 7 10:08:34 2020 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 495DF3A041E for ; Tue, 7 Apr 2020 10:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=sn3rd.com 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 lTlZWte_UGaM for ; Tue, 7 Apr 2020 10:08:22 -0700 (PDT) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B386D3A08E5 for ; Tue, 7 Apr 2020 10:07:44 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id b62so106297qkf.6 for ; Tue, 07 Apr 2020 10:07:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=8X2mxWub5pMIWmzltsae8wSgnXbbeJ6ws9G8mLxzORg=; b=MrpeABToT/prFXKBwTH3ZmIB+p5JxW/0bhyIi5jA7JAf/CRB2IXkzOD0TKOeJ4rla0 9L//tXxJIjjRs1fVlizAN0hsDoLOZRMQQqLBtpyL+WuZF1YFDrjX15s8PU6I0mEjTp99 bxbuYCJziSAOCeuAIBXGd4nSj5IZQPzd2w854= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=8X2mxWub5pMIWmzltsae8wSgnXbbeJ6ws9G8mLxzORg=; b=AiIkUOWGbR3t8eggTz8KXBVVx9galWtMVCjuPcqWStr0ajrY+xrSskxRXaIIeEXbyO yZHmguOqn2JmAelI70dHTOymXRsDdV9N0wQsVZWJq/aCZKK+4EAE+cCZXnZme6+N7ZDQ i1pmwUcq+iqHAP5YQDvBk8y9AdunkyUcyMn31Nmp4eRvEF/WM7cBfjOUrJrwtYd2t8Ic 8/nOnH1d6p3yO+6UYCiCLAVbjncuvdyRECGjX/u1P1aPzDK7JmFCSw4gZunG/f5kuvwL yBmeQNyp45fYKLy+b7NWbGhBZ7XTaIJttQLvQPt7D2GcPpr1TQhBIOOr48h3mwWYfIyb zN+A== X-Gm-Message-State: AGi0PuZDboJMXJWqA5C4RbOFKZamZKtEFDsIi6jN4KNlKuPhmFg8qvkE BZGtsgczXP+0j2ALQ09pQmWH3G+ICF0= X-Google-Smtp-Source: APiQypI7aO3me4jA2C1PudBAGwjqKWiLj3c9jCHmy0IgwgQ8ZD7APCLnvhjf+GvhJCJpUvB6OZ5dlg== X-Received: by 2002:a05:620a:1185:: with SMTP id b5mr2804364qkk.24.1586279262404; Tue, 07 Apr 2020 10:07:42 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id z18sm18587013qtz.77.2020.04.07.10.07.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2020 10:07:41 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 7 Apr 2020 13:07:40 -0400 References: <4E07012F-AB53-4727-A309-D8A15222A433@sn3rd.com> <0E7E2E43-CC46-488E-981E-BF8417821D85@sn3rd.com> To: TLS List In-Reply-To: <0E7E2E43-CC46-488E-981E-BF8417821D85@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [TLS] consensus call: draft-ietf-tls-ticketrequests 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: Tue, 07 Apr 2020 17:08:30 -0000 hi TLS WG, Thank you for your input during the consensus call to add ticket reuse = text to draft-ietf-tls-ticketrequests. What we see are some very = strongly held positions on both sides of this issue, but what we do not = see is consensus to add text to support the ticket reuse case. What this = means is that the status quo from C.4 of RFC 8446 stands. The chairs do = not believe the SHOULD NOT from RFC 8446 needs to be repeated in this = draft. We will note however that we do see some potential for emerging = consensus to add a second counter. To expedite reaching consensus on = this point, we will run another separate consensus call to determine = whether to add a second counter. Likewise, we note that PR#18 [0] includes editorial changes as well as = text from PR#17 [1] that will be merged if we decide to add a second = counter. Joe and Sean [0] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18 [1] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/17 > On Mar 4, 2020, at 11:06, Sean Turner wrote: >=20 > one more time ... >=20 > All, >=20 > The purpose of this message is to help the chairs judge consensus on = the way forward for draft-ietf-tls-ticketrequests. The issue at hand is = whether the client-initiated ticket request mechanism [0] should be = modified to add support for ticket reuse, see [1] lines 160-214. As we = see it, the way forward involves either one draft or two. To that end, = we would like your input (YES or NO) on the following question by 2359 = UTC 18 March 2020: >=20 > Must the ticket reuse use case be addresses > in draft-ietf-tls-ticketrequests? >=20 > Full disclosure: RFC 8446 recommends against ticket reuse to help = protect clients from passive observers correlating connections [2]. The = PR supports ticket reuse for use cases for a server-to-server connection = that has fixed source addresses and no connection racing; if adopted the = WG will need to ensure that the security considerations are properly = documented. >=20 > Note: There have been at least three threads on this draft [3][4][5]. = Please, let=E2=80=99s try to avoid re-litigating the points made = therein. >=20 > Joe & Sean >=20 > [0] https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/ > [1] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18 > [2] https://tools.ietf.org/html/rfc8446#appendix-C.4 > [3] = https://mailarchive.ietf.org/arch/msg/tls/2cpoaJRushs09EFeTjPr-Ka3FeI/ > [4] = https://mailarchive.ietf.org/arch/msg/tls/-7J3gMmpHNw9t3URzxvM-3OaTR8/ > [5] = https://mailarchive.ietf.org/arch/msg/tls/FjhqbYYTwzgiV9weeCuxn0tHxPs/ From nobody Tue Apr 7 10:08:36 2020 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 D76813A041E for ; Tue, 7 Apr 2020 10:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=sn3rd.com 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 dwq12WqUg8T1 for ; Tue, 7 Apr 2020 10:08:28 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7383A08EB for ; Tue, 7 Apr 2020 10:07:53 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id y25so3256935qtv.7 for ; Tue, 07 Apr 2020 10:07:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=iucJstrGah7/E3qfOVzy6j6DIhCOs2pkXdgELv2lCLY=; b=kYAorqtZa8ysVX0Ek21hoIn8G0uyTInyO8sFo7/MY7adtiTLezcJAjy0bmtfkc11XI h2KcAkZ7/C39+miTtiIRG0NyKhrpy7WxqDTPNIXgcahedGIQ6qp2bOl37KM7A6FnhURr WjkWCGq8g+N2pwlmDioiqB13IX/5NLhN4J27U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=iucJstrGah7/E3qfOVzy6j6DIhCOs2pkXdgELv2lCLY=; b=ID84lsxuF/OLmjYsCRwVf0PMidz8nlbX0UQx4UdRv+s3ia0DnhJ/jjoQ5L9w7otZUr L2ASR1he23vXE+IaHQb5i+6hXm08qk2kmdvdpUgod+3q5D9bVXdrzJyCAfLVikEgIrH/ K7XQespJiTPL8HZaHFzvgBXHJyojixjL92b3YXlK5ggnlfrm08O8ZxqRc/SQAAABIIzQ UHUJVL6RRoD/FS/d4vgoE0GAFtLF+apBvby1LQdXH8Xq4pckPGi2+eWamz0JMfmcyGCB 6FIVDeJITIuEhEyCvG6df71y5lY0o1y6jaZfUbMcWNT9Cn+YulZbnvJFaA9VSAl/gNTN FLhQ== X-Gm-Message-State: AGi0Puairund0twqnTqbJYD48jFpy4geXtR/eYmlaHMd6AeQqbK4120k JmmY/q6ib4Uvy3k/xP3tkcoAleijGgY= X-Google-Smtp-Source: APiQypKQN/ZJbJTBN+DWcWQPw1FHXcwhZGqkht7GZmWxq5P4U6R4xKwzfCyyXuPETB4qwI0Tds/z2Q== X-Received: by 2002:aed:20e3:: with SMTP id 90mr3241191qtb.142.1586279265601; Tue, 07 Apr 2020 10:07:45 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id z18sm18587013qtz.77.2020.04.07.10.07.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Apr 2020 10:07:45 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Message-Id: Date: Tue, 7 Apr 2020 13:07:44 -0400 To: TLS List X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [TLS] 2nd consensus call: draft-ietf-tls-ticketrequests 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: Tue, 07 Apr 2020 17:08:31 -0000 hi TLS WG, During the consensus call to determine whether ticket reuse use cases = should be supported we did not see consensus to add that text, but we = did seem some potential emerging consensus to add a second field to the = extension; technically, it is to rename count->new_session_count and add = a new counter called resumption_count [0]. If you oppose this change, = please indicate on list by 2359 UTC 14 April 2020 and please state why. Joe and Sean [0] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/19= From nobody Tue Apr 7 17:08:35 2020 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 EE0463A0AD9 for ; Tue, 7 Apr 2020 17:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=iAguMKzL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ik+cWUpW 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 XNsnVQ1ugX5y for ; Tue, 7 Apr 2020 17:08:32 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4630A3A0AD5 for ; Tue, 7 Apr 2020 17:08:32 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 3D0855BE for ; Tue, 7 Apr 2020 20:08:31 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 07 Apr 2020 20:08:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=XCAFWTWOAyITNMzoP/y0usWP6k7ziSk Sv0J+JezjKL8=; b=iAguMKzLhEuPAe98Hi5WMjPViDyFsamEd/b/13oawFcr9b/ q42wnpMiv3KAk9Y2mpexwR3uNrXI0INkC8BzAUtYSALRtZuGBaiGvlvlBRwbYqVg rb/ZQkeUThHtORLQ3png0Ub1e/Weav64t0Tk0C2nF36AOlA/hY10HoTiDzFO5rWg E/mquryEkkDTyAJPIV54Cw3GplTEq6X8rDcDsUN8B1ldjcoBS3eN0vqD0nXOVMex n5yu6+EZsEqOdTHvuQfJdnLEx+BFZ0UKA5BS9pgcIHiLNSm2Yd66eAQlktiVluNg XZSaOI+gzH2qpR31d3BrEjAkp1XbU61D1lnf2vw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=XCAFWT WOAyITNMzoP/y0usWP6k7ziSkSv0J+JezjKL8=; b=ik+cWUpW01ovuPBj20rgin KL1pJywe5ywfQERUAJwL75+wDksjmgX7ffPr0AvnAGwqtllqbpscqP3mgEEzMfrm MrJU0SBxVBRyr+vIwBkFL69eg5q18+dutuIv4T88Qi9WZ1enepuFdi0U5WfQ/HEH W4QsyR8Ztt4b6xt0Xhnhzr4hrJzPlksZUMc88PxRnUla/jjWTmaVawULDhsmspNt QtfBiqKdfuRsQLoU8zGnmAfyO3nMWPr0mCLD9RsBBiO5V0fmcGfgOyvR2us8TZ6g e9ATlkSJclEX3wym6vSA6C1maffsTs+fHJIoakooljZg+l6N59xxMmmmGePNrKKg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeigdeftdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvth hfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 57511E00A6; Tue, 7 Apr 2020 20:08:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1084-gdc5e709-fmstable-20200406v2 Mime-Version: 1.0 Message-Id: <09bc4592-314f-4fe0-8b49-f18c367bed35@www.fastmail.com> In-Reply-To: References: Date: Wed, 08 Apr 2020 10:08:12 +1000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] 2nd consensus call: draft-ietf-tls-ticketrequests 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: Wed, 08 Apr 2020 00:08:34 -0000 I made a few comments on the pull request, but they are minor. Let's do this. On Wed, Apr 8, 2020, at 03:07, Sean Turner wrote: > hi TLS WG, > > During the consensus call to determine whether ticket reuse use cases > should be supported we did not see consensus to add that text, but we > did seem some potential emerging consensus to add a second field to the > extension; technically, it is to rename count->new_session_count and > add a new counter called resumption_count [0]. If you oppose this > change, please indicate on list by 2359 UTC 14 April 2020 and please > state why. > > Joe and Sean > > [0] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/19 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Apr 7 19:54:10 2020 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 3BBB23A085B for ; Tue, 7 Apr 2020 19:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 AbW-0t05P1ba for ; Tue, 7 Apr 2020 19:54:07 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3732B3A085A for ; Tue, 7 Apr 2020 19:54:07 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id h6so4024300lfc.0 for ; Tue, 07 Apr 2020 19:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kxGTgiJ3etV5Uf8b/1vzQVco5cjbDPF+YBoK+eFPejU=; b=YpXf8f7V5NORYC9pNk/dLppbDFEZRW8qZl6Tutsb28qjWGu1n4PMaAdQfYuVL40A8e EmIT22K6W/OdZe+Wd9Jxd0pLlSu82y1Ff6zsjx3gweIGRdzFDb1xMYW5S2/mFAP43/DR SsSihUKD2DuzsrrhwZoBl7uctPmY0ZDfH+wVTLkN210iN8b3KAFs5HaxCeBIzgEcu1uV 6ILamR2F9GHcQfSuZ4sfbF9GhuydZUv5JCNkpR3tD0NCI2HAJm7FQIa61IurQt/WPIcO X4pr9EZJ0fcFKs86EFDtFhYt794IO1bzN5FEy9n3wLR3+LgClURZRJLiIKDxBeap+Br1 FqQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kxGTgiJ3etV5Uf8b/1vzQVco5cjbDPF+YBoK+eFPejU=; b=mRBzmR//AxrYmeNFp4Wy8Vv+7525n7ELdg6GlyNQ+mnS4ZSg5LdUdSyKvvmtaU+F7W lHxO+686jzgwLq/SczKOMqBbZEC9bS6rTOqEsj7PIQHNh6uUYYp68BeAwT1d17I6wmVu sNVuvfSs5bqu7lbslUkXcVpXGvDxxBaQrs9YCNsu/i6PfJSU4lw6cdXP/8LZPEibdrCP ijcZGowPpbKPfBTSp5Ps1B+KrGxvuyHQVoVUWOgf0lWZ4s2htl7GqBxOZl3PJsa6JK11 4tC+T7PfZr6i/7WOfb3jU8GLQsepWhO42nj5gG8rLANRKydrYLLhOwErJpDhWBAXFDWc HMLQ== X-Gm-Message-State: AGi0Pubub5rlQtmXnLikmwdGvDSqN28MMg4c6suAchkpEp1ltpfD9rvx VridWOxg/34ep0p3MhDJtomeLqIdG4JMOfdHZiRfoIHO8uc= X-Google-Smtp-Source: APiQypKw8V/VZ5mC5kdp4miJL6CSIzGo1Da5LiIiePlLh91lIboQQUbprspXIuiKMrmzS3qBHCGL7g1MLQaKUOlsH58= X-Received: by 2002:a19:9141:: with SMTP id y1mr3099958lfj.168.1586314445317; Tue, 07 Apr 2020 19:54:05 -0700 (PDT) MIME-Version: 1.0 References: <09bc4592-314f-4fe0-8b49-f18c367bed35@www.fastmail.com> In-Reply-To: <09bc4592-314f-4fe0-8b49-f18c367bed35@www.fastmail.com> From: Eric Rescorla Date: Tue, 7 Apr 2020 19:53:29 -0700 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="00000000000003fca705a2be9d50" Archived-At: Subject: Re: [TLS] 2nd consensus call: draft-ietf-tls-ticketrequests 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: Wed, 08 Apr 2020 02:54:09 -0000 --00000000000003fca705a2be9d50 Content-Type: text/plain; charset="UTF-8" I also made a number of comments, but I think it's roughly fine. -Ekr On Tue, Apr 7, 2020 at 5:08 PM Martin Thomson wrote: > I made a few comments on the pull request, but they are minor. Let's do > this. > > On Wed, Apr 8, 2020, at 03:07, Sean Turner wrote: > > hi TLS WG, > > > > During the consensus call to determine whether ticket reuse use cases > > should be supported we did not see consensus to add that text, but we > > did seem some potential emerging consensus to add a second field to the > > extension; technically, it is to rename count->new_session_count and > > add a new counter called resumption_count [0]. If you oppose this > > change, please indicate on list by 2359 UTC 14 April 2020 and please > > state why. > > > > Joe and Sean > > > > [0] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/19 > > _______________________________________________ > > 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 > --00000000000003fca705a2be9d50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also made a number of comments, but I think it'= s roughly fine.

-Ekr


On Tu= e, Apr 7, 2020 at 5:08 PM Martin Thomson <mt@lowentropy.net> wrote:
I made a few comments on the pull request, but they= are minor.=C2=A0 Let's do this.

On Wed, Apr 8, 2020, at 03:07, Sean Turner wrote:
> hi TLS WG,
>
> During the consensus call to determine whether ticket reuse use cases =
> should be supported we did not see consensus to add that text, but we =
> did seem some potential emerging consensus to add a second field to th= e
> extension; technically, it is to rename count->new_session_count an= d
> add a new counter called resumption_count [0]. If you oppose this
> change, please indicate on list by 2359 UTC 14 April 2020 and please <= br> > state why.
>
> Joe and Sean
>
> [0] https://github.com/tlswg/draft= -ietf-tls-ticketrequest/pull/19
> _______________________________________________
> 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
--00000000000003fca705a2be9d50-- From nobody Wed Apr 8 05:40:35 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 451A43A0770; Wed, 8 Apr 2020 05:40:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.124.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <158634963321.22489.6583170356182202899@ietfa.amsl.com> Date: Wed, 08 Apr 2020 05:40:33 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-external-psk-importer-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 08 Apr 2020 12:40:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Importing External PSKs for TLS Authors : David Benjamin Christopher A. Wood Filename : draft-ietf-tls-external-psk-importer-04.txt Pages : 11 Date : 2020-04-07 Abstract: This document describes an interface for importing external Pre- Shared Keys (PSKs) into TLS 1.3. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-04 https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-external-psk-importer-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Apr 8 05:42:23 2020 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 5A78C3A0770 for ; Wed, 8 Apr 2020 05:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=TWGQwNDE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XhQ+4A4R 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 HV7CQReZNBDg for ; Wed, 8 Apr 2020 05:42:16 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DAEF3A0991 for ; Wed, 8 Apr 2020 05:42:03 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 540AF5C0083 for ; Wed, 8 Apr 2020 08:42:02 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Wed, 08 Apr 2020 08:42:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=gRcJetZ4zkKv8JsIIslAiceFW4V9vyH hWEjR6Z8MFJU=; b=TWGQwNDEbeQSy6QQDWpb8u+cvawrShkHce7iiN1YzyeRWHJ HUjRTsXOntlQ+9aiokCemCqOUkYg4mdOhhHi4iCh+X20YcbZkKfJImB9QnqO3D3E pcjzAGBjC9RAK5jym2fvU4Z6D/+DrvGNfzLgBxxbaWDrld9/Y/a9iQ7TimrhE3fe MooDh+WFmr8w6v1DMELxZwCxmncIghTBvQ1QUCj5jrUjrSX/ZhroFZsOmrR9eWug NDCcHLfOeufhaXbgCOkUob0+aMi7empYp5hHKvxWDgkUC/h0ArxVCMNQgOtiiqZI b/BPqKep0/NtrSELmHLP1xJJLMMpvZ2deXmxDjw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=gRcJet Z4zkKv8JsIIslAiceFW4V9vyHhWEjR6Z8MFJU=; b=XhQ+4A4Ru+2S5H71RxkB6c 7IrNRdRz7z5EnnVQIYs0fIl/xFmF3mRL1DOn+umh0kALpLBHQmZ9annkZgsyjc1l c5wxLffH3/mxKJEWko92kfl9m9EIm0SvDDkiG4ZrjCyPAewpvNtHVkTkzHgM2Jfc MBM89QR/Dcbmk9tVVKQ74ExjpSYwJavzCPgDJwLK8S5Lud9h4MfoC+WRcE0fJSiy +uTS+lNWfjH7pNCpdEN9jh10ihZWESQGWT7JKg3x8wYBNqF0OdeLAx6aXbRbFR4z YRu+nTv4xLFYeV43Sut7X/6+n6Am0BLShc2xYjWljInK25uFEmAnB8jps+K6wQIg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudejgdehgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomh dpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F2B2B3C00A1; Wed, 8 Apr 2020 08:42:01 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1104-g203475c-fmstable-20200408v2 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 08 Apr 2020 05:41:41 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-external-psk-importer 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: Wed, 08 Apr 2020 12:42:21 -0000 I merged this PR and submitted a new version. Thanks, all! Best, Chris On Mon, Mar 30, 2020, at 8:26 AM, Joseph Salowey wrote: > The working group last call for draft-ietf-tls-external-psk-importer > has completed. There is one PR for the document to address the WGLC > comments - > > https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/28 > > There is no consensus to adopt the proposed key schedule change > proposed by Jonathan. If no objections are raised to the new text in > the PR the authors should incorporate the PR and submit a revision on > Friday April 3. > > Thanks, > > Sean and Joe > > On Thu, Feb 20, 2020 at 4:45 PM Joseph Salowey wrote: > > Hi Folks, > > > > This is the working group last call for the "Importing External PSKs" draft available at https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-importer/. Please review the document and send your comments to the list by 2359 UTC on 6 March 2020. > > > > Note the the GH repo for this draft can be found at: https://github.com/tlswg/draft-ietf-tls-external-psk-importer > > > > Thanks, > > > > Sean and Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Apr 8 06:14:07 2020 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 125AC3A0AE8; Wed, 8 Apr 2020 06:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-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=ericsson.com 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 kaJnFwiXyWKJ; Wed, 8 Apr 2020 06:13:40 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2055.outbound.protection.outlook.com [40.107.22.55]) (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 2F0CB3A0AEA; Wed, 8 Apr 2020 06:13:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WGe9g7feu0nQsvLT5aZr1NcgLowNymH73ELShPyY6zhNDpzeiIp216BUgWX4/qhBRRieh3N1WknY3Mhb3/wAEG7zY1soLuvNULbSPjQj/HW8ufaSrySnGe0US6mKzpE/yVunbKBghZPa0t4OcfELw56s4JKL7GcxGygdg9D0juXEgF3WqWj7MLkfoK0YM24bgQTVxllxtPbsSducDzWiCc9e/6p/PC8mip66X7nDwYU+r7rGEur/GW0/MRXPvGhISwbxjqTSI4lmkC1ehN2oX3DRLHpVZDvfKCJhg3cA3NT41YcVzx73lVK62Xyd2+W4ntuwpJDe9TX5P9LVDneFEg== 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=r+NRmtFr4YKV0u0N8ASfBZZiq0PhS3N3j0Smj6akyoo=; b=GfEnMJJBYV9w5M6Mgk2z+JFuPBRogAjEiZGlEE/Caqj1+Xn1xXSXhH4ivGgrQMOhQhQcojSqYslWUMLNQ37v6fvHqTsfm36I+ASIetCmfbtonF8KRvc5qhAq+V+ETeKvkdas5qO75AwJAaO5RlOlnX9b8XTONYgA5AYlucQ5FMhT/fclTs9u9cEbVqr03IcdVJKKN7/9oM8QWjeLYfgtz6qsXZkZ/wpyZwUV7hQu/bQlOnCeTsNpF66l5sNzszw1qjFInfuFsENkTGTRq78UAeXImISTeI0sP3Z3Fuwn1avOwiW+/wqysfO0GCOmhQnt4ggGowxi1ojb85oqEJZahw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r+NRmtFr4YKV0u0N8ASfBZZiq0PhS3N3j0Smj6akyoo=; b=Ca0reI4y9XPJ2IOkxWJrL2zgJdz5a9sq4CUvdBaV3AqOvLt2KlC0zhY1UlK//cQRcIBu3VJXSv0dgjmltOh+aoUIT4o+Kvdxlcb1kMPZTfbMOaiOMDu8JVYEf2F9SfOV4bXM7aZr9tjO2nHujrHwyVimrJ96NWsqWaBPpHXsVNg= Received: from AM6PR07MB4584.eurprd07.prod.outlook.com (2603:10a6:20b:17::24) by AM6PR07MB5814.eurprd07.prod.outlook.com (2603:10a6:20b:9d::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.12; Wed, 8 Apr 2020 13:13:37 +0000 Received: from AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::928:dc19:896b:4b91]) by AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::928:dc19:896b:4b91%6]) with mapi id 15.20.2900.015; Wed, 8 Apr 2020 13:13:37 +0000 From: John Mattsson To: Hannes Tschofenig , "tls@ietf.org" , "uta@ietf.org" Thread-Topic: [TLS] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS Thread-Index: AQHWDaeDkPpKX8oyt0iX3UQ9nri0Dg== Date: Wed, 8 Apr 2020 13:13:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8ac83013-b3a8-411f-2014-08d7dbbea650 x-ms-traffictypediagnostic: AM6PR07MB5814: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0367A50BB1 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB4584.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(39860400002)(136003)(396003)(366004)(376002)(6506007)(53546011)(316002)(110136005)(91956017)(44832011)(81166007)(6512007)(2616005)(66574012)(64756008)(966005)(2906002)(6486002)(186003)(478600001)(66476007)(26005)(86362001)(66556008)(66946007)(8936002)(33656002)(71200400001)(5660300002)(76116006)(8676002)(36756003)(66446008)(81156014); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8wN1OYwyIRohFts5axjyEA5MwyQjQ7lmqLBennKjmxk2C5Ub9jCWTy81w/sD525aqxLQUioTYUdwiuZXa42kzHVi2Epz3mzAPqqCvqAH/RdB6UKTLNTpsRBQLgKBb8uJibXh1XovrR2BiU8cAjZrfxD2TvUNwy3HXsFzqr6PWrTMDYtnT/Ju0ye4FnYrOyYaz5YbnNLJVXPyl5CAdboRlEP4x8BHoJp6bSkheA2PYdPYzc1v7ACRjE91au8Fg2Wua0HuftGP84Qv7U41bRlL2UewltwmNUuUUON6YQIu9QRwzYH6ApR53xZmfwOG7vqhQdmM0tZOOqy5B+DD7pt50X97Cb239llvlKpEj3/HGasxwCBmaWPKZgQoV8fUYCYw+qBNXg0h6w0zGJRbHcG8Ie0exPDiQfCvRPsjz255qJawjv5G5Juegh4eWsyTgRlo0vsUmiifE3fwudton47GRgZuktJ8zC9qnbnocomrMKUIAa0Kws6SCq6Kt64pQg2fMHnh2oZWXN3dCGF4ubsqWw== x-ms-exchange-antispam-messagedata: UFC7n0S6ddiM4JS7B0h0OchNT3sHuxBgEiZy9yrr0fNc7tJHSHDYMPfNyS8UAJA6z+ygqxSBQd/WZRJQVQ67DGyzX/9zLXj3NCfAOl9HWidEnQNvg9GMsHn7zHqFBg7JOY8Ucyj8NENbhoYD4e2GPg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <67D9E2F5166C6F418B0A46D5A3095A37@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8ac83013-b3a8-411f-2014-08d7dbbea650 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2020 13:13:37.5043 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DmNdBbgx8YDcou9wEPxGktSQELYVaQ1Q+VjVAVmOTrlqntZVhxgAL7UO0+yjtmpeLRIkU5rPBkfcFH4SipHY2K+fVZ+JvZuHUZor+dfRFwo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5814 Archived-At: Subject: Re: [TLS] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS 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: Wed, 08 Apr 2020 13:13:46 -0000 SGkgSGFubmVzLA0KDQpJIGhhdmUgcmVxdWVzdGVkIGFuZCBiZWVuIGFzc2lnbmVkIHRpbWUgZm9y IGRyYWZ0LW1hdHRzc29uLXRscy1jYm9yLWNlcnQtY29tcHJlc3MtMDAgYW5kIGRyYWZ0LXJhemEt YWNlLWNib3ItY2VydGlmaWNhdGVzLTA0IGF0IHRoZSBVVEEgdmlydHVhbCBpbnRlcmltIG9uIE1h cmNoIDIzLg0KDQpXZSBoYXZlIGFuIGltcGxlbWVudGF0aW9uIG9mIGh0dHBzOi8vbGluay5zcHJp bmdlci5jb20vY2hhcHRlci8xMC4xMDA3JTJGOTc4LTMtMzE5LTkzNzk3LTdfMTQgLyBkcmFmdC1y YXphLWFjZS1jYm9yLWNlcnRpZmljYXRlcy0wMywgYnV0IHRoZSBjb2RlIGlzIG5vdCB3cml0dGVu IGluIGEgd2F5IHNvIHRoYXQgdGhlIGNvbXByZXNzaW9uIG1lY2hhbmlzbSBERVItPiBDQk9SIGNh biBiZSBleHRyYWN0ZWQuIFRoZSBleGFtcGxlIGluIGRyYWZ0LXJhemEtYWNlLWNib3ItY2VydGlm aWNhdGVzLTA0IHdhcyBjcmVhdGVkIGJ5IGhhbmQgd2l0aCBjYm9yLm1lLiBXZSBhcmUgcGxhbm5p bmcgdG8gaW1wbGVtZW50IGEgdXBkYXRlZCBzdGFuZGFsb25lIHZlcnNpb24gb2YgdGhlIERFUi0+ Q0JPUiBjb21wcmVzc2lvbiBhbmQgaG9wZWZ1bGx5IGhhdmUgaW50ZXJvcCB0ZXN0aW5nIGluIHRo ZSBDT1NFIFdHLg0KDQpDaGVlcnMsDQpKb2huDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSGFubmVz IFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+DQpEYXRlOiBGcmlkYXksIDMg QXByaWwgMjAyMCBhdCAxNDoyMA0KVG86IEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb249NDBl cmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+LCAiVExTQGlldGYub3JnIiA8dGxzQGlldGYub3Jn PiwgInV0YUBpZXRmLm9yZyIgPHV0YUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVExTXSBDQk9S IENlcnRpZmljYXRlIENvbXByZXNzaW9uIG9mIFJGQyA3OTI1IGNlcnRpZmljYXRlcyBzdWl0YWJs ZSBmb3IgY1RMUw0KDQogICAgSGkgSm9obiwNCiAgICANCiAgICBUaGFua3MgZm9yIHRoZSBoZWFk cy11cC4NCiAgICANCiAgICBEaXNjdXNzaW5nIHRoaXMgYXNwZWN0IGluIGRyYWZ0LXRzY2hvZmVu aWctdXRhLXRsczEzLXByb2ZpbGUtMDEgbWFrZXMgc2Vuc2UuDQogICAgDQogICAgSSB3YXMgd29u ZGVyaW5nIHdoZXRoZXIgeW91IGhhdmUgYmVlbiB3b3JraW5nIG9uIGFuIGltcGxlbWVudGF0aW9u IG9mIGRyYWZ0LW1hdHRzc29uLWNvc2UtY2Jvci1jZXJ0LWNvbXByZXNzLTAwIC8gZHJhZnQtcmF6 YS1hY2UtY2Jvci1jZXJ0aWZpY2F0ZXMtMDQuDQogICAgDQogICAgQ2lhbw0KICAgIEhhbm5lcw0K ICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTogVExTIDx0bHMt Ym91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEpvaG4gTWF0dHNzb24NCiAgICBTZW50OiBG cmlkYXksIEFwcmlsIDMsIDIwMjAgOTowMyBBTQ0KICAgIFRvOiBUTFNAaWV0Zi5vcmc7IHV0YUBp ZXRmLm9yZw0KICAgIFN1YmplY3Q6IFtUTFNdIENCT1IgQ2VydGlmaWNhdGUgQ29tcHJlc3Npb24g b2YgUkZDIDc5MjUgY2VydGlmaWNhdGVzIHN1aXRhYmxlIGZvciBjVExTDQogICAgDQogICAgSGks DQogICAgDQogICAgRHVyaW5nIHRoZSBDT1NFIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIHllc3Rl cmRheSwgdGhlcmUgd2FzIGFncmVlbWVudCB0aGF0IHRoZSBDT1NFIHdvcmtpbmcgZ3JvdXAgc2hv dWxkIHdvcmsgb24gQ0JPUiBjb21wcmVzc2lvbiBvZiBSRkMgNzkyNSBwcm9maWxlZCBYLjUwOSBj ZXJ0aWZpY2F0ZXMuIFRoZSB3b3JrIHdpbGwgYmUgYmFzZWQgb24gZHJhZnQtcmF6YS1hY2UtY2Jv ci1jZXJ0aWZpY2F0ZXMgYW5kIGRyYWZ0LW1hdHRzc29uLWNvc2UtY2Jvci1jZXJ0LWNvbXByZXNz IGFuZCB0aGUgdHdvIGRyYWZ0cyB3aWxsIGJlIG1lcmdlZC4gRG9pbmcgdGhpcyB3b3JrIGluIGEg c2VjdXJpdHkgZ3JvdXAgZm9jdXNlZCBvbiBDQk9SIG1ha2VzIGEgbG90IG9mIHNlbnNlLg0KICAg IA0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0c3Nvbi1jb3NlLWNi b3ItY2VydC1jb21wcmVzcy0wMA0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1yYXphLWFjZS1jYm9yLWNlcnRpZmljYXRlcy0wNA0KICAgIA0KICAgIFRoZSBDT1NFIGRyYWZ0 IGNoYXJ0ZXIgaGFzIGFscmVhZHkgYmVlbiB1cGRhdGVkIHRvIHJlZmxlY3QgdGhpcy4NCiAgICAN CiAgICBodHRwczovL2dpdGh1Yi5jb20vY29zZS13Zy9DaGFydGVyL2Jsb2IvbWFzdGVyL0NoYXJ0 ZXIubWQNCiAgICANCiAgICBBcyB0aGUgYWxnb3JpdGhtIGlzIGZvY3VzZWQgb24gY29tcHJlc3Np bmcgUkZDIDc5MjUgcHJvZmlsZWQgY2VydGlmaWNhdGVzLCBJdCBzZWVtcyBsaWtlIGEgdmVyeSBn b29kIG1hdGNoIGZvciBjVExTLiBUbyBrZWVwIHRoZSBudW1iZXIgb2YgaW50ZXJuZXQtZHJhZnRz IGRvd24sIEkgcGxhbiB0byBhbHNvIGluY2x1ZGUgdGhlIFRMUyBJQU5BIHJlZ2lzdHJhdGlvbnMg aW4gdGhlIG1lcmdlZCBkcmFmdCBzdWJtaXR0ZWQgdG8gdGhlIENPU0UgV0cgYW5kIGxldCBkcmFm dC1tYXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNvbXByZXNzLTAwIGV4cGlyZS4NCiAgICANCiAgICBB bnkgY29tbWVudHMgZnJvbSB0aGUgVExTIFdHIGFyZSB2ZXJ5IHdlbGNvbWUsIGJ1dCBvdGhlcndp c2UgdGhlc2UgaXMgbm90IHNvIG11Y2ggdG8gZGlzY3VzcywgdGhpcyBpcyBqdXN0IGFub3RoZXIg Y2VydGlmaWNhdGUgY29tcHJlc3Npb24gYWxnb3JpdGhtLiBBbnkgVExTIHJlbGF0ZWQgZGlzY3Vz c2lvbnMgd291bGQgbGlrZWx5IGJlIHJlZ2FyZGluZyB0aGUgY2VydGlmaWNhdGUgcHJvZmlsZSBp biBSRkMgNzkyNSBhbmQgaWYgYW55IGNsYXJpZmljYXRpb25zIG9yIHVwZGF0ZXMgYXJlIG5lZWRl ZC4gVGhpcyBpcyBsaWtlbHkgYmVzdCBkaXNjdXNzZWQgaW4gVVRBIHdoaWNoIG1heSB0YWtlIHVw IHdvcmsgb24gYSBUTFMvRFRMUyAxLjMgdXBkYXRlIG9mIFJGQyA3OTI1Lg0KICAgIA0KICAgIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10c2Nob2ZlbmlnLXV0YS10bHMxMy1wcm9m aWxlLTAxDQogICAgDQogICAgQ2hlZXJzLA0KICAgIEpvaG4NCiAgICANCiAgICAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb25A ZXJpY3Nzb24uY29tPg0KICAgIERhdGU6IFRodXJzZGF5LCAxMiBNYXJjaCAyMDIwIGF0IDA4OjU4 DQogICAgVG86ICJUTFNAaWV0Zi5vcmciIDxUTFNAaWV0Zi5vcmc+DQogICAgQ2M6ICJ1dGFAaWV0 Zi5vcmciIDx1dGFAaWV0Zi5vcmc+DQogICAgU3ViamVjdDogRlc6IE5ldyBWZXJzaW9uIE5vdGlm aWNhdGlvbiBmb3IgZHJhZnQtbWF0dHNzb24tdGxzLWNib3ItY2VydC1jb21wcmVzcy0wMC50eHQN CiAgICANCiAgICAgICAgSGksDQogICAgDQogICAgICAgIFdlIGhhdmUgc3VibWl0dGVkIGEgbmV3 IGRyYWZ0IHRvIFRMUyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWF0dHNzb24t dGxzLWNib3ItY2VydC1jb21wcmVzcy0wMCBUaGUgZHJhZnQgcmVnaXN0ZXIgYSBuZXcgY29tcHJl c3Npb24gYWxnb3JpdGhtcyBmb3IgdXNlIHdpdGggVExTIENlcnRpZmljYXRlIENvbXByZXNzaW9u IGluIFRMUyAxLjMgYW5kIERUTFMgMS4zIChkcmFmdC1pZXRmLXRscy1jZXJ0aWZpY2F0ZS1jb21w cmVzc2lvbikuDQogICAgDQogICAgICAgIFRoZSBkcmFmdCB1c2VzIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1yYXphLWFjZS1jYm9yLWNlcnRpZmljYXRlcy0wNCB0byBjb21wcmVz cyBSRkMgNzkyNSBwcm9maWxlcyBjZXJ0aWZpY2F0ZXMgYnkgZW5jb2RpbmcgdGhlbSBmcm9tIERF UiB0byBDQk9SLiBUaGUgYWltIGlzIHRvIGJlIGNvbXBhdGlibGUgd2l0aCBhbGwgUkZDIDc5MjUg cHJvZmlsZWQgY2VydGlmaWNhdGVzLiBXaXRoIHRoZSBpbmNsdWRlZCBleGFtcGxlIERFUiBlbmNv ZGVkIFJGQyA3OTI1IGNlcnRpZmljYXRlIHRvIGNlcnRpZmljYXRlIGlzIGNvbXByZXNzZWQgZnJv bSAzMTQgdG8gMTM2IGJ5dGVzLCBhIGNvbXByZXNzaW9uIHJhdGUgb2YgNTclLg0KICAgIA0KICAg ICAgICBUaGUgZ2VuZXJhbCBwdXJwb3NlIGNvbXByZXNzaW9uIGFsZ29yaXRobXMgZGVmaW5lZCBp biBkcmFmdC1pZXRmLXRscy1jZXJ0aWZpY2F0ZS1jb21wcmVzc2lvbiBkbyBub3Qgc2VlbSBhYmxl IHRvIGNvbXByZXNzIHByb2ZpbGVkIFJGQyA3OTI1IFguNTA5IGNlcnRpZmljYXRlcyBtdWNoIGF0 IGFsbC4gemxpYiBjb21wcmVzc2VkIHRoZSBleGFtcGxlIGNlcnQgOSUsIGJ1dCBmb3Igb3RoZXIg Y2VydGlmaWNhdGVzIHdlIHRlc3RlZCwgemxpYiBkaWQgaW4gbWFueSBjYXNlcyBub3QgcHJvdmlk ZSBhbnkgY29tcHJlc3Npb24gYXQgYWxsLg0KICAgIA0KICAgICAgICBXZSBoYXZlIHN1Ym1pdHRl ZCBhIHNpbWlsYXIgZHJhZnQgdG8gdGhlIENPU0UgV0cgcmVnaXN0ZXJpbmcgYSBuZXcgYWxnb3Jp dGhtcyBmb3IgdGhlIFRMUyAxLjMgY2VydGlmaWNhdGUgY29tcHJlc3Npb24gZXh0ZW5zaW9uLg0K ICAgIA0KICAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWF0dHNzb24t dGxzLWNib3ItY2VydC1jb21wcmVzcy0wMA0KICAgIA0KICAgICAgICBDaGVlcnMsDQogICAgICAg IEpvaG4NCiAgICANCiAgICAgICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICAgICAg RnJvbTogImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9y Zz4NCiAgICAgICAgRGF0ZTogTW9uZGF5LCA5IE1hcmNoIDIwMjAgYXQgMjE6MTkNCiAgICAgICAg VG86IEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb25AZXJpY3Nzb24uY29tPiwgSm9obiBNYXR0 c3NvbiA8am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20+LCBKb2VsIEjDtmdsdW5kIDxqb2VsLmhv Z2x1bmRAcmkuc2U+LCBKb2VsIEhvZ2x1bmQgPGpvZWwuaG9nbHVuZEByaS5zZT4sIEfDtnJhbiBT ZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPiwgTWFydGluIEZ1cnVoZWQgPG1h cnRpbi5mdXJ1aGVkQG5leHVzZ3JvdXAuY29tPiwgR8O2cmFuIFNlbGFuZGVyIDxnb3Jhbi5zZWxh bmRlckBlcmljc3Nvbi5jb20+LCBTaGFoaWQgUmF6YSA8c2hhaGlkLnJhemFAcmkuc2U+DQogICAg ICAgIFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWF0dHNzb24t dGxzLWNib3ItY2VydC1jb21wcmVzcy0wMC50eHQNCiAgICANCiAgICANCiAgICAgICAgICAgIEEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tYXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNvbXByZXNz LTAwLnR4dA0KICAgICAgICAgICAgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBK b2huIFByZXVzcyBNYXR0c3NvbiBhbmQgcG9zdGVkIHRvIHRoZQ0KICAgICAgICAgICAgSUVURiBy ZXBvc2l0b3J5Lg0KICAgIA0KICAgICAgICAgICAgTmFtZTpkcmFmdC1tYXR0c3Nvbi10bHMtY2Jv ci1jZXJ0LWNvbXByZXNzDQogICAgICAgICAgICBSZXZpc2lvbjowMA0KICAgICAgICAgICAgVGl0 bGU6Q0JPUiBDZXJ0aWZpY2F0ZSBBbGdvcml0aG0gZm9yIFRMUyBDZXJ0aWZpY2F0ZSBDb21wcmVz c2lvbg0KICAgICAgICAgICAgRG9jdW1lbnQgZGF0ZToyMDIwLTAzLTA5DQogICAgICAgICAgICBH cm91cDpJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCiAgICAgICAgICAgIFBhZ2VzOjYNCiAgICAgICAg ICAgIFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtbWF0dHNzb24tdGxzLWNib3ItY2VydC1jb21wcmVzcy0wMC50eHQNCiAgICAgICAgICAg IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1t YXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNvbXByZXNzLw0KICAgICAgICAgICAgSHRtbGl6ZWQ6ICAg ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0c3Nvbi10bHMtY2Jvci1j ZXJ0LWNvbXByZXNzLTAwDQogICAgICAgICAgICBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tYXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNv bXByZXNzDQogICAgDQogICAgDQogICAgICAgICAgICBBYnN0cmFjdDoNCiAgICAgICAgICAgICAg IENlcnRpZmljYXRlIGNoYWlucyBvZnRlbiB0YWtlIHVwIHRoZSBtYWpvcml0eSBvZiB0aGUgYnl0 ZXMNCiAgICAgICAgICAgICAgIHRyYW5zbWl0dGVkIGluIFRMUyBoYW5kc2hha2VzLiAgTGFyZ2Ug aGFuZHNoYWtlcyBjYW4gY2F1c2UgcHJvYmxlbXMsDQogICAgICAgICAgICAgICBwYXJ0aWN1bGFy bHkgaW4gY29uc3RyYWluZWQgSW9UIGVudmlyb25tZW50cy4gIFJGQyA3OTI1IGRlZmluZXMgYSBU TFMNCiAgICAgICAgICAgICAgIGNlcnRpZmljYXRlIHByb2ZpbGUgZm9yIGNvbnN0cmFpbmVkIElv VC4gIEdlbmVyYWwgcHVycG9zZSBjb21wcmVzc2lvbg0KICAgICAgICAgICAgICAgYWxnb3JpdGht cyBjYW4gaW4gbWFueSBjYXNlcyBub3QgY29tcHJlc3MgUkZDIDc5MjUgcHJvZmlsZWQNCiAgICAg ICAgICAgICAgIGNlcnRpZmljYXRlcyBhdCBhbGwuICBCeSB1c2luZyB0aGUgZmFjdCB0aGF0IHRo ZSBjZXJ0aWZpY2F0ZXMgYXJlDQogICAgICAgICAgICAgICBwcm9maWxlZCwgdGhlIENCT1IgY2Vy dGlmaWNhdGUgY29tcHJlc3Npb24gYWxnb3JpdGhtcyBjYW4gaW4gbWFueQ0KICAgICAgICAgICAg ICAgY2FzZXMgY29tcHJlc3MgUkZDIDc5MjUgcHJvZmlsZWQgY2VydGlmaWNhdGVzIHdpdGggb3Zl ciA1MCUuIFRoaXMNCiAgICAgICAgICAgICAgIGRvY3VtZW50IHNwZWNpZmllcyB0aGUgQ0JPUiBj ZXJ0aWZpY2F0ZSBjb21wcmVzc2lvbiBhbGdvcml0aG0gZm9yIHVzZQ0KICAgICAgICAgICAgICAg d2l0aCBUTFMgQ2VydGlmaWNhdGUgQ29tcHJlc3Npb24gaW4gVExTIDEuMyBhbmQgRFRMUyAxLjMu DQogICAgDQogICAgDQogICAgDQogICAgDQogICAgICAgICAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u DQogICAgICAgICAgICB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZh aWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KICAgIA0KICAgICAgICAgICAgVGhlIElFVEYgU2Vj cmV0YXJpYXQNCiAgICANCiAgICANCiAgICANCiAgICANCiAgICANCiAgICANCiAgICBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFRMUyBtYWlsaW5n IGxpc3QNCiAgICBUTFNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Rscw0KICAgIElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlz IGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28g YmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhl IGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9y IHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4N CiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAg IFRMUyBtYWlsaW5nIGxpc3QNCiAgICBUTFNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KICAgIA0KDQo= From nobody Wed Apr 8 06:29:51 2020 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 C2B953A08B5; Wed, 8 Apr 2020 06:29:44 -0700 (PDT) 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, 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=JUxd0aNT; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=JUxd0aNT 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 rPPLRNl1esJQ; Wed, 8 Apr 2020 06:29:42 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on20610.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1a::610]) (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 C78AC3A08B2; Wed, 8 Apr 2020 06:29:41 -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=tMGdBfbxP6DbfpEyTF6H+3T9GPezvwy8RivVOTIgg4w=; b=JUxd0aNT1L2dAAK1g06+yD3gY76jyfSSucHnSjfnH45WI+NHX8dvCryD6U6UZgu1Xtn/PpOZbuOdlAnqDnvnF+ahcDmw97B+mcdTGxTpi/aRvTvvyhBGMpCNswVVq1x+ukIB8oGObpI7YqiqpqTY8Rc2OTaqLT29+Tkb664G8Nc= Received: from AM0P190CA0022.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:190::32) by AM5PR0801MB1857.eurprd08.prod.outlook.com (2603:10a6:203:4e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Wed, 8 Apr 2020 13:29:38 +0000 Received: from VE1EUR03FT052.eop-EUR03.prod.protection.outlook.com (2603:10a6:208:190:cafe::3a) by AM0P190CA0022.outlook.office365.com (2603:10a6:208:190::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Wed, 8 Apr 2020 13:29:38 +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 VE1EUR03FT052.mail.protection.outlook.com (10.152.19.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Wed, 8 Apr 2020 13:29:37 +0000 Received: ("Tessian outbound eadf07c3b4bb:v50"); Wed, 08 Apr 2020 13:29:37 +0000 X-CR-MTA-TID: 64aa7808 Received: from 5165e4a73be1.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 04AC9452-8B02-40CD-9B10-BCE23A5F3C52.1; Wed, 08 Apr 2020 13:29:32 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 5165e4a73be1.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 08 Apr 2020 13:29:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NIw41vm9H+SvSVfAVNxAAlZCa2yQsw5xmi2uGwAsQ9xsXWxLc6S0prvfB/fcrRH7+paM9ZZeSMAl4r0XcwWQNrXrcAxKt0uyYxmt/U2WJ24MiHMJloJjvN6vhCWaAGy5M9YOy4hufW1o0lmRkoYYtx6inVdyGbGD0DJh01/XR9DcZtAtsDjHWL9LJXOM28pte1Sru0X/nBFZJlsixlxljFNNsu4wmv4VXNDUjfO5HUvlP0d72xuXXZvOmtoz+hEWN+0vsPatBWFSJVpMEC2/d0T547KDq0LXI/hi0eHlG6tsc7DQZB0d4qaI35Csb0W6cYddwg/N4dyhVwAHhu3gEw== 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=tMGdBfbxP6DbfpEyTF6H+3T9GPezvwy8RivVOTIgg4w=; b=k+G1aJ0U8JI+L6IrN+PobIMB0MShi/AI7bybwmvm6juZMwEwoJP8AgLMC7lEy3YU9A9mlTHxR4yokQRVv92kvDTA131RkRcxIr/9SnfPUyRWnTxR+AonfvQqQIWXDsk4sf/hik7sxlmT33eN9RXwmKAxr7QLQmolx1kruJtShq4MW6kT4P5Q86GkPr3/FM21uHveEU4oUftmA05MLKOnjA9QF0G4KvIjAg8z93Hasq6VJi5lFKLBW1JVRCjL4RiSX9mls+53U7yMyGeZubuNZL0yPZehw+ogrFkRkoIOwaqzqcmF/6ZQ+kkl75gTqjU+s0giK+ppGcn5kMwnTfA3vg== 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=tMGdBfbxP6DbfpEyTF6H+3T9GPezvwy8RivVOTIgg4w=; b=JUxd0aNT1L2dAAK1g06+yD3gY76jyfSSucHnSjfnH45WI+NHX8dvCryD6U6UZgu1Xtn/PpOZbuOdlAnqDnvnF+ahcDmw97B+mcdTGxTpi/aRvTvvyhBGMpCNswVVq1x+ukIB8oGObpI7YqiqpqTY8Rc2OTaqLT29+Tkb664G8Nc= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3762.eurprd08.prod.outlook.com (2603:10a6:208:100::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.15; Wed, 8 Apr 2020 13:29:30 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2878.022; Wed, 8 Apr 2020 13:29:30 +0000 From: Hannes Tschofenig To: John Mattsson , "tls@ietf.org" , "uta@ietf.org" Thread-Topic: [TLS] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS Thread-Index: AQHWDaeDkPpKX8oyt0iX3UQ9nri0DqhvOAag Date: Wed, 8 Apr 2020 13:29:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 116b1e97-f95a-41b9-86d2-f6524c9f6771.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.119] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 5ec161b7-db81-4fa1-f2aa-08d7dbc0e2a1 x-ms-traffictypediagnostic: AM0PR08MB3762:|AM5PR0801MB1857: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0367A50BB1 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(39860400002)(396003)(366004)(376002)(136003)(66946007)(52536014)(66446008)(66556008)(8936002)(6506007)(33656002)(966005)(66476007)(53546011)(478600001)(55016002)(9686003)(64756008)(86362001)(71200400001)(81156014)(8676002)(2906002)(186003)(66574012)(316002)(7696005)(81166007)(26005)(110136005)(76116006)(5660300002); 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: OA/XBcNAVaXrrFjF/1htlyhen/hfrfU8ZFnX1Cr5tAKBKbr/nTcBtUNJITLEJiAuZ91Si/IFScTjRUIBaZfMAEkPs1PuyYDCKY8j/xaOA50+gmCgr7QupvfIljM6UFu6MI+zHiN6aFk7duC974PXLe5pyfONbIVys4EUmRSCJh1ZlXs1bGOTMu1LcPbX2gtp6YG1tBxpzeBzfpUexeddKwdF7iwFOuN6rR0DMjuhhBfRLejdFswLtxxBZ4syFmgkto5JR7bvkc7reIMb37BwtT+qBYfoCEo54jq1Bo8tDUCsDXIPbZr/19eZFq9wgAaiUIo5/Bg8xddSrpyVxHGVgFMxUDzaobM2RoN4ASW21CKHNsVJFydlGL9J5EqXI+M/6dHMjqLWK2WINzbbyt/aJlTdJI9OYW8mGlSCTbUrwJnKUkPanUD8jk97IeFEPQIp+RDmUMk0zfaHMixzyHr44NyyDJt4cjkrZMP5/9E5OHOcJ7hqrd03OGNYVl/LLghh+z1loFDRRLVUjmODcpX6pA== x-ms-exchange-antispam-messagedata: wK/2/tnfop4XTriuzvCw6PFpZNg+A8Eqtzx5EPKWB+0VCdmm7uv/v5WCnI1U6ii10A134H6IeJtqh3G09B0ayxjWm3jrMuLarDlCSSebVu4JFpe+xVBvokp51JBU0KkS32tBC5yyXF0Z0wSYAxFusA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3762 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT052.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)(136003)(346002)(376002)(39860400002)(46966005)(2906002)(316002)(186003)(7696005)(26005)(36906005)(356004)(110136005)(6506007)(53546011)(336012)(9686003)(8676002)(55016002)(86362001)(81166007)(450100002)(52536014)(81156014)(5660300002)(8936002)(478600001)(66574012)(33656002)(26826003)(70586007)(82740400003)(966005)(47076004)(70206006); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 65219477-4c0e-4a8c-7493-08d7dbc0de60 X-Forefront-PRVS: 0367A50BB1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 9RblPdrdECyb5F0t7jpPyXnXbdMqCPHMSb1hLXcwZ+odRA/cup3cKRYDqRj/C5fDrwuDJcIGWDf7UmJ/npLfGHk7sCFWXfBVG7PDgdcl96sU9pFMzfBKXnNC0ipbYA1dUCjCwTEyIlealwMoZkVgavlbFAYpK/AJGfZapU2Foai1WSjgGMZXUN8sXFqeelEDplw8/QW53cYpYtjArlMzwuQN5CSo0G/aaOtaLDJ4l4rrmNVpvr0CCnyrN3hPEClUKYfC/FcZkH6ajVD0Zu35BywfKRSrgd7DKIXBpONpCBmDt4/eYbK9Fh/zDZtDNe2dUfnIXgeYX6tn3aRtcIkutVkFis4Mh/1gi4Vp2nFBV3aVs+KePBQbL8x9glXrLvb9OpmDFe172SO7g30k/YDD+reGvblWoxPoHni25KSekgAr2XWETfmx0kFFTOFpd33antJB/MAbjfug9sFGDYEGHOy1DPsY1hIp5oDoWJzlOXKnNvGfew52laj2YPKgMipap/kR9jao5ZCWNFqGJa11olh9RF/8OT8UBbecq3xf2Z1HA93+LPZUClXJtkbBz7bqXNYJMYyG8BzosOP0Bw3KOw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2020 13:29:37.6961 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5ec161b7-db81-4fa1-f2aa-08d7dbc0e2a1 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: AM5PR0801MB1857 Archived-At: Subject: Re: [TLS] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS 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: Wed, 08 Apr 2020 13:29:45 -0000 VGhhbmtzIGZvciB0aGUgaW5mbywgSm9obi4gSSB3aWxsIGhhdmUgYSBsb29rIGF0IHRoaXMgcHVi bGljYXRpb24uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKb2huIE1hdHRz c29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgQXByaWwg OCwgMjAyMCAzOjE0IFBNDQpUbzogSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2Zlbmln QGFybS5jb20+OyB0bHNAaWV0Zi5vcmc7IHV0YUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNd IENCT1IgQ2VydGlmaWNhdGUgQ29tcHJlc3Npb24gb2YgUkZDIDc5MjUgY2VydGlmaWNhdGVzIHN1 aXRhYmxlIGZvciBjVExTDQoNCkhpIEhhbm5lcywNCg0KSSBoYXZlIHJlcXVlc3RlZCBhbmQgYmVl biBhc3NpZ25lZCB0aW1lIGZvciBkcmFmdC1tYXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNvbXByZXNz LTAwIGFuZCBkcmFmdC1yYXphLWFjZS1jYm9yLWNlcnRpZmljYXRlcy0wNCBhdCB0aGUgVVRBIHZp cnR1YWwgaW50ZXJpbSBvbiBNYXJjaCAyMy4NCg0KV2UgaGF2ZSBhbiBpbXBsZW1lbnRhdGlvbiBv ZiBodHRwczovL2xpbmsuc3ByaW5nZXIuY29tL2NoYXB0ZXIvMTAuMTAwNyUyRjk3OC0zLTMxOS05 Mzc5Ny03XzE0IC8gZHJhZnQtcmF6YS1hY2UtY2Jvci1jZXJ0aWZpY2F0ZXMtMDMsIGJ1dCB0aGUg Y29kZSBpcyBub3Qgd3JpdHRlbiBpbiBhIHdheSBzbyB0aGF0IHRoZSBjb21wcmVzc2lvbiBtZWNo YW5pc20gREVSLT4gQ0JPUiBjYW4gYmUgZXh0cmFjdGVkLiBUaGUgZXhhbXBsZSBpbiBkcmFmdC1y YXphLWFjZS1jYm9yLWNlcnRpZmljYXRlcy0wNCB3YXMgY3JlYXRlZCBieSBoYW5kIHdpdGggY2Jv ci5tZS4gV2UgYXJlIHBsYW5uaW5nIHRvIGltcGxlbWVudCBhIHVwZGF0ZWQgc3RhbmRhbG9uZSB2 ZXJzaW9uIG9mIHRoZSBERVItPkNCT1IgY29tcHJlc3Npb24gYW5kIGhvcGVmdWxseSBoYXZlIGlu dGVyb3AgdGVzdGluZyBpbiB0aGUgQ09TRSBXRy4NCg0KQ2hlZXJzLA0KSm9obg0KDQrvu78tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVExTIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29t Pg0KRGF0ZTogRnJpZGF5LCAzIEFwcmlsIDIwMjAgYXQgMTQ6MjANClRvOiBKb2huIE1hdHRzc29u IDxqb2huLm1hdHRzc29uPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPiwgIlRMU0BpZXRm Lm9yZyIgPHRsc0BpZXRmLm9yZz4sICJ1dGFAaWV0Zi5vcmciIDx1dGFAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW1RMU10gQ0JPUiBDZXJ0aWZpY2F0ZSBDb21wcmVzc2lvbiBvZiBSRkMgNzkyNSBj ZXJ0aWZpY2F0ZXMgc3VpdGFibGUgZm9yIGNUTFMNCg0KICAgIEhpIEpvaG4sDQoNCiAgICBUaGFu a3MgZm9yIHRoZSBoZWFkcy11cC4NCg0KICAgIERpc2N1c3NpbmcgdGhpcyBhc3BlY3QgaW4gZHJh ZnQtdHNjaG9mZW5pZy11dGEtdGxzMTMtcHJvZmlsZS0wMSBtYWtlcyBzZW5zZS4NCg0KICAgIEkg d2FzIHdvbmRlcmluZyB3aGV0aGVyIHlvdSBoYXZlIGJlZW4gd29ya2luZyBvbiBhbiBpbXBsZW1l bnRhdGlvbiBvZiBkcmFmdC1tYXR0c3Nvbi1jb3NlLWNib3ItY2VydC1jb21wcmVzcy0wMCAvIGRy YWZ0LXJhemEtYWNlLWNib3ItY2VydGlmaWNhdGVzLTA0Lg0KDQogICAgQ2lhbw0KICAgIEhhbm5l cw0KDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBUTFMgPHRscy1i b3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgSm9obiBNYXR0c3Nvbg0KICAgIFNlbnQ6IEZy aWRheSwgQXByaWwgMywgMjAyMCA5OjAzIEFNDQogICAgVG86IFRMU0BpZXRmLm9yZzsgdXRhQGll dGYub3JnDQogICAgU3ViamVjdDogW1RMU10gQ0JPUiBDZXJ0aWZpY2F0ZSBDb21wcmVzc2lvbiBv ZiBSRkMgNzkyNSBjZXJ0aWZpY2F0ZXMgc3VpdGFibGUgZm9yIGNUTFMNCg0KICAgIEhpLA0KDQog ICAgRHVyaW5nIHRoZSBDT1NFIHZpcnR1YWwgaW50ZXJpbSBtZWV0aW5nIHllc3RlcmRheSwgdGhl cmUgd2FzIGFncmVlbWVudCB0aGF0IHRoZSBDT1NFIHdvcmtpbmcgZ3JvdXAgc2hvdWxkIHdvcmsg b24gQ0JPUiBjb21wcmVzc2lvbiBvZiBSRkMgNzkyNSBwcm9maWxlZCBYLjUwOSBjZXJ0aWZpY2F0 ZXMuIFRoZSB3b3JrIHdpbGwgYmUgYmFzZWQgb24gZHJhZnQtcmF6YS1hY2UtY2Jvci1jZXJ0aWZp Y2F0ZXMgYW5kIGRyYWZ0LW1hdHRzc29uLWNvc2UtY2Jvci1jZXJ0LWNvbXByZXNzIGFuZCB0aGUg dHdvIGRyYWZ0cyB3aWxsIGJlIG1lcmdlZC4gRG9pbmcgdGhpcyB3b3JrIGluIGEgc2VjdXJpdHkg Z3JvdXAgZm9jdXNlZCBvbiBDQk9SIG1ha2VzIGEgbG90IG9mIHNlbnNlLg0KDQogICAgaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hdHRzc29uLWNvc2UtY2Jvci1jZXJ0LWNvbXBy ZXNzLTAwDQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXJhemEtYWNlLWNi b3ItY2VydGlmaWNhdGVzLTA0DQoNCiAgICBUaGUgQ09TRSBkcmFmdCBjaGFydGVyIGhhcyBhbHJl YWR5IGJlZW4gdXBkYXRlZCB0byByZWZsZWN0IHRoaXMuDQoNCiAgICBodHRwczovL2dpdGh1Yi5j b20vY29zZS13Zy9DaGFydGVyL2Jsb2IvbWFzdGVyL0NoYXJ0ZXIubWQNCg0KICAgIEFzIHRoZSBh bGdvcml0aG0gaXMgZm9jdXNlZCBvbiBjb21wcmVzc2luZyBSRkMgNzkyNSBwcm9maWxlZCBjZXJ0 aWZpY2F0ZXMsIEl0IHNlZW1zIGxpa2UgYSB2ZXJ5IGdvb2QgbWF0Y2ggZm9yIGNUTFMuIFRvIGtl ZXAgdGhlIG51bWJlciBvZiBpbnRlcm5ldC1kcmFmdHMgZG93biwgSSBwbGFuIHRvIGFsc28gaW5j bHVkZSB0aGUgVExTIElBTkEgcmVnaXN0cmF0aW9ucyBpbiB0aGUgbWVyZ2VkIGRyYWZ0IHN1Ym1p dHRlZCB0byB0aGUgQ09TRSBXRyBhbmQgbGV0IGRyYWZ0LW1hdHRzc29uLXRscy1jYm9yLWNlcnQt Y29tcHJlc3MtMDAgZXhwaXJlLg0KDQogICAgQW55IGNvbW1lbnRzIGZyb20gdGhlIFRMUyBXRyBh cmUgdmVyeSB3ZWxjb21lLCBidXQgb3RoZXJ3aXNlIHRoZXNlIGlzIG5vdCBzbyBtdWNoIHRvIGRp c2N1c3MsIHRoaXMgaXMganVzdCBhbm90aGVyIGNlcnRpZmljYXRlIGNvbXByZXNzaW9uIGFsZ29y aXRobS4gQW55IFRMUyByZWxhdGVkIGRpc2N1c3Npb25zIHdvdWxkIGxpa2VseSBiZSByZWdhcmRp bmcgdGhlIGNlcnRpZmljYXRlIHByb2ZpbGUgaW4gUkZDIDc5MjUgYW5kIGlmIGFueSBjbGFyaWZp Y2F0aW9ucyBvciB1cGRhdGVzIGFyZSBuZWVkZWQuIFRoaXMgaXMgbGlrZWx5IGJlc3QgZGlzY3Vz c2VkIGluIFVUQSB3aGljaCBtYXkgdGFrZSB1cCB3b3JrIG9uIGEgVExTL0RUTFMgMS4zIHVwZGF0 ZSBvZiBSRkMgNzkyNS4NCg0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10 c2Nob2ZlbmlnLXV0YS10bHMxMy1wcm9maWxlLTAxDQoNCiAgICBDaGVlcnMsDQogICAgSm9obg0K DQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBGcm9tOiBKb2huIE1hdHRzc29u IDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4NCiAgICBEYXRlOiBUaHVyc2RheSwgMTIgTWFy Y2ggMjAyMCBhdCAwODo1OA0KICAgIFRvOiAiVExTQGlldGYub3JnIiA8VExTQGlldGYub3JnPg0K ICAgIENjOiAidXRhQGlldGYub3JnIiA8dXRhQGlldGYub3JnPg0KICAgIFN1YmplY3Q6IEZXOiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LW1hdHRzc29uLXRscy1jYm9yLWNlcnQt Y29tcHJlc3MtMDAudHh0DQoNCiAgICAgICAgSGksDQoNCiAgICAgICAgV2UgaGF2ZSBzdWJtaXR0 ZWQgYSBuZXcgZHJhZnQgdG8gVExTIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1t YXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNvbXByZXNzLTAwIFRoZSBkcmFmdCByZWdpc3RlciBhIG5l dyBjb21wcmVzc2lvbiBhbGdvcml0aG1zIGZvciB1c2Ugd2l0aCBUTFMgQ2VydGlmaWNhdGUgQ29t cHJlc3Npb24gaW4gVExTIDEuMyBhbmQgRFRMUyAxLjMgKGRyYWZ0LWlldGYtdGxzLWNlcnRpZmlj YXRlLWNvbXByZXNzaW9uKS4NCg0KICAgICAgICBUaGUgZHJhZnQgdXNlcyBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtcmF6YS1hY2UtY2Jvci1jZXJ0aWZpY2F0ZXMtMDQgdG8gY29t cHJlc3MgUkZDIDc5MjUgcHJvZmlsZXMgY2VydGlmaWNhdGVzIGJ5IGVuY29kaW5nIHRoZW0gZnJv bSBERVIgdG8gQ0JPUi4gVGhlIGFpbSBpcyB0byBiZSBjb21wYXRpYmxlIHdpdGggYWxsIFJGQyA3 OTI1IHByb2ZpbGVkIGNlcnRpZmljYXRlcy4gV2l0aCB0aGUgaW5jbHVkZWQgZXhhbXBsZSBERVIg ZW5jb2RlZCBSRkMgNzkyNSBjZXJ0aWZpY2F0ZSB0byBjZXJ0aWZpY2F0ZSBpcyBjb21wcmVzc2Vk IGZyb20gMzE0IHRvIDEzNiBieXRlcywgYSBjb21wcmVzc2lvbiByYXRlIG9mIDU3JS4NCg0KICAg ICAgICBUaGUgZ2VuZXJhbCBwdXJwb3NlIGNvbXByZXNzaW9uIGFsZ29yaXRobXMgZGVmaW5lZCBp biBkcmFmdC1pZXRmLXRscy1jZXJ0aWZpY2F0ZS1jb21wcmVzc2lvbiBkbyBub3Qgc2VlbSBhYmxl IHRvIGNvbXByZXNzIHByb2ZpbGVkIFJGQyA3OTI1IFguNTA5IGNlcnRpZmljYXRlcyBtdWNoIGF0 IGFsbC4gemxpYiBjb21wcmVzc2VkIHRoZSBleGFtcGxlIGNlcnQgOSUsIGJ1dCBmb3Igb3RoZXIg Y2VydGlmaWNhdGVzIHdlIHRlc3RlZCwgemxpYiBkaWQgaW4gbWFueSBjYXNlcyBub3QgcHJvdmlk ZSBhbnkgY29tcHJlc3Npb24gYXQgYWxsLg0KDQogICAgICAgIFdlIGhhdmUgc3VibWl0dGVkIGEg c2ltaWxhciBkcmFmdCB0byB0aGUgQ09TRSBXRyByZWdpc3RlcmluZyBhIG5ldyBhbGdvcml0aG1z IGZvciB0aGUgVExTIDEuMyBjZXJ0aWZpY2F0ZSBjb21wcmVzc2lvbiBleHRlbnNpb24uDQoNCiAg ICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hdHRzc29uLXRscy1jYm9y LWNlcnQtY29tcHJlc3MtMDANCg0KICAgICAgICBDaGVlcnMsDQogICAgICAgIEpvaG4NCg0KICAg ICAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgICAgICBGcm9tOiAiaW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KICAgICAgICBEYXRl OiBNb25kYXksIDkgTWFyY2ggMjAyMCBhdCAyMToxOQ0KICAgICAgICBUbzogSm9obiBNYXR0c3Nv biA8am9obi5tYXR0c3NvbkBlcmljc3Nvbi5jb20+LCBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRz c29uQGVyaWNzc29uLmNvbT4sIEpvZWwgSMO2Z2x1bmQgPGpvZWwuaG9nbHVuZEByaS5zZT4sIEpv ZWwgSG9nbHVuZCA8am9lbC5ob2dsdW5kQHJpLnNlPiwgR8O2cmFuIFNlbGFuZGVyIDxnb3Jhbi5z ZWxhbmRlckBlcmljc3Nvbi5jb20+LCBNYXJ0aW4gRnVydWhlZCA8bWFydGluLmZ1cnVoZWRAbmV4 dXNncm91cC5jb20+LCBHw7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNlbGFuZGVyQGVyaWNzc29uLmNv bT4sIFNoYWhpZCBSYXphIDxzaGFoaWQucmF6YUByaS5zZT4NCiAgICAgICAgU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tYXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNv bXByZXNzLTAwLnR4dA0KDQoNCiAgICAgICAgICAgIEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFm dC1tYXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNvbXByZXNzLTAwLnR4dA0KICAgICAgICAgICAgaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBKb2huIFByZXVzcyBNYXR0c3NvbiBhbmQg cG9zdGVkIHRvIHRoZQ0KICAgICAgICAgICAgSUVURiByZXBvc2l0b3J5Lg0KDQogICAgICAgICAg ICBOYW1lOmRyYWZ0LW1hdHRzc29uLXRscy1jYm9yLWNlcnQtY29tcHJlc3MNCiAgICAgICAgICAg IFJldmlzaW9uOjAwDQogICAgICAgICAgICBUaXRsZTpDQk9SIENlcnRpZmljYXRlIEFsZ29yaXRo bSBmb3IgVExTIENlcnRpZmljYXRlIENvbXByZXNzaW9uDQogICAgICAgICAgICBEb2N1bWVudCBk YXRlOjIwMjAtMDMtMDkNCiAgICAgICAgICAgIEdyb3VwOkluZGl2aWR1YWwgU3VibWlzc2lvbg0K ICAgICAgICAgICAgUGFnZXM6Ng0KICAgICAgICAgICAgVVJMOiAgICAgICAgICAgIGh0dHBzOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYXR0c3Nvbi10bHMtY2Jvci1jZXJ0 LWNvbXByZXNzLTAwLnR4dA0KICAgICAgICAgICAgU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1hdHRzc29uLXRscy1jYm9yLWNlcnQtY29tcHJl c3MvDQogICAgICAgICAgICBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LW1hdHRzc29uLXRscy1jYm9yLWNlcnQtY29tcHJlc3MtMDANCiAgICAgICAgICAg IEh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LW1hdHRzc29uLXRscy1jYm9yLWNlcnQtY29tcHJlc3MNCg0KDQogICAgICAgICAgICBBYnN0 cmFjdDoNCiAgICAgICAgICAgICAgIENlcnRpZmljYXRlIGNoYWlucyBvZnRlbiB0YWtlIHVwIHRo ZSBtYWpvcml0eSBvZiB0aGUgYnl0ZXMNCiAgICAgICAgICAgICAgIHRyYW5zbWl0dGVkIGluIFRM UyBoYW5kc2hha2VzLiAgTGFyZ2UgaGFuZHNoYWtlcyBjYW4gY2F1c2UgcHJvYmxlbXMsDQogICAg ICAgICAgICAgICBwYXJ0aWN1bGFybHkgaW4gY29uc3RyYWluZWQgSW9UIGVudmlyb25tZW50cy4g IFJGQyA3OTI1IGRlZmluZXMgYSBUTFMNCiAgICAgICAgICAgICAgIGNlcnRpZmljYXRlIHByb2Zp bGUgZm9yIGNvbnN0cmFpbmVkIElvVC4gIEdlbmVyYWwgcHVycG9zZSBjb21wcmVzc2lvbg0KICAg ICAgICAgICAgICAgYWxnb3JpdGhtcyBjYW4gaW4gbWFueSBjYXNlcyBub3QgY29tcHJlc3MgUkZD IDc5MjUgcHJvZmlsZWQNCiAgICAgICAgICAgICAgIGNlcnRpZmljYXRlcyBhdCBhbGwuICBCeSB1 c2luZyB0aGUgZmFjdCB0aGF0IHRoZSBjZXJ0aWZpY2F0ZXMgYXJlDQogICAgICAgICAgICAgICBw cm9maWxlZCwgdGhlIENCT1IgY2VydGlmaWNhdGUgY29tcHJlc3Npb24gYWxnb3JpdGhtcyBjYW4g aW4gbWFueQ0KICAgICAgICAgICAgICAgY2FzZXMgY29tcHJlc3MgUkZDIDc5MjUgcHJvZmlsZWQg Y2VydGlmaWNhdGVzIHdpdGggb3ZlciA1MCUuIFRoaXMNCiAgICAgICAgICAgICAgIGRvY3VtZW50 IHNwZWNpZmllcyB0aGUgQ0JPUiBjZXJ0aWZpY2F0ZSBjb21wcmVzc2lvbiBhbGdvcml0aG0gZm9y IHVzZQ0KICAgICAgICAgICAgICAgd2l0aCBUTFMgQ2VydGlmaWNhdGUgQ29tcHJlc3Npb24gaW4g VExTIDEuMyBhbmQgRFRMUyAxLjMuDQoNCg0KDQoNCiAgICAgICAgICAgIFBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1p c3Npb24NCiAgICAgICAgICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCiAgICAgICAgICAgIFRoZSBJRVRGIFNl Y3JldGFyaWF0DQoNCg0KDQoNCg0KDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCiAgICBUTFMgbWFpbGluZyBsaXN0DQogICAgVExTQGlldGYub3Jn DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCiAgICBJTVBP UlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1l bnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBp bW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIg cGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZv cm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQogICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBUTFMgbWFpbGluZyBsaXN0DQogICAg VExTQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 bHMNCg0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQg YW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVn ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0 byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBj b3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Wed Apr 8 07:11:26 2020 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 8BB303A0C9A for ; Wed, 8 Apr 2020 07:11:24 -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=hZ7oHNNO; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=hZ7oHNNO 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 dtZSK1hvhm7i for ; Wed, 8 Apr 2020 07:11:21 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150057.outbound.protection.outlook.com [40.107.15.57]) (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 519143A0C88 for ; Wed, 8 Apr 2020 07:11:07 -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=pQTUlZGnYLpnjW/Wl+IkEVGNGrlfK9EmkBFkj4ME4nM=; b=hZ7oHNNOBJ3G1I4vWw+PnXLkdd8i4Fyhy//xdaGxQR76yDsTk4RA6wWBDMq0wBzhFlBJWEaAk+p/PIaZbnBYgg96shVAyb94d1VUEOP5w4QH+n/ybUKxKpJKK8Xk2d8W/r7MeSuPlhrUd4aFpIGPA6fDAu9132Az9vkH8rCPZEg= Received: from DB6PR0301CA0052.eurprd03.prod.outlook.com (2603:10a6:4:54::20) by VI1PR08MB4575.eurprd08.prod.outlook.com (2603:10a6:803:eb::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Wed, 8 Apr 2020 14:11:04 +0000 Received: from DB5EUR03FT049.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:54:cafe::66) by DB6PR0301CA0052.outlook.office365.com (2603:10a6:4:54::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Wed, 8 Apr 2020 14:11:04 +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 DB5EUR03FT049.mail.protection.outlook.com (10.152.20.191) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.17 via Frontend Transport; Wed, 8 Apr 2020 14:11:04 +0000 Received: ("Tessian outbound e2c88df8bbbe:v50"); Wed, 08 Apr 2020 14:11:04 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: a666447a925f7ddd X-CR-MTA-TID: 64aa7808 Received: from 889a12b9ce91.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id C56594D5-E057-42EC-9711-E4836F3CD987.1; Wed, 08 Apr 2020 14:10:59 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 889a12b9ce91.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 08 Apr 2020 14:10:59 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EEQQLi9MfS8xYC0UyrzxxyeQOGSj/C5spmlZFCnh/+7hxU/OBkEOc5MdYqpcut57lbc6WU82g4w+HoAUdVLsy3LEPsMHSq5ZDakqicKvSpBcETz9XrSdSewZVEI8ivNXEcU5EaMmsP/IOOGizmZ7llql3sFSqERP1m9WinUzbbDxFLIufFKRABoedq86tyGdvZMmeetnwk8CYO8PHcQoEPwfo0obYu8y8Prl89Bxz+DgDhWWg03p1zUZQRgxnVRHzJfHy8ZIuBj/Pr/CwIF7e3lAePPD3arVzyhFubo2OsfAidEby2igxE2tzcQlQ2aJqFpRbQMBtC9jPN+KMQc+VA== 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=pQTUlZGnYLpnjW/Wl+IkEVGNGrlfK9EmkBFkj4ME4nM=; b=VRRtE6JpbHuDYYdbQidfBC/plEwO2pGLGjLZG4USk++HMdaMzbwpQ9JtxB8q/wMx69QjB7e0GXuzlcCSf7I0PVXAfj9hQxpZsskjot8Lr7t6t5kHK2XwfrKIEmFIXNsq1TpLqulW7o3drNDvLAWqEOoUabp3vEl6ToYE477x6u28AiO19JcWu7PLbTL36Nbzm+u78fGHtNngiq/iehKvwKE53ZZ5owxvtgHrlFDaNJSI/2IdQsskO8G+phXohrKysW0yiA0r29VK9oPV8AtH7R9tePwOewDOAfNzkX5O3iD9RW4/jPc9uIwiJgYYjBm5+fDv2vAjAUoQ/AlR3YpCzg== 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=pQTUlZGnYLpnjW/Wl+IkEVGNGrlfK9EmkBFkj4ME4nM=; b=hZ7oHNNOBJ3G1I4vWw+PnXLkdd8i4Fyhy//xdaGxQR76yDsTk4RA6wWBDMq0wBzhFlBJWEaAk+p/PIaZbnBYgg96shVAyb94d1VUEOP5w4QH+n/ybUKxKpJKK8Xk2d8W/r7MeSuPlhrUd4aFpIGPA6fDAu9132Az9vkH8rCPZEg= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (52.135.163.143) by AM6PR08MB3512.eurprd08.prod.outlook.com (20.177.115.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Wed, 8 Apr 2020 14:10:57 +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.2878.021; Wed, 8 Apr 2020 14:10:57 +0000 From: Hanno Becker To: Thomas Fossati , Rob Sayre CC: "tls@ietf.org" Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQgAO7OoCAAKsoAP//86kAgAAdq4D///6F3YAAREwAgAD0k7I= Date: Wed, 8 Apr 2020 14:10:57 +0000 Message-ID: References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> <03849701-1A14-4E1A-8298-D483E74E380C@arm.com> , In-Reply-To: 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: da07e82f-49b9-46a0-df8e-08d7dbc6acc8 x-ms-traffictypediagnostic: AM6PR08MB3512:|AM6PR08MB3512:|VI1PR08MB4575: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 0367A50BB1 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)(366004)(346002)(39860400002)(396003)(376002)(136003)(86362001)(9686003)(6506007)(316002)(71200400001)(8676002)(33656002)(55016002)(81156014)(81166007)(7696005)(4326008)(478600001)(64756008)(2906002)(966005)(76116006)(66946007)(110136005)(19627405001)(26005)(52536014)(66476007)(66446008)(186003)(8936002)(66556008)(5660300002); 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: DC40EibaMIvnZppacHVj5pEKFmPi3VH1upyBt899eZkP5gk+w+CsAv7teFuCzrnNdvpGIwlg94UCS9vj0Y7x098HNl+8T4K1AZZZXWssKAgzYcvzG9IN4Zi1zxMD6yB6LjPgiUGAzWLNqlo2IvN8BUfTeGRi77nJUSboLtUh6hH/QN/fsyxh7Hfx5wxEwmChflKyIFXm151a4vdBJxdgVKeZNpOHimZuolXogx7x/mWw9nA0bTtOXWC0cebgWwQA7x9i+E2AezAFecx3ygKdfeKI0Qqnln2DVpc6pG6DPBlHvZ/kFWFYv2A+wBr8wGTGO1dwc7QUUH5B4JzqFyhxnSAIR0HkOUkG5W6arf2H18eFg1N4Lqzv1ycfJw0drP2I6YaR13hltqrAeyf+ErtLloC8RHRnGBknKz7gm9QHMUjCFN/zOaWtsrxRCIZexjwWMb/SUbFJ5lxlpghOoD354jRi1ZrHXBkAV0VF77IbU3b/NmkqYrk0Fz8QqXl3/EvXDmiynmQXdB2gQtNS05nmkg== x-ms-exchange-antispam-messagedata: kA0UeUP/3q8kG1X19Og6LMeZmOozklN6WaSzZPzUaSjvcbwiP6huBvPEgZeG7lpLVXBIGtaMfr8wcsSHaWxjVRPMHkrGs7DKPkGhJSW+kslFZ/4RuTtpZi1Ac61TRqBfuPK3XGI/UbBgQQoLHeDEZw== Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3318F770AD9A53CC0C9F88FA9BC30AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3512 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT049.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)(136003)(376002)(46966005)(2906002)(47076004)(336012)(7696005)(81156014)(33656002)(9686003)(81166007)(8936002)(356004)(55016002)(5660300002)(8676002)(70206006)(82740400003)(478600001)(86362001)(316002)(966005)(70586007)(52536014)(26005)(186003)(26826003)(6506007)(4326008)(110136005)(19627405001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: d27b000b-0250-418f-3f87-08d7dbc6a8d3 X-Forefront-PRVS: 0367A50BB1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Ojqzk50lgDuqL/xjSzEOIGWcyMSwh++mKeSZQGPu58zuVrqveJKF0vV3dkW+Q1wXF9l/1wD3ihwIW2n19gQPTulLcDYUDyawcnRM+XxL8v3Og6pHKgz0l5Y/otCCjSpB00/53nWGXhfG4sN2cctAt6O7Wgbxx9E3gU/EG1TMvONiA1Okfh7gtk0nwvWxQVlvsZ1SHoCG99befHf1mVaYacOXPQpZZ3jIQIcqPDaWGzcUIBJHq4XWgazH5Wow59ju0O1vXjqk5HxVflZYJn6eNCTMSO52pjAvXQ1sCNTk5E4MHYRZZqWZwgNevV78D2j6MpGfhSI97JfF/mxZByIlwJP7p0B5pcMiBqK6PVJJGFPa044sx8ozorMFqqkAwhPzCIpIzIrrZh8QpfzDz9eTc05kaWOhshQVvlTu8QM9ObcJg+yNstKzbstZ9uFqzYXfqJQP+PZt7aB6SnIZaIdPrQIuUyDNsdk6qAgoE1JiT4FSNJRcsCUQ/uFfSOtioVMH6+tb39StJONWr/vG7dVDLoy4SexaWdvkhk2fZ7IfqtqIxheaVxTh5esfwdiym7OOKaZ8/vwL+eRi8Xw9NOkSiA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Apr 2020 14:11:04.4987 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: da07e82f-49b9-46a0-df8e-08d7dbc6acc8 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: VI1PR08MB4575 Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Wed, 08 Apr 2020 14:11:25 -0000 --_000_AM6PR08MB3318F770AD9A53CC0C9F88FA9BC30AM6PR08MB3318eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thomas, Hi Ekr, > > * Receiving ACKs: Upon receipt of an ACK, implementations should note > > which messages have been received and omit them from future > > retransmissions. It is up to the implementation to decide when to > > retransmit and what to retransmit, but it is recommended they > > retransmit after a period of time during which no further ACK messages > > have been received. They may also proactively retransmit parts of a > > flight early if an ACK message indicates a gap (note, though, that in > > this example one would only retransmit the gap, not the gap + tail as > > before). > > Looks like a sound proposal to me. The only problem I see with this is > that recovery from tail loss is not efficient, which might or might not > be a problem, depending on the loss pattern of your path. > > > By contrast. we do know that DTLS retransmission is too slow and given > > that small flights are common, losing the ability to indicate that you > > lost a tail seems undesirable. > > I agree this should be avoided if possible. As far as I see, tail loss indication involves a timer in both cases: - As it stands, tail loss recovery is triggered by the ACK resulting from t= he 'lack of progress' indicator of disruption, described in the second bullet point of https://tools.ietf.org/= html/draft- ietf-tls-dtls13-37#section-7.1 In particular, it only occurs after a 'short' timer triggered on the receiv= er, where by 'short' I mean that is has smaller threshold than the ordinary retransmission timer from DTLS 1.2,= marking the bottom line recovery time we want to improve upon. - Likewise, there's short timer based recovery in the new proposal, but mir= rored: The sender retransmits upon noticing a gap in the ACKs, which too can be detected by a short timer as i= n the current proposal. Best, 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_AM6PR08MB3318F770AD9A53CC0C9F88FA9BC30AM6PR08MB3318eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Thomas, Hi Ekr,

> > * Receiving ACKs: Upon receipt of an ACK, i= mplementations should note
> > which messages have been received and = omit them from future
> > retransmissions. It is up to the imple= mentation to decide when to
> > retransmit and what to retransmit, but= it is recommended they
> > retransmit after a period of time duri= ng which no further ACK messages
> > have been received. They may also proa= ctively retransmit parts of a
> > flight early if an ACK message indicat= es a gap (note, though, that in
> > this example one would only retransmit= the gap, not the gap + tail as
> > before).
>
> Looks like a sound proposal to me.  Th= e only problem I see with this is
> that recovery from tail loss is not efficie= nt, which might or might not
> be a problem, depending on the loss pattern= of your path.
>
> > By contrast. we do know that DTLS retr= ansmission is too slow and given
> > that small flights are common, losing = the ability to indicate that you
> > lost a tail seems undesirable.<= br>
>
> I agree this should= be avoided if possible.

As far as I see, tail loss indication involves a time= r in both cases:

- As it stands,= tail loss recovery is triggered by the ACK resulting from the 'lack of pro= gress' indicator of 
disruption, described in the second bullet point of https://to= ols.ietf.org/html/draft- ietf-tls-dtls13-37#section-7.1 
In particular, it only occurs after a 'short' timer triggered on the receiver, where by 'short' I mean that is 
has smaller threshold than the ordinary retransmission timer = from DTLS 1.2, marking the bottom line 
recovery time we want to improve upon.

- Likewise, the= re's short timer based recovery in the new proposal, but mirrored: The send= er retransmits upon 
noticing a gap in the ACKs, which too can be detected by a sh= ort timer as in the current proposal.

Best,
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_AM6PR08MB3318F770AD9A53CC0C9F88FA9BC30AM6PR08MB3318eurp_-- From nobody Thu Apr 9 04:27:44 2020 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 A532D3A08CD for ; Thu, 9 Apr 2020 04:27:36 -0700 (PDT) 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, 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=4H4wsJqu; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=4H4wsJqu 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 j-ZPVysh1KOw for ; Thu, 9 Apr 2020 04:27:34 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0620.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::620]) (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 507E63A0873 for ; Thu, 9 Apr 2020 04:27:34 -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=3qHmd3bwUqSWv1Tjgg+2ywCdPa5zPYqe51vcbHdoEwI=; b=4H4wsJqukSB6acMWf2wwku7ALMevk5bSoeLWDg3QgJy0dHjFf+rZ6FKQhBFUpOUVYhNagt5TTSGwXqEMueydE5CD5tPKU9VXyc0l0/9ajMqXC5PKT1S/iL9TpLpAN+oEHKxotn0M/qhvQA3IO9qnKF2yX2l1KWPgap3/7gClqQU= Received: from AM6PR01CA0068.eurprd01.prod.exchangelabs.com (2603:10a6:20b:e0::45) by VE1PR08MB4894.eurprd08.prod.outlook.com (2603:10a6:802:a8::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Thu, 9 Apr 2020 11:27:31 +0000 Received: from AM5EUR03FT024.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:e0:cafe::67) by AM6PR01CA0068.outlook.office365.com (2603:10a6:20b:e0::45) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.17 via Frontend Transport; Thu, 9 Apr 2020 11:27:30 +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 AM5EUR03FT024.mail.protection.outlook.com (10.152.16.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.18 via Frontend Transport; Thu, 9 Apr 2020 11:27:30 +0000 Received: ("Tessian outbound af37c2b81632:v50"); Thu, 09 Apr 2020 11:27:30 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: c175594aff6ad166 X-CR-MTA-TID: 64aa7808 Received: from 3d47005802c2.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A7D44E55-E9C9-4949-98F8-C47E935862FE.1; Thu, 09 Apr 2020 11:27:24 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 3d47005802c2.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 09 Apr 2020 11:27:24 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YB2W9Gqy+4A1qce+iv/52RTl1rb6wWSmnUv8ca+2ncBZP4CkODCanlYy1K0Qyei9sixJQbH/XYw42VoSoMvta9cDRiYUZgF0XyecMYLLtnnZluOH3UuXjoMcF0cGS+ab5K0/TGJmyqhmM3K15oua3hgCME6ojRXl6G15+Hu5H5QHPcwfe75SJJqlG1CmpRygVYwpkwc42+COP64ti9iAVyDQT8ojfIu/tnrsq47fQYfRXGuMklKnr9G1HF6IMn/tjYxECKknqsDRcTEg76PHSFCMBrCqyQCQJwgFUJt8iS7XDuz8HGxNXbg8Uock6mRAvWti2Ld8HUk4grmYgd65QA== 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=3qHmd3bwUqSWv1Tjgg+2ywCdPa5zPYqe51vcbHdoEwI=; b=oegs/iaUd5zsn2045MS3Fy+QN366dkg0y2HwG5I0wCvrDytxf1RpflEHPz4lP8RjnAdTEO3+tA5b+ZltuCQDWRZOajXMTpZaNUnvDlZjZwxx70u659Us9jec/97buNErggI6eGQkVG3tH8Lel6voocRJQc+cfwg99qTRWwI9RMqm5my6rs3oqVNfUhduXusxZX9dhc56BHco+iDwg08UWsSyQNB+STVQswEm3NftFOdV8j8sdRxVzSMwmxyZHYbVCPe7wbJsiBou1RYDjLCQt9O9IAHAnBVz2GyjE6JASmY9HVMZfnApuKjbs40La/q+bQ30QFL0HCbQzYJlx0Ww0A== 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=3qHmd3bwUqSWv1Tjgg+2ywCdPa5zPYqe51vcbHdoEwI=; b=4H4wsJqukSB6acMWf2wwku7ALMevk5bSoeLWDg3QgJy0dHjFf+rZ6FKQhBFUpOUVYhNagt5TTSGwXqEMueydE5CD5tPKU9VXyc0l0/9ajMqXC5PKT1S/iL9TpLpAN+oEHKxotn0M/qhvQA3IO9qnKF2yX2l1KWPgap3/7gClqQU= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB3638.eurprd08.prod.outlook.com (2603:10a6:20b:4b::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Thu, 9 Apr 2020 11:27:21 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::b08c:a849:e63d:6150]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::b08c:a849:e63d:6150%7]) with mapi id 15.20.2900.015; Thu, 9 Apr 2020 11:27:21 +0000 From: Thomas Fossati To: Hanno Becker , Rob Sayre CC: "tls@ietf.org" , Thomas Fossati Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQgAO7OoCAAKsoAP//86kAgAAdq4D///6F3YAAREwAgAD0k7KAA3V2gA== Date: Thu, 9 Apr 2020 11:27:21 +0000 Message-ID: References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> <03849701-1A14-4E1A-8298-D483E74E380C@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 91d43daa-f3fe-45be-877b-08d7dc78fd84 x-ms-traffictypediagnostic: AM6PR08MB3638:|AM6PR08MB3638:|VE1PR08MB4894: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:6430;OLM:10000; x-forefront-prvs: 0368E78B5B X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(136003)(396003)(376002)(39860400002)(366004)(91956017)(66476007)(2906002)(6512007)(76116006)(6506007)(66946007)(8936002)(81156014)(8676002)(66446008)(53546011)(186003)(66556008)(64756008)(26005)(71200400001)(6486002)(110136005)(2616005)(54906003)(5660300002)(478600001)(36756003)(33656002)(86362001)(81166007)(4326008)(316002); 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: oKFPYpZfVxFOQD4bO0kApSR9hq6iaFAp7PurgR/jmQsgxsi2QYgVcVemtXISU3cKO028zeAm7O0iZMFf0pI3nlPqRmQ6iMKyDNoj1zSAkdr/uXxkYfb5LQppVTsPL5VCBRYg1QNUTjnFNm7gwxQ7zQFpX2J/QHVvfm+ylRW/UBt/moHLXRP4r0ayMe3JUY3F4XTziTzxyb5rvPUspIkKIrlYHx6e9DvuxR8BSJ0LfuRFTzCxGV59IWRMLwKqxEZT1C7wirMYE2HMMSmnM6VjBXnXnAcf4eGK98BjMI85QaBINVJEEMzjM5keZX6TX2t/xueNMIFSDhQAlnkJJl6q5kcRdunFnU5KecXyn+hRT45KxZVDm5KpGpFSRMm2JB7YWCPeNpiv4Ql8+zIAoVK4P3ytCI+XOctOOii+5ZTAAqhsXRyjUszULq6oUaYKGh1x x-ms-exchange-antispam-messagedata: z4cC8BmprUz43lupxXDHeSMZ+dkVALrg7rpAwjbDxQKH1hYywgBMOF6EkQ/IX34jiBbCcepulz4qefER6kYNKAWsoIi7YnqBZCxjThekz9DPh36q5+fJ1kl9zt2QfCUlK8eN0GlBFAIvx4DH24r8vw== Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3638 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT024.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)(39860400002)(136003)(376002)(346002)(396003)(46966005)(70586007)(316002)(356004)(82740400003)(86362001)(33656002)(54906003)(70206006)(36906005)(110136005)(2906002)(36756003)(26826003)(4326008)(6506007)(53546011)(6486002)(47076004)(2616005)(478600001)(6512007)(8676002)(26005)(5660300002)(336012)(81166007)(81156014)(8936002)(186003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 5cf2410a-110d-406d-89df-08d7dc78f860 X-Forefront-PRVS: 0368E78B5B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: werE9meV7HX0PxrtttdC5tCUEKKUFWprgNWZtk3jGZ5khXKfeCB+KWH4eMzSLYwPSxQI7hjEN0pZOo2WGYkmlWSVCcEjpOH0f31pTl8Ebg1XryxZJmunvseWKbXuOq7Q0Jk4gFxFrwE4wImvc6qY0ucQmwUN4++66QZQGiBr0QN/iToVQhFiA1XlNBQC7FViyCbSK/JSYPc5HSlx6Hw4/Cn1UGGSI+Hk4sDONqQffG/wGrMnKddEb9DOhzO6S/ixPJE0ymk6EXidDgbtYBmEMcNYDmP7qiDl2kVdoBfsCOK/uD//v5RqfXsy56jIm5bvB+RKvTroaxz9tqu/GQBhWEA+iNajkmgv3clKRw4gWsFMbz1yJ/u3vCbmwtlWCjbYWFtlunMcmGlRyZLp63sdxhrxpgmpic3ZINlA6YyXXFzNsBxSvjcP8jC4He3MLHXivJUrq5Yl2elDjCj4uzc7ky80pHwZVjrMeLmxG19IZ6ABCDTVUFIyxb7nNZrhGEX2O8bh4iU/DaEEf77hK/Ir+w== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2020 11:27:30.3111 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 91d43daa-f3fe-45be-877b-08d7dc78fd84 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: VE1PR08MB4894 Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Thu, 09 Apr 2020 11:27:43 -0000 SGV5IEhhbm5vLA0KDQpPbiAwOC8wNC8yMDIwLCAxNToxMSwgIkhhbm5vIEJlY2tlciIgPEhhbm5v LkJlY2tlckBhcm0uY29tPiB3cm90ZToNCj4gQXMgZmFyIGFzIEkgc2VlLCB0YWlsIGxvc3MgaW5k aWNhdGlvbiBpbnZvbHZlcyBhIHRpbWVyIGluIGJvdGggY2FzZXM6DQo+DQo+IC0gQXMgaXQgc3Rh bmRzLCB0YWlsIGxvc3MgcmVjb3ZlcnkgaXMgdHJpZ2dlcmVkIGJ5IHRoZSBBQ0sgcmVzdWx0aW5n DQo+ICAgZnJvbSB0aGUgJ2xhY2sgb2YgcHJvZ3Jlc3MnIGluZGljYXRvciBvZiBkaXNydXB0aW9u LCBkZXNjcmliZWQgaW4NCj4gICB0aGUgc2Vjb25kIGJ1bGxldCBwb2ludCBvZiBkcmFmdC1pZXRm LXRscy1kdGxzMTMtMzcjc2VjdGlvbi03LjENCj4gICBJbiBwYXJ0aWN1bGFyLCBpdCBvbmx5IG9j Y3VycyBhZnRlciBhICdzaG9ydCcgdGltZXIgdHJpZ2dlcmVkIG9uIHRoZQ0KPiAgIHJlY2VpdmVy LCB3aGVyZSBieSAnc2hvcnQnIEkgbWVhbiB0aGF0IGlzIGhhcyBzbWFsbGVyIHRocmVzaG9sZCB0 aGFuDQo+ICAgdGhlIG9yZGluYXJ5IHJldHJhbnNtaXNzaW9uIHRpbWVyIGZyb20gRFRMUyAxLjIs IG1hcmtpbmcgdGhlIGJvdHRvbQ0KPiAgIGxpbmUgcmVjb3ZlcnkgdGltZSB3ZSB3YW50IHRvIGlt cHJvdmUgdXBvbi4NCj4NCj4gLSBMaWtld2lzZSwgdGhlcmUncyBzaG9ydCB0aW1lciBiYXNlZCBy ZWNvdmVyeSBpbiB0aGUgbmV3IHByb3Bvc2FsLA0KPiAgIGJ1dCBtaXJyb3JlZDogVGhlIHNlbmRl ciByZXRyYW5zbWl0cyB1cG9uIG5vdGljaW5nIGEgZ2FwIGluIHRoZQ0KPiAgIEFDS3MsIHdoaWNo IHRvbyBjYW4gYmUgZGV0ZWN0ZWQgYnkgYSBzaG9ydCB0aW1lciBhcyBpbiB0aGUgY3VycmVudA0K PiAgIHByb3Bvc2FsLg0KDQpZb3UgYXJlIHJpZ2h0LCB0aGlzIHdvdWxkbid0IGhhdmUgd29yc2Ug dGFpbC1sb3NzIHJlY292ZXJ5IHRoYW4gd2hhdCBpcw0KY3VycmVudGx5IHNwZWNpZmllZC4gIFNv LCBhbGwgdGhpbmdzIGNvbnNpZGVyZWQgaXQgbG9va3MgbGlrZSBhIHJlYWwNCmltcHJvdmVtZW50 IGNvbXBhcmVkIHRvIGR0bHMxMy0zNy4NCg0KQ291bGQgY29sbGVjdCB0aGUgdGV4dCBmcm9tIHRo aXMgdGhyZWFkIGluIGEgUFIgYWdhaW5zdCBTZWN0aW9uIDc/ICBUaGlzDQp3YXkgZm9sa3MgdGhh dCBoYXZlbid0IGZvbGxvd2VkIHRoZSBkaXNjdXNzaW9uIGNsb3NlbHkgY2FuIHNlZSBob3cgeW91 cg0KcHJvcG9zYWwgbG9va3Mgb3ZlcmFsbC4NCg0KY2hlZXJzLCB0aGFua3MhDQoNCklNUE9SVEFO VCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMg YXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVk aWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJz b24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0 aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Thu Apr 9 06:01:31 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4114B3A0AAF; Thu, 9 Apr 2020 06:01:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: tls-chairs@ietf.org, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.125.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <158643725969.2046.7924101648018985342@ietfa.amsl.com> Date: Thu, 09 Apr 2020 06:01:00 -0700 Archived-At: Subject: [TLS] Alissa Cooper's No Objection on charter-ietf-tls-05-03: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 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: Thu, 09 Apr 2020 13:01:01 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-tls-05-03: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-tls/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Would be nice to see milestones. From nobody Thu Apr 9 06:20:58 2020 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 698CA3A0AE8 for ; Thu, 9 Apr 2020 06:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 o1erqhbAyQaj for ; Thu, 9 Apr 2020 06:20:54 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35DC73A0763 for ; Thu, 9 Apr 2020 06:20:54 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id z23so7881862lfh.8 for ; Thu, 09 Apr 2020 06:20:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tDll7EhBrksICiewLg7e4STJuX33veGsc2CukRoA5Lk=; b=SaO+O7UfbJ+wva9Uf1W2o0WID3DMH2HKbCrMG9/O7i9h5Z5gX1FJymUj7RFh1wYFP0 EIgko93nRfhObrNJvE894auwe8/GpyESjYcM06wNt5DEtW4SAh5vZS3ZtwM3y82yqSFR 1M5EhUsN/OLmClcbA8Lg+CJUvUqZMRIx/UCelEt2EXTnRkv9rkjaALFedNmPg7u8uaL8 rqFKwpAofVn+GBU42sGtARdXZQEtbj0Mh13AuiK6GGSXu9M5kt4XKWM3ZKXF5zLg86Ox drEp6SzHkmseAWwV6t9TKvC1byaHP5q8jdHhFhwFdhGstW+/G4uSn+iPaG8wJYcDpfWo ENLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tDll7EhBrksICiewLg7e4STJuX33veGsc2CukRoA5Lk=; b=JqTOEnH5/WL5tAmBKJrZpH5U6UB3hCnL6H/jljKi+XUHx4soa2Yaz3YMHSNYHI7rlH DimspIi5ddmajbrq/zJu2DPMT7BWBbxPnIJpWTOYZuMdMFZf2Nouy+ytTTxSeUUZAn3C gcn2xqcO5qaoPs6aEDrPAwtmaAvsmkLoRSqqvo0YSRu+7OAHUf4V+dJEm5avcmie1Eg/ /ctZl16FocvYHcYf70AXPsdqMjdoq4Tlgw1Xw46gXDhtCljyQxfdjh/xBuBPcUma9mus 2aGFDEin6pArXULQjR21BKlVABBhn4PMMj5cMgD9aeM8fHHTszvRbbKPv7iTBSdcnSWR XqdA== X-Gm-Message-State: AGi0PubgRBEbCfFZQQmVKSJWxMRHCHpEBm6eJD8qRlflUa9iOKUUk1ct 1r2TLDRJOSn+IpyfsQ6K70CX+mhwcHKCBOLgg62j6A== X-Google-Smtp-Source: APiQypLsYZLVxHA24fYXZyDSElupzi8Vj3PZiqXfAywcxYQCL8uYdAoLdY8MF7k2NYb90YtVqb0HHLu6Or3FKwhV7Y4= X-Received: by 2002:a19:6a06:: with SMTP id u6mr7627046lfu.140.1586438451403; Thu, 09 Apr 2020 06:20:51 -0700 (PDT) MIME-Version: 1.0 References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> <03849701-1A14-4E1A-8298-D483E74E380C@arm.com> In-Reply-To: From: Eric Rescorla Date: Thu, 9 Apr 2020 06:20:15 -0700 Message-ID: To: Thomas Fossati Cc: Hanno Becker , Rob Sayre , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005aae6705a2db7c6d" Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Thu, 09 Apr 2020 13:20:56 -0000 --0000000000005aae6705a2db7c6d Content-Type: text/plain; charset="UTF-8" Assuming I understand Hanno's proposal, I do not believe that this is in fact an improvement, as it does not cover the important case where the record containing the SH is lost and then the rest of the messages from the server are uninterpretable. -Ekr On Thu, Apr 9, 2020 at 4:27 AM Thomas Fossati wrote: > Hey Hanno, > > On 08/04/2020, 15:11, "Hanno Becker" wrote: > > As far as I see, tail loss indication involves a timer in both cases: > > > > - As it stands, tail loss recovery is triggered by the ACK resulting > > from the 'lack of progress' indicator of disruption, described in > > the second bullet point of draft-ietf-tls-dtls13-37#section-7.1 > > In particular, it only occurs after a 'short' timer triggered on the > > receiver, where by 'short' I mean that is has smaller threshold than > > the ordinary retransmission timer from DTLS 1.2, marking the bottom > > line recovery time we want to improve upon. > > > > - Likewise, there's short timer based recovery in the new proposal, > > but mirrored: The sender retransmits upon noticing a gap in the > > ACKs, which too can be detected by a short timer as in the current > > proposal. > > You are right, this wouldn't have worse tail-loss recovery than what is > currently specified. So, all things considered it looks like a real > improvement compared to dtls13-37. > > Could collect the text from this thread in a PR against Section 7? This > way folks that haven't followed the discussion closely can see how your > proposal looks overall. > > cheers, thanks! > > 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 > --0000000000005aae6705a2db7c6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Assuming I understand Hanno's proposal, I do not = believe that this is in fact an improvement, as it does not cover the impor= tant case where the record containing the SH is lost and then the rest of t= he messages from the server are uninterpretable.

<= div>-Ekr


On Thu, Apr 9, 2020 at 4:27 AM Thomas Fossati= <Thomas.Fos= sati@arm.com> wrote:
Hey Hanno,

On 08/04/2020, 15:11, "Hanno Becker" <Hanno.Becker@arm.com> wrote:
> As far as I see, tail loss indication involves a timer in both cases:<= br> >
> - As it stands, tail loss recovery is triggered by the ACK resulting >=C2=A0 =C2=A0from the 'lack of progress' indicator of disruptio= n, described in
>=C2=A0 =C2=A0the second bullet point of draft-ietf-tls-dtls13-37#sectio= n-7.1
>=C2=A0 =C2=A0In particular, it only occurs after a 'short' time= r triggered on the
>=C2=A0 =C2=A0receiver, where by 'short' I mean that is has smal= ler threshold than
>=C2=A0 =C2=A0the ordinary retransmission timer from DTLS 1.2, marking t= he bottom
>=C2=A0 =C2=A0line recovery time we want to improve upon.
>
> - Likewise, there's short timer based recovery in the new proposal= ,
>=C2=A0 =C2=A0but mirrored: The sender retransmits upon noticing a gap i= n the
>=C2=A0 =C2=A0ACKs, which too can be detected by a short timer as in the= current
>=C2=A0 =C2=A0proposal.

You are right, this wouldn't have worse tail-loss recovery than what is=
currently specified.=C2=A0 So, all things considered it looks like a real improvement compared to dtls13-37.

Could collect the text from this thread in a PR against Section 7?=C2=A0 Th= is
way folks that haven't followed the discussion closely can see how your=
proposal looks overall.

cheers, thanks!

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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000005aae6705a2db7c6d-- From nobody Thu Apr 9 06:59:45 2020 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 D48D23A0BAE for ; Thu, 9 Apr 2020 06:59:42 -0700 (PDT) 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, 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=IdqF7OY0; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=IdqF7OY0 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 KdV33HPWX8P9 for ; Thu, 9 Apr 2020 06:59:38 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10056.outbound.protection.outlook.com [40.107.1.56]) (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 AF1773A0BAB for ; Thu, 9 Apr 2020 06:59:37 -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=mqyYcJ6tQeyZilPbIOPHkUElMFqt8RZWFmIjs6unw18=; b=IdqF7OY0uUeS4cqMHlgzi8a5ci2Kio4cdcstfLLSClGdrdScLsjY8dA9RZV5+gfNcTEqDm8pXld2DsrTgetKn0+PYEzet/kdp0mSUHuwDjnuiztuA4kqAbRmYHkVmlNRT3BJl6ojJjIgRpbMAsGS7VbjHDTCauApBgn8emhYKEs= Received: from DB6PR0802CA0038.eurprd08.prod.outlook.com (2603:10a6:4:a3::24) by VI1PR08MB5470.eurprd08.prod.outlook.com (2603:10a6:803:136::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Thu, 9 Apr 2020 13:59:35 +0000 Received: from DB5EUR03FT047.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:a3:cafe::df) by DB6PR0802CA0038.outlook.office365.com (2603:10a6:4:a3::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Thu, 9 Apr 2020 13:59:35 +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 DB5EUR03FT047.mail.protection.outlook.com (10.152.21.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.18 via Frontend Transport; Thu, 9 Apr 2020 13:59:34 +0000 Received: ("Tessian outbound e2c88df8bbbe:v50"); Thu, 09 Apr 2020 13:59:34 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 5ca3241ec4d89fd2 X-CR-MTA-TID: 64aa7808 Received: from a6a56e783aec.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 72BBC5A7-604C-4B5D-9C1A-9E84DB9F709C.1; Thu, 09 Apr 2020 13:59:29 +0000 Received: from EUR02-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a6a56e783aec.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 09 Apr 2020 13:59:29 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VsJiCIm3Xis4lvwf/5DceBIrTPgB12CHdelG+jeUUfN4desPlogv1EnSZasyGqORZqdoCJjXwdgZj/a/wnhEzuqczolldpJXCCp+lD3kQI3PWryc9GSjg9AA1EV9026cdCoFNMl98JJJmAg7R4MBZXVYoxysR7FVQWTLBJG4GCmsPtRyORtaNCccTdWbIpNN1ZmKObHa2SDdJMFDOFpplh5m6L2pOm2xQYJi22nQnnI3LxqdZcvKWPTvCGqyF21XH3zcUFcHxeTIh1rMN9MOEyqf4bjHIA5PAXJAzX0SbgmYoM+F36mZLEJPkvysCjm3RT7OJL/hNCfgsFFL6QTcew== 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=mqyYcJ6tQeyZilPbIOPHkUElMFqt8RZWFmIjs6unw18=; b=fDKpVN0ll6Ye+WYUZkBVjtAWeopaAV0MZj0pm9RaU5Wb1RHesM/cmzUBuuZPF/HOzG+JgAUf3IUxLpHlJRxTnepxXwYlFtCxtZL0T2plvwpJG1DJZrNm6EE1omWDMqEqLtXZcdbBmD7p3aV3qx1/KaU7v09B5H6c6XWc9WOkE2Dt9IYKttm2NNp0rXvu1ePqcJE7HAfZMh+eNfKB/V8CxexhrptRbEzft1CJSldufeAdD14AKcI2SzGMgzPgjXyTc0WN2zy3zr3P//97ob/neoqTUH42inAzGHHZOt7F4l+4IKVNg1879PHsk//+4qyMd1Kwp/LnS85fKPJot2CzZw== 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=mqyYcJ6tQeyZilPbIOPHkUElMFqt8RZWFmIjs6unw18=; b=IdqF7OY0uUeS4cqMHlgzi8a5ci2Kio4cdcstfLLSClGdrdScLsjY8dA9RZV5+gfNcTEqDm8pXld2DsrTgetKn0+PYEzet/kdp0mSUHuwDjnuiztuA4kqAbRmYHkVmlNRT3BJl6ojJjIgRpbMAsGS7VbjHDTCauApBgn8emhYKEs= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB4007.eurprd08.prod.outlook.com (2603:10a6:20b:a1::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.16; Thu, 9 Apr 2020 13:59:27 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::b08c:a849:e63d:6150]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::b08c:a849:e63d:6150%7]) with mapi id 15.20.2900.015; Thu, 9 Apr 2020 13:59:27 +0000 From: Thomas Fossati To: Eric Rescorla CC: Hanno Becker , Rob Sayre , "tls@ietf.org" , Thomas Fossati Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQgAO7OoCAAKsoAP//86kAgAAdq4D///6F3YAAREwAgAD0k7KAA3V2gIAADseAgAAbtwA= Date: Thu, 9 Apr 2020 13:59:27 +0000 Message-ID: <337B9506-31F3-463C-B447-FEFBEFEC32A7@arm.com> References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> <03849701-1A14-4E1A-8298-D483E74E380C@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 9d81e217-b2b5-4637-8a23-08d7dc8e3c29 x-ms-traffictypediagnostic: AM6PR08MB4007:|AM6PR08MB4007:|VI1PR08MB5470: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:10000; x-forefront-prvs: 0368E78B5B X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(346002)(376002)(136003)(396003)(366004)(8936002)(316002)(71200400001)(86362001)(4744005)(81156014)(66446008)(91956017)(76116006)(4326008)(66556008)(66946007)(64756008)(2616005)(66476007)(186003)(81166007)(478600001)(6486002)(6512007)(33656002)(966005)(8676002)(26005)(6506007)(54906003)(53546011)(36756003)(2906002)(6916009)(5660300002); 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: kV89cUHvkesHN9xvTvxqmRV2e4/bXmcd25U9qyESLvh2679MVjTPZSTwIUVt+ciJWeu4OgE/X38aVqblQFWyUpjnfN7fvBaxEnii3K5xMdlSg+RYvXbUEDWlGMH1uv8UMtkVSpGpMdFjpqPlb1mSyTzXwQ77bGIW+kezIkDNE0kuU5aNbMUWK56pMmeGuY/Atmco18JWw4E24XYjJXXw8F04j1+jV/qSw0kh+pvc48LN2Ct40WyNCSEpn9eEdLFDPL0KMU8QVD/uqt3y4cDNQaZkPd0NYXyf11CP0/+7QsfG4w1nszZb621YVfJN0jhkiIoTlsy8RfhmeJFalJceUKktGjs0bzo1RjA+R2ysOmw6Gb3iKoT0A104MAAUJQCL5dwCR2TYYGM/TScRe16Au+YuSLWrIPtKbSc7QwjTTjzv47ram1Ck/kuO30mkwEMlbuuVCzraePN2SlBcgES0Wh71NG42cGV71WwgNrdT6jjxHKO2Gp6KJW+MCnJ5M1QyQ4XIpQMaUNgLXQN0VGEGeA== x-ms-exchange-antispam-messagedata: oeybHU3Dej8WjDO2om4F5y7b5y+A4xZC3AIEubN46cJZsYPQjzQz4N3vIOpfce43Mjx8OL+wKL+mML38DZWRVZGhztAEQlGgoX9jg/0/3knqhuJlCQpmFtjslVLtOKtkYAtTtGA9ENtpDo+0utMq9Q== Content-Type: text/plain; charset="utf-8" Content-ID: <4E1DF7E08D2F794BBC90BBF9934DA35B@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4007 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT047.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)(39860400002)(346002)(376002)(396003)(136003)(46966005)(478600001)(81156014)(6862004)(4326008)(82740400003)(36756003)(4744005)(356004)(2906002)(81166007)(316002)(5660300002)(6486002)(70586007)(70206006)(47076004)(6512007)(6506007)(53546011)(8676002)(26826003)(336012)(966005)(86362001)(2616005)(8936002)(186003)(33656002)(26005)(54906003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: ed6dfa5a-3497-4379-f856-08d7dc8e37a5 X-Forefront-PRVS: 0368E78B5B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: HVHGsRSlFnvX76jFjCZadzQBIAhd+kO5n9NDp9cMPifosKkxjiJejg95CVeO+MYQZu/aMywLUtM02gkdyobRL3a3iG9/LzzBTfOFF2BNiXLs61Mts9lTW5QiweguaxyyPzT2LPIsiXDD/MOPVFQRfJC3dIEKmwRqTjcU/uZRC8ynLk3/seWl1fzHQMtelDx854BadEyErA6FE9ww8EzzmBEWviAOX6IGty+UYa3H1LQJNY6Wxy/Zv2vL+r2ekTSP79m5t3UP7YjGMCG4/xFoW2ewda2F0BP4u/OKJjPKkaPXPE9y8R5QAhpv3fooTuNDX3k8yec+7ksolOQ58SND4h9u8xabEd8Lgos+naVVab3ltYI/H+v+MpgZmldSL2ZIwL32exp0GMbGIphRNNqeH/os83fot6j42DyIWiNJc67RT+NRT//sy6rpKi1K/p3VgEAZYynrhdUh3UsN375E4OR4VHkFsBCQ+a1ZMslfhqoM1BeaQhAoCpY+QXGqpvyZ3mvt8i4IXoGNcLcYNUlwoAllY5PGjFFzvfU/jvi5GHAwLGSNYKA2mQweSVfY6GNw7/gwBlD3Cakfj+xHgKUVAg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2020 13:59:34.8976 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9d81e217-b2b5-4637-8a23-08d7dc8e3c29 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: VI1PR08MB5470 Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Thu, 09 Apr 2020 13:59:44 -0000 T24gMDkvMDQvMjAyMCwgMTQ6MjAsICJFcmljIFJlc2NvcmxhIiA8ZWtyQHJ0Zm0uY29tPiB3cm90 ZToNCj4gQXNzdW1pbmcgSSB1bmRlcnN0YW5kIEhhbm5vJ3MgcHJvcG9zYWwsIEkgZG8gbm90IGJl bGlldmUgdGhhdCB0aGlzIGlzDQo+IGluIGZhY3QgYW4gaW1wcm92ZW1lbnQsIGFzIGl0IGRvZXMg bm90IGNvdmVyIHRoZSBpbXBvcnRhbnQgY2FzZSB3aGVyZQ0KPiB0aGUgcmVjb3JkIGNvbnRhaW5p bmcgdGhlIFNIIGlzIGxvc3QgYW5kIHRoZW4gdGhlIHJlc3Qgb2YgdGhlIG1lc3NhZ2VzDQo+IGZy b20gdGhlIHNlcnZlciBhcmUgdW5pbnRlcnByZXRhYmxlLg0KDQpJIGRvbid0IHdhbnQgdG8gc3Bl YWsgZm9yIEhhbm5vIGhlcmUgYnV0IHRoZSByZWZpbmVtZW50IHByb3Bvc2VkIGluIFsxXSwNCnNw ZWNpZmljYWxseSB0aGUgYml0IHRoYXQgc2F5czoNCg0KICBbLi4uXSBUaGV5IG1heSBhbHNvIHBy b2FjdGl2ZWx5IHJldHJhbnNtaXQgcGFydHMgb2YgYSBmbGlnaHQgZWFybHkgaWYNCiAgYW4gQUNL IG1lc3NhZ2UgaW5kaWNhdGVzIGEgZ2FwLg0KDQpzaG91bGQgY292ZXIgdGhlIGNhc2UgeW91IG1l bnRpb24gSSB0aGluay4NCg0KWzFdIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9t c2cvdGxzL3cybkVZRUIzWk1zNWJ6ZWpxY0hWRU8tT0JWUS8NCg0KSU1QT1JUQU5UIE5PVElDRTog VGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlk ZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0 IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55 IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Thu Apr 9 07:18:10 2020 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 2E6933A044F for ; Thu, 9 Apr 2020 07:18:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 Qs21uk64P4PG for ; Thu, 9 Apr 2020 07:18:06 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206D23A044E for ; Thu, 9 Apr 2020 07:18:06 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id h25so1697740lja.10 for ; Thu, 09 Apr 2020 07:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4LnhnznKfjUwO72570Dx5sdEY76OFsyFHxE4cDj7uPA=; b=sGf19YB6evnjvraayqZv74SN38Cn43kdMaFLWFF/b2VdF6zcsErw6b0wtWbaOk/UbS nrQ3kolZHOeLjYqECPsHsmExvOClk4szC/zVLazSz8rECXiJf2JBbzfDRgILiyfkRnIt m/H7kBYAjIGy9qTC2wnb/equTj1qwY7pLf6qwKAyF10h/NoXI4g+Oaiw43GTkbJegvdy PD/oUMN0DHQQIvnqBE9cBZ2AWQzzGkfzD2olsgK2NxIE/TryiRlZx3twDBFAFIE86vZa 7yTu52gCqVPbGM22Y9Xxx4QhkHEx6TMVfI/YFfYEh5lZp6hWIgn1GdDI42AE7sWndQOA n4Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4LnhnznKfjUwO72570Dx5sdEY76OFsyFHxE4cDj7uPA=; b=a6uFsXyA5FDacN9fOG0LSaou1HjlhR9N0Hx1H/v9YZCPzshBxk5iG+OsC6I21sqqPX hnjS+pjL1AsAIryzKrIxUrbyJPqzbtQPPuHdnc4x9ivLsI9eQREmTyPGjjZjPDGd4mr9 ieYRpmyVX8lsiRjrXv6LCaagTZgSGgw54SgWAv+5wclRCQFQMVc+nT7Afu9NI7uWjjz7 uno0D4F3K2anDyRwtu4FDb/edUAcTWr7PMGXAaXF2pUxEXASGTk3J3rDFG5aoYRB1kHR ZPAt5yxevoQ3VviW2be67N4/wRIopc6igJeBGwaJ4+sIJI/i6gBZibTifpMhzXJSKvqc DhCw== X-Gm-Message-State: AGi0PuZO49DZxvNIr42TxBBz35PQIY25q7tvXbzF7e7X8eKnmSXzE+0z a0nBfzHLEWO5UqJ1IQHYEECoQbdm1PJ3+0YdJnpxgw== X-Google-Smtp-Source: APiQypLDIn+YN7thEZxw3BqgSZ7gGtIS6IrFUXpy8U56Qhxitzl4J9ezUmQZ0BiwGLQvg2qmFyMoiXFgV5L2vprByvM= X-Received: by 2002:a2e:351a:: with SMTP id z26mr14969ljz.162.1586441883851; Thu, 09 Apr 2020 07:18:03 -0700 (PDT) MIME-Version: 1.0 References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> <03849701-1A14-4E1A-8298-D483E74E380C@arm.com> <337B9506-31F3-463C-B447-FEFBEFEC32A7@arm.com> In-Reply-To: <337B9506-31F3-463C-B447-FEFBEFEC32A7@arm.com> From: Eric Rescorla Date: Thu, 9 Apr 2020 07:17:27 -0700 Message-ID: To: Thomas Fossati Cc: Hanno Becker , Rob Sayre , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f1db8305a2dc48b5" Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Thu, 09 Apr 2020 14:18:08 -0000 --000000000000f1db8305a2dc48b5 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 9, 2020 at 6:59 AM Thomas Fossati wrote: > On 09/04/2020, 14:20, "Eric Rescorla" wrote: > > Assuming I understand Hanno's proposal, I do not believe that this is > > in fact an improvement, as it does not cover the important case where > > the record containing the SH is lost and then the rest of the messages > > from the server are uninterpretable. > > I don't want to speak for Hanno here but the refinement proposed in [1], > specifically the bit that says: > > [...] They may also proactively retransmit parts of a flight early if > an ACK message indicates a gap. > > should cover the case you mention I think. > But this requires being able to send an empty ACK that means "I got nothing". In which case, I don't see how it's really different from the current text except that it gives the sender less guidance. -Ekr --000000000000f1db8305a2dc48b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 9, 2020 at 6:59 AM Thomas= Fossati <Thomas.Fossati@arm.c= om> wrote:
ekr@rtfm.com> wrote:
> Assuming I understand Hanno's proposal, I do not believe that this= is
> in fact an improvement, as it does not cover the important case where<= br> > the record containing the SH is lost and then the rest of the messages=
> from the server are uninterpretable.

I don't want to speak for Hanno here but the refinement proposed in [1]= ,
specifically the bit that says:

=C2=A0 [...] They may also proactively retransmit parts of a flight early i= f
=C2=A0 an ACK message indicates a gap.

should cover the case you mention I think.

<= div>But this requires being able to send an empty ACK that means "I go= t nothing". In which case, I don't see how it's really differe= nt from the current text except that it gives the sender less guidance.

-Ekr

--000000000000f1db8305a2dc48b5-- From nobody Thu Apr 9 07:28:27 2020 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 36ACE3A0766 for ; Thu, 9 Apr 2020 07:28:25 -0700 (PDT) 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, 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=X/eb5uWu; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=X/eb5uWu 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 XyvCcwYhPQsy for ; Thu, 9 Apr 2020 07:28:19 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70077.outbound.protection.outlook.com [40.107.7.77]) (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 536553A0764 for ; Thu, 9 Apr 2020 07:28:19 -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=YYgCxS5xx76ISLVSOxpKRGrWR+x8CEU+D1OWMWeDe5E=; b=X/eb5uWusQezcLFo5HTvlqf/D0Jt05WO8G4VfEj39Fick3oGayzRfAsscQTRN796OmGIt7JaF60mvBahaskO6BUitPzFBhwe2cIIKTfmvZauO9gu/e8rPyyZ+9u25EtILA6Ac9DZhprvU+wV9SiTn/LRsJFH3uScLgzFd5t9jfA= Received: from AM6P194CA0040.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:84::17) by AM0PR08MB4499.eurprd08.prod.outlook.com (2603:10a6:208:140::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.17; Thu, 9 Apr 2020 14:28:15 +0000 Received: from AM5EUR03FT003.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:84:cafe::de) by AM6P194CA0040.outlook.office365.com (2603:10a6:209:84::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Thu, 9 Apr 2020 14:28:15 +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 AM5EUR03FT003.mail.protection.outlook.com (10.152.16.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Thu, 9 Apr 2020 14:28:15 +0000 Received: ("Tessian outbound 9e48e1321951:v50"); Thu, 09 Apr 2020 14:28:15 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 6425a059da2e4886 X-CR-MTA-TID: 64aa7808 Received: from 87f62c7fdf80.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 98A89D46-67CE-4D66-9600-2872CA358C68.1; Thu, 09 Apr 2020 14:28:10 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 87f62c7fdf80.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 09 Apr 2020 14:28:10 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XwqWQ1b+8kZEM6RmkC6nR3TaAevNOn7NC4WGVEXFTYCrKhIZNfWrq/R6e1abtWlIOLI0ixnDHPaDW9Zu/+t0JQWOrm2b4Ozpjwekfw3DAxuWj0ZbZxMU6Ilpib7DYCqDXUw7Zdz4T5lqtg5II4Axhqp3kMdOfAJYa/lIH5XwOMkcPDDKXmZIce8NhkcmNr1CQsHTwJ52MtJnLRiLh8jxxgje+FjTUl33tS+SLGt7Er8J8P0vJeLWhQw42e2ntp0HY+dR8FdbX0Kku/kIgIlcdnD19VrNw6RfzP2pCVs817wh1lsM6+UzZcnYag575WnLiSO+DRmlXHrOl5BZY3871A== 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=YYgCxS5xx76ISLVSOxpKRGrWR+x8CEU+D1OWMWeDe5E=; b=Q+pUFMEyv3olmUkM+C7EISOZf580zC/4R1P5NteGzgrMARyNHbniWs0CP2YEu1UmVwG/t1IFW3FEJY3qaj5GzrHiyyelNGEdXIMGmbasdynlSmQ9JNdPeo0a81p0gySVIsDYAY1M4gZjoYZLkYeH9MpczWn4hVBXXa/Om39xHiLUPph6vQnLjOTFtxzkWfd6Iqw0A5jCaG3ZgPA4omoH5uSj+UjczDgjD/FzrcNnbp7Gn0wEXughEeaj70WQ3T6EsYbL1lEs/y6FaKY1Io7lnNy3Q5wDYKPpTr8NzMGi6auggQx1vhM2BNTVuhmJxm8LLPo6vfl0siO4T6T7qT6E0Q== 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=YYgCxS5xx76ISLVSOxpKRGrWR+x8CEU+D1OWMWeDe5E=; b=X/eb5uWusQezcLFo5HTvlqf/D0Jt05WO8G4VfEj39Fick3oGayzRfAsscQTRN796OmGIt7JaF60mvBahaskO6BUitPzFBhwe2cIIKTfmvZauO9gu/e8rPyyZ+9u25EtILA6Ac9DZhprvU+wV9SiTn/LRsJFH3uScLgzFd5t9jfA= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB5286.eurprd08.prod.outlook.com (2603:10a6:20b:aa::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Thu, 9 Apr 2020 14:28:08 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::b08c:a849:e63d:6150]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::b08c:a849:e63d:6150%7]) with mapi id 15.20.2900.015; Thu, 9 Apr 2020 14:28:08 +0000 From: Thomas Fossati To: Eric Rescorla CC: Hanno Becker , Rob Sayre , "tls@ietf.org" , Thomas Fossati Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQgAO7OoCAAKsoAP//86kAgAAdq4D///6F3YAAREwAgAD0k7KAA3V2gIAADseAgAAbtwD///RFgAACd9OA Date: Thu, 9 Apr 2020 14:28:08 +0000 Message-ID: <5744AFC1-D9B5-421E-893B-949ACA76C51D@arm.com> References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> <03849701-1A14-4E1A-8298-D483E74E380C@arm.com> <337B9506-31F3-463C-B447-FEFBEFEC32A7@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1ced8b99-95e9-4a7c-2cff-08d7dc923dee x-ms-traffictypediagnostic: AM6PR08MB5286:|AM6PR08MB5286:|AM0PR08MB4499: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:7691;OLM:9508; x-forefront-prvs: 0368E78B5B X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(396003)(136003)(366004)(376002)(39860400002)(346002)(8676002)(4326008)(36756003)(5660300002)(478600001)(76116006)(26005)(71200400001)(6506007)(53546011)(91956017)(6916009)(186003)(316002)(2906002)(81156014)(54906003)(33656002)(86362001)(6486002)(66946007)(66556008)(66476007)(2616005)(64756008)(81166007)(8936002)(66446008)(6512007); 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: E09DD+sSWsjNK+mpCEVbnW8r55XBjw8Mb+0ff2SoXP42voYepJ0o5aVDp8HTcW2MYtCsU+u5hn1bJ0xNTD6kcTna3gDZuVKZIomdgQQn9i1+yjAX0aYWffkAYeaIS7ExibegGU4hzyN6kiI4VbRavlB6jl/KEEyr9pyCmkPFxJEImsDe4fMdUqcbCt8FlxhZ23z4iWWdSvF3DE4pIiI4Glrvk8eu3BFH24CIgWSwlgFQEVhgDYPnUjXjDROO0+6erTloH89NoNu3QMnvt0N87xSXH8pFfA0l0oXVErYrhLlXWuawUd/xfhddeIBPMVNBEFXqFsEE0gnbPnz9iD3cLbAat+3bfpJKG2Mu5fxBQoQs3XNPdnYXqDZKBG9eIPCn8tqZdgtMG66rDyX092WwyS5NBGgfHgssvQgAK4fOT0xUTe3VvfZAShdb/CFO7rLh x-ms-exchange-antispam-messagedata: 9Oa73PqgxTejhJ3DgQLSa/T+ELgFB0q7Ygdrt+Y7E62wk0RgWZuK3BQR2QGqjRYxb3/yajcfc0knjNnLJthQHviRSQegM1/zpFN19EsOt3XcS2yLN9ieBVvHWt412K2eas7LEZ3j+4oqpc8AauDASA== Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5286 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT003.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)(376002)(136003)(39860400002)(396003)(346002)(46966005)(8936002)(356004)(5660300002)(81156014)(8676002)(53546011)(6506007)(186003)(6486002)(2616005)(82740400003)(26826003)(2906002)(26005)(478600001)(36756003)(33656002)(336012)(54906003)(47076004)(6512007)(81166007)(316002)(6862004)(86362001)(70206006)(70586007)(4326008)(36906005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: e11dd0cf-99e8-41db-3409-08d7dc92397c X-Forefront-PRVS: 0368E78B5B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: GzoO1vz2CnX5v4cdTJFLndwU6ZyJFKOiO/Vd6PR+bNJEB4IIr3b5sDwbPsEW+ChEzxhsyoOveyoohPdbhyqGNkG6xAM7BmOJljDZ0bb40g6naCceUyZ5NKTRe3eo+NcFGa1tDcjNrte3ta7jNZjNKgh7+SXSL/nXcNE4uObNnWnmcrqXd13QKMfj8Y8c9zyDkopq77IIwe2XSsrusS3E4m9ZvU7j3I64nuUfQpqykrt1MW7rVeZZB4lyfKlaIJ2gQNJLHmFHRN/yPk6vx1Eg7xpTK/I51JCNX46Hm/SyOk7Rj/RfK0sf3TxZe0vWHkg16WIM1t9S2eYMtkgPmVSHNV1gmAFS9a/EfGSEaeXQPRB046/9ySRFubtc2t2zB/M1TpYgJF2qkTOqxieiPM/OGUx02zyt8gZh/ny0iiwAkkJookQxL39g3Qczy6k7JOjAkzVpRR5sHKM6FNE0xQq4RYBBvPuCU4ihy45mD44jvDsYEVUlyCp0TAotYI9wMLj0yoxut27+Q+Q99mur3kNcCg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2020 14:28:15.7979 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1ced8b99-95e9-4a7c-2cff-08d7dc923dee 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: AM0PR08MB4499 Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Thu, 09 Apr 2020 14:28:25 -0000 T24gMDkvMDQvMjAyMCwgMTU6MTgsICJFcmljIFJlc2NvcmxhIiA8ZWtyQHJ0Zm0uY29tPiB3cm90 ZToNCj4gPiBPbiBUaHUsIEFwciA5LCAyMDIwIGF0IDY6NTkgQU0gVGhvbWFzIEZvc3NhdGkgPFRo b21hcy5Gb3NzYXRpQGFybS5jb20+IHdyb3RlOg0KPiA+IE9uIDA5LzA0LzIwMjAsIDE0OjIwLCAi RXJpYyBSZXNjb3JsYSIgPGVrckBydGZtLmNvbT4gd3JvdGU6DQo+ID4gPiBBc3N1bWluZyBJIHVu ZGVyc3RhbmQgSGFubm8ncyBwcm9wb3NhbCwgSSBkbyBub3QgYmVsaWV2ZSB0aGF0IHRoaXMNCj4g PiA+IGlzIGluIGZhY3QgYW4gaW1wcm92ZW1lbnQsIGFzIGl0IGRvZXMgbm90IGNvdmVyIHRoZSBp bXBvcnRhbnQgY2FzZQ0KPiA+ID4gd2hlcmUgdGhlIHJlY29yZCBjb250YWluaW5nIHRoZSBTSCBp cyBsb3N0IGFuZCB0aGVuIHRoZSByZXN0IG9mDQo+ID4gPiB0aGUgbWVzc2FnZXMgZnJvbSB0aGUg c2VydmVyIGFyZSB1bmludGVycHJldGFibGUuDQo+ID4NCj4gPiBJIGRvbid0IHdhbnQgdG8gc3Bl YWsgZm9yIEhhbm5vIGhlcmUgYnV0IHRoZSByZWZpbmVtZW50IHByb3Bvc2VkIGluDQo+ID4gWzFd LCBzcGVjaWZpY2FsbHkgdGhlIGJpdCB0aGF0IHNheXM6DQo+ID4NCj4gPiAgIFsuLi5dIFRoZXkg bWF5IGFsc28gcHJvYWN0aXZlbHkgcmV0cmFuc21pdCBwYXJ0cyBvZiBhIGZsaWdodCBlYXJseQ0K PiA+ICAgaWYgYW4gQUNLIG1lc3NhZ2UgaW5kaWNhdGVzIGEgZ2FwLg0KPiA+DQo+ID4gc2hvdWxk IGNvdmVyIHRoZSBjYXNlIHlvdSBtZW50aW9uIEkgdGhpbmsuDQo+DQo+IEJ1dCB0aGlzIHJlcXVp cmVzIGJlaW5nIGFibGUgdG8gc2VuZCBhbiBlbXB0eSBBQ0sgdGhhdCBtZWFucyAiSSBnb3QNCj4g bm90aGluZyIuIEluIHdoaWNoIGNhc2UsIEkgZG9uJ3Qgc2VlIGhvdyBpdCdzIHJlYWxseSBkaWZm ZXJlbnQgZnJvbQ0KPiB0aGUgY3VycmVudCB0ZXh0IGV4Y2VwdCB0aGF0IGl0IGdpdmVzIHRoZSBz ZW5kZXIgbGVzcyBndWlkYW5jZS4NCg0KTm90IHN1cmUgdGhlcmUncyBhbiAiZW1wdHkgQUNLIiBp biBIYW5ubydzIHByb3Bvc2FsLiAgVGhpcyBpcyBob3cgSQ0KaW50ZXJwcmV0IGl0IGluIHRoZSBj b250ZXh0IG9mIHlvdXIgZXhhbXBsZTogaW4gdGhlIHNlY29uZCBmbGlnaHQsIGlmDQpyZWMjMCAo Y29udGFpbmluZyBTSCkgaXMgbG9zdCBhbmQgcmVjIzEgZ2V0cyB0aHJvdWdoLCB0aGUgcmVjZWl2 ZXIgc2VuZHMNCkFDSyB7MX0uICBGcm9tIHRoYXQgdGhlIHNlbmRlciBjYW4gaW5mZXIgdGhlIGdh cCBhbmQgcmV0cmFuc21pdCByZWMjMC4NCg0KKEJ1dCBhZ2FpbiwgSSdtIG5vdCBoaW0gYW5kIHRo YXQncyB3aHkgSSBzdWdnZXN0ZWQgY29sbGVjdGluZyBhbGwgdGhlDQpwaWVjZXMgb2YgdGhpcyBk aXNjdXNzaW9uIHRvZ2V0aGVyIGluIG9uZSBQUi4pDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBj b250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlh bCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBu b3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3Ig YW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRp dW0uIFRoYW5rIHlvdS4NCg== From nobody Thu Apr 9 07:34:15 2020 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 83A013A077E for ; Thu, 9 Apr 2020 07:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 XNvZ_5G5KDhR for ; Thu, 9 Apr 2020 07:34:05 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D5C3A0786 for ; Thu, 9 Apr 2020 07:34:05 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id v16so11717548ljg.5 for ; Thu, 09 Apr 2020 07:34:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cm3ziCrZpml1SoDIjc3PpEAkShBjOfa6IK60q6UPvR0=; b=Ci0o9m0k/kKyUrLmEdKxl1+IE1u3Qej3r/3ZMbMAIxL+L5jeTWOETcMlYxoMblA4AN xKj3b96TEdvFHzCXJ+oaWRGajYWHqpPxYAmS/U5wILmMEFKmE0oOqfZ44qj2ezoiCE/g l2eCw6BAI43vp9L4f6P3oeKsgOVWqDb+9hmDQIzQEQBg0guSMkElgDOsuh+EkNo13vai wFdcwGtGPSXWbf+DYp8SDwLL/fx6Uy5geFEXL/7XmpkWtE3KmXbHAk4gcnHPVq0DFUhJ XeK6ReBpm+JI599u7E62IfPzyaDhN5KEt/Yup202PuqO+pQnGtTgMcnDQDc28MePrDYF aj0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cm3ziCrZpml1SoDIjc3PpEAkShBjOfa6IK60q6UPvR0=; b=BSfqMXAZdDEeMZhvYMrLNXMjFugV3DCOAMJzm/vK7uzQ2L+d2wqNOlo0Z7gxGk7Ea+ jreeJN4vbR55UH5oiDoeSLunbf+Huhl6mO5fSeIAjfan8VJ2G5Dpd3bK0a5hbOAwsBj2 XqxnurLI8SdlAGaRp54dyH3HoQLYk6BCLnzJGRtGm6+o/FtQzz3HxfrTdBE736DjYq2G GbREqAzv39MRxeATyR544Shb92CY3bJM1ALjik8cdwajv8BuWPAlQR++6s4xi5SE++8W prZmFigoSqCV/Q/gwoak+gXoggdcPoJaXnJr1mCzbrjQiSLEx5bRUcOZ2Pj0Mj1QQwzX 4kqA== X-Gm-Message-State: AGi0PuZdy51YpaoMhMmMNPzP6Oy52QeQX3K9TNpbOEtz5j0RlhzlxGUL gEzOFXlS04ZhwUnRluoxjGLx0RvD6jEXzM1B53u8/w== X-Google-Smtp-Source: APiQypIDAOTgnGVcUeNPmQ+LT3EG3HMzEDmqZs5hzPU15etizNcwJbAP372KRDu4IPD+umcox1zHXsa8pnBBOSqab4E= X-Received: by 2002:a2e:b0ee:: with SMTP id h14mr43939ljl.35.1586442842994; Thu, 09 Apr 2020 07:34:02 -0700 (PDT) MIME-Version: 1.0 References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> <03849701-1A14-4E1A-8298-D483E74E380C@arm.com> <337B9506-31F3-463C-B447-FEFBEFEC32A7@arm.com> <5744AFC1-D9B5-421E-893B-949ACA76C51D@arm.com> In-Reply-To: <5744AFC1-D9B5-421E-893B-949ACA76C51D@arm.com> From: Eric Rescorla Date: Thu, 9 Apr 2020 07:33:26 -0700 Message-ID: To: Thomas Fossati Cc: Hanno Becker , Rob Sayre , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001d06a805a2dc82ab" Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Thu, 09 Apr 2020 14:34:13 -0000 --0000000000001d06a805a2dc82ab Content-Type: text/plain; charset="UTF-8" On Thu, Apr 9, 2020 at 7:28 AM Thomas Fossati wrote: > On 09/04/2020, 15:18, "Eric Rescorla" wrote: > > > On Thu, Apr 9, 2020 at 6:59 AM Thomas Fossati > wrote: > > > On 09/04/2020, 14:20, "Eric Rescorla" wrote: > > > > Assuming I understand Hanno's proposal, I do not believe that this > > > > is in fact an improvement, as it does not cover the important case > > > > where the record containing the SH is lost and then the rest of > > > > the messages from the server are uninterpretable. > > > > > > I don't want to speak for Hanno here but the refinement proposed in > > > [1], specifically the bit that says: > > > > > > [...] They may also proactively retransmit parts of a flight early > > > if an ACK message indicates a gap. > > > > > > should cover the case you mention I think. > > > > But this requires being able to send an empty ACK that means "I got > > nothing". In which case, I don't see how it's really different from > > the current text except that it gives the sender less guidance. > > Not sure there's an "empty ACK" in Hanno's proposal. This is how I > interpret it in the context of your example: in the second flight, if > rec#0 (containing SH) is lost and rec#1 gets through, the receiver sends > ACK {1}. From that the sender can infer the gap and retransmit rec#0. > You can't send ACK{1} because you can't decrypt it because it is out of order with respect to the DH key. This is the point of the empty ACK. -Ekr > (But again, I'm not him and that's why I suggested collecting all the > pieces of this discussion together in one PR.) > > 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. > --0000000000001d06a805a2dc82ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 9, 2020 at 7:28 AM Thomas= Fossati <Thomas.Fossati@arm.c= om> wrote:
ekr@rtfm.com> wrote:
> > On Thu, Apr 9, 2020 at 6:59 AM Thomas Fossati <Thomas.Fossati@arm.com>= wrote:
> > On 09/04/2020, 14:20, "Eric Rescorla" <ekr@rtfm.com> wrote:
> > > Assuming I understand Hanno's proposal, I do not believe= that this
> > > is in fact an improvement, as it does not cover the importan= t case
> > > where the record containing the SH is lost and then the rest= of
> > > the messages from the server are uninterpretable.
> >
> > I don't want to speak for Hanno here but the refinement propo= sed in
> > [1], specifically the bit that says:
> >
> >=C2=A0 =C2=A0[...] They may also proactively retransmit parts of a= flight early
> >=C2=A0 =C2=A0if an ACK message indicates a gap.
> >
> > should cover the case you mention I think.
>
> But this requires being able to send an empty ACK that means "I g= ot
> nothing". In which case, I don't see how it's really diff= erent from
> the current text except that it gives the sender less guidance.

Not sure there's an "empty ACK" in Hanno's proposal.=C2= =A0 This is how I
interpret it in the context of your example: in the second flight, if
rec#0 (containing SH) is lost and rec#1 gets through, the receiver sends ACK {1}.=C2=A0 From that the sender can infer the gap and retransmit rec#0.=

You can't send ACK{1} because you = can't=C2=A0 decrypt it because it is out of order with respect to the D= H key. This is the point of the empty ACK.

-Ekr



(But again, I'm not him and that's why I suggested collecting all t= he
pieces of this discussion together in one PR.)

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.
--0000000000001d06a805a2dc82ab-- From nobody Thu Apr 9 08:09:51 2020 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 18E3A3A0959 for ; Thu, 9 Apr 2020 08:09:50 -0700 (PDT) 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, RCVD_IN_MSPIKE_H2=-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=u8VbDkVq; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=u8VbDkVq 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 RsIqxJoO9WlR for ; Thu, 9 Apr 2020 08:09:47 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2050.outbound.protection.outlook.com [40.107.22.50]) (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 0C2C13A0957 for ; Thu, 9 Apr 2020 08:09:46 -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=BGwIkY0x9yrDmZ5HDwXkGHUKqOvqcV2nOL1qcHq7bdk=; b=u8VbDkVqnWSk1x5ZE3yCkyqNlBqyTnEFg2rqmYGNn2WNYZcj+1hoShom9y/fNG0iItzH5f4JigLFwkkSruEnXEWtY0hqIkTXCQcmYSdeGqWuG389u7pcIspOLw/TVPhmb7+JOTfM9rB6w1W8xFgMtiqbUdemF9aVmoNmVMvPCGY= Received: from AM7PR02CA0008.eurprd02.prod.outlook.com (2603:10a6:20b:100::18) by VI1PR08MB2958.eurprd08.prod.outlook.com (2603:10a6:803:3d::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19; Thu, 9 Apr 2020 15:09:43 +0000 Received: from AM5EUR03FT043.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:100:cafe::f8) by AM7PR02CA0008.outlook.office365.com (2603:10a6:20b:100::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Thu, 9 Apr 2020 15:09:43 +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 AM5EUR03FT043.mail.protection.outlook.com (10.152.17.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Thu, 9 Apr 2020 15:09:43 +0000 Received: ("Tessian outbound 4b84da486446:v50"); Thu, 09 Apr 2020 15:09:43 +0000 X-CR-MTA-TID: 64aa7808 Received: from c34be9d582a1.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A680C6FC-6DEA-422A-A18B-A1D4197665AF.1; Thu, 09 Apr 2020 15:09:38 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id c34be9d582a1.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 09 Apr 2020 15:09:38 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gyzzK75jOTInB1iId2flaMRNFnfSkMBI8p0nRhfwwWEzNsUlGGdqFP2uJNq2sW6YcMeai0fogKEi9yd00A0AAol+5ZTNtKX8tUm7P3kmyld2t8xrqYhI6pAbjnUtvoQXD3SyqzuxunXEyH/3zlOGfofa2L69lYqsKSUxZwr2UTFSSfQOw33OI3vrLcm/T5tIQzUT41dIEzRzMEB3VcwS+4iHTL3wTpy9M+vKedpaLIITKXbBVrUHB1pslV6wjItLq8CskfxgxFwTu8ty0l+0UMXq3UHZxFHDcLaje1nqv9s2ODSqD2LMWuvwjXaJx9CSUf6WnUdGta6CDoJ1Ez02BA== 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=BGwIkY0x9yrDmZ5HDwXkGHUKqOvqcV2nOL1qcHq7bdk=; b=nCi8cqOsVICbh2Ap6v1IX3jOGOiUwcheWHNjv4+P5+7m7BuxvUIHZnT/BgHUrt+H8bDTK9XeZkPKT+RpDUjSZ0WZin+QNPXRSxexOXlXdVcqTHJ8Ujjq1KRkNuLa9Fp3zYocDCauLTv49AXv3uhU4fODIIuir8iL6CjCj2HLmwDhre1KghXpCrCMRytaiThY9v+1WupAYk4gv7XJGNulCvkGLqZBuOIO3pdfVWeGv3Z5DZDddqe5XnbWJK764rGl9bf6rQN0b7vMI4aATMRXdNWZdHwF4/wX36TBHJM9q+a6MxMGg11zZLZWUNcNP2EAV2ELl+BtHLWWyNHN5zikmw== 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=BGwIkY0x9yrDmZ5HDwXkGHUKqOvqcV2nOL1qcHq7bdk=; b=u8VbDkVqnWSk1x5ZE3yCkyqNlBqyTnEFg2rqmYGNn2WNYZcj+1hoShom9y/fNG0iItzH5f4JigLFwkkSruEnXEWtY0hqIkTXCQcmYSdeGqWuG389u7pcIspOLw/TVPhmb7+JOTfM9rB6w1W8xFgMtiqbUdemF9aVmoNmVMvPCGY= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB4130.eurprd08.prod.outlook.com (2603:10a6:208:132::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Thu, 9 Apr 2020 15:09:37 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::2159:870b:25df:e612%5]) with mapi id 15.20.2878.022; Thu, 9 Apr 2020 15:09:37 +0000 From: Hannes Tschofenig To: Eric Rescorla , Thomas Fossati CC: "tls@ietf.org" Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQgAO7OoCAAKsoAP//86kAgAAdq4D///6F3YAAREwAgAD0k7KAA3V2gIAADseAgAAbtwD///RFgAACd9OA///wuAD///bb0A== Date: Thu, 9 Apr 2020 15:09:37 +0000 Message-ID: References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> <03849701-1A14-4E1A-8298-D483E74E380C@arm.com> <337B9506-31F3-463C-B447-FEFBEFEC32A7@arm.com> <5744AFC1-D9B5-421E-893B-949ACA76C51D@arm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: a09488af-6381-4821-91f8-0fc6de131954.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.115.119] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: af6b052f-4d50-47f3-40ae-08d7dc9808c1 x-ms-traffictypediagnostic: AM0PR08MB4130:|AM0PR08MB4130:|VI1PR08MB2958: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 0368E78B5B X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(396003)(39860400002)(376002)(346002)(366004)(7696005)(6506007)(53546011)(66476007)(66946007)(316002)(66556008)(81156014)(9686003)(8936002)(4326008)(110136005)(86362001)(71200400001)(66446008)(64756008)(6636002)(33656002)(76116006)(966005)(26005)(81166007)(478600001)(186003)(2906002)(52536014)(55016002)(5660300002)(8676002); 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: yDQb0e2hXBP6y3Jf41bb3MrdS6+7RKVYMadPchJN+6XrWMOLKpfl9oGTVvEj6qCOSOnHV64l2GtBPf6KnMYFs/b7sNx7hmnBdtkA34ETf+qj7bTQxrGwMLbHZxd45dwubMS0hNjboiIjgvi1AOScEJghqSGnbUXa02/BoaBTgS66gb99GaFf5KKdHZRXKzpeoXI0G0TmRI1+j+801drkLpix0iBdIBu0LSGEdigtdmodfmH+o16ZMiIy3xsNlF183kr+RV7ctqSi0+XBq8oOcsCzXJTS+br9ZJkltiUL3fiOCMWgkkC0ZOnK44Mi1PMOjjndk1Rc7OA8upGRzbSIo05tfcl/mC7SnZpCYl4ucEkqjZQx+crUN9z/+1gW+RSuzyETc8BsI1RCCvong6q4JP5BNwV+zzoN0mKh/RIlTeJsRa5VqD0AOCptxIAxhu+0WHnuwvHVyIcrTrltT6LCrp8s4xBhe6OOGWR3bqvWTWuAhqsTux6+jdKEmZndXz+uTTJYK8STKlCkG13vgyV/VA== x-ms-exchange-antispam-messagedata: Y3LzYoHRaDXzXQK2vwliiTNith5e2FftKMDfKG2Z6opwSEJUtQa0gGHrz0y3dHDK6gx90m6GUpqviwe/IJlCU+/wgtynMGiAYQWJajnn+NPx8TLs0HYHfZ+ub7zeTq2i/AZh8skAfRMsFzVvM42XNA== Content-Type: multipart/alternative; boundary="_000_AM0PR08MB37166F4946EE1A27499AD1E8FAC10AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4130 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT043.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)(39860400002)(396003)(136003)(346002)(376002)(46966005)(6506007)(316002)(478600001)(36906005)(110136005)(47076004)(82740400003)(26826003)(81166007)(33964004)(52536014)(5660300002)(70206006)(70586007)(966005)(26005)(86362001)(8936002)(4326008)(336012)(55016002)(53546011)(186003)(9686003)(6636002)(33656002)(356004)(7696005)(8676002)(81156014)(2906002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 8f4de4c1-a9af-4b95-adc0-08d7dc98051e X-Forefront-PRVS: 0368E78B5B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jXq6A4D/3poAUmtooz5/i8HKvsVOu7UzPr8oeCCUowg4ypbEKFGKs9dB/rlDX5hPivYRrdLG9kqGeKFHzUeCUalRlGmSQpnFr5Twm89NmZz40CtCFOniSDUS1uI24zxwNUK6JHZVt/gCKgdVX6vsW6SCX5Pl0aSN130NKQGZCG602keCiGjwWrUn0K1vIDE1KKXtS0inQdPhtrgqzoZ6oAFOCt026/ZmfX+/20mk/yVlPPNuTbRhuYTfK8ltlwWOJfS+ICn/gKIV7+RKKDVytCjrTrz1nzeul3v57j0YguFc/xsvsI0XL/8TPQAIDEFnENUppyMvUVaWf5Gn73xDaeh+B1/oEXkK6bAujvJ/JDO5bHmvuHkwdbuM9UKcMQY9HJ9kszm64avOQJ6/qXuccsxcmIMx6eKDWwhX1b0xz/0I2SZNa4pyamGJfs48nEsQzMF7O+XJF/B/JNHGf26GhMeuMaXBUDiS1HVgmcD2Ti1oEjWo0IVLjDbDzpa3M2ofn6I8TbtK4VzZqBD/Lv9ss/50hRMD4uUyLLqraWcZEIZj1rdLtWwG55YHskWCoTpU1VAJ+HglELgC2Exwd26s2Q== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2020 15:09:43.5456 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: af6b052f-4d50-47f3-40ae-08d7dc9808c1 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: VI1PR08MB2958 Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Thu, 09 Apr 2020 15:09:50 -0000 --_000_AM0PR08MB37166F4946EE1A27499AD1E8FAC10AM0PR08MB3716eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGhvbWFzLCBIaSBFa3IsDQoNCkl0IHNlZW1zIHdlIG5lZWQgdG8gZml4IEZpZ3VyZSAxMSBv ZiBTZWN0aW9uIDcuMSBvZg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi10bHMt ZHRsczEzLTM3Lmh0bWw8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi10bHMtZHRs czEzLTM3Lmh0bWwjc2VjdGlvbi03LjE+DQooQUNLWzFdIHNob3VsZCBhY3R1YWxseSBiZSBBQ0tb XSkNCg0KSXQgc2hvdWxkIGZvbGxvdyB0aGUg4oCcZW1wdHkgQUNL4oCdIGRlc2NyaXB0aW9uIG9m IHRoZSBsYXN0IHBhcmFncmFwaCBvZiB0aGUgc2FtZSBzZWN0aW9uLg0KDQpHb29kIGNhdGNoIQ0K DQpDaWFvDQpIYW5uZXMNCg0KRnJvbTogVExTIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIEVyaWMgUmVzY29ybGENClNlbnQ6IFRodXJzZGF5LCBBcHJpbCA5LCAyMDIwIDQ6MzMg UE0NClRvOiBUaG9tYXMgRm9zc2F0aSA8VGhvbWFzLkZvc3NhdGlAYXJtLmNvbT4NCkNjOiB0bHNA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBFZmZpY2llbmN5IG9mIEFDS2luZyBzY2hlbWUN Cg0KDQoNCk9uIFRodSwgQXByIDksIDIwMjAgYXQgNzoyOCBBTSBUaG9tYXMgRm9zc2F0aSA8VGhv bWFzLkZvc3NhdGlAYXJtLmNvbTxtYWlsdG86VGhvbWFzLkZvc3NhdGlAYXJtLmNvbT4+IHdyb3Rl Og0KT24gMDkvMDQvMjAyMCwgMTU6MTgsICJFcmljIFJlc2NvcmxhIiA8ZWtyQHJ0Zm0uY29tPG1h aWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToNCj4gPiBPbiBUaHUsIEFwciA5LCAyMDIwIGF0IDY6 NTkgQU0gVGhvbWFzIEZvc3NhdGkgPFRob21hcy5Gb3NzYXRpQGFybS5jb208bWFpbHRvOlRob21h cy5Gb3NzYXRpQGFybS5jb20+PiB3cm90ZToNCj4gPiBPbiAwOS8wNC8yMDIwLCAxNDoyMCwgIkVy aWMgUmVzY29ybGEiIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0K PiA+ID4gQXNzdW1pbmcgSSB1bmRlcnN0YW5kIEhhbm5vJ3MgcHJvcG9zYWwsIEkgZG8gbm90IGJl bGlldmUgdGhhdCB0aGlzDQo+ID4gPiBpcyBpbiBmYWN0IGFuIGltcHJvdmVtZW50LCBhcyBpdCBk b2VzIG5vdCBjb3ZlciB0aGUgaW1wb3J0YW50IGNhc2UNCj4gPiA+IHdoZXJlIHRoZSByZWNvcmQg Y29udGFpbmluZyB0aGUgU0ggaXMgbG9zdCBhbmQgdGhlbiB0aGUgcmVzdCBvZg0KPiA+ID4gdGhl IG1lc3NhZ2VzIGZyb20gdGhlIHNlcnZlciBhcmUgdW5pbnRlcnByZXRhYmxlLg0KPiA+DQo+ID4g SSBkb24ndCB3YW50IHRvIHNwZWFrIGZvciBIYW5ubyBoZXJlIGJ1dCB0aGUgcmVmaW5lbWVudCBw cm9wb3NlZCBpbg0KPiA+IFsxXSwgc3BlY2lmaWNhbGx5IHRoZSBiaXQgdGhhdCBzYXlzOg0KPiA+ DQo+ID4gICBbLi4uXSBUaGV5IG1heSBhbHNvIHByb2FjdGl2ZWx5IHJldHJhbnNtaXQgcGFydHMg b2YgYSBmbGlnaHQgZWFybHkNCj4gPiAgIGlmIGFuIEFDSyBtZXNzYWdlIGluZGljYXRlcyBhIGdh cC4NCj4gPg0KPiA+IHNob3VsZCBjb3ZlciB0aGUgY2FzZSB5b3UgbWVudGlvbiBJIHRoaW5rLg0K Pg0KPiBCdXQgdGhpcyByZXF1aXJlcyBiZWluZyBhYmxlIHRvIHNlbmQgYW4gZW1wdHkgQUNLIHRo YXQgbWVhbnMgIkkgZ290DQo+IG5vdGhpbmciLiBJbiB3aGljaCBjYXNlLCBJIGRvbid0IHNlZSBo b3cgaXQncyByZWFsbHkgZGlmZmVyZW50IGZyb20NCj4gdGhlIGN1cnJlbnQgdGV4dCBleGNlcHQg dGhhdCBpdCBnaXZlcyB0aGUgc2VuZGVyIGxlc3MgZ3VpZGFuY2UuDQoNCk5vdCBzdXJlIHRoZXJl J3MgYW4gImVtcHR5IEFDSyIgaW4gSGFubm8ncyBwcm9wb3NhbC4gIFRoaXMgaXMgaG93IEkNCmlu dGVycHJldCBpdCBpbiB0aGUgY29udGV4dCBvZiB5b3VyIGV4YW1wbGU6IGluIHRoZSBzZWNvbmQg ZmxpZ2h0LCBpZg0KcmVjIzAgKGNvbnRhaW5pbmcgU0gpIGlzIGxvc3QgYW5kIHJlYyMxIGdldHMg dGhyb3VnaCwgdGhlIHJlY2VpdmVyIHNlbmRzDQpBQ0sgezF9LiAgRnJvbSB0aGF0IHRoZSBzZW5k ZXIgY2FuIGluZmVyIHRoZSBnYXAgYW5kIHJldHJhbnNtaXQgcmVjIzAuDQoNCllvdSBjYW4ndCBz ZW5kIEFDS3sxfSBiZWNhdXNlIHlvdSBjYW4ndCAgZGVjcnlwdCBpdCBiZWNhdXNlIGl0IGlzIG91 dCBvZiBvcmRlciB3aXRoIHJlc3BlY3QgdG8gdGhlIERIIGtleS4gVGhpcyBpcyB0aGUgcG9pbnQg b2YgdGhlIGVtcHR5IEFDSy4NCg0KLUVrcg0KDQoNCg0KKEJ1dCBhZ2FpbiwgSSdtIG5vdCBoaW0g YW5kIHRoYXQncyB3aHkgSSBzdWdnZXN0ZWQgY29sbGVjdGluZyBhbGwgdGhlDQpwaWVjZXMgb2Yg dGhpcyBkaXNjdXNzaW9uIHRvZ2V0aGVyIGluIG9uZSBQUi4pDQoNCklNUE9SVEFOVCBOT1RJQ0U6 IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp ZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBp dCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFu eSBtZWRpdW0uIFRoYW5rIHlvdS4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0 aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFs c28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2Ug dGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2Us IG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlv dS4NCg== --_000_AM0PR08MB37166F4946EE1A27499AD1E8FAC10AM0PR08MB3716eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgVGhvbWFzLCBIaSBFa3IsIDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JdCBzZWVtcyB3ZSBuZWVkIHRvIGZpeCBGaWd1cmUgMTEgb2YgU2VjdGlvbiA3LjEg b2YgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXRscy1kdGxzMTMtMzcuaHRtbCNzZWN0aW9uLTcu MSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi10bHMtZHRsczEzLTM3Lmh0bWw8 L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oQUNLWzFdIHNob3VsZCBh Y3R1YWxseSBiZSBBQ0tbXSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUQxQzFEO2JhY2tncm91bmQ6d2hpdGUiPkl0IHNob3VsZCBmb2xsb3cgdGhlIOKAnGVt cHR5IEFDS+KAnSBkZXNjcmlwdGlvbiBvZiB0aGUgbGFzdCBwYXJhZ3JhcGggb2YgdGhlIHNhbWUg c2VjdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R29vZCBjYXRjaCEgPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNpYW88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhhbm5lczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gVExTICZs dDt0bHMtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkVyaWMgUmVz Y29ybGE8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEFwcmlsIDksIDIwMjAgNDozMyBQTTxi cj4NCjxiPlRvOjwvYj4gVGhvbWFzIEZvc3NhdGkgJmx0O1Rob21hcy5Gb3NzYXRpQGFybS5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiB0bHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtUTFNdIEVmZmljaWVuY3kgb2YgQUNLaW5nIHNjaGVtZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gVGh1LCBBcHIgOSwgMjAyMCBhdCA3OjI4IEFNIFRob21hcyBGb3NzYXRp ICZsdDs8YSBocmVmPSJtYWlsdG86VGhvbWFzLkZvc3NhdGlAYXJtLmNvbSI+VGhvbWFzLkZvc3Nh dGlAYXJtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIDA5LzA0LzIwMjAsIDE1OjE4LCAmcXVvdDtFcmljIFJlc2NvcmxhJnF1b3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0u Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IE9uIFRodSwgQXByIDksIDIwMjAgYXQg Njo1OSBBTSBUaG9tYXMgRm9zc2F0aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRob21hcy5Gb3NzYXRp QGFybS5jb20iIHRhcmdldD0iX2JsYW5rIj5UaG9tYXMuRm9zc2F0aUBhcm0uY29tPC9hPiZndDsg d3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IE9uIDA5LzA0LzIwMjAsIDE0OjIwLCAmcXVvdDtFcmljIFJl c2NvcmxhJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9i bGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgQXNz dW1pbmcgSSB1bmRlcnN0YW5kIEhhbm5vJ3MgcHJvcG9zYWwsIEkgZG8gbm90IGJlbGlldmUgdGhh dCB0aGlzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaXMgaW4gZmFjdCBhbiBpbXByb3ZlbWVudCwgYXMg aXQgZG9lcyBub3QgY292ZXIgdGhlIGltcG9ydGFudCBjYXNlPGJyPg0KJmd0OyAmZ3Q7ICZndDsg d2hlcmUgdGhlIHJlY29yZCBjb250YWluaW5nIHRoZSBTSCBpcyBsb3N0IGFuZCB0aGVuIHRoZSBy ZXN0IG9mPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlIG1lc3NhZ2VzIGZyb20gdGhlIHNlcnZlciBh cmUgdW5pbnRlcnByZXRhYmxlLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJIGRvbid0 IHdhbnQgdG8gc3BlYWsgZm9yIEhhbm5vIGhlcmUgYnV0IHRoZSByZWZpbmVtZW50IHByb3Bvc2Vk IGluPGJyPg0KJmd0OyAmZ3Q7IFsxXSwgc3BlY2lmaWNhbGx5IHRoZSBiaXQgdGhhdCBzYXlzOjxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDtbLi4uXSBUaGV5IG1heSBh bHNvIHByb2FjdGl2ZWx5IHJldHJhbnNtaXQgcGFydHMgb2YgYSBmbGlnaHQgZWFybHk8YnI+DQom Z3Q7ICZndDsmbmJzcDsgJm5ic3A7aWYgYW4gQUNLIG1lc3NhZ2UgaW5kaWNhdGVzIGEgZ2FwLjxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBzaG91bGQgY292ZXIgdGhlIGNhc2UgeW91IG1l bnRpb24gSSB0aGluay48YnI+DQomZ3Q7PGJyPg0KJmd0OyBCdXQgdGhpcyByZXF1aXJlcyBiZWlu ZyBhYmxlIHRvIHNlbmQgYW4gZW1wdHkgQUNLIHRoYXQgbWVhbnMgJnF1b3Q7SSBnb3Q8YnI+DQom Z3Q7IG5vdGhpbmcmcXVvdDsuIEluIHdoaWNoIGNhc2UsIEkgZG9uJ3Qgc2VlIGhvdyBpdCdzIHJl YWxseSBkaWZmZXJlbnQgZnJvbTxicj4NCiZndDsgdGhlIGN1cnJlbnQgdGV4dCBleGNlcHQgdGhh dCBpdCBnaXZlcyB0aGUgc2VuZGVyIGxlc3MgZ3VpZGFuY2UuPGJyPg0KPGJyPg0KTm90IHN1cmUg dGhlcmUncyBhbiAmcXVvdDtlbXB0eSBBQ0smcXVvdDsgaW4gSGFubm8ncyBwcm9wb3NhbC4mbmJz cDsgVGhpcyBpcyBob3cgSTxicj4NCmludGVycHJldCBpdCBpbiB0aGUgY29udGV4dCBvZiB5b3Vy IGV4YW1wbGU6IGluIHRoZSBzZWNvbmQgZmxpZ2h0LCBpZjxicj4NCnJlYyMwIChjb250YWluaW5n IFNIKSBpcyBsb3N0IGFuZCByZWMjMSBnZXRzIHRocm91Z2gsIHRoZSByZWNlaXZlciBzZW5kczxi cj4NCkFDSyB7MX0uJm5ic3A7IEZyb20gdGhhdCB0aGUgc2VuZGVyIGNhbiBpbmZlciB0aGUgZ2Fw IGFuZCByZXRyYW5zbWl0IHJlYyMwLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IGNhbid0IHNlbmQgQUNLezF9IGJlY2F1c2Ug eW91IGNhbid0Jm5ic3A7IGRlY3J5cHQgaXQgYmVjYXVzZSBpdCBpcyBvdXQgb2Ygb3JkZXIgd2l0 aCByZXNwZWN0IHRvIHRoZSBESCBrZXkuIFRoaXMgaXMgdGhlIHBvaW50IG9mIHRoZSBlbXB0eSBB Q0suPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KKEJ1 dCBhZ2FpbiwgSSdtIG5vdCBoaW0gYW5kIHRoYXQncyB3aHkgSSBzdWdnZXN0ZWQgY29sbGVjdGlu ZyBhbGwgdGhlPGJyPg0KcGllY2VzIG9mIHRoaXMgZGlzY3Vzc2lvbiB0b2dldGhlciBpbiBvbmUg UFIuKTxicj4NCjxicj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVt YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUg cHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNv bnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsDQogb3Ig c3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Ljxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KSU1Q T1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVy IHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRoZSBp bmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM0PR08MB37166F4946EE1A27499AD1E8FAC10AM0PR08MB3716eurp_-- From nobody Thu Apr 9 08:12:32 2020 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 1D74E3A0963 for ; Thu, 9 Apr 2020 08:12:31 -0700 (PDT) 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, 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=LSsrcida; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=LSsrcida 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 bsJyQUc_fJHB for ; Thu, 9 Apr 2020 08:12:25 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80042.outbound.protection.outlook.com [40.107.8.42]) (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 2ADFE3A0964 for ; Thu, 9 Apr 2020 08:12:24 -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=4VpIUPqLNBfoUbqamEbfIAL+Vf1rFBaGIrNvsmSyK2I=; b=LSsrcidabraFNJTN/Lcui0I4uLhXwQICNJrWF4/1etRbljw3+ABEvhxQpCjp8cdJjBqyPQxO/nkZKC+9Ow6ixnruNAaLwolbnVKzIa6p7WgBavMlj+n63y5NhrhHfhlOp1ftop1He4EDhkFjsswHpsonFHEY2OZFztI7HPIVZ3s= Received: from VI1PR07CA0197.eurprd07.prod.outlook.com (2603:10a6:802:3f::21) by DBBPR08MB4854.eurprd08.prod.outlook.com (2603:10a6:10:d9::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Thu, 9 Apr 2020 15:12:21 +0000 Received: from VE1EUR03FT012.eop-EUR03.prod.protection.outlook.com (2603:10a6:802:3f:cafe::4a) by VI1PR07CA0197.outlook.office365.com (2603:10a6:802:3f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.12 via Frontend Transport; Thu, 9 Apr 2020 15:12:21 +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 VE1EUR03FT012.mail.protection.outlook.com (10.152.18.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Thu, 9 Apr 2020 15:12:21 +0000 Received: ("Tessian outbound af37c2b81632:v50"); Thu, 09 Apr 2020 15:12:21 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 153b11e7334c7d38 X-CR-MTA-TID: 64aa7808 Received: from 7ec40d0b9e84.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F0513C3B-E623-4BBB-9927-49E5B2DE4287.1; Thu, 09 Apr 2020 15:12:15 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 7ec40d0b9e84.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 09 Apr 2020 15:12:15 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aYzKS9Y8PhNsUbLOoE54DUAEFxUNdVnRLHgyiOlcvwr3W+yAvOGRiWhoVHxWc50iJRdZJ45urS0+GUV66GXgBM35xwFDuB7S4z6Kw9c6U9Ce2ZHB+GxBSMV4vAesyaX+IjDg8ErwS4cX51VZScfGzIbEdaiybjIs+9kRsawGq0HwqCZ/jV8DM19BHzXy5LLGhVNgrmXIeiKRjgE4W4n29vyf+HoS2JXb1Ajl7uGcDWg7MFNFw29s/VIBEmm6r04PT3kv1EIcHYdc0nLG25cjGjg+B7mFC+2DeMdWXFE5YNYj9xvf4U39v/REfKjnV8qSKyoMTSgDsAMpd5s4Qo907A== 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=4VpIUPqLNBfoUbqamEbfIAL+Vf1rFBaGIrNvsmSyK2I=; b=aqktnE9QF+DYKbxmzaz9WY1k+SfVOMn2bV1/WbgbVX8nvxbFfKmKbl/sVirtyZS2BvZfgfCexOVIvG1khphdBVrIHGB6WZnXn0UaVf+t+/OjMfEI/FngUagsONnkAYbcF4+uBD0wRVD0s2arSYZIsOSLbWcn42/PUYJINppRuXjg43LxCbFuWwLbJZVsOI/cuT7NS9kn4MpRaSOje/coaiTaXTz5c2/4yISbXUV8kD+CuOWm2OkjyLKrpmpzo1pVrOxBFgzn7Tny76LEcKYgXuYgW73dwN+sLi4RxtXobK7kQwz5eExtiGUzfOs6d6aTH6MD8zf5/wZZSfJtWVpt6A== 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=4VpIUPqLNBfoUbqamEbfIAL+Vf1rFBaGIrNvsmSyK2I=; b=LSsrcidabraFNJTN/Lcui0I4uLhXwQICNJrWF4/1etRbljw3+ABEvhxQpCjp8cdJjBqyPQxO/nkZKC+9Ow6ixnruNAaLwolbnVKzIa6p7WgBavMlj+n63y5NhrhHfhlOp1ftop1He4EDhkFjsswHpsonFHEY2OZFztI7HPIVZ3s= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB3751.eurprd08.prod.outlook.com (2603:10a6:20b:84::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.19; Thu, 9 Apr 2020 15:12:13 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::b08c:a849:e63d:6150]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::b08c:a849:e63d:6150%7]) with mapi id 15.20.2900.015; Thu, 9 Apr 2020 15:12:13 +0000 From: Thomas Fossati To: Eric Rescorla CC: Hanno Becker , Rob Sayre , "tls@ietf.org" , Thomas Fossati Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQgAO7OoCAAKsoAP//86kAgAAdq4D///6F3YAAREwAgAD0k7KAA3V2gIAADseAgAAbtwD///RFgAACd9OA///wuACAABuZAA== Date: Thu, 9 Apr 2020 15:12:13 +0000 Message-ID: References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> <03849701-1A14-4E1A-8298-D483E74E380C@arm.com> <337B9506-31F3-463C-B447-FEFBEFEC32A7@arm.com> <5744AFC1-D9B5-421E-893B-949ACA76C51D@arm.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 8360ac1c-984d-4adc-9683-08d7dc9866eb x-ms-traffictypediagnostic: AM6PR08MB3751:|AM6PR08MB3751:|DBBPR08MB4854: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:6430;OLM:10000; x-forefront-prvs: 0368E78B5B X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(136003)(346002)(376002)(39860400002)(396003)(366004)(6512007)(86362001)(76116006)(36756003)(33656002)(53546011)(6916009)(2906002)(66556008)(81166007)(316002)(4326008)(54906003)(71200400001)(6506007)(2616005)(64756008)(5660300002)(26005)(66946007)(186003)(81156014)(91956017)(66446008)(478600001)(8936002)(66476007)(8676002)(6486002); 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: 0qNm8fJRNSqPLk897oQlS64xmgKjjs6qBNDRR2pkObAHIQa+TLRslnmjZx7N59PZWMc+6qSIOP4qYVuRrFCGvQv5rPkoPRQmKVrqgdcrasNRUv6Y3KU5TXAjAfCr7N7UPrzXmm4Rp0oHPuIl3wqnDWuC7uoZKPOF5K9zMDfGabpNOPLL+0nn57qCpYfFJNiFC8+qvaSEXx5P53oJnAvNvAf6c1gNO2YZBrQAZb9nCfG8M+HMu3CaTVNL3QzRZUioPAgmamc5N68xLo3cbK9Mib4dIk4VsE2agXgulk+g/gHgMrRwoGpq3A9rvjo6dX2/VI5Djlvr/CMH37VfLulmxXMq8Ez6YDOltjzQWOh8zpg/qLOYGR/K4Q2aA3KdQJeJl+PLZhGOajR7EVVcQOlhNrOowf7aWWThcumcHcO3z7sgSxTsy+c1iXGy6EWmnscl x-ms-exchange-antispam-messagedata: CQLa12AztCpegD1AB4LXaX3EVzF8ZKfW2vJo86sPlamUCKjZh8rQv/XKntPqgaVRe8YPZ5jkl6v2eyhFQj+exHSXklElLIe6TIxqP1quw0B0ALmp844TVF/R597Iey7uuOvEqXUYZ8qgYkIjxn9J+w== Content-Type: text/plain; charset="utf-8" Content-ID: <988347B421410349B44DCCA417D93715@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3751 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT012.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)(39860400002)(396003)(136003)(376002)(346002)(46966005)(26826003)(82740400003)(54906003)(316002)(47076004)(8936002)(53546011)(70586007)(70206006)(81156014)(356004)(5660300002)(36756003)(36906005)(81166007)(6506007)(186003)(6512007)(6862004)(4326008)(336012)(2906002)(478600001)(2616005)(6486002)(8676002)(26005)(33656002)(86362001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: a6a4e716-fda9-405f-86cd-08d7dc9861ed X-Forefront-PRVS: 0368E78B5B X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: qjwW92jOVFNdsaGngA2FXYqSTgRS1oGpC1YkgsbelgCDFQqrwm3VQ1c9XXzPHr2Q6lgPLsn/K1QJdNfTXENavx+HIO6U8VB86JqLjIGMBNiG7qLD8f9zPr3pmzUBPjUR2XabrQ8pyI/RO9uYlILkgJtjCp8S27stuk1OhMgSiflbkZf0EQTSy4vnjUG3ElLRi87q7k4pojF8tkZnc7dQWdxPrRu1ar1SDS9mGiZijEEAduwSBN6UwkqFputd2RJXYLEm+zp1DgJeYN8dA2Zzfxf/oEwMbg6WINDH3UpRxTV7/uC+iDmERpNNM1XYWbLVqNVyLBI2cZJXgDLAHNWA+JLDtqMr8c1fQJ4LH3Emi+ga1KenaPtvWVB7KELdcH+NBtmGlTYFLNO7zOLcPTltUbh4PijFddDXDg3832SRC9QiCvHVlbI5c4xpfiBWdiPr2JRnqdDWBIyjv2NL4odsLXmQwZOc0eh9YcEqVUmCexeYHk88M0o2/yodBtem9AfBx+pd+QIs5WJ1pK0cuiK2QA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Apr 2020 15:12:21.5058 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8360ac1c-984d-4adc-9683-08d7dc9866eb 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: DBBPR08MB4854 Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Thu, 09 Apr 2020 15:12:31 -0000 T24gMDkvMDQvMjAyMCwgMTU6MzQsICJFcmljIFJlc2NvcmxhIiA8ZWtyQHJ0Zm0uY29tPiB3cm90 ZToNCj4gPiA+IEJ1dCB0aGlzIHJlcXVpcmVzIGJlaW5nIGFibGUgdG8gc2VuZCBhbiBlbXB0eSBB Q0sgdGhhdCBtZWFucyAiSQ0KPiA+ID4gZ290IG5vdGhpbmciLiBJbiB3aGljaCBjYXNlLCBJIGRv bid0IHNlZSBob3cgaXQncyByZWFsbHkgZGlmZmVyZW50DQo+ID4gPiBmcm9tIHRoZSBjdXJyZW50 IHRleHQgZXhjZXB0IHRoYXQgaXQgZ2l2ZXMgdGhlIHNlbmRlciBsZXNzDQo+ID4gPiBndWlkYW5j ZS4NCj4gPg0KPiA+IE5vdCBzdXJlIHRoZXJlJ3MgYW4gImVtcHR5IEFDSyIgaW4gSGFubm8ncyBw cm9wb3NhbC4gIFRoaXMgaXMgaG93IEkNCj4gPiBpbnRlcnByZXQgaXQgaW4gdGhlIGNvbnRleHQg b2YgeW91ciBleGFtcGxlOiBpbiB0aGUgc2Vjb25kIGZsaWdodCwNCj4gPiBpZiByZWMjMCAoY29u dGFpbmluZyBTSCkgaXMgbG9zdCBhbmQgcmVjIzEgZ2V0cyB0aHJvdWdoLCB0aGUNCj4gPiByZWNl aXZlciBzZW5kcyBBQ0sgezF9LiAgRnJvbSB0aGF0IHRoZSBzZW5kZXIgY2FuIGluZmVyIHRoZSBn YXAgYW5kDQo+ID4gcmV0cmFuc21pdCByZWMjMC4NCj4gPg0KPiA+IFlvdSBjYW4ndCBzZW5kIEFD S3sxfSBiZWNhdXNlIHlvdSBjYW4ndCAgZGVjcnlwdCBpdCBiZWNhdXNlIGl0IGlzDQo+ID4gb3V0 IG9mIG9yZGVyIHdpdGggcmVzcGVjdCB0byB0aGUgREgga2V5LiBUaGlzIGlzIHRoZSBwb2ludCBv ZiB0aGUNCj4gPiBlbXB0eSBBQ0suDQoNClRydWUsIHNvIHlvdSBzZW5kIEFDS3t9IChhcyBwZXIg bGFzdCBwYXJhIG9mIFNlY3Rpb24gNy4xKSBhbmQgc2ltaWxhcmx5DQp0aGUgcmVjZWl2ZXIgY2Fu IGRlZHVjZSBhIGdhcCAtLSBpbmRlZWQgYSB2ZXJ5IHByZWNpc2Ugb25lIC0tIGFuZA0KcmUtc2Vu ZCByZWNvcmQgY29udGFpbmluZyB0aGUgU0guDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250 ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBh bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3Qg ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55 IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0u IFRoYW5rIHlvdS4NCg== From nobody Fri Apr 10 19:44:48 2020 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 837673A15C7 for ; Fri, 10 Apr 2020 19:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com 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 hKcKodCZktsu for ; Fri, 10 Apr 2020 19:44:35 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD81D3A15C8 for ; Fri, 10 Apr 2020 19:44:34 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id 71so2924739qtc.12 for ; Fri, 10 Apr 2020 19:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GJWGbp0otXIfHlI1xJHBvRScCCPwzVH3w9mxxUC5DZU=; b=GVG6Io0P6J3OtE4q83OCLQJ/5QrsZYJbk8QKTdEhJk3ox64p4LDVvdZt1cCdIelRd4 NLmcYXdONyRxAeI/sToBtvu1XKOrcqfkff4EX7ioc3IbSdfR+wfsV7s9/tp+5o3F0ihb FfyMQC98i8XfGUqJ/mSh0aHPPULdVSHFoAowA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GJWGbp0otXIfHlI1xJHBvRScCCPwzVH3w9mxxUC5DZU=; b=SyeBdj2atCvzH2l2raoZaUWWZUaVthMr7BIBWIMuyv/SlaDylWfHV6HTIgKS65tnhr zwG9/9iDIhopAdrOcyUTW8NE/kFTUYaxEWCQTUj4Rg9AtgbLb0y9j5fBc+DsLtq1FCf1 kij4XVLuyfgAN63gSA2eDPByOUSH7Fa9aKEChzwH2EX+YG++A1ko/t2c/mAxp42BdubT yRD8QfbCxCVQyK0ndCNoMMoPOk1dkOLZo+t/+bYHRTPmxn2QYxn3mPKWAKzqfAoc5XNx Lqku00EamzLDXdJrzqoKR37PcoDGixg/yhh/3ffmB1+ziSva6RbXwqbxzZwGBqdwZdrQ SVsg== X-Gm-Message-State: AGi0PubfyghaPbSwkM8B9FtYoaoAFC/+OYk7xxB/xmcen439RGD5jjXf bBDNFDqU3m7M3kDaaOj5QYPL+g== X-Google-Smtp-Source: APiQypLqU8T3HENhkRF7RKb07J9prushXriA++8mHRoUuwuoGiajwgMHSUCDrJoFWlnAPVuCC7IzTg== X-Received: by 2002:ac8:31ac:: with SMTP id h41mr2004589qte.139.1586573073638; Fri, 10 Apr 2020 19:44:33 -0700 (PDT) Received: from sn3rd.lan ([75.102.131.34]) by smtp.gmail.com with ESMTPSA id c207sm3056015qkb.7.2020.04.10.19.44.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Apr 2020 19:44:32 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Sean Turner In-Reply-To: Date: Fri, 10 Apr 2020 22:44:30 -0400 Cc: TLS List , "uta@ietf.org" , Hannes Tschofenig Content-Transfer-Encoding: quoted-printable Message-Id: <641927D7-CC49-4417-874E-12D44F6D6023@sn3rd.com> References: To: John Mattsson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [TLS] [Uta] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS 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: Sat, 11 Apr 2020 02:44:40 -0000 -hat John, There is already a certificate compression mechanism defined in = draft-ietf-tls-certificate-compression, which is currently in the RFC = editor=E2=80=99s queue. How do these documents relate to that one? spt > On Apr 8, 2020, at 09:29, Hannes Tschofenig = wrote: >=20 > Thanks for the info, John. I will have a look at this publication. >=20 > -----Original Message----- > From: John Mattsson > Sent: Wednesday, April 8, 2020 3:14 PM > To: Hannes Tschofenig ; tls@ietf.org; = uta@ietf.org > Subject: Re: [TLS] CBOR Certificate Compression of RFC 7925 = certificates suitable for cTLS >=20 > Hi Hannes, >=20 > I have requested and been assigned time for = draft-mattsson-tls-cbor-cert-compress-00 and = draft-raza-ace-cbor-certificates-04 at the UTA virtual interim on March = 23. >=20 > We have an implementation of = https://link.springer.com/chapter/10.1007%2F978-3-319-93797-7_14 / = draft-raza-ace-cbor-certificates-03, but the code is not written in a = way so that the compression mechanism DER-> CBOR can be extracted. The = example in draft-raza-ace-cbor-certificates-04 was created by hand with = cbor.me. We are planning to implement a updated standalone version of = the DER->CBOR compression and hopefully have interop testing in the COSE = WG. >=20 > Cheers, > John >=20 > =EF=BB=BF-----Original Message----- > From: TLS on behalf of Hannes Tschofenig = > Date: Friday, 3 April 2020 at 14:20 > To: John Mattsson , = "TLS@ietf.org" , "uta@ietf.org" > Subject: Re: [TLS] CBOR Certificate Compression of RFC 7925 = certificates suitable for cTLS >=20 > Hi John, >=20 > Thanks for the heads-up. >=20 > Discussing this aspect in draft-tschofenig-uta-tls13-profile-01 = makes sense. >=20 > I was wondering whether you have been working on an implementation = of draft-mattsson-cose-cbor-cert-compress-00 / = draft-raza-ace-cbor-certificates-04. >=20 > Ciao > Hannes >=20 > -----Original Message----- > From: TLS On Behalf Of John Mattsson > Sent: Friday, April 3, 2020 9:03 AM > To: TLS@ietf.org; uta@ietf.org > Subject: [TLS] CBOR Certificate Compression of RFC 7925 = certificates suitable for cTLS >=20 > Hi, >=20 > During the COSE virtual interim meeting yesterday, there was = agreement that the COSE working group should work on CBOR compression of = RFC 7925 profiled X.509 certificates. The work will be based on = draft-raza-ace-cbor-certificates and = draft-mattsson-cose-cbor-cert-compress and the two drafts will be = merged. Doing this work in a security group focused on CBOR makes a lot = of sense. >=20 > = https://tools.ietf.org/html/draft-mattsson-cose-cbor-cert-compress-00 > https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-04 >=20 > The COSE draft charter has already been updated to reflect this. >=20 > https://github.com/cose-wg/Charter/blob/master/Charter.md >=20 > As the algorithm is focused on compressing RFC 7925 profiled = certificates, It seems like a very good match for cTLS. To keep the = number of internet-drafts down, I plan to also include the TLS IANA = registrations in the merged draft submitted to the COSE WG and let = draft-mattsson-tls-cbor-cert-compress-00 expire. >=20 > Any comments from the TLS WG are very welcome, but otherwise these = is not so much to discuss, this is just another certificate compression = algorithm. Any TLS related discussions would likely be regarding the = certificate profile in RFC 7925 and if any clarifications or updates are = needed. This is likely best discussed in UTA which may take up work on a = TLS/DTLS 1.3 update of RFC 7925. >=20 > https://tools.ietf.org/html/draft-tschofenig-uta-tls13-profile-01 >=20 > Cheers, > John >=20 > -----Original Message----- > From: John Mattsson > Date: Thursday, 12 March 2020 at 08:58 > To: "TLS@ietf.org" > Cc: "uta@ietf.org" > Subject: FW: New Version Notification for = draft-mattsson-tls-cbor-cert-compress-00.txt >=20 > Hi, >=20 > We have submitted a new draft to TLS = https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00 The = draft register a new compression algorithms for use with TLS Certificate = Compression in TLS 1.3 and DTLS 1.3 = (draft-ietf-tls-certificate-compression). >=20 > The draft uses = https://tools.ietf.org/html/draft-raza-ace-cbor-certificates-04 to = compress RFC 7925 profiles certificates by encoding them from DER to = CBOR. The aim is to be compatible with all RFC 7925 profiled = certificates. With the included example DER encoded RFC 7925 certificate = to certificate is compressed from 314 to 136 bytes, a compression rate = of 57%. >=20 > The general purpose compression algorithms defined in = draft-ietf-tls-certificate-compression do not seem able to compress = profiled RFC 7925 X.509 certificates much at all. zlib compressed the = example cert 9%, but for other certificates we tested, zlib did in many = cases not provide any compression at all. >=20 > We have submitted a similar draft to the COSE WG registering a = new algorithms for the TLS 1.3 certificate compression extension. >=20 > = https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00 >=20 > Cheers, > John >=20 > -----Original Message----- > From: "internet-drafts@ietf.org" > Date: Monday, 9 March 2020 at 21:19 > To: John Mattsson , John Mattsson = , Joel H=C3=B6glund , = Joel Hoglund , G=C3=B6ran Selander = , Martin Furuhed = , G=C3=B6ran Selander = , Shahid Raza > Subject: New Version Notification for = draft-mattsson-tls-cbor-cert-compress-00.txt >=20 >=20 > A new version of I-D, = draft-mattsson-tls-cbor-cert-compress-00.txt > has been successfully submitted by John Preuss Mattsson and = posted to the > IETF repository. >=20 > Name:draft-mattsson-tls-cbor-cert-compress > Revision:00 > Title:CBOR Certificate Algorithm for TLS Certificate = Compression > Document date:2020-03-09 > Group:Individual Submission > Pages:6 > URL: = https://www.ietf.org/internet-drafts/draft-mattsson-tls-cbor-cert-compress= -00.txt > Status: = https://datatracker.ietf.org/doc/draft-mattsson-tls-cbor-cert-compress/ > Htmlized: = https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-mattsson-tls-cbor-cert-compres= s >=20 >=20 > Abstract: > Certificate chains often take up the majority of the = bytes > transmitted in TLS handshakes. Large handshakes can = cause problems, > particularly in constrained IoT environments. RFC 7925 = defines a TLS > certificate profile for constrained IoT. General = purpose compression > algorithms can in many cases not compress RFC 7925 = profiled > certificates at all. By using the fact that the = certificates are > profiled, the CBOR certificate compression algorithms = can in many > cases compress RFC 7925 profiled certificates with over = 50%. This > document specifies the CBOR certificate compression = algorithm for use > with TLS Certificate Compression in TLS 1.3 and DTLS = 1.3. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the = time of submission > until the htmlized version and diff are available at = tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > 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 >=20 >=20 > 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. > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta From nobody Sun Apr 12 00:32:54 2020 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 BAD513A1E99 for ; Sun, 12 Apr 2020 00:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=t8YTbhur; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nipPQmRD 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 3WYNItb4fStg for ; Sun, 12 Apr 2020 00:32:45 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBE33A1791 for ; Sun, 12 Apr 2020 00:32:45 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 882605C00DE for ; Sun, 12 Apr 2020 03:32:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 12 Apr 2020 03:32:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=hSjgl46v7T0GUn4udLMEebMx2x7PFxtsrYLZIsJqKJk=; b=t8YTbhur rX3u5lmFTzGoAEeYRN3zK2hlIUtoCb1dZIuwiGkaVUoiwWFMeI/qqaf9ZZCvgcMe usGAR3YBJNN43CuRr5S2d2AWteOI88KMO4wSbI1nAAo47eyHiDd/oMjKeSlENo8W ckfKp8IRI9OqNGbbtkbx7/dX/A0gyYmsnU13qRgskKSXYaXkaHAKjD9+qNbB7lzw vVraBOP9aIlajgvAnTR/ct/8jYP5ZlDdpS5KMAlhmc6/yxoLD/6KQOpsvUfMws2q 9C7ucD1X+x2XdyA53claniKJHh+Z/Wy/1KpdjUTy3eLKK4bzaPV4OzKs3gRGrpZp jKwAV4HHxwbjxQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=hSjgl46v7T0GUn4udLMEebMx2x7PF xtsrYLZIsJqKJk=; b=nipPQmRDXD62kOTV6rhfEAP7Q9csDuue5qnpKQnC0Oarp 2xQDFqvE8jmTAvT41m4KovQHG1fVpZOMvYz7pdlz6y66xuD4OkPaTRDUZcOUgXqU Zcwwdl6IXaj7a0lBYRqTMAiGABbdaIs7YKigunJjSMGLZo9pDJCPea8ijQ61JX+A NDu1/hDxoThWtfLZ9Imu3QeijYmF49UnMCCOvyMFPHJ/V12Df6+eYdXtAhFyuxEa LoJLjsjX2/stwIK+6XcpH1RAu7feOZ59FUBEgZrXFqxpDT2dqzU5i5YKebD5yb5p OQyDaC5L7Y0PXHwlPrtT0bilUx/Q41Xpkj8HoUCrw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrvdeigddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecukfhppeehuddrudeguddrudejjedrhedvnecuvehluhhsthgv rhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplh ihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az115.internal.cloudapp.net (unknown [51.141.177.52]) by mail.messagingengine.com (Postfix) with ESMTPA id 2F50E3280068 for ; Sun, 12 Apr 2020 03:32:44 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============5837860028385887195==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: tls@ietf.org Message-Id: <20200412073244.2F50E3280068@mailuser.nyi.internal> Date: Sun, 12 Apr 2020 03:32:44 -0400 (EDT) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) 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: Sun, 12 Apr 2020 07:32:52 -0000 --===============5837860028385887195== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/draft-ietf-tls-esni (+2/-0/=F0=9F=92=AC1) 2 issues created: - Limit "Don't stick out" to explicit signals (by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/215=20 - Clarify whether ClientHelloInner can support TLS 1.2. (by chris-wood) https://github.com/tlswg/draft-ietf-tls-esni/issues/214=20 1 issues received 1 new comments: - #204 Anonymity sets (1 by ret394) https://github.com/tlswg/draft-ietf-tls-esni/issues/204=20 * tlswg/draft-ietf-tls-external-psk-importer (+0/-1/=F0=9F=92=AC1) 1 issues received 1 new comments: - #26 Clarify MUSTs (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/26= =20 1 issues closed: - Clarify MUSTs https://github.com/tlswg/draft-ietf-tls-external-psk-impo= rter/issues/26=20 * tlswg/tls-exported-authenticator (+1/-0/=F0=9F=92=AC1) 1 issues created: - Generalize authentication terminology (by chris-wood) https://github.com/tlswg/tls-exported-authenticator/issues/56=20 1 issues received 1 new comments: - #56 Generalize authentication terminology (1 by chris-wood) https://github.com/tlswg/tls-exported-authenticator/issues/56=20 Pull requests ------------- * tlswg/draft-ietf-tls-esni (+1/-0/=F0=9F=92=AC4) 1 pull requests submitted: - README: fix links to WG docs (by Lekensteyn) https://github.com/tlswg/draft-ietf-tls-esni/pull/213=20 1 pull requests received 4 new comments: - #209 padding scheme text (4 by chris-wood, sayrer, sftcd) https://github.com/tlswg/draft-ietf-tls-esni/pull/209=20 * tlswg/draft-ietf-tls-external-psk-importer (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Tighten up IANA considerations (by jsalowey) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/29=20 1 pull requests merged: - Editorial pass to simplify text and unify terminology. https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/28=20 * tlswg/draft-ietf-tls-ticketrequest (+1/-0/=F0=9F=92=AC4) 1 pull requests submitted: - Use two counters for fresh and resumed connections (by chris-wood) https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/19=20 1 pull requests received 4 new comments: - #19 Use two counters for fresh and resumed connections (4 by chris-wood= , martinthomson, tfpauly) https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/19=20 * tlswg/dtls13-spec (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #129 Removed term "deprotection" (1 by ekr) https://github.com/tlswg/dtls13-spec/pull/129=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============5837860028385887195== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday April 12, 2020

Issues

tlswg/draft-ietf-tls-esni (+2/-0/=F0=9F=92=AC1)

2 issues created:

1 issues received 1 new comments:

tlswg/draft-ietf-tls-external-psk-importer (+0/-1/=F0=9F=92=AC1)

1 issues received 1 new comments:

1 issues closed:

tlswg/tls-exported-authenticator (+1/-0/=F0=9F=92=AC1)

1 issues created:

1 issues received 1 new comments:

Pull requests

tlswg/draft-ietf-tls-esni (+1/-0/=F0=9F=92=AC4)

1 pull requests submitted:

1 pull requests received 4 new comments:

tlswg/draft-ietf-tls-external-psk-importer (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

tlswg/draft-ietf-tls-ticketrequest (+1/-0/=F0=9F=92=AC4)

1 pull requests submitted:

1 pull requests received 4 new comments:

tlswg/dtls13-spec (+0/-0/=F0=9F=92=AC1)

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============5837860028385887195==-- From nobody Sun Apr 12 14:24:25 2020 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 8BABA3A0926 for ; Sun, 12 Apr 2020 14:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 IN2N-LV0gNb9 for ; Sun, 12 Apr 2020 14:24:20 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014D13A0925 for ; Sun, 12 Apr 2020 14:24:19 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id n8so1965264otk.5 for ; Sun, 12 Apr 2020 14:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=McFCZNjVreEI4FRHF8pqyqn3EISmj9LjLYPqZot+kq0=; b=se/HcPzNMqJaPWxEMUesXfPxSlbK0/cl7t3vydYxTPFewZI6xdH4NcAOJpV7bznW40 E81N3FLy5M5FjKkuF5FS26rugLKtcL6QjY5slJPWMk7p1bHzO+iSad9t+1PVXsXXkMeA 1UzvPcvVEquP3Y4LyNPZvp2akvs/g3X1oR/zYAig7jxoAi0hn4zk7xdROqrkk09kUdF9 JJUHATTRgxJ6MZsDC92aRMhKJGjnOaCkaxaRcv9qe4J5Orj27rHcf6wEJv1F3zB6L8YV Xjwq15wOOc8opeIszNBq7WYqk61W00U1/ur0C2SjpaXqRLYx0AEmcGD6g1wzQ6IsAZzi kZEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=McFCZNjVreEI4FRHF8pqyqn3EISmj9LjLYPqZot+kq0=; b=LNRNqvspxDLF4xPvPXx9DUH20eZr71y8YjkS/lv86eulVPoki4K6fpSl4zy0WqHwnm r/WsRXoCQxhm9V2L0TOjfXyn++fFid6V/K8VXz65Etu7UhAp9Ui7cUdiT6W/joy2p/7e DHzJxES6JBGaHrD73zT7TqDnq+d/Qlcy2lQ7sJCgcr55nU5cgnWzV8GxZuODpbPHWijH XRfZ2Rk7xoRbSbcnVF3IL4k6zgowh2jmheuM1MKVMbvnXX29+FXIY2ZlRn1lRVb9WfKa oczgzivgZ1rYy3nQNX8mX6V//jTrRqsn2UXCxiH6OpQYeaDu5eKzloArmcHmq1Sn3azM UFqQ== X-Gm-Message-State: AGi0PuZvPTVMCUzHZqG5cfrgzyZIwtK8NKderhKmIlPjGn5RlhSU4bnM p9FZ5oQHOF08RJkuDSRqkofl+SXTwgXAVpKSkW3TwA== X-Google-Smtp-Source: APiQypIl9C2XI3th0lLdJlPykqROVSne8G8FbE2NaZ+usVSrD31PCezW9m1zwiy791vRMpwAvgcfB0kojPHOZpKPVgU= X-Received: by 2002:a9d:7f92:: with SMTP id t18mr10183014otp.55.1586726658847; Sun, 12 Apr 2020 14:24:18 -0700 (PDT) MIME-Version: 1.0 References: <20200412073244.2F50E3280068@mailuser.nyi.internal> In-Reply-To: <20200412073244.2F50E3280068@mailuser.nyi.internal> From: Darin Pettis Date: Sun, 12 Apr 2020 16:24:08 -0500 Message-ID: To: Repository Activity Summary Bot , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000db367405a31e964f" Archived-At: Subject: Re: [TLS] Weekly github digest (TLS Working Group Drafts) 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: Sun, 12 Apr 2020 21:24:25 -0000 --000000000000db367405a31e964f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi - trying to understand the intent of this: =E2=80=9CDon=E2=80=99t stick= out=E2=80=9D approach to eSNI, now being called ECHO apparently. About a year ago, the understanding was that eSNI would be identifiable and that enterprises wouldn=E2=80=99t need to use it internally and that it wou= ld only be used on the Internet. Is that not the case anymore? On Sun, Apr 12, 2020 at 2:33 AM Repository Activity Summary Bot < do_not_reply@mnot.net> wrote: > Sunday April 12, 2020 Issues tlswg/draft-ietf-tls-esni (+2/-0/=F0=9F=92= =AC1) > > 2 issues created: > > - #215 Limit "Don't stick out" to explicit signals > (by > chris-wood) > - #214 Clarify whether ClientHelloInner can support TLS 1.2. > (by > chris-wood) > > 1 issues received 1 new comments: > > - #204 Anonymity sets > (1 by > ret394) > > tlswg/draft-ietf-tls-external-psk-importer (+0/-1/=F0=9F=92=AC1) > > 1 issues received 1 new comments: > > - #26 Clarify MUSTs > > (1 by chris-wood) > > 1 issues closed: > > - #26 Clarify MUSTs > > > tlswg/tls-exported-authenticator (+1/-0/=F0=9F=92=AC1) > > 1 issues created: > > - #56 Generalize authentication terminology > (by > chris-wood) > > 1 issues received 1 new comments: > > - #56 Generalize authentication terminology > (1 by > chris-wood) > > Pull requests tlswg/draft-ietf-tls-esni (+1/-0/=F0=9F=92=AC4) > > 1 pull requests submitted: > > - #213 README: fix links to WG docs > (by > Lekensteyn) > > 1 pull requests received 4 new comments: > > - #209 padding scheme text > (4 by > chris-wood, sayrer, sftcd) > > tlswg/draft-ietf-tls-external-psk-importer (+1/-1/=F0=9F=92=AC0) > > 1 pull requests submitted: > > - #29 Tighten up IANA considerations > > (by jsalowey) > > 1 pull requests merged: > > - #28 Editorial pass to simplify text and unify terminology. > > > tlswg/draft-ietf-tls-ticketrequest (+1/-0/=F0=9F=92=AC4) > > 1 pull requests submitted: > > - #19 Use two counters for fresh and resumed connections > (by > chris-wood) > > 1 pull requests received 4 new comments: > > - #19 Use two counters for fresh and resumed connections > (4 by > chris-wood, martinthomson, tfpauly) > > tlswg/dtls13-spec (+0/-0/=F0=9F=92=AC1) > > 1 pull requests received 1 new comments: > > - #129 Removed term "deprotection" > (1 by ekr) > > Repositories tracked by this digest: > > - https://github.com/tlswg/draft-ietf-tls-semistatic-dh > - https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate > - https://github.com/tlswg/draft-ietf-tls-esni > - https://github.com/tlswg/certificate-compression > - https://github.com/tlswg/draft-ietf-tls-external-psk-importer > - https://github.com/tlswg/draft-ietf-tls-ticketrequest > - https://github.com/tlswg/tls-flags > - https://github.com/tlswg/dtls13-spec > - https://github.com/tlswg/dtls-conn-id > - https://github.com/tlswg/tls-subcerts > - https://github.com/tlswg/oldversions-deprecate > - https://github.com/tlswg/sniencryption > - https://github.com/tlswg/tls-exported-authenticator > - https://github.com/tlswg/draft-ietf-tls-grease > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000db367405a31e964f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi - trying to understand the intent of this: =C2=A0= =E2=80=9CDon=E2=80=99t stick out=E2=80=9D approach to eSNI, now being calle= d ECHO apparently. =C2=A0

About a year ago, the understanding was that eSNI would be identi= fiable and that enterprises wouldn=E2=80=99t need to use it internally and = that it would only be used on the Internet. =C2=A0=C2=A0

Is that not the case anymore?
On Sun, = Apr 12, 2020 at 2:33 AM Repository Activity Summary Bot <do_not_reply@mnot.net> wrote:

Sunday April 12, 2020

Issues

tlswg/draft-ietf-tls-esni (+2/-0/=F0=9F=92=AC1)

2 issues created:

1 issues received 1 new comments:

tlswg/draft-ietf-tls-external-psk-importer (+0/-1/=F0=9F=92=AC1)

1 issues received 1 new comments:

1 issues closed:

tlswg/tls-exported-authenticator (+1/-0/=F0=9F=92=AC1)

1 issues created:

1 issues received 1 new comments:

Pull requests

tlswg/draft-ietf-tls-esni (+1/-0/=F0=9F=92=AC4)

1 pull requests submitted:

1 pull requests received 4 new comments:

tlswg/draft-ietf-tls-external-psk-importer (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

tlswg/draft-ietf-tls-ticketrequest (+1/-0/=F0=9F=92=AC4)

1 pull requests submitted:

1 pull requests received 4 new comments:

tlswg/dtls13-spec (+0/-0/=F0=9F=92=AC1)

1 pull requests received 1 new comments:

Repositories tracked by this digest:

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000db367405a31e964f-- From nobody Mon Apr 13 11:06:59 2020 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 E84153A1A5A for ; Mon, 13 Apr 2020 11:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com 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 naVZE64uZret for ; Mon, 13 Apr 2020 11:06:50 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 BC7F83A1A59 for ; Mon, 13 Apr 2020 11:06:50 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 03DI083h028571; Mon, 13 Apr 2020 19:06:49 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=IgJ6Cl4x0lhXjo5f6tbpRBUyO0O3T8Jf+BCOio2WZCs=; b=aF+706j/yJHfye0E78jbFoq6TweTo9XAVGxr6eDvpM3Ad+JgK2MVNGTOBNHkw3htjxna 9O0sKzAbWzpy2yGFodq2QV+S/X6J/UIuXYZogOlqrlkGdxuPjIE6MCggqsJ8RunVscXf rf+BIcOU3WuLj+fKVgUXtGjWzYRvwvzQmrI+yqXBVI9+kb4cc2kepCO7YDswcFw9c7DZ YwQ+swh14P2Ta0DTdxGz3KY5NVhdITM8sGjkYNL4mezx1HTBMLdWwePHLTwdunNB8w6n MOZ0vrz28h0p3iQdpid0dr0kY9cBPd6Cns3KBFJhBE5wcvwZOL/dyukUDSjauTKPADIL Qg== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 30bpkk54h1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Apr 2020 19:06:49 +0100 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.27/8.16.0.27) with SMTP id 03DI2QFg029251; Mon, 13 Apr 2020 14:06:48 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.113]) by prod-mail-ppoint6.akamai.com with ESMTP id 30b97v8jw6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 13 Apr 2020 14:06:47 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.165.123) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 13 Apr 2020 13:06:46 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.006; Mon, 13 Apr 2020 13:06:46 -0500 From: "Salz, Rich" To: Darin Pettis , Repository Activity Summary Bot , "TLS@ietf.org" Thread-Topic: [TLS] Weekly github digest (TLS Working Group Drafts) Thread-Index: AQHWEJykyF5xilbJcEC/h6lTX3L1/6h2U/8AgAEYHwA= Date: Mon, 13 Apr 2020 18:06:45 +0000 Message-ID: <29F3CEEE-46B0-4805-904F-C5D5B62B4F81@akamai.com> References: <20200412073244.2F50E3280068@mailuser.nyi.internal> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20040502 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.114.9] Content-Type: multipart/alternative; boundary="_000_29F3CEEE46B04805904FC5D5B62B4F81akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-13_09:2020-04-13, 2020-04-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=710 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2002250000 definitions=main-2004130139 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-13_09:2020-04-13, 2020-04-13 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 priorityscore=1501 bulkscore=0 malwarescore=0 clxscore=1011 adultscore=0 suspectscore=0 lowpriorityscore=0 spamscore=0 mlxscore=0 mlxlogscore=704 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004130138 Archived-At: Subject: Re: [TLS] Weekly github digest (TLS Working Group Drafts) 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: Mon, 13 Apr 2020 18:06:55 -0000 --_000_29F3CEEE46B04805904FC5D5B62B4F81akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgQWJvdXQgYSB5ZWFyIGFnbywgdGhlIHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQgZVNOSSB3 b3VsZCBiZSBpZGVudGlmaWFibGUgYW5kIHRoYXQgZW50ZXJwcmlzZXMgd291bGRu4oCZdCBuZWVk IHRvIHVzZSBpdCBpbnRlcm5hbGx5IGFuZCB0aGF0IGl0IHdvdWxkIG9ubHkgYmUgdXNlZCBvbiB0 aGUgSW50ZXJuZXQuDQoNCkl0IHdhcyBhbHdheXMgbXkgdW5kZXJzdGFuZGluZyB0aGF0IHRoZSBp bmZvcm1hdGlvbiB3b3VsZCBiZSBoaWRkZW4sIGJ1dCB0aGF0IHlvdSBjb3VsZCBhbHdheXMgdGVs bCBpdCB3YXMgdGhlcmUuICBUaGF0IGlzIHN0aWxsIHRoZSBjYXNlLiBPbmx5IHVzZWQgb24gdGhl IEludGVybmV0PyAgRG8geW91IGhhdmUgYSBsaW5rIHRvIHRoYXQ/DQoNCkkgZXhwZWN0LCBmb3Ig ZXhhbXBsZSwgc29tZSBicm93c2VycyB3aWxsIGFsd2F5cyBzZW5kIGl0LCBldmVuIGlmIHBvaW50 aW5nIHRvIHRoZSBzYW1lIHNpdGUuDQoNCg== --_000_29F3CEEE46B04805904FC5D5B62B4F81akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <29976A085C6BFA4DBC9196CD627E3AAA@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTU1 MTUwODI5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjM4NjMwNjUyO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDozOTIyMzcxNDQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjE1NTQ4MTYwNTg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21z by1saXN0LWlkOjUwMDQzNzEyOTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTExODQ0NDg5Njt9 DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0KQGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6NzgxMjYyNTI4Ow0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotMTAzMjU1MjAzODt9DQpAbGlzdCBsMzpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDM6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2 ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6OTI1OTY1MzQ5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlk czotMTE5OTY5MDg1Njt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3Qt aWQ6MTI4NTk2MDQ2NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTM3MjczOTExNjt9DQpAbGlz dCBsNTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDU6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDU6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDU6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDU6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDU6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDU6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDU6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDYNCgl7bXNvLWxpc3QtaWQ6MTI5MjQ0MTExMzsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6LTc1OTY2Mjk3ODt9DQpAbGlzdCBsNjpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDY6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDY6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDY6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDY6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDY6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDY6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDY6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDcNCgl7bXNvLWxpc3QtaWQ6MTI5OTkxNzY3MzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTI5 NDg4MDUwNjt9DQpAbGlzdCBsNzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3 OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDc6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDc6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDc6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDgNCgl7bXNvLWxpc3QtaWQ6MTMw OTc0NzU3NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODkzMDA4MTcyO30NCkBsaXN0IGw4Omxl dmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDg6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpA bGlzdCBsODpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsODpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsODpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsODpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsODpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsODpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsODpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsOQ0KCXttc28tbGlzdC1pZDoxNDUzOTgyMDk5Ow0KCW1zby1saXN0LXRl bXBsYXRlLWlkczo3Njc2MDAzMzA7fQ0KQGxpc3QgbDk6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsOTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw5OmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw5OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoy LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGw5OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw5Omxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw5OmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGw5OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGw5OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMA0KCXtt c28tbGlzdC1pZDoxNzY1MDM0NDAyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTgxMjE1ODt9 DQpAbGlzdCBsMTA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTA6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsMTA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDEwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMDpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTA6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDExDQoJe21zby1saXN0LWlkOjE5 Mjg0NjM3MDk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02Mzc0ODA1MzY7fQ0KQGxpc3QgbDEx OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDExOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDExOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMTps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTE6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDExOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwxMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTE6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDExOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMg0KCXttc28tbGlzdC1pZDoxOTI4OTI2OTQzOw0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMDMxNzI1OTAg MTkwMTExMDI0NCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTI6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpOw0K CW1zby1hbnNpLWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KQGxpc3QgbDEyOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDEyOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTI6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTI6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEyOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx MjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwxMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTMNCgl7bXNvLWxpc3QtaWQ6MTk3NzM2ODc2MzsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4MDczMjE3Njt9DQpAbGlzdCBsMTM6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDox LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBs MTM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEzOmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMzpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMTM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDEzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMzpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDE0DQoJe21zby1saXN0LWlkOjE5Nzg2ODU2Njg7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi01NTE2NzUzMjY7fQ0KQGxpc3QgbDE0OmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDE0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNv LWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE0OmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxNDpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDE0OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxNDpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTQ6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDE0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdj4NCjx1bCBzdHlsZT0ibWFy Z2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxMiBsZXZlbDEgbGZvMTUiPkFib3V0IGEg eWVhciBhZ28sIHRoZSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IGVTTkkgd291bGQgYmUgaWRlbnRp ZmlhYmxlIGFuZCB0aGF0IGVudGVycHJpc2VzIHdvdWxkbuKAmXQgbmVlZCB0byB1c2UgaXQgaW50 ZXJuYWxseSBhbmQgdGhhdCBpdCB3b3VsZCBvbmx5IGJlIHVzZWQgb24gdGhlIEludGVybmV0LiAm bmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgd2FzIGFsd2F5cyBt eSB1bmRlcnN0YW5kaW5nIHRoYXQgdGhlIGluZm9ybWF0aW9uIHdvdWxkIGJlIGhpZGRlbiwgYnV0 IHRoYXQgeW91IGNvdWxkIGFsd2F5cyB0ZWxsIGl0IHdhcyB0aGVyZS4mbmJzcDsgVGhhdCBpcyBz dGlsbCB0aGUgY2FzZS4gT25seSB1c2VkIG9uIHRoZSBJbnRlcm5ldD8mbmJzcDsgRG8geW91IGhh dmUgYSBsaW5rIHRvIHRoYXQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZXhwZWN0LCBmb3Ig ZXhhbXBsZSwgc29tZSBicm93c2VycyB3aWxsIGFsd2F5cyBzZW5kIGl0LCBldmVuIGlmIHBvaW50 aW5nIHRvIHRoZSBzYW1lIHNpdGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_29F3CEEE46B04805904FC5D5B62B4F81akamaicom_-- From nobody Tue Apr 14 00:14:02 2020 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 A9D0D3A0E7A for ; Tue, 14 Apr 2020 00:14:01 -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=PXe1LLB4; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=PXe1LLB4 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 wwE4SGBelAq4 for ; Tue, 14 Apr 2020 00:13:58 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00050.outbound.protection.outlook.com [40.107.0.50]) (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 149173A0E79 for ; Tue, 14 Apr 2020 00:13:57 -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=WNbuEWu13kn7tkuQgP+nphKCtp6G3Y/VMY0/p+ICwVU=; b=PXe1LLB4Vup4yhP18LzjM8rnb/Wi1AjIVtWP6L3ksJTB8OnEfPPC9Em31rdpyyiSXRDtuBm7BVuiH62SCOtmQluBFOi/B788RWmGtZtwTxwlRTESOAH0sc0STjA1y+EnKTMil5/KxSfIyfWMuYKohW5rfB6bRereFVt2+SzSvPM= Received: from DB8PR06CA0049.eurprd06.prod.outlook.com (2603:10a6:10:120::23) by AM6PR08MB4472.eurprd08.prod.outlook.com (2603:10a6:20b:bf::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.24; Tue, 14 Apr 2020 07:13:54 +0000 Received: from DB5EUR03FT039.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:120:cafe::4) by DB8PR06CA0049.outlook.office365.com (2603:10a6:10:120::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.17 via Frontend Transport; Tue, 14 Apr 2020 07:13:54 +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 DB5EUR03FT039.mail.protection.outlook.com (10.152.21.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.18 via Frontend Transport; Tue, 14 Apr 2020 07:13:54 +0000 Received: ("Tessian outbound 5345ff401cf8:v50"); Tue, 14 Apr 2020 07:13:54 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: c268176ca60d871f X-CR-MTA-TID: 64aa7808 Received: from 36586897dd4d.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id FDD5E94E-3E97-4CEB-B1A0-367D99739CC4.1; Tue, 14 Apr 2020 07:13:48 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 36586897dd4d.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 14 Apr 2020 07:13:48 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HjzfnjLitfDZLOOcbyGsHkwOZun2LdYgJ1GpMh69ARIm9HXELWFQx/dgYXi7TlsQHNYRBN+weALNM3oyOVq+PfecZHlGSGEXYTOw/rMkeKYkWZfOTXOijjadJBvZg/J5m4jib8rUwzPj90Zx4nGpWigppTpNocxJLLrrERhEJlAg2fAbvCx92hKrHFjWvjJ84cfBes1e3el3g71bGQsZUbcZ7RAt3LGFfe0PTCAdc04rnfmw8EDsVce6FASX5NAHh6/kauFtHuCYCxcLZLmpRNPieGvo7wRuiGDUlnAr6VyoWVt8XEcqeTORcgyiOs1w3J+i0DZ3RyNEBAYsK0WbXQ== 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=WNbuEWu13kn7tkuQgP+nphKCtp6G3Y/VMY0/p+ICwVU=; b=b19uBALWFTJL7z+Z/EddinOFXzUi5jHW3QMblU/n5TCFCRe/f6KrtCauzp/SMZAU7Hzk2vIVlW2uRl+2r1pffiMJHIlOJskLNRPd/7UFUxxb99zVzq7Lg/CIYN5uMSpGXH2t8cv7O3K0uzlNXrKjwSNbZJel+mKv3EDT853Arx64u2mp9jyK568UAB8n7sffxNZ/pHWHD88Vf5GhMkxwl1TCS/WglZiJ8CFSUR5tmiGFtYfuOVK3GVoYm4hgxs5ojYa+1EBh44zGQ112G9TFCDDhEpCe96ZV9Q5XAbYlijb0/eYMIL6aHWdBws9B4U3NNFWN5aosQ+gauEoEJED1kg== 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=WNbuEWu13kn7tkuQgP+nphKCtp6G3Y/VMY0/p+ICwVU=; b=PXe1LLB4Vup4yhP18LzjM8rnb/Wi1AjIVtWP6L3ksJTB8OnEfPPC9Em31rdpyyiSXRDtuBm7BVuiH62SCOtmQluBFOi/B788RWmGtZtwTxwlRTESOAH0sc0STjA1y+EnKTMil5/KxSfIyfWMuYKohW5rfB6bRereFVt2+SzSvPM= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6PR08MB3958.eurprd08.prod.outlook.com (2603:10a6:20b:a6::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15; Tue, 14 Apr 2020 07:13:46 +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.2900.028; Tue, 14 Apr 2020 07:13:46 +0000 From: Hanno Becker To: Thomas Fossati , Eric Rescorla CC: Rob Sayre , "tls@ietf.org" Thread-Topic: [TLS] Efficiency of ACKing scheme Thread-Index: AQHWCdUmcw6BnTFxZ0GrZHianQcZlahnnDQQgAO7OoCAAKsoAP//86kAgAAdq4D///6F3YAAREwAgAD0k7KAA3V2gIAADseAgAAbtwD///RFgAACd9OA///wuACAABuZAIAHQ2AZ Date: Tue, 14 Apr 2020 07:13:46 +0000 Message-ID: References: <8fed27dc-f5eb-4104-8308-186c361781bc@www.fastmail.com> <6EC8987C-A1E0-454F-AF09-A43260EB2B56@arm.com> <03849701-1A14-4E1A-8298-D483E74E380C@arm.com> <337B9506-31F3-463C-B447-FEFBEFEC32A7@arm.com> <5744AFC1-D9B5-421E-893B-949ACA76C51D@arm.com> , In-Reply-To: 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.177.220.146] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 4920b0c4-d9ea-4f9d-a429-08d7e0436416 x-ms-traffictypediagnostic: AM6PR08MB3958:|AM6PR08MB3958:|AM6PR08MB4472: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0373D94D15 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)(39860400002)(376002)(346002)(366004)(396003)(136003)(66446008)(64756008)(66556008)(66476007)(53546011)(9686003)(81156014)(86362001)(8676002)(478600001)(8936002)(33656002)(55016002)(6506007)(7696005)(186003)(76116006)(66946007)(5660300002)(19627405001)(26005)(54906003)(316002)(71200400001)(2906002)(4326008)(110136005)(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: +N+euyCIGIqpYNztKbDwEYMf4G44UN6baUh4yHRWMiuNG9vHqO2I3jAPMrA9Y4A583FUUFQUFE1iBEHPh6IL+RYm46SknRvU82OVpMrvwP9/HKS60qs8ykKOSLJNjZ67NeT50BUfwcKmLA3Ep2tCOooy/qD4fhVRaUt7sHap2LM9GoKOgvvZFxPyfrl7iQuHUvHCtKpYJwrjPAhA50TyxaLpNYJt1BL0qDkIBbHuzKq+0cnlJ+5IUmqiaOf5rCOmSuWIoAmLFXjG8ZJMy+XXPaZBeFlR3jbz8map8rPeASb9OMmS1s31TLMUsVDIY2c+DqJraYkACOdX12KNaeN4GTl/Y28u0tFbk2oda+EXzL4c7YVqHn6dSD0dzNvy4nCkEpavtuHMbvKlMbj6bQakNKURBFhrUscgqZRdSFYHaeTWdoimi4KMuOj277kpN8Dr x-ms-exchange-antispam-messagedata: eQ2txjwj4iUzAGiT/TW6kM4JquNv+FJYnG9ob6aWbYDCiZM6Ji+JhGDJlaZa54ucA3rUY/NYM8LsD0EakaEg7rS3+N6i1Cg7BwMVjn8+damgJ+f7LB/zZz6kNIEAJ1xib0J/PyiKb2CRllj2573AcA== Content-Type: multipart/alternative; boundary="_000_AM6PR08MB331808EE59103725876EC1CC9BDA0AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3958 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT039.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)(376002)(39860400002)(136003)(46966005)(26826003)(47076004)(86362001)(9686003)(55016002)(186003)(70586007)(81166007)(70206006)(19627405001)(336012)(82740400003)(478600001)(356005)(8936002)(2906002)(110136005)(54906003)(52536014)(33656002)(6506007)(81156014)(5660300002)(4326008)(53546011)(26005)(316002)(8676002)(7696005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 1eaa4229-752e-436d-dd01-08d7e0435f6c X-Forefront-PRVS: 0373D94D15 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: elwm37Bqpe9BreU2DC+2QxHQ592XSPvjLcErZhrb9zVyinZjvvGaarFoysUwcr9I9C42dJ/1+TksxnZdtsC9OffSymr2NnZhvdBOGBKWZ5Xq/qvOjer/OAQf3BqMyHuguCLLhwKVcs3v0JNZg/CIMxGrInTCwPhZ+cr3WhYpDEhwe4nzBZDlETnJ/UJxqZH+nqfn3DKOubdXnnDJZryw4aPmpr5iY4ogakBQnyqb3i1I27abteDHJfAP8a/hQl+lvBmQcH5eV5Rc92EwnhNl4djzOuqAb1coIm5owjgG4qwc6F7BuLzplFcKdnHt45IlW/37qv56LiZiZ8Pc0av1T/3kMeJ7qoADHr15XiEQKff6EKmmDpbmWOVpv8y/2o6TQNFFzUbiBTi+mCTuq53jzG5L9i9kXrWq6kI5urtAHajm0wz32M88tJljyipA4UM2gKjTOKjqaLNAVjE1o3RZTDxiLVd1pxOU4hoY0RgsVDKOfgMgt0ECZF9SnuwpGe5NFqlN1zMpr9Uf7LCGzKxO1A== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2020 07:13:54.2690 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4920b0c4-d9ea-4f9d-a429-08d7e0436416 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: AM6PR08MB4472 Archived-At: Subject: Re: [TLS] Efficiency of ACKing scheme 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: Tue, 14 Apr 2020 07:14:02 -0000 --_000_AM6PR08MB331808EE59103725876EC1CC9BDA0AM6PR08MB3318eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Apologies for the late reply. First, let me say that foremost I wanted to highlight the potential efficiency problem with the current solution. The mentioned alternative isn't yet fully thought through, so it may well have drawbacks itself that render it no better than the current version. However, in any case I'd hope we can in the end find a solution which doesn't suffer from the current inefficiency, as this seems prohibitive for IoT deployments. Replying to Ekr's initial comment first: > ISTM that the easiest way to deal with this is to have the sender > treat the current ACK state as the union of the states it has received > and permit receivers to only ACK each packet once (while encouraging them > to fill the ACK packet). Then you would retransmit if your new ACK state > was partial rather than if the ACK was partial. I agree, something along those lines should work and I was attempting that with the proposed text, though spelling out the details doesn't seem entire= ly straightforward. For example, we don't want to retransmit immediately if we receive an ACK such that the new cumulative ACK state is partial, because otherwise we'd retransmit many times while building up the ACK state. The proposed text therefore recommends to retransmit after a sufficiently long period during which no further ACK is received. Receivers, in turn, may send ACKs one-by-one, though it is encouraged to fill them, as you said. So if I understand your comment above correctly, it appears to be in line with the intention of the proposed new text. Note that the proposal leaves it open whether receivers send ACKs recurringly, even if everything is transmitted perfectly, or only when they notice a disruption. The only recommendation I think the text should make is that once an implementation decides to start ACKing, it shouldn't leave a too large time-gap between two consecutive ACKs: This is for the recommended heuristic of "retransmission on ACK-less period" on the sender to work. Best, Hanno ________________________________ From: Thomas Fossati Sent: Thursday, April 9, 2020 4:12 PM To: Eric Rescorla Cc: Hanno Becker ; Rob Sayre ; tls@= ietf.org ; Thomas Fossati Subject: Re: [TLS] Efficiency of ACKing scheme On 09/04/2020, 15:34, "Eric Rescorla" wrote: > > > But this requires being able to send an empty ACK that means "I > > > got nothing". In which case, I don't see how it's really different > > > from the current text except that it gives the sender less > > > guidance. > > > > Not sure there's an "empty ACK" in Hanno's proposal. This is how I > > interpret it in the context of your example: in the second flight, > > if rec#0 (containing SH) is lost and rec#1 gets through, the > > receiver sends ACK {1}. From that the sender can infer the gap and > > retransmit rec#0. > > > > You can't send ACK{1} because you can't decrypt it because it is > > out of order with respect to the DH key. This is the point of the > > empty ACK. True, so you send ACK{} (as per last para of Section 7.1) and similarly the receiver can deduce a gap -- indeed a very precise one -- and re-send record containing the SH. 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_AM6PR08MB331808EE59103725876EC1CC9BDA0AM6PR08MB3318eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,

Apologies for the late reply.

First, let me say that foremost I wanted to highlight the potential
efficiency problem with the current solution. The mentioned alternativ= e
isn't yet fully thought through, so it may well have drawbacks itself<= br>
that render it no better than the current version. However, in any
case I'd hope we can in the end find a solution which doesn't suffer f= rom
the current inefficiency, as this seems prohibitive for IoT deployment= s.

Replying to Ekr's initial comment first:
> ISTM that the easiest way to deal with this is to have the sender=
> treat the current ACK state as the union of the states it has rec= eived
> and permit receivers to only ACK each packet once (while encourag= ing them
> to fill the ACK packet). Then you would retransmit if your new AC= K state
> was partial rather than if the ACK was partial.

I agree, something along those lines should work and I was attempting = that
with the proposed text, though spelling out the details doesn't seem e= ntirely
straightforward. For example, we don't want to retransmit immediately = if we
receive an ACK such that the new cumulative ACK state is partial, beca= use
otherwise we'd retransmit many times while building up the ACK state. = The
proposed text therefore recommends to retransmit after a sufficiently<= br>
long period during which no further ACK is received.

Receivers, in turn, may send ACKs one-by-one, though it is encouraged<= br>
to fill them, as you said.

So if I understand your comment above correctly, it appears
to be in line with the intention of the proposed new text.

Note that the proposal leaves it open whether receivers send
ACKs recurringly, even if everything is transmitted perfectly,
or only when they notice a disruption. The only recommendation
I think the text should make is that once an implementation decides
to start ACKing, it shouldn't leave a too large time-gap between
two consecutive ACKs: This is for the recommended heuristic of
"retransmission on ACK-less period" on the sender to work.

Best,
Hanno
From: Thomas Fossati <Th= omas.Fossati@arm.com>
Sent: Thursday, April 9, 2020 4:12 PM
To: Eric Rescorla <ekr@rtfm.com>
Cc: Hanno Becker <Hanno.Becker@arm.com>; Rob Sayre <sayrer@= gmail.com>; tls@ietf.org <tls@ietf.org>; Thomas Fossati <Thomas= .Fossati@arm.com>
Subject: Re: [TLS] Efficiency of ACKing scheme
 
On 09/04/2020, 15:34,= "Eric Rescorla" <ekr@rtfm.com> wrote:
> > > But this requires being able to send an empty ACK that means= "I
> > > got nothing". In which case, I don't see how it's reall= y different
> > > from the current text except that it gives the sender less > > > guidance.
> >
> > Not sure there's an "empty ACK" in Hanno's proposal.&nb= sp; This is how I
> > interpret it in the context of your example: in the second flight= ,
> > if rec#0 (containing SH) is lost and rec#1 gets through, the
> > receiver sends ACK {1}.  From that the sender can infer the = gap and
> > retransmit rec#0.
> >
> > You can't send ACK{1} because you can't  decrypt it because = it is
> > out of order with respect to the DH key. This is the point of the=
> > empty ACK.

True, so you send ACK{} (as per last para of Section 7.1) and similarly
the receiver can deduce a gap -- indeed a very precise one -- and
re-send record containing the SH.

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_AM6PR08MB331808EE59103725876EC1CC9BDA0AM6PR08MB3318eurp_-- From nobody Tue Apr 14 01:13:35 2020 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 472933A0408 for ; Tue, 14 Apr 2020 01:13:33 -0700 (PDT) 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=IsbIikfA; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=IsbIikfA 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 9k5a7HEmAlET for ; Tue, 14 Apr 2020 01:13:31 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60071.outbound.protection.outlook.com [40.107.6.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 280E13A0404 for ; Tue, 14 Apr 2020 01:13:30 -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=BofMFLTb2Z9xnoaUOem/+FEzyV2EahAaSa2ZljukZMg=; b=IsbIikfAZzGypzm9c9vxtY9Ym6EC8TZD0HS7OCOVXgJqc0rZLpxSvFjalPV2FWXiu0EXBKWNnlsNH4hbvO1ZfCE+8Rkb0i7z/te6Q72Is/QSFgRNSbjU3tmGLH9i8QUm0F4xKgAX6ud9tDApMBqOOIHgFbBbvpTxXSNwRlW38u0= Received: from DB6PR07CA0173.eurprd07.prod.outlook.com (2603:10a6:6:43::27) by AM0PR08MB4388.eurprd08.prod.outlook.com (2603:10a6:208:13e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.20; Tue, 14 Apr 2020 08:13:28 +0000 Received: from DB5EUR03FT045.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:43:cafe::6) by DB6PR07CA0173.outlook.office365.com (2603:10a6:6:43::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.12 via Frontend Transport; Tue, 14 Apr 2020 08:13:28 +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 DB5EUR03FT045.mail.protection.outlook.com (10.152.21.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.18 via Frontend Transport; Tue, 14 Apr 2020 08:13:27 +0000 Received: ("Tessian outbound 55454527ea3b:v50"); Tue, 14 Apr 2020 08:13:27 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 8e8e6a6da40d2d06 X-CR-MTA-TID: 64aa7808 Received: from bbde79b6848b.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 50793117-F821-4DA0-8607-0EFBEA3EA6CA.1; Tue, 14 Apr 2020 08:13:22 +0000 Received: from EUR05-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id bbde79b6848b.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 14 Apr 2020 08:13:22 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VwGiKRMfAzLuPAN+PXxrRRgM9X4PFChGaG4EQ0HNUbTkAfOD5l3LBRu5NP2bWjfS0Rn8qJlVBp7x0QMBVgTsXRuPDIw7n7QKUBnBC+kJ9I1Yitwb1tdeK2pcRqq4ltKuHBBoRobOHcyTDW0m+oSVItt0G+6tzDgQ8+pBoOnb1LFo5cL+TNmM8Lx0GeSY44y+T6bhQOeUbFkaCZVyEbXhb6IESkFBemGpMEQuy7tiw9u8CRZwNKNhGHzhsQaJPDcS0MVXR9IxX6lM4pyKci6F3LZ5g/CoBxst0rD52UcJukRfjQElpykYklE5gMvkMUvjwEusQ4ETQtdEbDvkD6mQHg== 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=BofMFLTb2Z9xnoaUOem/+FEzyV2EahAaSa2ZljukZMg=; b=n9ZzvDSjHFkZFIFxuE847YNq8waSZedXa2m7r4JRgLprQ7efFRegP/7N2jdAhEiXr9cL25kRpGZ62YUm2ZcSPhsOdVGAZvMcF8L5NxyU/5YnF7eFwyNYjBkthexw+TVNSwwt4F5W9RdkvC7ioFyJZi2LiL0wAJByeXonx7TFubB98QWZZbYltpfSyrXM5lvCXN9DgjV5gp2CFskoT91naFE4X8E2Y7O5RD5tAM7LnUvUJJQ7mwywMPNePpEjmiYQ++sAe4h9mIO8ePE3fy+OEF3AJ+5jLC/WrqX9V4YldeeHkMouoTdDoKno4l7kD2MOUvJQfMW00aGKPLF97gaWqQ== 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=BofMFLTb2Z9xnoaUOem/+FEzyV2EahAaSa2ZljukZMg=; b=IsbIikfAZzGypzm9c9vxtY9Ym6EC8TZD0HS7OCOVXgJqc0rZLpxSvFjalPV2FWXiu0EXBKWNnlsNH4hbvO1ZfCE+8Rkb0i7z/te6Q72Is/QSFgRNSbjU3tmGLH9i8QUm0F4xKgAX6ud9tDApMBqOOIHgFbBbvpTxXSNwRlW38u0= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6PR08MB5256.eurprd08.prod.outlook.com (2603:10a6:20b:e7::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.26; Tue, 14 Apr 2020 08:13:20 +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.2900.028; Tue, 14 Apr 2020 08:13:20 +0000 From: Hanno Becker To: "tls@ietf.org" Thread-Topic: [TLS] Epochs for ACKs Thread-Index: AQHWEjKVvSYAqKGPhk+YiefphRO+/A== Date: Tue, 14 Apr 2020 08:13:20 +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.177.220.146] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 15d5fa0b-6aef-4499-4da3-08d7e04bb622 x-ms-traffictypediagnostic: AM6PR08MB5256:|AM0PR08MB4388: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:10000; x-forefront-prvs: 0373D94D15 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)(39860400002)(136003)(346002)(376002)(396003)(366004)(186003)(5660300002)(19627405001)(81156014)(6916009)(71200400001)(8676002)(86362001)(8936002)(2906002)(76116006)(52536014)(316002)(66946007)(478600001)(33656002)(55016002)(66446008)(64756008)(7696005)(66556008)(6506007)(9686003)(26005)(66476007); 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: yJGOVIIGdhqxtOCCDYsyRx1mi6d0P0tRs/qZF/ZNFW7HR2G4AE6JCh5TFX7RoSrlVUQut6+9Rfhl8DjyUvjZGSnix7dsrz/HUxKuBoRTppBiI0V4ona5udcLJSoaKOXBGNg7MX5kkM32iPmtChq9/vkZbkXhbxLa1QlH07bDV0oYp2tZYstdd70bRawhvpuQ1unQODN/1pxv010KM/QEWP5N84IWl9KI2BLjzp3l2wv1ilRbeVwUfkrJj6Uk0+TxaxxrorxEhny0XT5qIwNnpm/vmFe9sYPxH9glfkfuXk/UOSruZEC96by8z5wdGRhwfwQCCaLNVbcvWlN6J6NbTEflpSRisOv75Ps4OyNcb3Vh2ZSyr5fJnCexC/CHkx+qndhVxI6QWfL5gWzwuFRdEMz+ntQEU+DH5pCkWmF5Q+THuigkg8vLV/9As3iHsPMU x-ms-exchange-antispam-messagedata: zvdFQPLIbSs5TN4jL7WFNiLxaAxMfNUqMwaC6IuIsJPvzJsXZz+QKWT2Ap9/s6469zG42UAvbKnXH4qS+gqrEmKSySY5xbDz6L27rVanhcfyqoMpyfWhDrZp532AdkJMvyxnENcY8NJfamtjYBreQQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB331888C090D386EBC440A0A99BDA0AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5256 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT045.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)(346002)(39860400002)(136003)(376002)(396003)(46966005)(33656002)(86362001)(478600001)(26826003)(186003)(26005)(7696005)(2906002)(70206006)(70586007)(336012)(6916009)(316002)(82740400003)(81156014)(6506007)(81166007)(55016002)(8936002)(47076004)(356005)(8676002)(19627405001)(5660300002)(52536014)(9686003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 4381182b-20ef-4702-afd0-08d7e04bb1c0 X-Forefront-PRVS: 0373D94D15 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: tpWKKaXtn6kCe8gO8RSOLCcuPV2kyNUIc5biPHq0lPq4+Z3kubQNLQQijkbiSLo+8bukcpG0+1x4eaIFXsJB1c8rpVIk6hx7wCrqSFNZ53abGNqZ1wOdO5r4DeFP/Bri2aocbgEaTJBsBk+BLePVARNzjh+droMqrvOM+zM/kkptYmO6Wd0eNHkDPybJgUYLwOmTQZqxrkNGXfPo3WtPCwBkQFERHGfDDKN8sGGGCVwYprvL0IE7vWLr0I/AXIFwDvgZPNRzrHlytt5rvbQbqDwOCWwZMGFGzxmmfU1EZdtOgKadkBtued/K8x9ahAiBNVmi/rQPvlh9qifpiVMTUV2og8e7rCdz0Z/5b49Sun15c60CuGElSxOuaF+tB1e8MzxT39RmzQz56C5hSGE2JqLq6mIMp/cRthyFWkf4ywqCQQ1rvFWYvg8VOZ7Nkc14nyUEss8Wpp7hDIR1I6d5CMq4z49mXMpV7jiOAkJN33ecoOpmxY0OS4c5hCKrKiPuQrg7tqBD6NAoE+e/IGGY0g== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Apr 2020 08:13:27.8704 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 15d5fa0b-6aef-4499-4da3-08d7e04bb622 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: AM0PR08MB4388 Archived-At: Subject: [TLS] Epochs for ACKs 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: Tue, 14 Apr 2020 08:13:33 -0000 --_000_AM6PR08MB331888C090D386EBC440A0A99BDA0AM6PR08MB3318eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, On ACK protection, DTLS 1.3 Draft 37 says in Section 7: ACK records MUST be sent with an epoch that is equal to or higher than the record which is being acknowledged. Implementations SHOULD simply use the current key. Since the update of incoming and outgoing keying material is independent, I don't know how this can be enforced: After a sequence of key updates, the incoming epoch might be 42 while the outgoing epoch is 17. What problems arise if one replaces the paragraph by the following: ACK records MUST be sent with the current key, irrespective of the epoch that is used to protect the record that is being acknowledged. It appears that the paragraph is particularly relevant for the case of ACKing a ServerHello, which as far as I understand shall happen with epoch 1. Since 'current key' doesn't appear unambiguously defined at the point of the client processing the ServerHello, it might be worth spelling out this case explicitly. Best, 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_AM6PR08MB331888C090D386EBC440A0A99BDA0AM6PR08MB3318eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,

On ACK pro= tection, DTLS 1.3 Draft 37 says in Section 7:

 = ;  ACK records MUST be sent with an epoch that is equal to or higher
 = ;  than the record which is being acknowledged.  Implementations = SHOULD
 = ;  simply use the current key.

Since= the update of incoming and outgoing keying material is
indep= endent, I don't know how this can be enforced: After a
seque= nce of key updates, the incoming epoch might be 42 while
the o= utgoing epoch is 17.

What = problems arise if one replaces the paragraph by the following:

 = ;  ACK records MUST be sent with the current key, irrespective<= br>
 = ;  of the epoch that is used to protect the record that is
  &nb= sp;being acknowledged.

It appears= that the paragraph is particularly relevant for the case
of ACKing = a ServerHello, which as far as I understand shall happen
with epoch= 1. Since 'current key' doesn't appear unambiguously
defined at= the point of the client processing the ServerHello, it
might be w= orth spelling out this case explicitly.

Best,
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_AM6PR08MB331888C090D386EBC440A0A99BDA0AM6PR08MB3318eurp_-- From nobody Tue Apr 14 04:28:51 2020 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 0C8963A0C89 for ; Tue, 14 Apr 2020 04:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 hcOY9hUEGe60 for ; Tue, 14 Apr 2020 04:28:48 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B053A0C84 for ; Tue, 14 Apr 2020 04:28:48 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id h6so12761621iok.11 for ; Tue, 14 Apr 2020 04:28:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=mUA5BB72ZU22gz88ekKLKV/awcThSDoRlMoirjTxalg=; b=RGqENjSSSE4PGMaMtHrjmufUxqXPModXuFGtfBtSxRKzJG6cweYTWkYHuitXMxAmLa L3bHDctTM4AU0QE3jEHRPwpbc6ZLlw3bWJ8UlahmuH500TRx5iVUzX/IvBUiSruS8vpD spzGgCyNLCryMkYkNUUuAJMkyx4X0vTOfaRvGTmXZau0Omb7d+JrLzQdPQqJ56eQD+Ah 91eIhStS/FOwNRfHUmATz5rIl45WN8Oti8Vusc9fZ/9QipWSAIrICCMTeJ9K5aT+wgHu 9wY2KfyF5dIdLfOmQyqGijgZ8mTgGiGCn42pC8zcvQX7CEeXTwev/OX2U8t6eQ8o++XD JiHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=mUA5BB72ZU22gz88ekKLKV/awcThSDoRlMoirjTxalg=; b=GOGtwCYPs6CRQyzkJTcO1gJTGG7+F12+nX2xyBZLZeNrw/1aOSwRgASCXvnawoX4PA W82mkkJvLz5rUlHXWmzScUIQ5c0AKYe7VIAbj0+DrJFMMD6KLRRTZ3peeDKtuEgVbbCg rN2NuxsMlH09wzvas8AnnN6ZT5yCo43kIDAs16+olk13t7K8nrC7UqJJ8rk+9RGuBSrJ H9KOyYF80LSvm4aAK+cM75lYJygmIAGUz6N9rDtJoOV2QDtyROLgOdny4MkZGCr3C9cq 9veX2qfFcaEymo3b+yBZ5GZY7cQb7RUjRF6qQ4poAnyC5NnHB+6C7jQAoCKQREN0FOvf P1fQ== X-Gm-Message-State: AGi0PuZFS2rYhJQaMfByUY+3Yn8I5LKhzXdpyRBEgAO2Qhtbt/c6z2WH bL2rPMH6h2Ilaq18RLYM6of2pW8FSA42gs25792PJ1QM X-Google-Smtp-Source: APiQypK/6tcMW6oaVsVkbQxIibBG1EbxbF8jtj3GEV2AZo8ItOjbQbazzl8Lx5So9LMFVihNeXksrFRHj4hfOJWbhVI= X-Received: by 2002:a02:8c4:: with SMTP id 187mr20081954jac.50.1586863727346; Tue, 14 Apr 2020 04:28:47 -0700 (PDT) MIME-Version: 1.0 References: <158680445215.7542.8231470525567908510@ietfa.amsl.com> In-Reply-To: <158680445215.7542.8231470525567908510@ietfa.amsl.com> From: Raja Ashok Date: Tue, 14 Apr 2020 16:58:36 +0530 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="000000000000c6867205a33e8085" Archived-At: Subject: [TLS] New Version Notification for draft-rashok-tls-ticket-request-msg-01.txt 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: Tue, 14 Apr 2020 11:28:50 -0000 --000000000000c6867205a33e8085 Content-Type: text/plain; charset="UTF-8" Hi All, Updated draft with performance improvement on Client's App data processing when TLSv1.3 server ignores session ticket msg after handshake. Requesting all to provide your opinion on this draft. +------------------+-------------------------+-------------------------+ | Num of Ticket | Average time taken by | Average time taken by | | send by Serv | SSL_read | SSL_read | | after handshake | (AES_GCM_256) | (Chacha20Poly1305) | +------------------+-------------------------+-------------------------+ | 0 | 62 usecs | 56 usecs | | 1 | 102 usecs | 86 usecs | | 2 | 132 usecs | 128 usecs | | 4 | 195 usecs | 185 usecs | | 6 | 250 usecs | 241 usecs | +----------------------------------------------------------------------+ +------------------+-------------------------+-------------------------+ | Num of Ticket | Average number of | Average number of | | send by Serv | connections per second | connections per second | | after handshake | (AES_GCM_256) | (Chacha20Poly1305) | +------------------+-------------------------+-------------------------+ | 0 | 1260 | 1356 | | 1 | 1134 | 1229 | | 2 | 1092 | 1141 | | 4 | 1001 | 1060 | | 6 | 929 | 1002 | +----------------------------------------------------------------------+ A new version of I-D, draft-rashok-tls-ticket-request-msg-01.txt has been successfully submitted by Raja Ashok and posted to the IETF repository. Name: draft-rashok-tls-ticket-request-msg Revision: 01 Title: TLS Ticket Request Message Document date: 2020-04-14 Group: Individual Submission Pages: 5 URL: https://www.ietf.org/internet-drafts/draft-rashok-tls-ticket-request-msg-01.txt Status: https://datatracker.ietf.org/doc/draft-rashok-tls-ticket-request-msg/ Htmlized: https://tools.ietf.org/html/draft-rashok-tls-ticket-request-msg-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-rashok-tls-ticket-request-msg Diff: https://www.ietf.org/rfcdiff?url2=draft-rashok-tls-ticket-request-msg-01 Abstract: TLS session ticket provides a stateless mechanism for server to resume connection with client. As per TLS 1.3 [RFC8446], server always sends arbitary number of session ticket after handshake. This document introduces a new message which is TicketRequest message, it can be send by client after handshake at any point of connection lifetime to retrieve new session ticket. The proposed mechanism in this document is only for TLS 1.3 and DTLS 1.3 and future versions. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --000000000000c6867205a33e8085 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

Updated draft with performance improvement on C= lient's App data processing when TLSv1.3 server ignores session ticket = msg after handshake. Requesting all to provide your opinion on this draft.<= br>
+--------------=
----+-------------------------+-------------------------+
|   Num of Ticket  |  Average time taken by  |  Average time taken by  |
|   send by Serv   |        SSL_read         |        SSL_read         |
|  after handshake |      (AES_GCM_256)      |    (Chacha20Poly1305)   |
+------------------+-------------------------+-------------------------+
|        0         |         62 usecs        |          56 usecs       |
|        1         |        102 usecs        |          86 usecs       |
|        2         |        132 usecs        |         128 usecs       |
|        4         |        195 usecs        |         185 usecs       |
|        6         |        250 usecs        |         241 usecs       |
+----------------------------------------------------------------------+

+------------------+-------------------------+-------------------------+
|   Num of Ticket  |    Average number of    |    Average number of    |
|   send by Serv   |  connections per second |  connections per second |
|  after handshake |      (AES_GCM_256)      |    (Chacha20Poly1305)   |
+------------------+-------------------------+-------------------------+
|        0         |           1260          |           1356          |
|        1         |           1134          |           1229          |
|        2         |           1092          |           1141          |
|        4         |           1001          |           1060          |
|        6         |            929          |           1002          |
+----------------------------------------------------------------------+

A new version of I-D, draft-rashok-tls-ticket-request-msg-01.txt

has been successfully submitted by Raja Ashok and posted to the

IETF repository.



Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-rashok-tls-ticket-reque=
st-msg

Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001

Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TLS Ticket Request Message

Document date:=C2=A0 2020-04-14

Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission

Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 5

URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-rashok-=
tls-ticket-request-msg-01.txt

Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-rashok-tls-ticket-reques=
t-msg/

Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-rashok-tls-ticket-request-msg-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-rashok-tls-ticket-requ=
est-msg

Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-rashok-tls-ti=
cket-request-msg-01



Abstract:

=C2=A0 =C2=A0TLS session ticket provides a stateless mechanism for server t=
o

=C2=A0 =C2=A0resume connection with client.=C2=A0 As per TLS 1.3 [RFC8446],=
 server

=C2=A0 =C2=A0always sends arbitary number of session ticket after handshake=
.=C2=A0 This

=C2=A0 =C2=A0document introduces a new message which is TicketRequest messa=
ge, it

=C2=A0 =C2=A0can be send by client after handshake at any point of connecti=
on

=C2=A0 =C2=A0lifetime to retrieve new session ticket.=C2=A0 The proposed me=
chanism in

=C2=A0 =C2=A0this document is only for TLS 1.3 and DTLS 1.3 and future vers=
ions.









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat
--000000000000c6867205a33e8085-- From nobody Tue Apr 14 09:15:41 2020 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 D51733A0B62 for ; Tue, 14 Apr 2020 09:15:37 -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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com 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 yOgVndguM3y6 for ; Tue, 14 Apr 2020 09:15:31 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87E333A0AE1 for ; Tue, 14 Apr 2020 09:14:51 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id b10so10578432qtt.9 for ; Tue, 14 Apr 2020 09:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=swPeFsrzHUcZ99ti+fX2b6Hcofx1O5YKk6VVXu/peo0=; b=urUmuYkg9Yp0/tIoLAOvjZdLrORseo77uJ2/0z/ca70rySvWx6GrzAHeRorQ+hj9dB AfdEIBt3HgolNQ20/jWqC/lKDe5qGTEUj5Rd13sMXcgQEKMF/fyB7ob0zzc5WwQXv41H IxdgTHfJlKAgawgWi2Iz+WDiSvjuH7O/9TDXIKvpcB0fNKubsv2cy752fba1ZK2DWBlP f+Ez1xYFJllP3HpF+skQKcBpLV9mgGCWyQWD/idon/CF3b2u5g6R4QHzu+zIEQ6+R0OC 7wj3KKsU4HMda5ks1ft9ZTaAqC2Lk+BWIsQamIuTnx2sXDCjDdjgxNDjsRpiupVJPYpC c9EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=swPeFsrzHUcZ99ti+fX2b6Hcofx1O5YKk6VVXu/peo0=; b=hjgJku++D/qpDku4iCpylJjS7Kf77JUcH9wEBJsxCI4YdoiRuygHqDH+d7XQku6Tiv f+vem8a0B7Anv5ZfuXVC8m7qLDwIK2TgTYQD2fVBsCTxZrM/nYYTJLUp6E0qCazP23Sx sXTEyFSrv4PSLavBHMaaNR1dAXXS8XmTgqT+uDbn/HTtvWBTAqBCNwMFzo72wrFlxKdx uCOozrGV6a7rZBKMSTBGeFZnFAdPbHvNSo06S8G2Z/5ca1hJEFg+HCrS7S+mqaL1jDvC a78ALNKPXLDIcMoADU4MIr7aISPU0EoubPqh1FdHyj0+ed16LgxjuRk9auc+HWH21088 EAKw== X-Gm-Message-State: AGi0PuaY+BKzfpCInS7Ve99AHjsJO6Owgez2SA6Sqkp0yl+Fmsxzpotm Hgv5i6llPWE4e7iBK+5Pvwe6GcInzHKzWiekrDaE/n/NZ6k= X-Google-Smtp-Source: APiQypLuKJ6ujsR6TTe2aWwaYy4VjLLSBrkrR16A+sL47+Xy3wKeviB3PWWPn1m3h3lm2cU4n0124hv7ed9u3C8qV/k= X-Received: by 2002:ac8:1833:: with SMTP id q48mr8111659qtj.38.1586880890089; Tue, 14 Apr 2020 09:14:50 -0700 (PDT) MIME-Version: 1.0 From: Joseph Salowey Date: Tue, 14 Apr 2020 09:14:39 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000c14d9905a3427f81" Archived-At: Subject: [TLS] April Vitrual TLS Interim Scheduled 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: Tue, 14 Apr 2020 16:15:40 -0000 --000000000000c14d9905a3427f81 Content-Type: text/plain; charset="UTF-8" The April TLS interim virtual meeting is scheduled for 2020-04-27 19:00 - 21:00 UTC More details will follow shortly. Agenda is available here: https://datatracker.ietf.org/meeting/interim-2020-tls-01/session/tls Cheers, Sean, Joe and Chris --000000000000c14d9905a3427f81 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The April TLS interim virtual meeting is scheduled for
2020-0= 4-27 19:00 - 21:00 UTC

More details will follow shortly. Ag= enda is available here:=C2=A0https://datatracker.ietf.org/meeting/int= erim-2020-tls-01/session/tls

<= div>Cheers,

Sean, Joe and Chris
--000000000000c14d9905a3427f81-- From nobody Wed Apr 15 15:42:47 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E803A0BAF; Wed, 15 Apr 2020 15:42:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <158699056568.21356.13551972231001973459@ietfa.amsl.com> Date: Wed, 15 Apr 2020 15:42:45 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-hybrid-design-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 15 Apr 2020 22:42:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Hybrid key exchange in TLS 1.3 Authors : Douglas Stebila Scott Fluhrer Shay Gueron Filename : draft-ietf-tls-hybrid-design-00.txt Pages : 34 Date : 2020-04-15 Abstract: Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3. Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@ietf.org or on the GitHub repository which contains the draft: https://github.com/dstebila/draft-ietf-tls-hybrid-design. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-hybrid-design-00 https://datatracker.ietf.org/doc/html/draft-ietf-tls-hybrid-design-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 17 08:16:03 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1CC3A0CEF; Fri, 17 Apr 2020 08:15:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158713653959.791.15169592800227699396@ietfa.amsl.com> Date: Fri, 17 Apr 2020 08:15:39 -0700 Archived-At: Subject: [TLS] Transport Layer Security (tls) WG Virtual Meeting: 2020-04-27 CHANGED X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 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, 17 Apr 2020 15:15:40 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Transport Layer Security (tls) Working Group will hold a virtual interim meeting on 2020-04-27 from 12:00 to 14:00 America/Los_Angeles (19:00 to 21:00 UTC). Agenda: 1. Administrivia and agenda bashing 2. ECHO 3. PSK design team readout Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mc71746458639560e90b93107357cd77b From nobody Sun Apr 19 00:32:32 2020 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 85E313A0366 for ; Sun, 19 Apr 2020 00:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=GLlcZx2U; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zDjp6XN9 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 5lNnh2x9R-oJ for ; Sun, 19 Apr 2020 00:32:28 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087E43A1C42 for ; Sun, 19 Apr 2020 00:32:27 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 882615EB for ; Sun, 19 Apr 2020 03:32:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 19 Apr 2020 03:32:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=oIXS9R37FhCk/chLgTyZ7mmBm/N/8KQ1fbGERgcZGvY=; b=GLlcZx2U CRf9V6ds3WjJPzG1KcS4X4UGzmjmF6CFACpDMJtjdi1bvB5qOcgYJSOmCGjnNsrD Z7k53QV9hmR9ZX4/6txUvWnRPWji9ttYFJT6TDTQJuX+ILtSSvATWCo2XpmlkNVb EKxrtY2WjO+OU3K4Dyv15nlcSi/VXtX3KGi9v0ZR0NodSyJcXH3x9/glX3b+udqz eqJHmq3mY9FJWz35MqiIojBxHZabSSzAOkWsNWOdaWP+qrpBfuyPLUbVqMpsUkGE 7qflrWp5tzQHIrKIHU/rSqVTC/QZNUz8OIX7AvKwoDxzSaVQtS4KOtM30/AMOagx y96+s7XdohobTg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=oIXS9R37FhCk/chLgTyZ7mmBm/N/8 KQ1fbGERgcZGvY=; b=zDjp6XN9+nmsAPc6CKcSC+ikwJdFtfLiWvp0dOhSqSijV itUrZrBcqALD2hqlNnvMqVbQ7aYkjmDsnWXiV6W4mW+sCkRcFJBVneW4qLEGPRTm ooPi9+m4fjatEC9pa+O20vktuko25i59JeyC19lY7bnPoUrnaEQBcMiaYAV2z4ut m4XvHeSB1L1IQE16jtkfZCedNNuV0wFgpTmOB80sVwPFevjpQBQmPLjVdahunaix FqsQnTHEKAoSY7I6SqcoMCg6iXxsdI0sylofGoCi9M78RQiSHkMXMXvx8aamRHZY JsJIepTVrDza7zO2DT+TitZOleU02UYBPuyrS6uSw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgedtgdduudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuffhomhgrihhnpe hgihhthhhusgdrtghomhenucfkphephedvrddujeejrddujedrvdegvdenucevlhhushht vghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvph hlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az89.internal.cloudapp.net (unknown [52.177.17.242]) by mail.messagingengine.com (Postfix) with ESMTPA id F155D3280059 for ; Sun, 19 Apr 2020 03:32:26 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============8921556442476151659==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: tls@ietf.org Message-Id: <20200419073226.F155D3280059@mailuser.nyi.internal> Date: Sun, 19 Apr 2020 03:32:26 -0400 (EDT) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) 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: Sun, 19 Apr 2020 07:32:31 -0000 --===============8921556442476151659== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/draft-ietf-tls-esni (+5/-0/=F0=9F=92=AC11) 5 issues created: - two type codes needed for interop (by sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/220=20 - cardinality of ECHOConfig vs. HTTPSSVC (by sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/219=20 - HPKE code points vs. TLS ciphersuites (by sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/218=20 - ECHOConfigContents.extensions is not needed (by sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/217=20 - where servers put CH details/hints: ECHOConfig or HTTPSSVC? (by sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/216=20 3 issues received 11 new comments: - #219 cardinality of ECHOConfig vs. HTTPSSVC (2 by davidben, sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/219=20 - #216 where servers put CH details/hints: ECHOConfig or HTTPSSVC? (5 by= bemasc, davidben, sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/216=20 - #214 Clarify whether ClientHelloInner can support TLS 1.2. (4 by chris-= wood, sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/214=20 Pull requests ------------- * tlswg/draft-ietf-tls-esni (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - README: fix links to WG docs https://github.com/tlswg/draft-ietf-tls-esni/pull/213=20 * tlswg/draft-ietf-tls-ticketrequest (+0/-2/=F0=9F=92=AC0) 2 pull requests merged: - Ticket request with separate resumption and new_session counts. https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18=20 - Use two counters for fresh and resumed connections https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/19=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============8921556442476151659== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday April 19, 2020

Issues

tlswg/draft-ietf-tls-esni (+5/-0/=F0=9F=92=AC11)

5 issues created:

3 issues received 11 new comments:

Pull requests

tlswg/draft-ietf-tls-esni (+0/-1/=F0=9F=92=AC0)

1 pull requests merged:

tlswg/draft-ietf-tls-ticketrequest (+0/-2/=F0=9F=92=AC0)

2 pull requests merged:

Repositories tracked by this digest:

--===============8921556442476151659==-- From nobody Sun Apr 19 14:40:09 2020 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 038FE3A1238 for ; Sun, 19 Apr 2020 14:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 F_nn9xoGvBeZ for ; Sun, 19 Apr 2020 14:40:06 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360833A1237 for ; Sun, 19 Apr 2020 14:40:06 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id z26so7758109ljz.11 for ; Sun, 19 Apr 2020 14:40:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Uo4iMUeT6K4r4kty2L1ZLUhClDyoel2O3KeSBgmCZls=; b=QA1cBnQ84IhV0bDe8Qcp9qS4r8Abm2nOzmufE2sroXMAOZwTZ5p4x5JcjKjAmI3QRl 862/Rq/XC6SQW6XSOuV30aUmhGsQ69PNoanHLKEf+xMHSIszab97M7OFaYTxrXGeveU9 vCFkjogbl5QsfwtGhoLaP1tlnic5k6J2M9sH2ZvHkuqiyoxKOTm9uhm8BoNGsvd4W1QW 84cO8log2df35iJzhkVgE1qiY926aZ6AAWz/+v/5GPShJ446MrmQU7PCTXAbgohDyCjf V5D++1XLXWSc6M13qb0+oDEaGYwEPqZSm30O74wtkThRXgRwca7mUe6kos2t1dwcNa+E aHpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Uo4iMUeT6K4r4kty2L1ZLUhClDyoel2O3KeSBgmCZls=; b=psKvhFqvqCKM5mnGzQN5DfY2TRZ4ZLJgIS8GmFw0C5L2hy7Eq6eaVzSdTaM8IRkbRL qNfQrHO/5qEUd68h+UvtyGRGHl9yLI8k1Xv5xdx0t19ua6/Tmdaq6F1BWEcKrywhO46R l/1A7tGzhGqz4Fe/1YYDJckqOmW1qS97WZ9Ut9lwtJ6FHQ6oeVP8HDMwxLCy02JIUxGg py3U/sx9nhXwLRglHCiweHEW/nMjbF7WwSh+qLCA47PwzOE5WT6mBKUloYVIdq471Zmq f0WLhyzjxLdcy2SHbpLQFowOVQ5dw7qTEGglYhpKlu8fpIx6hjcrp7jQUPrHwfjloMHR CbRg== X-Gm-Message-State: AGi0Puap54pBTKo/3tGgaI7krJ+IFhO5Eiik0CyN0Zjb1Ij8VRY8Ploo m9x0Kw8ga6XJv672/WfzzGaIt9OpcjrQn8ligJ1dzQ== X-Google-Smtp-Source: APiQypI9scv1JrrQwIDrQrvxgDXQB5/z3HsUKlYibjBuGRQgOiMJXEoRFm/se4frajLduCtcObQEPCNh5x8S0jdaYpA= X-Received: by 2002:a2e:b0ee:: with SMTP id h14mr8519403ljl.35.1587332404229; Sun, 19 Apr 2020 14:40:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Sun, 19 Apr 2020 14:39:27 -0700 Message-ID: To: Hanno Becker Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001848c605a3aba06b" Archived-At: Subject: Re: [TLS] Epochs for ACKs 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: Sun, 19 Apr 2020 21:40:08 -0000 --0000000000001848c605a3aba06b Content-Type: text/plain; charset="UTF-8" I have posted a PR to clarify this: https://github.com/tlswg/dtls13-spec/pull/142 On Tue, Apr 14, 2020 at 1:13 AM Hanno Becker wrote: > Hi all, > > On ACK protection, DTLS 1.3 Draft 37 says in Section 7: > > ACK records MUST be sent with an epoch that is equal to or higher > than the record which is being acknowledged. Implementations SHOULD > simply use the current key. > > Since the update of incoming and outgoing keying material is > independent, I don't know how this can be enforced: After a > sequence of key updates, the incoming epoch might be 42 while > the outgoing epoch is 17. > > What problems arise if one replaces the paragraph by the following: > > ACK records MUST be sent with the current key, irrespective > of the epoch that is used to protect the record that is > being acknowledged. > > It appears that the paragraph is particularly relevant for the case > of ACKing a ServerHello, which as far as I understand shall happen > with epoch 1. Since 'current key' doesn't appear unambiguously > defined at the point of the client processing the ServerHello, it > might be worth spelling out this case explicitly. > > 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 > --0000000000001848c605a3aba06b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have posted a PR to clarify this: https://github.com/tlswg/dtls13-spec/pu= ll/142

On Tue, Apr 14, 2020 at 1:13 AM Hanno Becker <Hanno.Becker@arm.com> wrote:
Hi all,

On ACK protec= tion, DTLS 1.3 Draft 37 says in Section 7:

=C2=A0 = =C2=A0ACK records MUST be sent with an epoch that is equal to or higher
=C2=A0 = =C2=A0than the record which is being acknowledged.=C2=A0 Implementations SH= OULD
=C2=A0 = =C2=A0simply use the current key.

Since th= e update of incoming and outgoing keying material is
independ= ent, I don't know how this can be enforced: After a
sequence= of key updates, the incoming epoch might be 42 while
the outg= oing epoch is 17.

What pro= blems arise if one replaces the paragraph by the following:

=C2=A0 = =C2=A0ACK records MUST be sent with the current key, irrespective
=C2=A0 = =C2=A0of the epoch that is used to protect the record that is
=C2=A0 =C2=A0= being acknowledged.

It appears th= at the paragraph is particularly relevant for the case
of ACKing a S= erverHello, which as far as I understand shall happen
with epoch 1.= Since 'current key' doesn't appear unambiguously
defined at th= e point of the client processing the ServerHello, it
might be wort= h spelling out this case explicitly.

Best,<= /div>
Hanno<= /div> 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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000001848c605a3aba06b-- From nobody Sun Apr 19 15:23:23 2020 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 9C0823A05AC for ; Sun, 19 Apr 2020 15:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 MrKkAm0t_Q9X for ; Sun, 19 Apr 2020 15:23:21 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 45A133A05AA for ; Sun, 19 Apr 2020 15:23:20 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 010ED1A9537; Sun, 19 Apr 2020 18:23:19 -0400 (EDT) Date: Sun, 19 Apr 2020 18:23:18 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20200419222318.GY41308@straasha.imrryr.org> Reply-To: tls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: [TLS] Ticket request PR#20 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: Sun, 19 Apr 2020 22:23:23 -0000 I uploaded a small pull request for the ticket request draft: https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/20 it stipulates that servers SHOULD send at least one ticket unless *both* counters are zero. A client willing to accept tickets for either of the two handshake types is capable of accepting a ticket for the other. Yes, this leaves the door open to later define (or not) special semantics for the zero value to be used between mutually consenting clients and servers. -- Viktor. From nobody Sun Apr 19 15:42:31 2020 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 EE35D3A07BA for ; Sun, 19 Apr 2020 15:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 x0XAsgJQ-A1y for ; Sun, 19 Apr 2020 15:42:27 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61EBE3A07AE for ; Sun, 19 Apr 2020 15:42:27 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id j3so7849803ljg.8 for ; Sun, 19 Apr 2020 15:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JKtjr6jx6xdhKgFvEeP0sHGtEGd6vGwm5e1sC8HAZlQ=; b=GxQYYJgeufFRoPiZS0AOWv+WvkvqSVLiG+xBxNS0H53fIeBJ8r9uWuPEWCK9bOehR7 ijbt7JoEsz14/shXDcGwiMtZe7Qim6hQqqGcUUXrk3DkPGNfU1yiNOgBSJ+dM7C7wLoD Bvpe09+gJAsGn6KboiJfZcHLT+/6+YeSTqGoz/cWL9kZ82pkuKejZQh/epLw4AQOJu6f jFHxTIezLi9HLxTQE5qQYDEh9U+LRke9IkaviGgZBbKUoXhzCBY9KIBkuwYMmqT/UByg 9r/N94FXtcPsPnCu0GhsnGldXv3GOTMuMu2w40zzQJ2bBPxbVTG3swamPoHwk4ZdQBdw IgCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JKtjr6jx6xdhKgFvEeP0sHGtEGd6vGwm5e1sC8HAZlQ=; b=sw28HZy6hOzf0OlnE3SzO/WtO2XjpHfxTztd4DKQcJdHjhvOIIIXs5zKjUIt7viC2Q ZiN+U9rX6BengoQdOI6x7UP/GKGk8CUhdfAqbSDyTmCLsTmSwqfMcPiLvapAU4T9xr1d gcmxWuFgGR6ndw+9+SxAdD1WmbcBlrgGtUiMia2Me0iM3trFecyZNoNTAJoMAELaY9ul IRi5Pz1S0XG+A68NOB3dL33Wne5zW458Z9sC2Qw5FNjw09xvBnd5qfp8/aGN3PG9Wi5P SnLOseSOeO+4siIN6oppBQQjOY9Bwe2QPv64VVdYkdjBd7S+UVwdY9F4D8AtgnVXozsY q64g== X-Gm-Message-State: AGi0PubfSeYuBaJZnhXUGlWcG4TYk8mTm3GPwWWFujtzDSL8n+e/44WG 7LM3RAczUzbHpRkiQLZssfxnWAhlbrajrB2NYBIjv7S+kCk= X-Google-Smtp-Source: APiQypLQj30IFdRn1fwCO/eCsoNLod0SUE4UcQyfy+JcVp+sZdV+Vm4tnBEPcMnbIjv9RaxhvzHudJrzv8XQ0Wi90oo= X-Received: by 2002:a2e:351a:: with SMTP id z26mr8127370ljz.162.1587336145499; Sun, 19 Apr 2020 15:42:25 -0700 (PDT) MIME-Version: 1.0 References: <20200419222318.GY41308@straasha.imrryr.org> In-Reply-To: <20200419222318.GY41308@straasha.imrryr.org> From: Eric Rescorla Date: Sun, 19 Apr 2020 15:41:49 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="0000000000001789c605a3ac7f6c" Archived-At: Subject: Re: [TLS] Ticket request PR#20 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: Sun, 19 Apr 2020 22:42:30 -0000 --0000000000001789c605a3ac7f6c Content-Type: text/plain; charset="UTF-8" I don't think we should make this change. In the context of this draft, if the client wants that behavior, it should send {1, 1}. -Ekr On Sun, Apr 19, 2020 at 3:23 PM Viktor Dukhovni wrote: > I uploaded a small pull request for the ticket request draft: > > https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/20 > > it stipulates that servers SHOULD send at least one ticket unless *both* > counters are zero. A client willing to accept tickets for either of the > two handshake types is capable of accepting a ticket for the other. > > Yes, this leaves the door open to later define (or not) special > semantics for the zero value to be used between mutually consenting > clients and servers. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000001789c605a3ac7f6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think we should make this change. In the = context of this draft, if the client wants that behavior, it should send {1= , 1}.

-Ekr


On Sun, Apr 19, 202= 0 at 3:23 PM Viktor Dukhovni <= ietf-dane@dukhovni.org> wrote:
I uploaded a small pull request for the ticket reques= t draft:

=C2=A0 =C2=A0 https://github.com/tlswg/= draft-ietf-tls-ticketrequest/pull/20

it stipulates that servers SHOULD send at least one ticket unless *both* counters are zero.=C2=A0 A client willing to accept tickets for either of t= he
two handshake types is capable of accepting a ticket for the other.

Yes, this leaves the door open to later define (or not) special
semantics for the zero value to be used between mutually consenting
clients and servers.

--
=C2=A0 =C2=A0 Viktor.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000001789c605a3ac7f6c-- From nobody Sun Apr 19 16:06:28 2020 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 0167F3A0873 for ; Sun, 19 Apr 2020 16:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 tsr2Q6pCU7_j for ; Sun, 19 Apr 2020 16:06:25 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 A29F73A0870 for ; Sun, 19 Apr 2020 16:06:25 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 823D71A93B9; Sun, 19 Apr 2020 19:06:23 -0400 (EDT) Date: Sun, 19 Apr 2020 19:06:23 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20200419230623.GZ41308@straasha.imrryr.org> Reply-To: tls@ietf.org References: <20200419222318.GY41308@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [TLS] Ticket request PR#20 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: Sun, 19 Apr 2020 23:06:27 -0000 On Sun, Apr 19, 2020 at 03:41:49PM -0700, Eric Rescorla wrote: > I don't think we should make this change. In the context of this draft, if > the client wants that behavior, it should send {1, 1}. That precludes clients from soliciting 0 *only* from servers that support some future specification, and otherwise getting 1 from servers that support only the current specification. Such clients are not looking for a static server behaviour, but rather need only certain servers to return 0, and the rest to return 1. In any case, if sending 1 or more unconditionally was fine for RFC8446 (e.g. per the text in C.4) it is hard to imagine why it is suddenly so important to insist that the server be able to send 0 when receiving {1, 0} or {0, 1}. Servers that don't support this new extension at all will send 1 (or more). So it is clearly not a big deal also for servers that do support it to do likewise. Since there is no specific *use-case* for {1, 0} to mean 0 at present, that couldn't also be handled by sending {0, 0}, there is no reason to stand in the way of defining {1, 0} to be a solicitation for at least 1 ticket regardless of the handshake type. The only objection that makes sense is a blocking tactic to preclude potential future refinement of this draft to support reuse, but surely blocking that evolution can be deferred to the discussion of the (misguided?) I-D that proposes it. -- Viktor. From nobody Mon Apr 20 04:10:52 2020 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 667F63A0B74 for ; Mon, 20 Apr 2020 04:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.013 X-Spam-Level: X-Spam-Status: No, score=0.013 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, T_SPF_TEMPERROR=0.01, 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=rvWpETfN; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=rvWpETfN 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 m5EunUI6puVZ for ; Mon, 20 Apr 2020 04:10:41 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80074.outbound.protection.outlook.com [40.107.8.74]) (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 BD7EA3A0B78 for ; Mon, 20 Apr 2020 04:10:35 -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=XxFCHxB9f2PXQqKwrwq9uGaxGC+aBYY1YzPv2aBBWtc=; b=rvWpETfNnxzga/OVCVYXAvlPCHoaXVu/2QxeHrxHPO+hjirIExT11ScgicNSN8jW7Gb4L1q5RffbIJkWovdNDBwMxuDP92yT9Zn+DE5prBduUx/zA9ZhXp6zrtt89ZVgvmgCcidh7+vtT1u8v/fxyrzP2tUMzs4ctUK8nbXAjxU= Received: from DBBPR09CA0034.eurprd09.prod.outlook.com (2603:10a6:10:d4::22) by VI1PR08MB3902.eurprd08.prod.outlook.com (2603:10a6:803:c2::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Mon, 20 Apr 2020 11:10:31 +0000 Received: from DB5EUR03FT044.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:d4:cafe::20) by DBBPR09CA0034.outlook.office365.com (2603:10a6:10:d4::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25 via Frontend Transport; Mon, 20 Apr 2020 11:10:31 +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 DB5EUR03FT044.mail.protection.outlook.com (10.152.21.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.15 via Frontend Transport; Mon, 20 Apr 2020 11:10:31 +0000 Received: ("Tessian outbound ecb846ece464:v53"); Mon, 20 Apr 2020 11:10:31 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 8334ace0e636002b X-CR-MTA-TID: 64aa7808 Received: from d49606e92ae5.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 78611862-035E-4CB0-A87E-060A45DE1D9F.1; Mon, 20 Apr 2020 11:10:25 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id d49606e92ae5.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 20 Apr 2020 11:10:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=E3gRjVF69Amkay8O/m9gB1cLuQ180xjrQSm5S3FOQETJIdBOo+86F2STAcsD2z0/1gXQq3T59dc7E6boAKdYWruUZDoCAKUVHDFA1r6Uj0hP4aLaVKyZYtQbwxUIOU4JSMQL6oW7Uk8kE8Z7bvcvI5SwlAfuog0BxU9d9tg4EJ2QQSijlZFW/JrnnUcZMXJr8Z2SVcAN3DF/BB9l7LMd/yaDJDzgOl9QtXmqGfi0dpZe7wSWYuDskG9KFQy+ShsYMAB0L29Faog1pxmhwpx39fQpHgkM6c+42DDG3StAG4mDdXFRjWiKhpWNUz+TBqlXQSSVmTuy05mR8s1pFhFRWg== 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=XxFCHxB9f2PXQqKwrwq9uGaxGC+aBYY1YzPv2aBBWtc=; b=lTp5CYkeZoyX8Nz1a+3W5ElMQjjly5UUxvozn8IF4r8d1beOgbyO1s9uSRCOHDWMvt7GYVFDk7w8hg02/AR8TY8XZuehIeXqKmF98mtdBxs29J0Vt9+NhpHQr8Jmu93/+EySsZLGHqnunLCLVungGGsO++kq5wl+LLWycBQ2O59vOExLFWXecobTKVESmj9P6AvEXlKbzVBhtS4WEt+9YKnnXA7bSefusUFEfuKoqM3EvSPaB5rcKUwxmGg2sLYXR++IGs0WMcFU/ZgaasGDMRAMM3x3IIOzGVtD35NJhOqK51iEOfz2Q3pIAHuEJsxu9A8Ixro+FIcDDF80mjuFtA== 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=XxFCHxB9f2PXQqKwrwq9uGaxGC+aBYY1YzPv2aBBWtc=; b=rvWpETfNnxzga/OVCVYXAvlPCHoaXVu/2QxeHrxHPO+hjirIExT11ScgicNSN8jW7Gb4L1q5RffbIJkWovdNDBwMxuDP92yT9Zn+DE5prBduUx/zA9ZhXp6zrtt89ZVgvmgCcidh7+vtT1u8v/fxyrzP2tUMzs4ctUK8nbXAjxU= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6PR08MB4360.eurprd08.prod.outlook.com (2603:10a6:20b:b3::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.26; Mon, 20 Apr 2020 11:10:23 +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.2921.027; Mon, 20 Apr 2020 11:10:23 +0000 From: Hanno Becker To: Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] Epochs for ACKs Thread-Index: AQHWEjKVvSYAqKGPhk+YiefphRO+/KiBAZqAgADicsM= Date: Mon, 20 Apr 2020 11:10:23 +0000 Message-ID: References: , In-Reply-To: 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.177.220.146] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 7adef2c0-5c24-4ff9-d95b-08d7e51b7097 x-ms-traffictypediagnostic: AM6PR08MB4360:|VI1PR08MB3902: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 03793408BA 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)(396003)(136003)(376002)(39860400002)(346002)(366004)(478600001)(55016002)(52536014)(53546011)(9686003)(6916009)(8676002)(6506007)(186003)(316002)(26005)(81156014)(66446008)(64756008)(66476007)(7696005)(71200400001)(5660300002)(2906002)(19627405001)(66556008)(4326008)(33656002)(966005)(8936002)(86362001)(76116006)(66946007); 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: n3MQ9ai/Xg0d6Kiapcy0K26Tnic/t2QUho9AXQnLXtD0fJQDE7fq1NdvUvcnzMsKUCYtuMmGCjWnXgHj5Vjv93VOnK7wqYVlS4aPbiQk/n4oELjchSSdRsTHdQbl1AmBn9hmBFAC1RXyfAiivokceT2tr9umQdAeGW6/DftrCQAh3ssZ3LDVv44mvlRJqEXxSisBpYMoRrs351BzbgfOSob8iGbnZPzK/DLtEu9kMFgVpesTWB4988tYWqUWEDqXsbRDt5UNcj2A6Lo2TivsCuMR9dO0dPh4Ro+VtBi0sIYA7WrsmOZwbvrdUy9MjTp4e1XxwJF/e/BdCLYEmXiIrVsCeQuDFiGtz1VjrThP3xZ9TLCTlmqj/OKICvsqrDz/QQOt6E0hMHL6Np5fr08DQPRnDrnUZM67rI0EtslfhJ1KQA5KzrH3ztoByfk8s6de/ck83mOJh5MJXpshvfoE3y/SLditUWKBTHhHxGomIKV+ann7UgWBSvmpdfO0gEF65lc0gJnxwVK8sfUeAZB5xg== x-ms-exchange-antispam-messagedata: 5EfpyuWiaLJ48JcxRlQjnQbKSjy5nWj0HCMB5vG5LxD6UeTZ8c+rPQXncIsm8knlJamkFprkLhqJ2jIdH+/bZzvdU9LK1KHtrwXngO+eC16kiKEb8vgzrYa/k6xZb/k3yCP1fjYy5K0b8kl+NNWVVA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB33186638A32A0AD2D30FF8C79BD40AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4360 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT044.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)(376002)(346002)(136003)(39860400002)(46966005)(82740400003)(47076004)(4326008)(7696005)(6862004)(26005)(316002)(86362001)(81166007)(336012)(356005)(6506007)(53546011)(186003)(9686003)(70586007)(55016002)(52536014)(8936002)(19627405001)(8676002)(5660300002)(70206006)(478600001)(966005)(33656002)(2906002)(81156014); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: ff67cf61-b37a-41e1-144d-08d7e51b6c2a X-Forefront-PRVS: 03793408BA X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nUZsK1wixAxWzrLFHrPUCExu2Jht10wtQ7PsgMaQJv45wfyDyImNvAQkmKJ2mC4eKrPqdEVu5mCCdzGxwGIl6wmN9kR43uSeJNIGfkR9Clt/kNyEPBQxbBBVh4XrNUWP8djx0vBdxIOio3YHU/92VoWoyR7WqBQVcPY5GzxT2c681KIyfQLhBpX0OaI0oaXUokiETq+/qIZ4B6z/VfI7a0yWzMullwJVjFpDUK7S4Phm7E7prZCP0NcwfxDQlxuFlBb5sCKPuQfN79nQ/6m/DLC0AJFdTWmDXzTbEA39+Pu4K2RDAOzPLheHZBpauiX491Wk6hmMkdiZrbTZgK6QoDGMqSC3+RQ+4kVTCtNks8I0/jI2Lsy7C7DhAjh4JDoixoH5WX3zv8kDpaGp2U73a4cLXwFxWnx029iUiD9k12rj9IcXN0vnv+SEm7FfiCzCmcOdB2hyNCz9mwGxl+GzkwB0yx6MJe0hrxa45RVsb2AeIWJcmiPi8X99tWq0/y1iB4gWevAiZSLQeMb9OJrD/xYa35qV1Mg7Ozor3j7E53OLHAnsB+PqSjztd9kN4nru7VC+jgwKOFp+SxmQ5emQrg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Apr 2020 11:10:31.2021 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7adef2c0-5c24-4ff9-d95b-08d7e51b7097 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: VI1PR08MB3902 Archived-At: Subject: Re: [TLS] Epochs for ACKs 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: Mon, 20 Apr 2020 11:10:50 -0000 --_000_AM6PR08MB33186638A32A0AD2D30FF8C79BD40AM6PR08MB3318eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ekr, Great, thanks, I left comments on that PR. Cheers, Hano ________________________________ From: Eric Rescorla Sent: Sunday, April 19, 2020 10:39 PM To: Hanno Becker Cc: tls@ietf.org Subject: Re: [TLS] Epochs for ACKs I have posted a PR to clarify this: https://github.com/tlswg/dtls13-spec/pu= ll/142 On Tue, Apr 14, 2020 at 1:13 AM Hanno Becker > wrote: Hi all, On ACK protection, DTLS 1.3 Draft 37 says in Section 7: ACK records MUST be sent with an epoch that is equal to or higher than the record which is being acknowledged. Implementations SHOULD simply use the current key. Since the update of incoming and outgoing keying material is independent, I don't know how this can be enforced: After a sequence of key updates, the incoming epoch might be 42 while the outgoing epoch is 17. What problems arise if one replaces the paragraph by the following: ACK records MUST be sent with the current key, irrespective of the epoch that is used to protect the record that is being acknowledged. It appears that the paragraph is particularly relevant for the case of ACKing a ServerHello, which as far as I understand shall happen with epoch 1. Since 'current key' doesn't appear unambiguously defined at the point of the client processing the ServerHello, it might be worth spelling out this case explicitly. Best, 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls 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_AM6PR08MB33186638A32A0AD2D30FF8C79BD40AM6PR08MB3318eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ekr,

Great, thanks, I left comments on that PR.

Cheers,
Hano
From: Eric Rescorla <ekr= @rtfm.com>
Sent: Sunday, April 19, 2020 10:39 PM
To: Hanno Becker <Hanno.Becker@arm.com>
Cc: tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] Epochs for ACKs
 
I have posted a PR to clarify this: https://github.com/tlswg/dtls13-spec/pull/142

On Tue, Apr 14, 2020 at 1:13 AM Han= no Becker <Hanno.Becker@arm.com<= /a>> wrote:
Hi all,

On ACK protec= tion, DTLS 1.3 Draft 37 says in Section 7:

  &= nbsp;ACK records MUST be sent with an epoch that is equal to or higher
  &= nbsp;than the record which is being acknowledged.  Implementations SHO= ULD
  &= nbsp;simply use the current key.

Since th= e update of incoming and outgoing keying material is
independ= ent, I don't know how this can be enforced: After a
sequence= of key updates, the incoming epoch might be 42 while
the outg= oing epoch is 17.

What pro= blems arise if one replaces the paragraph by the following:

  &= nbsp;ACK records MUST be sent with the current key, irrespective
  &= nbsp;of the epoch that is used to protect the record that is
   = being acknowledged.

It appears th= at the paragraph is particularly relevant for the case
of ACKing a S= erverHello, which as far as I understand shall happen
with epoch 1.= Since 'current key' doesn't appear unambiguously
defined at th= e point of the client processing the ServerHello, it
might be wort= h spelling out this case explicitly.

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_AM6PR08MB33186638A32A0AD2D30FF8C79BD40AM6PR08MB3318eurp_-- From nobody Mon Apr 20 07:27:05 2020 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 187E33A0787 for ; Mon, 20 Apr 2020 07:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com 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 oHloQrWCK49W for ; Mon, 20 Apr 2020 07:26:57 -0700 (PDT) Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (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 D6E7F3A0784 for ; Mon, 20 Apr 2020 07:26:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=5065; q=dns/txt; s=VRSN; t=1587392817; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=lYAxEYrNPPvJrvXGl062I7EZpkgHFu4I8d/mykNefWQ=; b=hf/pHQmHYjvZqy8GmEryU10VXJlhp5V5t3gozXFbQaKg0t5tS01t5X7R fh9m/rLm64IP9nB8UoVTjsDJPi+aNV8M2dXgPngzIcWdTm9MzAG68+RmU CzvlNWbFrdnSRP42/xiORqJNmybQybrjvvvKrTANjsVUaJqSJd3MPFFF6 m+aOeQRIFSAvwuSm97Q1Aw4jk40q2+U/DJWKCfGBN3spU9tlvivl4aDiG VllU3lzwMVtEFdyPnqEplip2tjPMb1Tn4gz8mGUDPEuP/9RAqRXM73OEA XArTRRDyaaa6SYBok+lRQ9YYk6EkHJWtNbSfJlJ3FDa51SebZtmuzxRdT g==; IronPort-SDR: KQ6ETag6ibMzoN7h0eR3qkCHJ/tgT7otWPvPFdJ+kYjCpj2PGHpwU8CbfN4GzfLYFFeqPvY8YU cGXYFTQn9VTvLc/tj72h8warxXBiQGniAS7peqRz7gocJeL5Y1xj/106rOXTCvJlsFm2L5piHT GORDI45yAgsXb5/qh2gu7MqG2o/CS1YyK7CBPfSF/YToSiDc3IhdKqpXG/dKDHbC7FvCegCMSu 9f+m6c1LGTi4nXiLASNsPDRUtln8I9FRvkH4RWctk1E0XwaMdmpRcrmKW4fk8pRQpfVBLxmN9/ jao= X-IronPort-AV: E=Sophos;i="5.72,406,1580792400"; d="scan'208";a="1168029" IronPort-PHdr: =?us-ascii?q?9a23=3APxjWohURQD97QcEdbs9mavDUMZrV8LGtZVwlr6?= =?us-ascii?q?E/grcLSJyIuqrYbB2Dt8tkgFKBZ4jH8fUM07OQ7/m9HzBbqsnd+DBaKdoQDk?= =?us-ascii?q?ND0Z1X1yUbQ+e7SmTDZMbwaCI7GMkQHHRExFqcdXZvJcDlelfJqWez5zNBUj?= =?us-ascii?q?/2NA5yO/inUtWK15f/2O+94YDcbBtVjzShf7xyMA+2rQLMvcUKnIduMKk8xg?= =?us-ascii?q?bJr3dSdOlby2xkKFCckh3h4su84INv/z5ftv48+MNMS7n2c7g9QbdFEDkoLm?= =?us-ascii?q?c56dHkuhXEUQaB/GYXXH8MkhpPDQjF7RX6UYn0vyDnqOdz2zSUMNPvQ7wsVj?= =?us-ascii?q?us86lkSBnziCcaLDE5633YitZxjK1Avh2soQF0zpPOb4GUMPp+eb7dfc8fSG?= =?us-ascii?q?FcUMtdSzBND4WhZIYJEuEPP/tXr5PlqlUOsxWwGBWsCu3sxD9JmnD40qI13v?= =?us-ascii?q?89EQHf3gwsA84CvGjKoNjzKawcUfq1zK7NzTjbYf9Y2zD96IzMch8/p/GDRq?= =?us-ascii?q?x/ftbSyUU3CgjLk0mfqYv5PzOJ2OgGrm+W7/FgVeKoj24nrx9+oj60ycgylo?= =?us-ascii?q?bJhZkYyk7a+iVjwYY1Pty4SEF9YdK+DJRQsCSaOpJwT8g/QG9ooD43xqAatZ?= =?us-ascii?q?KhYSQHypoqywTCZ/GHfYWE+B3uWeKJLTtlmH5pYq+zihSu/US61+HxWcq53E?= =?us-ascii?q?xXoidGitXMuG4C2h/P5sWCT/Zw/Fuu1SqV2A3W9+1LPVw7mK/bJpE83LEwmJ?= =?us-ascii?q?8evEDeESDrhkr7irKdeF8+9eiy8evnZ63rppqbN4BplA7zKr8umsmjAeQgNQ?= =?us-ascii?q?gOQnSb9fy81LL9+U35R61Hg+AqnKfBrZzVJdwVqKG4DANJzIov8Qi/ACuh0N?= =?us-ascii?q?QChXkLNkhKdw+dg4j3IVHOO/b4Ae2jjFSrlTdn3/HGPrv/DZXRNnXPjavtca?= =?us-ascii?q?xg50Nexgc/181T6pJaB70bL//+Xlf9tNnCAR84Nwy0zfznCNJ41o4GQmKPAq?= =?us-ascii?q?iZMKfWsVCW4OIgOPeDa5MWuDvmNfgq+eTujX4imV8ccqmp24EbZ2y/HvRjO0?= =?us-ascii?q?mZe2bjgs8dEWcWuQozVPLkhlufXzNIZna9Qb485j8hBIKhF4fDSdPlvLvUlh?= =?us-ascii?q?ufJbVXa3xITFeWHj2gI7mgYN8NZT6cZMh7nWpXe6KmTtpr9RaqsAL8wbdsLa?= =?us-ascii?q?6cwSYfqY6pnIxu5+rXkRw0/zF/DOyD3nuMVGB7mCUDQDpgj/M3mlB01lrWif?= =?us-ascii?q?swuPdfD9EGv/4=3D?= X-IPAS-Result: =?us-ascii?q?A2GBBABfsJ1e/zGZrQpmgkGBeIJZsG8KAQEBAQEBAQEBB?= =?us-ascii?q?wETHAQBAYZ6NwYOAgMBAQsBAQEFAQEBAQEFAwEBAQKGEwglC4I7IoQqGjcBG?= =?us-ascii?q?h4GQhcPAQQbtyGFT4UYgTiJbYJmgUI+gRGIBGeFIgSOUYkLmiUDB4JEBJdfJ?= =?us-ascii?q?ZxSj22cawIEAgQFAhWBaIF6cIM6TxgNjj2RY44pgQ+BEAEB?= Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 20 Apr 2020 10:26:25 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1913.005; Mon, 20 Apr 2020 10:26:25 -0400 From: "Hollenbeck, Scott" To: "TLS@ietf.org" Thread-Topic: Comments on draft-dt-tls-external-psk-guidance-01 Thread-Index: AdYXH6KSBS1BAI8XTwWXm/Rvqwo8MQ== Date: Mon, 20 Apr 2020 14:26:25 +0000 Message-ID: <5baf193953c94e3093fda66c8e3baa4d@verisign.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [TLS] Comments on draft-dt-tls-external-psk-guidance-01 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: Mon, 20 Apr 2020 14:27:04 -0000 Here are a few comments gathered from Verisign Labs on draft-dt-tls-externa= l-psk-guidance-01: 1. Sec. 6, requirement 1 states "Low entropy keys are only secure against= active attack if a Password Authenticated Key Exchange (PAKE) is used with= TLS." "only secure ... if" may be too strong a statement, because there c= ould be other mechanisms for increasing the entropy of a pre-shared key tha= t do not meet the formal definition of a PAKE. Moreover, as defined in dra= ft-barnes-tls-pake, a PAKE repurposes the DH key share to carry a transform= ed version of the EPSK, so it involves a different architecture than the or= dinary process for incorporating EPSKs into the TLS key schedule that is as= sumed in most of the present draft. If the goal of the present draft is to encompass PAKEs as well as the ordin= ary process, then the scope of the draft should be broadened to something l= ike "handshakes based on EPSKs, whether through the ordinary process of in= corporating them into the key schedule, or through alternate mechanisms suc= h as PAKE where the DH key share is based on the EPSK." Alternatively, the statement in requirement 1 could be rephrased as follows= : "If only low-entropy keys are available, then key establishment mechanisms = such as Password Authenticated Key Exchange (PAKE) that mitigate the risk o= f offline dictionary attacks MUST be employed. Note that these mechanisms = do not necessarily follow the same architecture as the ordinary process for= incorporating EPSKs described in this draft." 2. Sec. 6, requirement 2 states, "Each PSK MUST NOT be shared between with = more than two logical nodes." This "MUST NOT" is stronger than the "NOT RE= COMMENDED to share the same PSK between more than one client and server" In Sec. 7 and would exclude group PSK use cases that are acknowledged in th= at section. The requirement is also inconsistent with this statement in Ap= pendix B of draft-ietf-tls-external-psk-importer: "Applications which require authenticating finer-grained roles while still = configuring a single shared PSK across all nodes can resolve this mismatch = either by exchanging roles over the TLS connection after the handshake or b= y incorporating the roles of both the client and server into the IPSK conte= xt string." If the intent is to restrict use to at most two nodes, then requirement 2 s= hould go even further and restrict use to one node in a TLS client role, an= d one in a TLS server role. We would therefore suggest that requirement 2 be changed to something like = the following: "Unless other accommodations are made, each PSK MUST be restricted in its u= se to at most two logical nodes: one logical node in a TLS client role and= one logical node in a TLS server role. (The two logical nodes MAY be the = same, in different roles.) Two acceptable accommodations are described in = [draft-ietf-tls-external-psk-importer]: exchanging client and server ident= ifiers over the TLS connection after the handshake; and incorporating iden= tifiers for both the client and the server into the context string for an = EPSK importer." (Note that we've changed "roles" to "identifiers" to align with Sec. 7) Related to this, "logical node" should be defined somewhere, e.g., "For pur= poses of this document, a logical node is a computing presence that other p= arties can interact with via the TLS protocol. A logical node could potent= ially be realized with multiple physical instances operating under common a= dministrative control, e.g., a server farm." Alternatively, the term "endp= oint," which is used elsewhere in this document, could be used here as well= (perhaps also avoiding the single use of "agent"). 3. Sec. 7 recommends that that each node selects one globally unique ident= ifier for all PSK handshakes, but without giving rationale why this approac= h is preferred for mitigating the attacks mentioned earlier in the section.= This may be limiting, because a logical node may legitimately be known to= different endpoints by different identifiers: a domain name in some cases= , an IPv4 address in other cases, and an IPv6 address in still other cases.= We would therefore recommend relaxing this recommendation. 4. General. The draft makes no mention of certificate-based authenticatio= n in connection with EPSKs, for instance as described in in RFC 8773, "TLS = 1.3 Extension for Certificate-based Authentication with an External Pre-Sha= red Key." We understand that use of external PSKs with certificates is out= of scope for the design team. Certificate-based authentication, potential= ly in combination with a DH exchange, can improve the security properties o= f TLS handshakes based on EPSKs and help protect against both rerouting att= acks and impersonation attacks. Is there any interest in adding some guidi= ng text to the document before it's adopted by the WG? We're willing to pr= ovide text for consideration. Scott From nobody Mon Apr 20 10:25:47 2020 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 41F273A0BF2; Mon, 20 Apr 2020 10:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.191 X-Spam-Level: X-Spam-Status: No, score=-0.191 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com 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 tlua-PcFPw4M; Mon, 20 Apr 2020 10:25:28 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80081.outbound.protection.outlook.com [40.107.8.81]) (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 6458A3A0C31; Mon, 20 Apr 2020 10:23:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cdkz4DZfFKKvu+exKawTmWgpL+ZypjfD+GqqhyN0v0CUXTp+L+PzCOOqznSzG6fD69lUyACt//LtDKQJT1lUcz30Knej2kGWEowABW89G8OKBS10SmNP2qzBAunjPGoKtF8zmO6k1c9zUtHL+S9KnyUIeQan4shX5wFvUaZyu4hTOy1LhSAlPDFF6PklW8ZD8/0jzWXhMjoRgK3Pm9xYu5L94BHKhHcOpUSaI+Q4USrwZd9HLCcHcK2dtdzD9d+O4NeC8w0QobqEOxZZQf8tRT8p9mnp5R4u3eJERlWCVE0VMSmQ0RnDRsSwQHQfoqeGE/OVX0zeMWSyGf4B604a9A== 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=CpplTD0BcP1dpVlR6lXqCqKOuZWGWq1nZ5gNU1qz+Ko=; b=ACVqQS5J0yrteWyAAKbDgQ2p9ZBQPVcASmRrESYIO5jAa9B4k4GvJhlGAgq8nzkG3kW6Ki0pYIR3N2X22wrEGIRyBp9pVpUrYpbUCKQy8XSAvkOcX8fkBypecbxeQAX662PnQgH+pgONzLr1eg0yd1XPHVzQNTriKJzXEN4WoYP6wYE1Sdj5GNbLzE2CVrtTYbgM2YSWX4HlJbv1WqYMSlqDTYn31P+ECyquF8yQq8KKuspeu/nIL1iPbjtTO7LOn9QNy354S43iZ/RB4U16PO1MyIg75h0jjCN3UQPdaTzW+erCBUUIS9gxOym9EPkwMuKxIUP86xQhK0re8cqODg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CpplTD0BcP1dpVlR6lXqCqKOuZWGWq1nZ5gNU1qz+Ko=; b=oA+yBgH15xGjtzyRorVjLLja45MEoVUlUEv1C1Qa4O8g1fHXS0/LRs1jXyTgZxMXT+kP0kY+uYgsj+3GytBY2e2LLhqyboMZlgaxQ3A8L7kGi00fHbc4BU4iKCrLqn1X1/W+TWMaA26mt+S3R0puQuPJDXCR2kkoZUcHyC4nusc= Received: from AM6PR07MB4584.eurprd07.prod.outlook.com (2603:10a6:20b:17::24) by AM6PR07MB4983.eurprd07.prod.outlook.com (2603:10a6:20b:6b::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.10; Mon, 20 Apr 2020 17:23:21 +0000 Received: from AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::928:dc19:896b:4b91]) by AM6PR07MB4584.eurprd07.prod.outlook.com ([fe80::928:dc19:896b:4b91%6]) with mapi id 15.20.2937.011; Mon, 20 Apr 2020 17:23:21 +0000 From: John Mattsson To: Sean Turner CC: TLS List , "uta@ietf.org" , Hannes Tschofenig Thread-Topic: [Uta] [TLS] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS Thread-Index: AQHWDaeDkPpKX8oyt0iX3UQ9nri0DqhvOAaggAQC6gCADzwNAA== Date: Mon, 20 Apr 2020 17:23:21 +0000 Message-ID: <9EB552D5-B1C1-4768-8D83-D264E554B726@ericsson.com> References: <641927D7-CC49-4417-874E-12D44F6D6023@sn3rd.com> In-Reply-To: <641927D7-CC49-4417-874E-12D44F6D6023@sn3rd.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.35.20030802 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [81.225.97.222] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 847e78a8-31ef-4c01-c00a-08d7e54f862b x-ms-traffictypediagnostic: AM6PR07MB4983: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03793408BA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB4584.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(39860400002)(346002)(136003)(376002)(966005)(36756003)(66946007)(86362001)(44832011)(186003)(76116006)(91956017)(71200400001)(478600001)(66574012)(8936002)(8676002)(81156014)(5660300002)(316002)(6512007)(6486002)(6916009)(54906003)(2616005)(33656002)(2906002)(26005)(4326008)(53546011)(6506007)(66476007)(66556008)(64756008)(66446008); DIR:OUT; SFP:1101; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Y1hxgU76kML8GG9NWzKFCd6an710X73YASSgFE2Qkt9z4J1FXFfVb6CesaLE2kvj/KSw++Vd524QNwgaxIFRfHGosLme78sI25s3gL5OXUl/rJSQ2tqjJ2QMEmx/rIs/tVHpDOUwjGeR+VJAdUrMeCku/iKFHtags3HcO3CiKLG6SIad2yfjrbas3q+mMB7alPlIGhSI4SEkYcNSksJEn2a99XT8yrb5ndZzKJaLiwfZoTqaygqLj1s4SxyLdjfMntm1qsT+k8BZugOzwy/ix3kBhUW5r6OJ5n8N1fE1ylr3G5oeaT5SJE5jzLYhqThoeLnuoCcPAloqrIUVRBI85E046lYUC5atlQ1ZMEhEdB0Lk0HP5594JUsf8rGMO+QzqiVYtqtYU5k8AvLumfVCeCjsJky0APjxpBo/r/1T1KO6V+IWZh6Lc6gZZZup/VowylYSKqVgH7uO+3fdeBuZqz3VIqU/yESFzga9KWvUI8zDGfQVE6JJLDtEH+omUgHDPNsJ8HQMtiZeMmp6f78iFQ== x-ms-exchange-antispam-messagedata: ku2HSTkmaU+MbVLk3Y14eeMU1sDN1ytbEnTynfMRyrmmjGh4e/Plvuq67acl3vhL47CX9ohpAYCU8O1UZS1KF+VWSZIlnFl/8tx95KvcCiegtDt1KwLRyJkbNGtdrzFGdoHUcBA9wQg/ifaYtn/aeQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <754EAE79DDACBE47941CC8722A861E57@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 847e78a8-31ef-4c01-c00a-08d7e54f862b X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2020 17:23:21.1556 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: v7Gk7tWl60qbVnPTCi8XR1poJFdWKUDriKpGlSgwNnsW/AWWqth7Ks4RWL86z0nF0tElLGz+ors+q6tMbveub6+RAixrlUAK51z8umTu9/8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB4983 Archived-At: Subject: Re: [TLS] [Uta] CBOR Certificate Compression of RFC 7925 certificates suitable for cTLS 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: Mon, 20 Apr 2020 17:25:43 -0000 SGkgU2VhbiwNCg0KVGhlIGRvY3VtZW50cyAocGxhbm5lZCB0byBiZSByZXBsYWNlZCB3aXRoIGEg c2luZ2xlIGRvY3VtZW50KSBzcGVjaWZpZXMgYSBuZXcgY29tcHJlc3Npb24gYWxnb3JpdGhtIGFu ZCBtYWtlcyBhbiBJQU5BIHJlZ2lzdHJhdGlvbiBvZiB0aGF0IG5ldyBjb21wcmVzc2lvbiBhbGdv cml0aG0gZm9yIHVzZSB3aXRoIGRyYWZ0LWlldGYtdGxzLWNlcnRpZmljYXRlLWNvbXByZXNzaW9u LiBUaGUgZGlmZmVyZW5jZSBjb21wYXJlZCB0byB0aGUgYWxyZWFkeSByZWdpc3RlcmVkIGFsZ29y aXRobXMgKHpsaWIsIGJyb3RsaSwgenN0ZCkgaXMgdGhhdCB0aGUgbmV3IGFsZ29yaXRobSBvbmx5 IHdvcmtzIGZvciBhIHNwZWNpZmljIHN1YnNldCBvZiBSRkMgNTI4MCwgbmFtZWx5IFJGQyA3OTI1 Lg0KDQpDaGVlcnMsDQpKb2huDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBTZWFuIFR1cm5lciA8c2VhbkBzbjNyZC5jb20+DQpEYXRlOiBTYXR1cmRheSwgMTEgQXByaWwg MjAyMCBhdCAwNDo0NA0KVG86IEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNzb25AZXJpY3Nzb24u Y29tPg0KQ2M6ICJUTFNAaWV0Zi5vcmciIDx0bHNAaWV0Zi5vcmc+LCAidXRhQGlldGYub3JnIiA8 dXRhQGlldGYub3JnPiwgSGFubmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5j b20+DQpTdWJqZWN0OiBSZTogW1V0YV0gW1RMU10gQ0JPUiBDZXJ0aWZpY2F0ZSBDb21wcmVzc2lv biBvZiBSRkMgNzkyNSBjZXJ0aWZpY2F0ZXMgc3VpdGFibGUgZm9yIGNUTFMNCg0KICAgIC1oYXQN CiAgICANCiAgICBKb2huLA0KICAgIA0KICAgIFRoZXJlIGlzIGFscmVhZHkgYSBjZXJ0aWZpY2F0 ZSBjb21wcmVzc2lvbiBtZWNoYW5pc20gZGVmaW5lZCBpbiBkcmFmdC1pZXRmLXRscy1jZXJ0aWZp Y2F0ZS1jb21wcmVzc2lvbiwgd2hpY2ggaXMgY3VycmVudGx5IGluIHRoZSBSRkMgZWRpdG9y4oCZ cyBxdWV1ZS4gSG93IGRvIHRoZXNlIGRvY3VtZW50cyByZWxhdGUgdG8gdGhhdCBvbmU/DQogICAg DQogICAgc3B0DQogICAgDQogICAgPiBPbiBBcHIgOCwgMjAyMCwgYXQgMDk6MjksIEhhbm5lcyBU c2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPiB3cm90ZToNCiAgICA+IA0KICAg ID4gVGhhbmtzIGZvciB0aGUgaW5mbywgSm9obi4gSSB3aWxsIGhhdmUgYSBsb29rIGF0IHRoaXMg cHVibGljYXRpb24uDQogICAgPiANCiAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQog ICAgPiBGcm9tOiBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4NCiAg ICA+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgOCwgMjAyMCAzOjE0IFBNDQogICAgPiBUbzogSGFu bmVzIFRzY2hvZmVuaWcgPEhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb20+OyB0bHNAaWV0Zi5vcmc7 IHV0YUBpZXRmLm9yZw0KICAgID4gU3ViamVjdDogUmU6IFtUTFNdIENCT1IgQ2VydGlmaWNhdGUg Q29tcHJlc3Npb24gb2YgUkZDIDc5MjUgY2VydGlmaWNhdGVzIHN1aXRhYmxlIGZvciBjVExTDQog ICAgPiANCiAgICA+IEhpIEhhbm5lcywNCiAgICA+IA0KICAgID4gSSBoYXZlIHJlcXVlc3RlZCBh bmQgYmVlbiBhc3NpZ25lZCB0aW1lIGZvciBkcmFmdC1tYXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNv bXByZXNzLTAwIGFuZCBkcmFmdC1yYXphLWFjZS1jYm9yLWNlcnRpZmljYXRlcy0wNCBhdCB0aGUg VVRBIHZpcnR1YWwgaW50ZXJpbSBvbiBNYXJjaCAyMy4NCiAgICA+IA0KICAgID4gV2UgaGF2ZSBh biBpbXBsZW1lbnRhdGlvbiBvZiBodHRwczovL2xpbmsuc3ByaW5nZXIuY29tL2NoYXB0ZXIvMTAu MTAwNyUyRjk3OC0zLTMxOS05Mzc5Ny03XzE0IC8gZHJhZnQtcmF6YS1hY2UtY2Jvci1jZXJ0aWZp Y2F0ZXMtMDMsIGJ1dCB0aGUgY29kZSBpcyBub3Qgd3JpdHRlbiBpbiBhIHdheSBzbyB0aGF0IHRo ZSBjb21wcmVzc2lvbiBtZWNoYW5pc20gREVSLT4gQ0JPUiBjYW4gYmUgZXh0cmFjdGVkLiBUaGUg ZXhhbXBsZSBpbiBkcmFmdC1yYXphLWFjZS1jYm9yLWNlcnRpZmljYXRlcy0wNCB3YXMgY3JlYXRl ZCBieSBoYW5kIHdpdGggY2Jvci5tZS4gV2UgYXJlIHBsYW5uaW5nIHRvIGltcGxlbWVudCBhIHVw ZGF0ZWQgc3RhbmRhbG9uZSB2ZXJzaW9uIG9mIHRoZSBERVItPkNCT1IgY29tcHJlc3Npb24gYW5k IGhvcGVmdWxseSBoYXZlIGludGVyb3AgdGVzdGluZyBpbiB0aGUgQ09TRSBXRy4NCiAgICA+IA0K ICAgID4gQ2hlZXJzLA0KICAgID4gSm9obg0KICAgID4gDQogICAgPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KICAgID4gRnJvbTogVExTIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVo YWxmIG9mIEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPg0KICAg ID4gRGF0ZTogRnJpZGF5LCAzIEFwcmlsIDIwMjAgYXQgMTQ6MjANCiAgICA+IFRvOiBKb2huIE1h dHRzc29uIDxqb2huLm1hdHRzc29uPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPiwgIlRM U0BpZXRmLm9yZyIgPHRsc0BpZXRmLm9yZz4sICJ1dGFAaWV0Zi5vcmciIDx1dGFAaWV0Zi5vcmc+ DQogICAgPiBTdWJqZWN0OiBSZTogW1RMU10gQ0JPUiBDZXJ0aWZpY2F0ZSBDb21wcmVzc2lvbiBv ZiBSRkMgNzkyNSBjZXJ0aWZpY2F0ZXMgc3VpdGFibGUgZm9yIGNUTFMNCiAgICA+IA0KICAgID4g ICAgSGkgSm9obiwNCiAgICA+IA0KICAgID4gICAgVGhhbmtzIGZvciB0aGUgaGVhZHMtdXAuDQog ICAgPiANCiAgICA+ICAgIERpc2N1c3NpbmcgdGhpcyBhc3BlY3QgaW4gZHJhZnQtdHNjaG9mZW5p Zy11dGEtdGxzMTMtcHJvZmlsZS0wMSBtYWtlcyBzZW5zZS4NCiAgICA+IA0KICAgID4gICAgSSB3 YXMgd29uZGVyaW5nIHdoZXRoZXIgeW91IGhhdmUgYmVlbiB3b3JraW5nIG9uIGFuIGltcGxlbWVu dGF0aW9uIG9mIGRyYWZ0LW1hdHRzc29uLWNvc2UtY2Jvci1jZXJ0LWNvbXByZXNzLTAwIC8gZHJh ZnQtcmF6YS1hY2UtY2Jvci1jZXJ0aWZpY2F0ZXMtMDQuDQogICAgPiANCiAgICA+ICAgIENpYW8N CiAgICA+ICAgIEhhbm5lcw0KICAgID4gDQogICAgPiAgICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KICAgID4gICAgRnJvbTogVExTIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxm IE9mIEpvaG4gTWF0dHNzb24NCiAgICA+ICAgIFNlbnQ6IEZyaWRheSwgQXByaWwgMywgMjAyMCA5 OjAzIEFNDQogICAgPiAgICBUbzogVExTQGlldGYub3JnOyB1dGFAaWV0Zi5vcmcNCiAgICA+ICAg IFN1YmplY3Q6IFtUTFNdIENCT1IgQ2VydGlmaWNhdGUgQ29tcHJlc3Npb24gb2YgUkZDIDc5MjUg Y2VydGlmaWNhdGVzIHN1aXRhYmxlIGZvciBjVExTDQogICAgPiANCiAgICA+ICAgIEhpLA0KICAg ID4gDQogICAgPiAgICBEdXJpbmcgdGhlIENPU0UgdmlydHVhbCBpbnRlcmltIG1lZXRpbmcgeWVz dGVyZGF5LCB0aGVyZSB3YXMgYWdyZWVtZW50IHRoYXQgdGhlIENPU0Ugd29ya2luZyBncm91cCBz aG91bGQgd29yayBvbiBDQk9SIGNvbXByZXNzaW9uIG9mIFJGQyA3OTI1IHByb2ZpbGVkIFguNTA5 IGNlcnRpZmljYXRlcy4gVGhlIHdvcmsgd2lsbCBiZSBiYXNlZCBvbiBkcmFmdC1yYXphLWFjZS1j Ym9yLWNlcnRpZmljYXRlcyBhbmQgZHJhZnQtbWF0dHNzb24tY29zZS1jYm9yLWNlcnQtY29tcHJl c3MgYW5kIHRoZSB0d28gZHJhZnRzIHdpbGwgYmUgbWVyZ2VkLiBEb2luZyB0aGlzIHdvcmsgaW4g YSBzZWN1cml0eSBncm91cCBmb2N1c2VkIG9uIENCT1IgbWFrZXMgYSBsb3Qgb2Ygc2Vuc2UuDQog ICAgPiANCiAgICA+ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0c3Nv bi1jb3NlLWNib3ItY2VydC1jb21wcmVzcy0wMA0KICAgID4gICAgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXJhemEtYWNlLWNib3ItY2VydGlmaWNhdGVzLTA0DQogICAgPiANCiAg ICA+ICAgIFRoZSBDT1NFIGRyYWZ0IGNoYXJ0ZXIgaGFzIGFscmVhZHkgYmVlbiB1cGRhdGVkIHRv IHJlZmxlY3QgdGhpcy4NCiAgICA+IA0KICAgID4gICAgaHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXll LmNvbS92MS91cmw/az03YmIwNzFmNS0yNzY0NzQ0YS03YmIwMzE2ZS04NjhmNjMzZGJmMjUtMmUz ODQwNWIxYWY1NTUzNCZxPTEmZT1jZjA5MGM5ZC1lNmZjLTRkOTktODRiYy03MWFkMjNkOGE1MjQm dT1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZjb3NlLXdnJTJGQ2hhcnRlciUyRmJsb2IlMkZt YXN0ZXIlMkZDaGFydGVyLm1kDQogICAgPiANCiAgICA+ICAgIEFzIHRoZSBhbGdvcml0aG0gaXMg Zm9jdXNlZCBvbiBjb21wcmVzc2luZyBSRkMgNzkyNSBwcm9maWxlZCBjZXJ0aWZpY2F0ZXMsIEl0 IHNlZW1zIGxpa2UgYSB2ZXJ5IGdvb2QgbWF0Y2ggZm9yIGNUTFMuIFRvIGtlZXAgdGhlIG51bWJl ciBvZiBpbnRlcm5ldC1kcmFmdHMgZG93biwgSSBwbGFuIHRvIGFsc28gaW5jbHVkZSB0aGUgVExT IElBTkEgcmVnaXN0cmF0aW9ucyBpbiB0aGUgbWVyZ2VkIGRyYWZ0IHN1Ym1pdHRlZCB0byB0aGUg Q09TRSBXRyBhbmQgbGV0IGRyYWZ0LW1hdHRzc29uLXRscy1jYm9yLWNlcnQtY29tcHJlc3MtMDAg ZXhwaXJlLg0KICAgID4gDQogICAgPiAgICBBbnkgY29tbWVudHMgZnJvbSB0aGUgVExTIFdHIGFy ZSB2ZXJ5IHdlbGNvbWUsIGJ1dCBvdGhlcndpc2UgdGhlc2UgaXMgbm90IHNvIG11Y2ggdG8gZGlz Y3VzcywgdGhpcyBpcyBqdXN0IGFub3RoZXIgY2VydGlmaWNhdGUgY29tcHJlc3Npb24gYWxnb3Jp dGhtLiBBbnkgVExTIHJlbGF0ZWQgZGlzY3Vzc2lvbnMgd291bGQgbGlrZWx5IGJlIHJlZ2FyZGlu ZyB0aGUgY2VydGlmaWNhdGUgcHJvZmlsZSBpbiBSRkMgNzkyNSBhbmQgaWYgYW55IGNsYXJpZmlj YXRpb25zIG9yIHVwZGF0ZXMgYXJlIG5lZWRlZC4gVGhpcyBpcyBsaWtlbHkgYmVzdCBkaXNjdXNz ZWQgaW4gVVRBIHdoaWNoIG1heSB0YWtlIHVwIHdvcmsgb24gYSBUTFMvRFRMUyAxLjMgdXBkYXRl IG9mIFJGQyA3OTI1Lg0KICAgID4gDQogICAgPiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtdHNjaG9mZW5pZy11dGEtdGxzMTMtcHJvZmlsZS0wMQ0KICAgID4gDQogICAgPiAg ICBDaGVlcnMsDQogICAgPiAgICBKb2huDQogICAgPiANCiAgICA+ICAgIC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQogICAgPiAgICBGcm9tOiBKb2huIE1hdHRzc29uIDxqb2huLm1hdHRzc29u QGVyaWNzc29uLmNvbT4NCiAgICA+ICAgIERhdGU6IFRodXJzZGF5LCAxMiBNYXJjaCAyMDIwIGF0 IDA4OjU4DQogICAgPiAgICBUbzogIlRMU0BpZXRmLm9yZyIgPFRMU0BpZXRmLm9yZz4NCiAgICA+ ICAgIENjOiAidXRhQGlldGYub3JnIiA8dXRhQGlldGYub3JnPg0KICAgID4gICAgU3ViamVjdDog Rlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWF0dHNzb24tdGxzLWNib3It Y2VydC1jb21wcmVzcy0wMC50eHQNCiAgICA+IA0KICAgID4gICAgICAgIEhpLA0KICAgID4gDQog ICAgPiAgICAgICAgV2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgdG8gVExTIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNvbXByZXNz LTAwIFRoZSBkcmFmdCByZWdpc3RlciBhIG5ldyBjb21wcmVzc2lvbiBhbGdvcml0aG1zIGZvciB1 c2Ugd2l0aCBUTFMgQ2VydGlmaWNhdGUgQ29tcHJlc3Npb24gaW4gVExTIDEuMyBhbmQgRFRMUyAx LjMgKGRyYWZ0LWlldGYtdGxzLWNlcnRpZmljYXRlLWNvbXByZXNzaW9uKS4NCiAgICA+IA0KICAg ID4gICAgICAgIFRoZSBkcmFmdCB1c2VzIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1yYXphLWFjZS1jYm9yLWNlcnRpZmljYXRlcy0wNCB0byBjb21wcmVzcyBSRkMgNzkyNSBwcm9m aWxlcyBjZXJ0aWZpY2F0ZXMgYnkgZW5jb2RpbmcgdGhlbSBmcm9tIERFUiB0byBDQk9SLiBUaGUg YWltIGlzIHRvIGJlIGNvbXBhdGlibGUgd2l0aCBhbGwgUkZDIDc5MjUgcHJvZmlsZWQgY2VydGlm aWNhdGVzLiBXaXRoIHRoZSBpbmNsdWRlZCBleGFtcGxlIERFUiBlbmNvZGVkIFJGQyA3OTI1IGNl cnRpZmljYXRlIHRvIGNlcnRpZmljYXRlIGlzIGNvbXByZXNzZWQgZnJvbSAzMTQgdG8gMTM2IGJ5 dGVzLCBhIGNvbXByZXNzaW9uIHJhdGUgb2YgNTclLg0KICAgID4gDQogICAgPiAgICAgICAgVGhl IGdlbmVyYWwgcHVycG9zZSBjb21wcmVzc2lvbiBhbGdvcml0aG1zIGRlZmluZWQgaW4gZHJhZnQt aWV0Zi10bHMtY2VydGlmaWNhdGUtY29tcHJlc3Npb24gZG8gbm90IHNlZW0gYWJsZSB0byBjb21w cmVzcyBwcm9maWxlZCBSRkMgNzkyNSBYLjUwOSBjZXJ0aWZpY2F0ZXMgbXVjaCBhdCBhbGwuIHps aWIgY29tcHJlc3NlZCB0aGUgZXhhbXBsZSBjZXJ0IDklLCBidXQgZm9yIG90aGVyIGNlcnRpZmlj YXRlcyB3ZSB0ZXN0ZWQsIHpsaWIgZGlkIGluIG1hbnkgY2FzZXMgbm90IHByb3ZpZGUgYW55IGNv bXByZXNzaW9uIGF0IGFsbC4NCiAgICA+IA0KICAgID4gICAgICAgIFdlIGhhdmUgc3VibWl0dGVk IGEgc2ltaWxhciBkcmFmdCB0byB0aGUgQ09TRSBXRyByZWdpc3RlcmluZyBhIG5ldyBhbGdvcml0 aG1zIGZvciB0aGUgVExTIDEuMyBjZXJ0aWZpY2F0ZSBjb21wcmVzc2lvbiBleHRlbnNpb24uDQog ICAgPiANCiAgICA+ICAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWF0 dHNzb24tdGxzLWNib3ItY2VydC1jb21wcmVzcy0wMA0KICAgID4gDQogICAgPiAgICAgICAgQ2hl ZXJzLA0KICAgID4gICAgICAgIEpvaG4NCiAgICA+IA0KICAgID4gICAgICAgIC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQogICAgPiAgICAgICAgRnJvbTogImludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyIgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCiAgICA+ICAgICAgICBEYXRlOiBNb25k YXksIDkgTWFyY2ggMjAyMCBhdCAyMToxOQ0KICAgID4gICAgICAgIFRvOiBKb2huIE1hdHRzc29u IDxqb2huLm1hdHRzc29uQGVyaWNzc29uLmNvbT4sIEpvaG4gTWF0dHNzb24gPGpvaG4ubWF0dHNz b25AZXJpY3Nzb24uY29tPiwgSm9lbCBIw7ZnbHVuZCA8am9lbC5ob2dsdW5kQHJpLnNlPiwgSm9l bCBIb2dsdW5kIDxqb2VsLmhvZ2x1bmRAcmkuc2U+LCBHw7ZyYW4gU2VsYW5kZXIgPGdvcmFuLnNl bGFuZGVyQGVyaWNzc29uLmNvbT4sIE1hcnRpbiBGdXJ1aGVkIDxtYXJ0aW4uZnVydWhlZEBuZXh1 c2dyb3VwLmNvbT4sIEfDtnJhbiBTZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29t PiwgU2hhaGlkIFJhemEgPHNoYWhpZC5yYXphQHJpLnNlPg0KICAgID4gICAgICAgIFN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWF0dHNzb24tdGxzLWNib3ItY2Vy dC1jb21wcmVzcy0wMC50eHQNCiAgICA+IA0KICAgID4gDQogICAgPiAgICAgICAgICAgIEEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tYXR0c3Nvbi10bHMtY2Jvci1jZXJ0LWNvbXByZXNzLTAw LnR4dA0KICAgID4gICAgICAgICAgICBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IEpvaG4gUHJldXNzIE1hdHRzc29uIGFuZCBwb3N0ZWQgdG8gdGhlDQogICAgPiAgICAgICAgICAg IElFVEYgcmVwb3NpdG9yeS4NCiAgICA+IA0KICAgID4gICAgICAgICAgICBOYW1lOmRyYWZ0LW1h dHRzc29uLXRscy1jYm9yLWNlcnQtY29tcHJlc3MNCiAgICA+ICAgICAgICAgICAgUmV2aXNpb246 MDANCiAgICA+ICAgICAgICAgICAgVGl0bGU6Q0JPUiBDZXJ0aWZpY2F0ZSBBbGdvcml0aG0gZm9y IFRMUyBDZXJ0aWZpY2F0ZSBDb21wcmVzc2lvbg0KICAgID4gICAgICAgICAgICBEb2N1bWVudCBk YXRlOjIwMjAtMDMtMDkNCiAgICA+ICAgICAgICAgICAgR3JvdXA6SW5kaXZpZHVhbCBTdWJtaXNz aW9uDQogICAgPiAgICAgICAgICAgIFBhZ2VzOjYNCiAgICA+ICAgICAgICAgICAgVVJMOiAgICAg ICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYXR0c3Nv bi10bHMtY2Jvci1jZXJ0LWNvbXByZXNzLTAwLnR4dA0KICAgID4gICAgICAgICAgICBTdGF0dXM6 ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWF0dHNzb24t dGxzLWNib3ItY2VydC1jb21wcmVzcy8NCiAgICA+ICAgICAgICAgICAgSHRtbGl6ZWQ6ICAgICAg IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYXR0c3Nvbi10bHMtY2Jvci1jZXJ0 LWNvbXByZXNzLTAwDQogICAgPiAgICAgICAgICAgIEh0bWxpemVkOiAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LW1hdHRzc29uLXRscy1jYm9yLWNlcnQt Y29tcHJlc3MNCiAgICA+IA0KICAgID4gDQogICAgPiAgICAgICAgICAgIEFic3RyYWN0Og0KICAg ID4gICAgICAgICAgICAgICBDZXJ0aWZpY2F0ZSBjaGFpbnMgb2Z0ZW4gdGFrZSB1cCB0aGUgbWFq b3JpdHkgb2YgdGhlIGJ5dGVzDQogICAgPiAgICAgICAgICAgICAgIHRyYW5zbWl0dGVkIGluIFRM UyBoYW5kc2hha2VzLiAgTGFyZ2UgaGFuZHNoYWtlcyBjYW4gY2F1c2UgcHJvYmxlbXMsDQogICAg PiAgICAgICAgICAgICAgIHBhcnRpY3VsYXJseSBpbiBjb25zdHJhaW5lZCBJb1QgZW52aXJvbm1l bnRzLiAgUkZDIDc5MjUgZGVmaW5lcyBhIFRMUw0KICAgID4gICAgICAgICAgICAgICBjZXJ0aWZp Y2F0ZSBwcm9maWxlIGZvciBjb25zdHJhaW5lZCBJb1QuICBHZW5lcmFsIHB1cnBvc2UgY29tcHJl c3Npb24NCiAgICA+ICAgICAgICAgICAgICAgYWxnb3JpdGhtcyBjYW4gaW4gbWFueSBjYXNlcyBu b3QgY29tcHJlc3MgUkZDIDc5MjUgcHJvZmlsZWQNCiAgICA+ICAgICAgICAgICAgICAgY2VydGlm aWNhdGVzIGF0IGFsbC4gIEJ5IHVzaW5nIHRoZSBmYWN0IHRoYXQgdGhlIGNlcnRpZmljYXRlcyBh cmUNCiAgICA+ICAgICAgICAgICAgICAgcHJvZmlsZWQsIHRoZSBDQk9SIGNlcnRpZmljYXRlIGNv bXByZXNzaW9uIGFsZ29yaXRobXMgY2FuIGluIG1hbnkNCiAgICA+ICAgICAgICAgICAgICAgY2Fz ZXMgY29tcHJlc3MgUkZDIDc5MjUgcHJvZmlsZWQgY2VydGlmaWNhdGVzIHdpdGggb3ZlciA1MCUu IFRoaXMNCiAgICA+ICAgICAgICAgICAgICAgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBDQk9SIGNl cnRpZmljYXRlIGNvbXByZXNzaW9uIGFsZ29yaXRobSBmb3IgdXNlDQogICAgPiAgICAgICAgICAg ICAgIHdpdGggVExTIENlcnRpZmljYXRlIENvbXByZXNzaW9uIGluIFRMUyAxLjMgYW5kIERUTFMg MS4zLg0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiAgICAgICAgICAgIFBs ZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0 aW1lIG9mIHN1Ym1pc3Npb24NCiAgICA+ICAgICAgICAgICAgdW50aWwgdGhlIGh0bWxpemVkIHZl cnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICA+IA0K ICAgID4gICAgICAgICAgICBUaGUgSUVURiBTZWNyZXRhcmlhdA0KICAgID4gDQogICAgPiANCiAg ICA+IA0KICAgID4gDQogICAgPiANCiAgICA+IA0KICAgID4gICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ICAgIFRMUyBtYWlsaW5nIGxpc3QN CiAgICA+ICAgIFRMU0BpZXRmLm9yZw0KICAgID4gICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90bHMNCiAgICA+ICAgIElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50 cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQg bWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lw aWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlz Y2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1 cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRo YW5rIHlvdS4NCiAgICA+ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgPiAgICBUTFMgbWFpbGluZyBsaXN0DQogICAgPiAgICBUTFNAaWV0Zi5v cmcNCiAgICA+ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQog ICAgPiANCiAgICA+IA0KICAgID4gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRo aXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxz byBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0 aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwg b3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91 Lg0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICA+IFV0YSBtYWlsaW5nIGxpc3QNCiAgICA+IFV0YUBpZXRmLm9yZw0KICAgID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91dGENCiAgICANCiAgICANCg0K From nobody Mon Apr 20 12:18:44 2020 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 1CA133A0CEE for ; Mon, 20 Apr 2020 12:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.699 X-Spam-Level: X-Spam-Status: No, score=-15.699 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com 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 u8ESrONELVLt for ; Mon, 20 Apr 2020 12:18:41 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13F7B3A0CE4 for ; Mon, 20 Apr 2020 12:18:41 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id k133so9834935oih.12 for ; Mon, 20 Apr 2020 12:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=nGUhbiVPWk51sFeClwXwBC6NO7vxcRyhM6bALbcL1NA=; b=ulXVkAdN7X3hJK2ZtHNVxtEzY0bTgkXZTo7o1R6kYQ9wEWlu6Jvwr5I+4TF/ZkKcdZ DB6CX8HTAYk//3QtbEfv2ZX6ak97kcPw2l7BdHfkC0Xk57JIO/pVecExuBOEpVT8XkmK 4OrxAZD9zaY7rRBkFAGBPvaDRPmC5pzesXuVJ+9xlnlxlyO2UY+4u1ATKPRSTxbvks9K iNDelhN22R1XZHD4QeOOlSY5eG3P4o55J8cGGikjL4/cnyDMo4yiSx/F56+IlHEQcKER Mgg518f3UNIHtSRNlfhdFFttOAkh7LeWi3w6Z3SIN3OLpHdrPbp+PBJH4t81YmiZI7r5 8ukw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=nGUhbiVPWk51sFeClwXwBC6NO7vxcRyhM6bALbcL1NA=; b=OadD7kMbIzKDzhUqQGVOpG+JBGwUfVeYeaxyUCLeSWbntjfpJ9XK1rrfDs9zJWkad2 8+l7N7EsWyQIs/w9/Z2FC5uxLeOxmwpDKqpK8EMk2btogj5WuGIcMjHKU6DgQL+S3qnx uMiJxPzMInqBcZh9NjwZUAPUbjqgR2s85wtN0nZQ8hsac0815IG8INo3iuzLnq+G8xy6 /lEZDDVB+MbGwFkO1nkGMmebINnHwJuJCxXOif/jPGppokyY+xlvrIM63v0NWvqVuUEB fKeKSeioTQ5rHBq0FpQhDxbxiL7Uuk4ZYu6SOs6ijL6fXJbJ2TwfqkTD8KGveyd8QdLS maVg== X-Gm-Message-State: AGi0PuajICLDT7CU72o0yxIA/eaVF/Mql4vLz1qQtrMMSbu7nVK81es6 XrSd6PWJkeR8xfVHmCaSKh3rUG27UYocF+bsZUx2w9tQ X-Google-Smtp-Source: APiQypL5BKq/xUEVhfeU5gRfk429gRCJKjW36qh0TTH5WQpf/2SxgoKhnL+Dqth6sqcTRyaulzAOSk/hYOmB68d42UY= X-Received: by 2002:aca:b8c5:: with SMTP id i188mr694459oif.2.1587410319713; Mon, 20 Apr 2020 12:18:39 -0700 (PDT) MIME-Version: 1.0 References: <20200419222318.GY41308@straasha.imrryr.org> <20200419230623.GZ41308@straasha.imrryr.org> In-Reply-To: <20200419230623.GZ41308@straasha.imrryr.org> From: Nick Harper Date: Mon, 20 Apr 2020 12:18:28 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="0000000000003885d105a3bdc415" Archived-At: Subject: Re: [TLS] Ticket request PR#20 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: Mon, 20 Apr 2020 19:18:43 -0000 --0000000000003885d105a3bdc415 Content-Type: text/plain; charset="UTF-8" On Sun, Apr 19, 2020 at 4:06 PM Viktor Dukhovni wrote: > On Sun, Apr 19, 2020 at 03:41:49PM -0700, Eric Rescorla wrote: > > > I don't think we should make this change. In the context of this draft, > if > > the client wants that behavior, it should send {1, 1}. > > That precludes clients from soliciting 0 *only* from servers that > support some future specification, and otherwise getting 1 from > servers that support only the current specification. > That's not true. Suppose there's some future specification FOOBAR that a client and server might support, and the client wants a resumption_count of 0 when the server supports FOOBAR and 1 if the server doesn't support FOOBAR. The apparent problem is that the client doesn't know whether the server supports FOOBAR when it writes its resumption_count value. It's true that the client doesn't know whether the server supports FOOBAR on its first connection to the server, but on that connection, the value of resumption_count is irrelevant. On future connections, the client can condition resumption_count based on whether FOOBAR was supported on the connection that the resumption ticket came from. > > Such clients are not looking for a static server behaviour, but > rather need only certain servers to return 0, and the rest > to return 1. > > In any case, if sending 1 or more unconditionally was fine for RFC8446 > (e.g. per the text in C.4) it is hard to imagine why it is suddenly so > important to insist that the server be able to send 0 when receiving > {1, 0} or {0, 1}. > > Servers that don't support this new extension at all will send 1 (or > more). So it is clearly not a big deal also for servers that do > support it to do likewise. > > Since there is no specific *use-case* for {1, 0} to mean 0 at present, > that couldn't also be handled by sending {0, 0}, there is no reason > to stand in the way of defining {1, 0} to be a solicitation for at > least 1 ticket regardless of the handshake type. > > The only objection that makes sense is a blocking tactic to preclude > potential future refinement of this draft to support reuse, but surely > blocking that evolution can be deferred to the discussion of the > (misguided?) I-D that proposes it. > My take on this PR is that it unnecessarily complicates the ticketrequest draft. As currently specified, the two values do what they say on the tin; with this PR there's an extra weird edge case. This complication is unnecessary based on my above description of how the FOOBAR spec can extend it. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000003885d105a3bdc415 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Apr 19, 2020 at 4:06 PM Vikto= r Dukhovni <ietf-dane@dukhovni= .org> wrote:
On Sun, Apr 19, 2020 at 03:41:49PM -0700, Eric Rescorla wrote:

> I don't think we should make this change. In the context of this d= raft, if
> the client wants that behavior, it should send {1, 1}.

That precludes clients from soliciting 0 *only* from servers that
support some future specification, and otherwise getting 1 from
servers that support only the current specification.
<= br>
That's not true. Suppose there's some future specific= ation FOOBAR that a client and server might support, and the client wants a= resumption_count of 0 when the server supports FOOBAR and 1 if the server = doesn't support FOOBAR. The apparent problem is that the client doesn&#= 39;t know whether the server supports FOOBAR when it writes its resumption_= count value. It's true that the client doesn't know whether the ser= ver supports FOOBAR on its first connection to the server, but on that conn= ection, the value of resumption_count is irrelevant. On future connections,= the client can condition resumption_count based on whether FOOBAR was supp= orted on the connection that the resumption ticket came from.=C2=A0

Such clients are not looking for a static server behaviour, but
rather need only certain servers to return 0, and the rest
to return 1.

In any case, if sending 1 or more unconditionally was fine for RFC8446
(e.g. per the text in C.4) it is hard to imagine why it is suddenly so
important to insist that the server be able to send 0 when receiving
{1, 0} or {0, 1}.

Servers that don't support this new extension at all will send 1 (or more).=C2=A0 So it is clearly not a big deal also for servers that do
support it to do likewise.

Since there is no specific *use-case* for {1, 0} to mean 0 at present,
that couldn't also be handled by sending {0, 0}, there is no reason
to stand in the way of defining {1, 0} to be a solicitation for at
least 1 ticket regardless of the handshake type.

The only objection that makes sense is a blocking tactic to preclude
potential future refinement of this draft to support reuse, but surely
blocking that evolution can be deferred to the discussion of the
(misguided?) I-D that proposes it.

My t= ake on this PR is that it unnecessarily complicates the ticketrequest=C2=A0= draft. As currently specified, the two values do what they say on the tin; = with this PR there's an extra weird edge case. This complication is unn= ecessary based on my above description of how the FOOBAR spec can extend it= .

--
=C2=A0 =C2=A0 Viktor.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000003885d105a3bdc415-- From nobody Mon Apr 20 12:28:57 2020 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 0C37A3A0DAC for ; Mon, 20 Apr 2020 12:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 76qrcTaIm3ze for ; Mon, 20 Apr 2020 12:28:43 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (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 A32593A0DC5 for ; Mon, 20 Apr 2020 12:28:43 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 9A32B1AA2AF; Mon, 20 Apr 2020 15:28:41 -0400 (EDT) Date: Mon, 20 Apr 2020 15:28:41 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20200420192841.GB41308@straasha.imrryr.org> Reply-To: tls@ietf.org References: <20200419222318.GY41308@straasha.imrryr.org> <20200419230623.GZ41308@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: Subject: Re: [TLS] Ticket request PR#20 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: Mon, 20 Apr 2020 19:28:56 -0000 On Mon, Apr 20, 2020 at 12:18:28PM -0700, Nick Harper wrote: > > That precludes clients from soliciting 0 *only* from servers that > > support some future specification, and otherwise getting 1 from > > servers that support only the current specification. > > > > That's not true. Suppose there's some future specification FOOBAR that a > client and server might support, and the client wants a resumption_count of > 0 when the server supports FOOBAR and 1 if the server doesn't support > FOOBAR. The apparent problem is that the client doesn't know whether the > server supports FOOBAR when it writes its resumption_count value. It's true > that the client doesn't know whether the server supports FOOBAR on its > first connection to the server, but on that connection, the value of > resumption_count is irrelevant. On future connections, the client can > condition resumption_count based on whether FOOBAR was supported on the > connection that the resumption ticket came from. Yes, that mostly works, but it will require a second extension (which would otherwise not be needed), and assumes that the *same* server software is doing the resumption as issued the initial ticket. That'll generally be true I guess, but is not guaranteed. In a load-balanced pool of servers, support for FOOBAR may not be universal. > My take on this PR is that it unnecessarily complicates the > ticketrequest draft. As currently specified, the two values do what > they say on the tin; with this PR there's an extra weird edge case. > This complication is unnecessary based on my above description of how > the FOOBAR spec can extend it. The "complexity" involved is exceedingly minimal, and introducing a second extension FOOBAR to modify the meaning of this extension is rather more complex. I'd like to have an opportunity to propose a later refinement of this specication to give a new meaning for {1,0} in this extension, without requiring any new FOOBAR extension. So my hope is that the case for {1,0} -> 0 tickets on resumption is rather weak, and {1,0} -> 1 is cheap enough to make it a reasonable compromise. -- Viktor. From nobody Tue Apr 21 05:54:16 2020 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 8DEBE3A0B88 for ; Tue, 21 Apr 2020 05:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=Bg6mAJ1n; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oXK2FFaw 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 iuN-IqqK-MQD for ; Tue, 21 Apr 2020 05:54:11 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ACB93A0B84 for ; Tue, 21 Apr 2020 05:54:10 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4DB5D5C0198 for ; Tue, 21 Apr 2020 08:54:10 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 21 Apr 2020 08:54:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=R0p6nsqbi8hfxGh1PH2JxJrbJ4dCuwe f8eQl5IWV7SQ=; b=Bg6mAJ1nDIczracPMc9MydgaJTthARtjChxs/JD+710P7RY 9v2giJXioco+2k5FYBTpizGxABdRVi+X+fJs5SG9dWUX3x33vxbgi2fupWXAAeGT 3LtTJ9qDEu+J0fBgJW1AESQgt/+croagE768StQBJ8i5XThBRUBxIzDQ6Sq9RRRR +Tk456gBaidBIcQtrm+suFLBiUTK/NaKk4l3J+TOD85akqTZVSasisgY7byCtwVr JFYGdiJIOTrhTHyoz7YpsKWDR05JhyM/qpmYao/wGC964PZntfi2f/cjEKaI4lmQ 49DBpWpgrEmAve59Gb0v9By3eTiF0Ykist19QNA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=R0p6ns qbi8hfxGh1PH2JxJrbJ4dCuwef8eQl5IWV7SQ=; b=oXK2FFawhFVglnkFUptXmM xzZkg/+43L9DO8b5UUq0OUHhG9/C8kgknE+2jUh2zw1V82oY0e/Q/qdKNg4hYSLJ QduW9N3kPoc/rKN5qbHGkciFS9dqDRoCyfJ7IHnHwjdPOShBZs6DqJKs0Ue+VkCj KcC5gFFi3F7l1SGkf3rL1UsREu6GQO0vpfA8PERzTrhvDOD0cWrwlMy5/R7L/x77 D12+IbxO+tPkGK1vk4OdiLiAFOB5KRJ/EJ0iHJlK468aAVsYmJNBFRj4X2IWDsGX RwViEv2+07wYnWOfUWopA8oh4Yfu7FONwOkN6b5o9xdAEuStNaWH97cD6QWKYgcQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeehgdehiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpgh hithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0FB37180091; Tue, 21 Apr 2020 08:54:10 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-1152-g08c8976-fmstable-20200420v1 Mime-Version: 1.0 Message-Id: <9051bc64-b116-490a-9465-2cbb26be5217@www.fastmail.com> In-Reply-To: <3aab08b9-d979-4952-85f6-62e993f6fb4b@www.fastmail.com> References: <3aab08b9-d979-4952-85f6-62e993f6fb4b@www.fastmail.com> Date: Tue, 21 Apr 2020 05:53:41 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] WGLC for "A Flags Extension for TLS 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: Tue, 21 Apr 2020 12:54:14 -0000 This WGLC is now complete. We need more reviews, and likely a bit more work, before moving this ahead. We'll run another WGLC once we have both. Yoav, can you please have a look at the comments and concerns raised below and address them as needed? Thanks, Chris, on behalf of the chairs On Mon, Apr 6, 2020, at 3:39 PM, Martin Thomson wrote: > I like this work, but I don't believe this to be ready yet. > > S1 > None of the current proposed extensions are such that the server > indicates support without the client first indicating support. So as > not to preclude future extensions that are so defined, this > specification allows the client to send an empty extension, > indicating support for TLS flags in general (and presumably some > unspecified features in particular). > > First, for clarification, the distinction between empty and > all-zero-valued is perhaps worth drawing on. Second, more seriously, > if this is the goal, the text needs to acknowledge that the possibility > exists on a *per-flag* basis. > > Third, more substantially, and invalidating the above, I don't think > that we should make flags introduce a new style of negotiation just > because it can. I would strongly prefer that this function as close as > possible to "empty ClientHello extension; empty EncryptedExtensions > extension". Aside from that, the utility of an advertisement from the > server that a client cannot respond to is pretty marginal. > > Fourth, this conflicts with the following text in S2: > > A server that supports this extension and also supports at least one > of the flag-type features that use this extension and that were > declared by the ClientHello extension SHALL send this extension with > the intersection of the flags it supports with the flags declared by > the client. > > Nit here: this isn't about support alone, it is the flags that the > server *chooses* to support. > > S2 > The server may need to send two tls_flags extensions, > one in the ServerHello and the other in the EncryptedExtensions > message. > > Are we confident that sending the same extension in both places is > safe? I know that clients have to implement this and so should be able > to test that this works, but it seems awkward. And it might not be > necessary. It's also not sufficient, as we currently allow responses > to ClientHello extensions to appear in Certificate (and for > CertificateRequest to carry "requests" in the other direction). > > Perhaps we might avoid this problem entirely. ServerHello extensions > are limited to key exchange. If we say that flags are limited (today) > to functional properties that don't affect key exchange, my thought is > that we don't lose much (if anything) by only allowing this extension > in EncryptedExtensions. > > I don't know what I think about Certificate extensions. This seems to > have a clear use there. > > Editorial: > > S1 > It might be better to draw examples from the canon of published RFCs > than to refer to things that might not get published. > > On Tue, Apr 7, 2020, at 00:53, Christopher Wood wrote: > > This is the working group last call for the "A Flags Extension for TLS > > 1.3" draft, available at: > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ > > > > Please review the document and send your comments to the list by April > > 20, 2020. The GitHub repository for this draft is available at: > > > > https://github.com/tlswg/tls-flags > > > > Thanks, > > Chris, on behalf of the chairs > > > > _______________________________________________ > > 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 > From nobody Tue Apr 21 06:58:11 2020 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 011913A0CE7 for ; Tue, 21 Apr 2020 06:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com 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 PwqidsfQ2Tdo for ; Tue, 21 Apr 2020 06:58:08 -0700 (PDT) Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 EF31E3A0CE6 for ; Tue, 21 Apr 2020 06:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=7277; q=dns/txt; s=VRSN; t=1587477482; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=EYEN/fSzd3Hlqpp/yEj2GtilPwfjyaLtWl4zvtod4LY=; b=Fyt7qAz33NhtoV4smQNFwocpxETdG04gN0EG85lZ+KeKilHlnkpTLt50 eXx0xhrVw1oABm9XvMRoZxbiUnCi03aODYu2g2KEN9FjjLyGb5PVn8jk3 0NWwLYFmmbGC6/PcXMQEvNs6A6OCXwfVMklYzle5D9+3Xy5YrQd4ySXLU ETGeq1f4H9CyT+Gak7JP/aatx4GhWzvg2PGGhTcFugA9iojP8UQlKxiOj U9bhVYY+6Nbnyj89ojvGvjyeVDB5Hszzu9CFvlVSDw2SwuMn5E3vKGgdr pXWBfND4g6sYCwd3oReTfRSsbDPOQ3SLtBaAOae0DSZfSoeRqzGrXO82x Q==; IronPort-SDR: svimTqIqvwDgDK7C7iJ3w2jby28l58lX01Y5lVfSThfqXy5jj1smXaJd9LWH8CIioELlrcb+9p 66JPODwbN9lvqQ+SQvAoxYHwrHlBJPTZFrFe56lVEhGlQxVvsvdoDWnUtF5Dg4dLSLIdmq9GBZ S9MP2EuHXcMoFwFYmKIkC8sBu62v3RrM90MzcFo7XQfXRdNUSs6DrPwDQJpwoY/0EOb1+ze0Ar Zlg6JIkKupZSRrbZI4siJVw/xzcbG+S3MOg0tFMKgIaYjVJh6sTb0YE3nNubMShTIOGq1CRT+0 tFQ= X-IronPort-AV: E=Sophos;i="5.72,410,1580774400"; d="scan'208";a="698145" IronPort-PHdr: =?us-ascii?q?9a23=3AHj+1sRzKkRpRo0zXCy+O+j09IxM/srCxBDY+r6?= =?us-ascii?q?Qd1OMfIJqq85mqBkHD//Il1AaPAdyGra4ZwLSG+4nbGkU4qa6bt34DdJEeHz?= =?us-ascii?q?Qksu4x2zIaPcieFEfgJ+TrZSFpVO5LVVti4m3peRMNQJW2aFLduGC94iAPER?= =?us-ascii?q?vjKwV1Ov71GonPhMiryuy+4ZLebxhIiTanbr5/LBq6oATSu8ILnYZsN6E9xw?= =?us-ascii?q?fTrHBVYepW32RoJVySnxb4+Mi9+YNo/jpTtfw86cNOSL32cKskQ7NWCjQmKH?= =?us-ascii?q?0169bwtRbfVwuP52ATXXsQnxFVHgXK9hD6XpP2sivnqupw3TSRMMPqQbwoXz?= =?us-ascii?q?mp8qFmQwLqhigaLT406GHZhNJtgqJHrhyvpB1/zJLbbo6aL/d+YrrdfdEGSW?= =?us-ascii?q?ZdQspdSSpMCZ68YYsVCOoBOP5Vo4f/qVsJqRu+ARejBOX0xTBWmnD23rU22P?= =?us-ascii?q?k8Hw7a2wwgA84OvHrJp9jyL6cSUee1zK3MzTrdafNZwiny55TLch06v/GDQ6?= =?us-ascii?q?hwccvKyUkuGAPFiE+cppDiPzOQz+kAtXWQ4el4Ve+3lmIrtxt9riWty8oikI?= =?us-ascii?q?XFm4IYx17e+Sh2xIs5PcC0RFJhbdK5EpZcqzuWO5Z5T84hWW1kpSU3x7sbsp?= =?us-ascii?q?ChZicK0o4oxxvHZvyCdIiH/wzsWf6KITd9mHJlYLW/hwuu8US4yu3zSM200F?= =?us-ascii?q?FSoydYjtfCrm0B2BzL5MaIS/Rx4lmt1SyR1w/P7eFEO1g0mbDBJJE82LIwiI?= =?us-ascii?q?ATsV/FHiPshEr2i6qWel0l+uiu9evnfq3rqoKAO4Nulw3zMKojltaiDek4PA?= =?us-ascii?q?UCRWeW9OCk2L3m50L5QbFKjvMskqnetZDXPd8bpq6+Aw9R1oYs9RC/ACy439?= =?us-ascii?q?sEnnkKN0xFdwydj4joIFHOIf/4DfGlj1uwlzdrwujKPqf9DZXVMnjDjLDhcK?= =?us-ascii?q?5j5UBa1QQ+1tFf6IxICrEPOv7zXVXxtNOLRiM+ZkaI593PCdhh2MUZQ23FSv?= =?us-ascii?q?ulFJj6sFKU6KQoOebaN6EPvzOoYdgi4/rji3U0klxZNZKi2ocLIjjsBfRhJ0?= =?us-ascii?q?GUZ3DhidQpD2oQvxE/Q+qsg1qHB20AL02uVr4xs2loQLmtCp3OE9ig?= X-IPAS-Result: =?us-ascii?q?A2GBBABF+55e/zGZrQpcAQmCQYRRliaaUAoBAQEBAQEBA?= =?us-ascii?q?QEHARMcBAEBhwI3Bg4CAwEBCwEBAQUBAQEBAQUDAQEBAoZAC4I7IoQqGjcBP?= =?us-ascii?q?kImAQQRCrkHhU+FMoE4iW2CZoFCPoERgluFFAEUhgkEjgMqiTKZLXwDB4JEB?= =?us-ascii?q?JdmJZxdj3OcbwIEAgQFAhWBaIF6cIM6TxgNoCFIjmOBEAEB?= Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 21 Apr 2020 09:57:57 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1913.005; Tue, 21 Apr 2020 09:57:57 -0400 From: "Hollenbeck, Scott" To: "TLS@ietf.org" Thread-Topic: Comments on draft-ietf-tls-external-psk-importer-04 Thread-Index: AdYX4WFdhLPIgsQ4RUymyBbaAf5mxQ== Date: Tue, 21 Apr 2020 13:57:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [TLS] Comments on draft-ietf-tls-external-psk-importer-04 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: Tue, 21 Apr 2020 13:58:10 -0000 Here are a few comments gathered from Verisign Labs on draft-ietf-tls-exter= nal-psk-importer-04. 1. Overview of draft goals and techniques. We've summarized our understan= ding of the draft here. Our subsequent comments are based on this understa= nding. a. Goal: The draft's goal is to define a mechanism by which a TLS client a= nd server can derive multiple, cryptographically separate imported PSKs (I= PSKs) from a single, shared external PSK (EPSK), such that each IPSK is ass= ociated with a different combination of protocol parameters (e.g., the targ= et KDF for the TLS key schedule). The IPSK then takes the place of the PSK= input. This goal is beneficial as it avoids the need for a client and ser= ver to establish different EPSKs for these different combinations. The dra= ft doesn't specify how to establish the EPSK initially (this is left out of= scope, as it is in TLS itself).=20 b. Mechanism: The IPSK is derived from the EPSK and other parameters via a= key derivation function associated with the EPSK. The other parameters in= clude a general-purpose context string, the identifier of the target protoc= ol, and the identifier of the target KDF. The IPSK is thereby bound to the= se parameters. The binding to the target KDF helps ensure that the input k= ey material for different KDFs are cryptographically separate.=20 c. Syntax: In support of this mechanism, the draft also specifies a new sy= ntax for the opaque PskIdentity.identity field in the TLS PSK extension. T= he new syntax includes the identity of the underlying EPSK (which remains a= n opaque string, as usual) and the associated protocol parameters. When a = server recognizes that the PSKIdentity.identity field has this syntax, if t= he server accepts the underlying EPSK and the associated parameters, the se= rver then derives the PSK input to the TLS key schedule from the underlying= EPSK and the other parameters. A client may offer multiple IPSK identitie= s, each with a different combination of underlying EPSK identities and asso= ciated parameters.=20 2. Technical comments.=20 a. Distinct identities? Sec. 3 states "Non-imported and imported PSKs are = distinct since their identities are different on the wire." We have two co= ncerns about this statement. First, the statement appears to suggest that = if two EPSKs have different identities, then they must have different secre= t values. But couldn't two EPSKs have the same secret value yet employ dif= ferent identities for convenience? For example, an endpoint might identify= the same EPSK with a domain name in some cases and with an IP address in o= thers. Second, and more fundamentally, the statement assumes that a non-im= ported EPSK, by definition, cannot be misinterpreted as an imported PSK. B= ut isn't the identifier of a non-imported EPSK just an opaque string? A no= n-imported EPSK identity could therefore have the same "bits on the wire" a= s an IPSK identity, if the client and server employ an identifier system th= at whose encoding happens to coincide with the ImportedIdentity structure d= efined in the draft. (Moreover, the identifier of a resumption PSK is just= an opaque string -- so couldn't this also collide with ImportedIdentity va= lues? Perhaps we are missing something even more fundamental in our readin= g.) ([draft-dt-tls-external-psk-guidance-01] covers similar issues in its = Sec. 6.1.2, "PSK Identity Collisions.") b. Attack impact. If it's possible for an opaque identifier for a non-impo= rted EPSK identity to have the same encoding as an ImportedIdentity value, = then how does the server recognize unambiguously that the opaque identifier= is intended to be an imported identity? The server could take an optimist= ic approach and assume that an identifier that meets the ImportedIdentity s= yntax is probably an imported identity, and run the code path for imported = identities first. If that path fails, however -- either because the server= doesn't accept the EPSK or associated parameters, or because the binder va= lue is incorrect -- then the server may need to run the code path for non-i= mported identities as a fallback, checking next to see if the opaque string= is recognized as an ordinary EPSK identity. But this practice just puts m= ore burden on a server against an attacker who replays (or makes up) the PS= KIdentity.identity value: two code paths are exercised for the price of on= e attempted handshake.=20 c. Mitigations. One way to reduce the burden is to impose a new requireme= nt that the opaque string can only have the ImportedIdentity syntax if the = client (or server in the case of hints) indeed intends to use the import me= chanism. An ordinary EPSK could have any other value, just not this kind. = But this may not be compatible with the installed base, especially with imp= lementations that allow clients and servers to specify arbitrary EPSK ident= ities. (Consider the case where an application adopts the imported identity= syntax for the use intended in this draft, and then decides to reuse the s= yntax for other purposes, including ordinary EPSK identities.) =20 Another way to ensure distinctness is to add a flag that indicates that the= PSK identity is an imported identity. But it's not clear where this flag w= ould go, given that the PskIdentity syntax isn't extensible. Perhaps there= could be an overall flag indicating that _all PSK identities are imported = identities? Or a new extension for imported PSKs? d. Key separation. Note that the foregoing discussion about EPSK identifi= ers potentially colliding is separate from the question about what happens = if an IPSK happens to collide with a non-imported EPSK. The draft handles = this effectively with different inputs to the binder derivation ("ext binde= r" vs. "imp binder"). But this happens after the implementation has alread= y decided whether to interpret the identifier as external or imported.=20 e. Incremental deployment. Section 6 states that " the derived PSK will n= ot be the same [as the underlying EPSK] since the importer differentiates t= he PSK via the identity, target protocol and target key KDF." However, the= next statement does not follow directly: "Thus, PSKs imported for TLS 1.3= are distinct from those used in TLS 1.2, and thereby avoid cross-protocol = collisions." Rather, the statement also depends on the requirement in Sect= ion 3 that clients (and servers) don't deliberately use EPSKs or IPSKs for = other purposes, and the security properties of the KDF that produces the IP= SK (which ensures that collisions don't occur accidentally). But there al= so seems to be an implication in Section 6 that the use of the KDF in the T= LS 1.3 importer doesn't conflict with the cryptographic functions used for = obtaining the TLS 1.2 pre-master secret. If so, this distinction should be= spelled out. Related to this, where Section 3 states, "Clients which import external key= s MUST NOT use either the external keys or the derived keys for any other p= urpose," should "Clients" be "Clients and servers" or simply "Endpoints"? Scott From nobody Tue Apr 21 08:27:45 2020 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 6526F3A0F1B for ; Tue, 21 Apr 2020 08:27:40 -0700 (PDT) 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=izwwS7jt; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=izwwS7jt 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 wOvc4widFGmq for ; Tue, 21 Apr 2020 08:27:33 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60062.outbound.protection.outlook.com [40.107.6.62]) (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 CFDF83A0EB7 for ; Tue, 21 Apr 2020 08:24:03 -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=VJ+D05+O1if0APTbtOGIp1/+GWju/dztbvc0xvvkI2s=; b=izwwS7jt7OpvfMsJg8WW0HoujZB990t4GWYz0xu9nt87yb5WpJ1t7ffw8d2AJAgmJGymQNZ3D7lppGZlyzsz9L06bGoosSOvXh/dYguK8wj6+BUuv8LxxHLfphmLL3g9CeceIqbtwTGg396NyyK7dLs5+bCH/bdlp08supTCCNM= Received: from AM6P195CA0106.EURP195.PROD.OUTLOOK.COM (2603:10a6:209:86::47) by AM6PR08MB5175.eurprd08.prod.outlook.com (2603:10a6:20b:ef::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Tue, 21 Apr 2020 15:23:41 +0000 Received: from VE1EUR03FT005.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:86:cafe::bf) by AM6P195CA0106.outlook.office365.com (2603:10a6:209:86::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25 via Frontend Transport; Tue, 21 Apr 2020 15:23:41 +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 VE1EUR03FT005.mail.protection.outlook.com (10.152.18.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.18 via Frontend Transport; Tue, 21 Apr 2020 15:23:40 +0000 Received: ("Tessian outbound 3a3e6dcbad0e:v53"); Tue, 21 Apr 2020 15:23:40 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: eadc22710a68a93f X-CR-MTA-TID: 64aa7808 Received: from 559b08a151d8.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 7C760627-665C-416A-9B13-EC76FA990172.1; Tue, 21 Apr 2020 15:23:35 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 559b08a151d8.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 21 Apr 2020 15:23:35 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l+xTgq5kuoNJ6r92/g8OXk8Lku7PNAH9DNm/zgMFoP8BdgoEVcCZEYCltBQtoHymKKIm1twHuifDoAzvPrJPq1a6sKYbx5BdquFSf8rAATVomO2Sd7PK+bOgoR+3PY5oNkyzvNrnXyWR9yAdSF4APXh9Ygi36wr0JTyOrwDHWemmVZOXWDSqFlza4u6tstIpPSQh963Smr923I30C3XCgx2lKrHf7bwz5dc1HzHSriNf6EUxqDUlaVVhiYl058VXmpjAhr5F3zq6tKzhvaaL/Gevkplqrw/PP4CrKVVr0rshZ7TqUO4/WFuvhpoWlP4mvDZMlMM+yYP+DuwV1soupg== 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=VJ+D05+O1if0APTbtOGIp1/+GWju/dztbvc0xvvkI2s=; b=GaCsL1Zsql+BAsa7X0jhs4cA5UjIL35OSwWYOVhSneXE67nu99UnShQ14N5y3v4+G1ZOCBEW6eShyv1htkvP9h03OoQK/kD6VfXDi2S49BV66ZqoEq/Z5baTXTURtxGUREGi+gnBH9E4pVvMi86C5jQ2rS8po0G1d3FIgh0seAzUmHcDPMxyxpjQnbTlcI5M+8Muu9jTUm4wXR9edXIDMc1SQe+XFMiz1s+9g26c+B3RltAOtrp4nx14/ZdHEn1TarFJQ0GG+Yvj9FRhvvUny2a73afgL+PI5NxvmUd9Ls/uH3zUwOaIUY2PaKHI+7ET1PHPtO6Zaocr4QyYcdHFZQ== 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=VJ+D05+O1if0APTbtOGIp1/+GWju/dztbvc0xvvkI2s=; b=izwwS7jt7OpvfMsJg8WW0HoujZB990t4GWYz0xu9nt87yb5WpJ1t7ffw8d2AJAgmJGymQNZ3D7lppGZlyzsz9L06bGoosSOvXh/dYguK8wj6+BUuv8LxxHLfphmLL3g9CeceIqbtwTGg396NyyK7dLs5+bCH/bdlp08supTCCNM= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6PR08MB3400.eurprd08.prod.outlook.com (2603:10a6:20b:42::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Tue, 21 Apr 2020 15:23:33 +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.2921.030; Tue, 21 Apr 2020 15:23:33 +0000 From: Hanno Becker To: "tls@ietf.org" Thread-Topic: [TLS] DTLS 1.3 AEAD additional data Thread-Index: AQHWF+iN1gKILcDltkmRr5OfopCaAQ== Date: Tue, 21 Apr 2020 15:23:33 +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.177.220.146] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 63717662-5c0e-4b9c-8e9b-08d7e607f8df x-ms-traffictypediagnostic: AM6PR08MB3400:|AM6PR08MB5175: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 038002787A 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)(396003)(346002)(39860400002)(136003)(366004)(376002)(55016002)(71200400001)(186003)(26005)(19627405001)(478600001)(86362001)(2906002)(66946007)(66476007)(66556008)(7696005)(64756008)(76116006)(66446008)(316002)(8936002)(33656002)(8676002)(81156014)(9686003)(6506007)(5660300002)(6916009)(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: QGlQGei96cjn3uwI8m5G5z1ZYjvVrqRRF7ehUSPrj9pkxn2o0XeWUXV0f689kQmL+6Eb1MBpMQw6k6ZGzT5kW+zod27yv3/LsLOIboUCh2O1Pa+MN1ITyu05ebPUL6+bYBRiCzcjAZSoMLrjYBpjsYxwJgsbusGdv5iTFFDnwHq87SgjHNxqG913ljMQETdVHF5Zi/Y26lCV/RX5usA6OtRO9lAJk7Y2geeqtavPOtpiPfWnmnpg8p02chcxCX0HXrLM9PfUZm4EIuYiGh5OAzVlXDHuQXw9EOuxlhybyiCN0durZFlVgCqzPKFaePDkOCSzjk38OjsC3m7nTf0lH3lzB3zWBUjKv0nJ45azPY9j6mX3Wa3QxHE/fvqvjJB+OXa2qXU3kTbxKCVdkysjMbhJCeZfcLbd1c0CJsbb8FszPRadER8kxcxz7coqtXG5 x-ms-exchange-antispam-messagedata: wBc5/iHUuOLGYCN3ykfJffu2GP9XxbHGupgWL0m0+wW/AjpJRFLdCHJWGol94I6qcfRdsb2LJ99V4ieeJaGbPGuOKqxCf1BtlDaOMwM5FqKShUzARrKXIMCR+s60qR6mQnn4WtdYIbciimPbnL4PxQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3318911C71C0DDB90480694A9BD50AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3400 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT005.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)(376002)(346002)(136003)(39860400002)(396003)(46966005)(7696005)(70586007)(26005)(19627405001)(52536014)(70206006)(336012)(8676002)(6916009)(186003)(81166007)(33656002)(9686003)(55016002)(5660300002)(81156014)(2906002)(86362001)(82740400003)(478600001)(316002)(36906005)(8936002)(47076004)(6506007)(356005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 71ac3bf9-d11b-4420-987b-08d7e607f44d X-Forefront-PRVS: 038002787A X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SoYAuycTWNT4gmPv0OLJw+2RgblpiBR8h1EEc+gNK0SVTZIGa5Vds1MdqRVpqUgRnNjNof0cFA7XH59hfny6RcZYjwPS1JtrhK/vtsgZt6st3jn3zBW7TyQYU5ZaZiTpa5kGGnzVj2+fT86YdGQnEOa59spErReNpX7z+N1+lTNFd/KkRgCg2PnYILjUTkv5nXWcFQonoda1DB2zKywaDvzXyuxQcKgRl7bm2QYZJVoCC4MVUgvL0TlPsZ0ot6YXPMKDAqFmkC10eC1JTG73CsGCIV4P4ibhsPy3N+NcvBnDIGD7vK0u26U4beOHxQ1Re+XizWh20G64+VtXDpbu9e2HISvIEAlcafGj95wAKqx2unmKC2qgSgiCTcQKouxs1M4y8jT0BHoU69cyB83vaKVKXsbUdRHaSn//sVSeopsyXpbmF9wbUCgxMJrBvQWFV5vyrhnNlIrDY/Jj91/GoWzRiSSwsevXhwZAxXy+EsJhiClzgATAKR5v6kZvLsXkDRB5XBuLLyeV7Mn3lfFeHw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Apr 2020 15:23:40.9413 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 63717662-5c0e-4b9c-8e9b-08d7e607f8df 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: AM6PR08MB5175 Archived-At: Subject: [TLS] DTLS 1.3 AEAD additional data 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: Tue, 21 Apr 2020 15:27:43 -0000 --_000_AM6PR08MB3318911C71C0DDB90480694A9BD50AM6PR08MB3318eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, To my understanding, DTLS 1.3 defines AEAD additional data for record prote= ction as the record header as seen on the wire. Quoting Draft 37, Section 4: ``` The entire header value shown in Figure 4 (but prior to record number encryption) is used as as the additional data value for the AEAD function. For instance, if the minimal variant is used, the AAD is 2 octets long. Note that this design is different from the additional data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. ``` I would like to suggest that DTLS 1.3 uses a structured representation of the record header instead, as do all other versions of [D]TLS as far as I understand. The reasons for this are as follows, in decreasing order of my perception of importance: - Omission of Connection ID Regarding the presence of Connection IDs in multiple records within a single datagram, Draft 37 says: ``` Implementations which send multiple records in the same datagram SHOULD omit the connection id from all but the first record; receiving implementations MUST assume that any subsequent records without connection IDs belong to the same assocatiation. ``` This means that the Connection ID for non-initial records in a datagram containing multiple records is _not_ part of the AEAD additional data for those records, which seems wrong. Concretely, one could inject such non-initial records into other datagrams using different CIDs, and the record protection wouldn't notice it. One might argue that CID shouldn't be part of the AEAD in the first place, but in any case, I believe the treatment should be uniform and not distinguish between initial and non-initial records in a datagram. - Modularity Decoupling the wire-presentation of the record header from record protection allows to implement record protection and the choice of record header independently: One piece of the implementation can take care of record protection - using the structured presentation of the record header - while another takes care of the wire-encoding. It is even possible to change the record header format in transit. One might of course turn this argument around and say that such modifications are unwanted and using the header on-the-wire as the AEAD allows to detect them, but I don't yet see the concrete problem with them so far. - Simplicity At first it seems that using the record header as an unstructured binary blob for AEAD makes things simpler, but I don't think this is the case: Prior to record decryption, the record sequence number needs to be decrypted, and for that purpose, the record header already has to be parsed. Hence, at the time of record decryption, the record header is already be present a modified, structured form, and retaining the corresponding modified binary form appears to create additional complexity which would be avoided if record protection would use the structured header presentation. - Uniformity with other [D]TLS versions Let me know what you think, Best, 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_AM6PR08MB3318911C71C0DDB90480694A9BD50AM6PR08MB3318eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,

To my understandin= g, DTLS 1.3 defines AEAD additional data for record protection
as the record head= er as seen on the wire. Quoting Draft 37, Section 4:

```
   The e= ntire header value shown in Figure 4 (but prior to record number
   encry= ption) is used as as the additional data value for the AEAD
   funct= ion.  For instance, if the minimal variant is used, the AAD is 2
   octet= s long.  Note that this design is different from the additional=
   data = calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID.
```

I would like to su= ggest that DTLS 1.3 uses a structured representation
of the record head= er instead, as do all other versions of [D]TLS as
far as I understan= d.

The reasons for th= is are as follows, in decreasing order of
my perception of i= mportance:

- Omission of Conn= ection ID

  Regarding t= he presence of Connection IDs in multiple records within
  a single da= tagram, Draft 37 says:

```
   Imple= mentations which send multiple records in the same datagram
   SHOUL= D omit the connection id from all but the first record;
   recei= ving implementations MUST assume that any subsequent records
   witho= ut connection IDs belong to the same assocatiation.
```

  This means = that the Connection ID for non-initial records in a
  datagram co= ntaining multiple records is _not_ part of the AEAD
  additional = data for those records, which seems wrong. Concretely,
  one could i= nject such non-initial records into other datagrams
  using diffe= rent CIDs, and the record protection wouldn't notice it.

  One might a= rgue that CID shouldn't be part of the AEAD in the first
  place, but in = any case, I believe the treatment should be uniform
  and not distin= guish between initial and non-initial records in  
  a datagram.

- Modularity

  Decoupling = the wire-presentation of the record header from
  record prot= ection allows to implement record protection and
  the choice = of record header independently: One piece of
  the impleme= ntation can take care of record protection -
  using the s= tructured presentation of the record header - while
  another tak= es care of the wire-encoding. It is even possible
  to change t= he record header format in transit.

  One might o= f course turn this argument around and say that
  such modifi= cations are unwanted and using the header on-the-wire
  as the AEAD= allows to detect them, but I don't yet see the
  concrete pr= oblem with them so far.

- Simplicity

  At first it= seems that using the record header as an
  unstructure= d binary blob for AEAD makes things simpler,
  but I don't= think this is the case: Prior to record
  decryption,= the record sequence number needs to be
  decrypted, = and for that purpose, the record header already
  has to be p= arsed. Hence, at the time of record decryption,
  the record = header is already be present a modified, structured
  form, and r= etaining the corresponding modified binary form
  appears to = create additional complexity which would be
  avoided if = record protection would use the structured
  header pres= entation.

- Uniformity with = other [D]TLS versions


Let me know what y= ou think,

Best,
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_AM6PR08MB3318911C71C0DDB90480694A9BD50AM6PR08MB3318eurp_-- From nobody Tue Apr 21 11:00:03 2020 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 52E313A08E5 for ; Tue, 21 Apr 2020 11:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 aXgJq_mHAxmE for ; Tue, 21 Apr 2020 10:59:58 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9DF3A08E8 for ; Tue, 21 Apr 2020 10:59:57 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id g4so6830022ljl.2 for ; Tue, 21 Apr 2020 10:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WsFU9ez6pjq/kOzyVrl3fcHmzX31rQ8JqxUDmfVO5Hc=; b=pS9ZEPQJfspYxnhjCSKJS1RNO6FnPjJ7lDtOQbEga3cVhESDtePUKxGB2WblxBDjcz AAI/l9xLA5ua3td7eVHePgolMcZEngDu2+AHpTMbVFmA5C66KpEQZb7+If7/2tlgFtc4 gyL+1Dc/Yiblls0IlbZ0kB2XQfmkQiJP6bFwW2jAFANp5yEWMpXKnoSgIfdUucC2Hflc v+mU3pUE7ZtI+Bj+nJ8tZf4u7GrXs5MZExLi3jerW4hgp2yD2LHe5VQfxwXSwOAblC1c eN7E18ZTLl9xh3IboEzzvECe4bh0dNw323hokxpGN3xCFCHNJD/vE+3TiKX0GPj5CaDk Pmbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WsFU9ez6pjq/kOzyVrl3fcHmzX31rQ8JqxUDmfVO5Hc=; b=bq5iwZLlEw52QGJCBZ8aAox6/AfUdadGzx9Et4vC8Xmdaj+zT3YbXQ9o+E2aP7W6WT eeSIO346Ty6FDJPbfQp6WvwpnMl+ccdqV5uxltPalO1izXs0r/Da1Di3RTIsgOYXsYIJ jWaB/SOVb5Yn5iWmaGwiJzE99hr6y85HVijL8EH+stxp//0ObxaupRNN5baNek60N6PS Gv7LMSn1trSUtG3G2IGNyMW7MaUWxJXqtVD9+vbWdlfKEt0v7xQRxGv6vnlBa3ku6NCx Vzrsfyb2TfcmKn5FAta3wQ3rO/DrJqx4/o3qszeEBVVYzbnq/GE4I1KeSTcPl9sBXX54 82Rg== X-Gm-Message-State: AGi0PuYog7i+ITbRikqoQGlLuOW+QvoDEG1cY/GU9c4OvEdcDGd2/lD7 gvp5P7lflkTDUJUBWVQMaDAogPbmmlGoXYJVkQ8m8A== X-Google-Smtp-Source: APiQypLz03ZqnVkmPcXBUYFNkKp2ndYtWDHw6PYAVqnI6k81SAV7Mv/st0pUU3PWDMNo2sFw/gDJsA9c5lwchZwR/mw= X-Received: by 2002:a2e:b0ee:: with SMTP id h14mr14497677ljl.35.1587491992800; Tue, 21 Apr 2020 10:59:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Tue, 21 Apr 2020 10:59:16 -0700 Message-ID: To: Hanno Becker Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000050a90305a3d0c869" Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Tue, 21 Apr 2020 18:00:01 -0000 --00000000000050a90305a3d0c869 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker wrote: > Hi all, > > To my understanding, DTLS 1.3 defines AEAD additional data for record > protection > as the record header as seen on the wire. Quoting Draft 37, Section 4: > > ``` > The entire header value shown in Figure 4 (but prior to record number > encryption) is used as as the additional data value for the AEAD > function. For instance, if the minimal variant is used, the AAD is 2 > octets long. Note that this design is different from the additional > data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. > ``` > > I would like to suggest that DTLS 1.3 uses a structured representation > of the record header instead, as do all other versions of [D]TLS as > far as I understand. > I am not in favor of this change as proposed. I think it is better to protect the data that is actually on the wire than to allow for changes in the on-the-wire representation that are not reflected in the integrity check. The reasons for this are as follows, in decreasing order of > my perception of importance: > > - Omission of Connection ID > > Regarding the presence of Connection IDs in multiple records within > a single datagram, Draft 37 says: > > ``` > Implementations which send multiple records in the same datagram > SHOULD omit the connection id from all but the first record; > receiving implementations MUST assume that any subsequent records > without connection IDs belong to the same assocatiation. > ``` > > This means that the Connection ID for non-initial records in a > datagram containing multiple records is _not_ part of the AEAD > additional data for those records, which seems wrong. Concretely, > one could inject such non-initial records into other datagrams > using different CIDs, and the record protection wouldn't notice it. > This seems like a reasonable point, though it's not clear to me that there is an actual problem here. I'd be in favor of explicitly including the CID in the AD as well as the header. > > > One might argue that CID shouldn't be part of the AEAD in the first > place, but in any case, I believe the treatment should be uniform > and not distinguish between initial and non-initial records in > a datagram. > We're not distinguishing it. The AD is protecting the record on the wire. - Modularity > > Decoupling the wire-presentation of the record header from > record protection allows to implement record protection and > the choice of record header independently: One piece of > the implementation can take care of record protection - > using the structured presentation of the record header - while > another takes care of the wire-encoding. It is even possible > to change the record header format in transit. > This seems like a defect, not a feature. - Simplicity > > At first it seems that using the record header as an > unstructured binary blob for AEAD makes things simpler, > but I don't think this is the case: Prior to record > decryption, the record sequence number needs to be > decrypted, and for that purpose, the record header already > has to be parsed. Hence, at the time of record decryption, > the record header is already be present a modified, structured > form, and retaining the corresponding modified binary form > appears to create additional complexity which would be > avoided if record protection would use the structured > header presentation. > I've implemented this for QUIC (I can't remember who at Mozilla did it for DTLS) and it's not particularly difficult. - Uniformity with other [D]TLS versions > I don't find this argument at all persuasive. To the contrary: we should break with DTLS 1.2 in any case where it's an improvement and not too onerous. -Ekr > > > Let me know what you think, > > 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 > --00000000000050a90305a3d0c869 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 21, 2020 at 8:39 AM Hanno= Becker <Hanno.Becker@arm.com> wrote:
Hi all,

To my understanding, DTL= S 1.3 defines AEAD additional data for record protection
as the record header as = seen on the wire. Quoting Draft 37, Section 4:

```
=C2=A0 =C2=A0The entire = header value shown in Figure 4 (but prior to record number
=C2=A0 =C2=A0encryption)= is used as as the additional data value for the AEAD
=C2=A0 =C2=A0function.= =C2=A0 For instance, if the minimal variant is used, the AAD is 2
=C2=A0 =C2=A0octets long= .=C2=A0 Note that this design is different from the additional
=C2=A0 =C2=A0data calcul= ation for DTLS 1.2 and for DTLS 1.2 with Connection ID.
```

I would like to suggest = that DTLS 1.3 uses a structured representation
of the record header ins= tead, as do all other versions of [D]TLS as
far as I understand.



my perception of importa= nce:

- Omission of Connection= ID

=C2=A0 Regarding the pre= sence of Connection IDs in multiple records within
=C2=A0 a single datagram= , Draft 37 says:

```
=C2=A0 =C2=A0Implementat= ions which send multiple records in the same datagram
=C2=A0 =C2=A0SHOULD omit= the connection id from all but the first record;
=C2=A0 =C2=A0receiving i= mplementations MUST assume that any subsequent records
=C2=A0 =C2=A0without con= nection IDs belong to the same assocatiation.
```

=C2=A0 This means that t= he Connection ID for non-initial records in a
=C2=A0 datagram containi= ng multiple records is _not_ part of the AEAD
=C2=A0 additional data f= or those records, which seems wrong. Concretely,
=C2=A0 one could inject = such non-initial records into other datagrams
=C2=A0 using different C= IDs, and the record protection wouldn't notice it.








--00000000000050a90305a3d0c869-- From nobody Tue Apr 21 12:31:53 2020 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 1DBCB3A0898 for ; Tue, 21 Apr 2020 12:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zAcfm3xxZWDM for ; Tue, 21 Apr 2020 12:31:49 -0700 (PDT) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71DEB3A0884 for ; Tue, 21 Apr 2020 12:31:48 -0700 (PDT) Received: by mail-wr1-x429.google.com with SMTP id g13so15883497wrb.8 for ; Tue, 21 Apr 2020 12:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IHlznP0Sa8GQINUcm8hJrRt5HwsKLtOWbfhLf8KIx4k=; b=mShwddo54uLqwzHwfG2K1OmBVR/qMapWrfXwa11C9Ayk6g6VO1wU0dR4/f3+lxDBAo Cn2YX8VaugayR3oaJzW0rTCnspoGdK5+Le5HSe0F5BODkVTfMgY/MktvPhC/TFmhppc6 vAnjVnON5RDk2ZrUE+7kGkELFrxSM2LeseAaLaloDzf0zOcCUqO/TxdZswTgSP3nGyRY m6vqyNGv8qOTe5bBkHSIlkKMGf0OPmQcgKcIhCT7Wuo3/SirYWpg/bJzaRyFNvkRRmNE jAKZn5HW+13UNn3xBAeg+bv0J+WGHTWh4UGI2TBDFbEjvY86/D5GeToQhF11za2zA/UI H8Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IHlznP0Sa8GQINUcm8hJrRt5HwsKLtOWbfhLf8KIx4k=; b=biqp6AncLddgw6X4j3JxY1/J7BqzLApfInD0qvl0i1QHZMYCCC1rLTRm2yR6H2rUt8 1cNixDZw9cGYC9/O58tqOEayu55ROzjNXl+lggxjTiE9VtyelKYVt16rCuqsw8lNUz36 d5q209LOewRjGUSlaQbni7Tia/URD3V2RNIuCf8bFa795f+t881EvRcoenQCR0q4T11a mfSx+tgaROLKbYQU07XAreFtOCIRuV1lFXmIo5Z5O3U3Q1rRHS+CYGuFDY7RfXipGAUi rvjNi6ruB4t72prmRlYusAv1jpDXxFVSC/8N+1niSq55E3oXL1Oa4NgPguUGTkBUdaaG O6Gw== X-Gm-Message-State: AGi0PuainD9oMigBm4Fb6raNLCO0/tfPSRWrAfbd38NwKcBdj625oIiN wJFHxrR9S7LI7mkuySmNgQ0OMDKZ X-Google-Smtp-Source: APiQypIY9Epq7w58jPJQZSZaSqoBTcANzAj4TIWcLNqLML2YGWNk8iHQO0jxHdKDswLTMqw45+dTpw== X-Received: by 2002:adf:fe41:: with SMTP id m1mr25239299wrs.52.1587497504519; Tue, 21 Apr 2020 12:31:44 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id n7sm4642833wmd.11.2020.04.21.12.31.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Apr 2020 12:31:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Yoav Nir In-Reply-To: <3aab08b9-d979-4952-85f6-62e993f6fb4b@www.fastmail.com> Date: Tue, 21 Apr 2020 22:31:41 +0300 Cc: tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <3aab08b9-d979-4952-85f6-62e993f6fb4b@www.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [TLS] WGLC for "A Flags Extension for TLS 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: Tue, 21 Apr 2020 19:31:53 -0000 Inline... > On 7 Apr 2020, at 1:39, Martin Thomson wrote: >=20 > I like this work, but I don't believe this to be ready yet. >=20 > S1 > None of the current proposed extensions are such that the server > indicates support without the client first indicating support. So = as > not to preclude future extensions that are so defined, this > specification allows the client to send an empty extension, > indicating support for TLS flags in general (and presumably some > unspecified features in particular). >=20 > First, for clarification, the distinction between empty and = all-zero-valued is perhaps worth drawing on. I think the description of the extension in section 2 is clear. An = extension without any flags set is empty, It=E2=80=99s not all = zero-valued. A FlagsExtensions field with a length of 1 and the one = byte being zero is an invalid encoding of the extension as its length is = the minimal length possible. So only an empty extension is meaningful. > Second, more seriously, if this is the goal, the text needs to = acknowledge that the possibility exists on a *per-flag* basis. Can you suggest text? >=20 > Third, more substantially, and invalidating the above, I don't think = that we should make flags introduce a new style of negotiation just = because it can. I would strongly prefer that this function as close as = possible to "empty ClientHello extension; empty EncryptedExtensions = extension". Aside from that, the utility of an advertisement from the = server that a client cannot respond to is pretty marginal. If this is what the group prefers, I=E2=80=99m fine with it, but then = there=E2=80=99s never any point in sending an empty extension, either = from the client of form the server. The absence of an individual flag is = always implied from the absence of the extension. > Fourth, this conflicts with the following text in S2: >=20 > A server that supports this extension and also supports at least one > of the flag-type features that use this extension and that were > declared by the ClientHello extension SHALL send this extension with > the intersection of the flags it supports with the flags declared by > the client. Agree. So either we abolish =E2=80=9Csilent client - server declares=E2=80= =9D extensions (let=E2=80=99s call them unsolicited), or we rephrase the = above something along the lines of: A server that supports the extension and also supports at least one = flag that was either present in the ClientHello extension or is allowed = to be sent unsolicited, SHALL send this extension with all of the flags = it is configured to support except those that are not allowed to be sent = unsolicited and that were not present in the ClientHello extension > Nit here: this isn't about support alone, it is the flags that the = server *chooses* to support. =E2=80=9Cconfigured to support=E2=80=9D ? > S2 > The server may need to send two tls_flags extensions, > one in the ServerHello and the other in the EncryptedExtensions > message. =20 >=20 > Are we confident that sending the same extension in both places is = safe? I know that clients have to implement this and so should be able = to test that this works, but it seems awkward. And it might not be = necessary. It's also not sufficient, as we currently allow responses to = ClientHello extensions to appear in Certificate (and for = CertificateRequest to carry "requests" in the other direction). I don=E2=80=99t think the two extensions ever carry the same flags. Each = server side flag should be one of three: serverHello, = encrpytedExtensions, or neither (if we are not expecting a response) I think this requires another field in the IANA registry. As for Certificate, I don=E2=80=99t see why we=E2=80=99d need to add bit = responses to Certificate. They can safely be sent in either serverHello = or encryptedExtensions. > Perhaps we might avoid this problem entirely. ServerHello extensions = are limited to key exchange. If we say that flags are limited (today) = to functional properties that don't affect key exchange, my thought is = that we don't lose much (if anything) by only allowing this extension in = EncryptedExtensions. I=E2=80=99m trying to come up with key exchange bits that might be = useful. Perhaps a new, improved alternative to HKDF? Support for = Quantum Key Exchange? > I don't know what I think about Certificate extensions. This seems to = have a clear use there. >=20 > Editorial: >=20 > S1 > It might be better to draw examples from the canon of published RFCs = than to refer to things that might not get published. I support I cna mention RI earlier. >=20 > On Tue, Apr 7, 2020, at 00:53, Christopher Wood wrote: >> This is the working group last call for the "A Flags Extension for = TLS=20 >> 1.3" draft, available at: >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ >>=20 >> Please review the document and send your comments to the list by = April=20 >> 20, 2020. The GitHub repository for this draft is available at: >>=20 >> https://github.com/tlswg/tls-flags >>=20 >> Thanks, >> Chris, on behalf of the chairs >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Apr 21 18:24:22 2020 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 F22AC3A090D for ; Tue, 21 Apr 2020 18:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 gGxmm4_2CsbA for ; Tue, 21 Apr 2020 18:24:19 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992333A08B6 for ; Tue, 21 Apr 2020 18:24:00 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id g10so248022lfj.13 for ; Tue, 21 Apr 2020 18:24:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+DhhP9q9QYeaGLrknaVHSgHDP2eowXK+D5jRMH7A8dw=; b=q8d5vPuz/F/keXcfZD4plP9/m9lAUGehhsZVsxPe/BnfNErfH0Tij99HManizssAGk sEnLI3cTtoZWseuo3oCkyLpJosJJsm9oRg5wVOn63ze6czoQGLG/P2CZCCg62ai2grsT Xz4y09L2OczEuN9Z9bCcXazKk8op1qrNouEocWJhqvX0a3A3MxRzKG14uJHzWGpyvFV+ T+SGLZr8NfMzIUVNUJYjc4N8o/z1gjhlatxCIdOkXnmSxUPixVe7U58ntTnaKwInfjI8 vZ/I73ybfAdeDXkSO6Wj7mvmbeYk5s3NWSmOawDgAZnM7TUBUAT3xdWhHFBVb6lNB1i3 FRAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+DhhP9q9QYeaGLrknaVHSgHDP2eowXK+D5jRMH7A8dw=; b=R/GXo8QmSSz5hfHXnOUbOm5eGGfxVgDr0Ast3V73HUr4LHQ+CYvNgLq09aEzPfSWH0 blqmDOsi+EnhNg2eoxtWc6j8SwmWQwopKl7nGzL+Z13jvMT6vYE1E/WgaWqxZJjb5kqN IiYcVykPxPn1mHMaZAIpFtnTSw/C2VnNxNpUPnf/doZlaHpw3QI9Gi8kYQD6mniRPdjS rQLjzSA6plLQRm0noPZl+lFX9MwqjcNRTGPOj1Yd9cc69y3DSC1XR2ePgytMyfW4MSY2 w9kZUJjhlq8PjJA77/1v8605H4WmeSZt+2yxFfjkIEw7eSxzlFgnB6kOJP9QhIJMWc7B XCvA== X-Gm-Message-State: AGi0PuaLOhudWmkV+e0xs/NDbEZQ1KcdwP0bMlD2mlKcZtbCphjZXESc 2LFL4TjMqoOuzMaebWckMdzmrGFc1Ibm5kUHwRF5w8LmP2qvuQ== X-Google-Smtp-Source: APiQypLyYSom7j+d2xcoqpTQO/RhwL7VxIQvMA4gafnnSe6KZln3i/5nsQOR+EE0yDJAa43bhJ9C9c3hgxR1s9zgRx8= X-Received: by 2002:a19:40d0:: with SMTP id n199mr15455342lfa.161.1587518638738; Tue, 21 Apr 2020 18:23:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Tue, 21 Apr 2020 18:23:22 -0700 Message-ID: To: Hanno Becker Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000089632505a3d6fcdf" Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Wed, 22 Apr 2020 01:24:21 -0000 --00000000000089632505a3d6fcdf Content-Type: text/plain; charset="UTF-8" I think there are two potential resolutions to your CID issue: 1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spec/pull/143 2. Forbid implicit CIDs (my preference) see: https://github.com/tlswg/dtls13-spec/issues/144 Would like to hear what others in the WG think. -Ekr On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla wrote: > > > On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker wrote: > >> Hi all, >> >> To my understanding, DTLS 1.3 defines AEAD additional data for record >> protection >> as the record header as seen on the wire. Quoting Draft 37, Section 4: >> >> ``` >> The entire header value shown in Figure 4 (but prior to record number >> encryption) is used as as the additional data value for the AEAD >> function. For instance, if the minimal variant is used, the AAD is 2 >> octets long. Note that this design is different from the additional >> data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. >> ``` >> >> I would like to suggest that DTLS 1.3 uses a structured representation >> of the record header instead, as do all other versions of [D]TLS as >> far as I understand. >> > > I am not in favor of this change as proposed. I think it is better to > protect the data that is actually on the wire than to allow for changes in > the on-the-wire representation that are not reflected in the integrity > check. > > > The reasons for this are as follows, in decreasing order of >> my perception of importance: >> >> - Omission of Connection ID >> >> Regarding the presence of Connection IDs in multiple records within >> a single datagram, Draft 37 says: >> >> ``` >> Implementations which send multiple records in the same datagram >> SHOULD omit the connection id from all but the first record; >> receiving implementations MUST assume that any subsequent records >> without connection IDs belong to the same assocatiation. >> ``` >> >> This means that the Connection ID for non-initial records in a >> datagram containing multiple records is _not_ part of the AEAD >> additional data for those records, which seems wrong. Concretely, >> one could inject such non-initial records into other datagrams >> using different CIDs, and the record protection wouldn't notice it. >> > > This seems like a reasonable point, though it's not clear to me that there > is an actual problem here. I'd be in favor of explicitly including the CID > in the AD as well as the header. > >> >> >> One might argue that CID shouldn't be part of the AEAD in the first >> place, but in any case, I believe the treatment should be uniform >> and not distinguish between initial and non-initial records in >> a datagram. >> > > We're not distinguishing it. The AD is protecting the record on the wire. > > > - Modularity >> >> Decoupling the wire-presentation of the record header from >> record protection allows to implement record protection and >> the choice of record header independently: One piece of >> the implementation can take care of record protection - >> using the structured presentation of the record header - while >> another takes care of the wire-encoding. It is even possible >> to change the record header format in transit. >> > > This seems like a defect, not a feature. > > > - Simplicity >> >> At first it seems that using the record header as an >> unstructured binary blob for AEAD makes things simpler, >> but I don't think this is the case: Prior to record >> decryption, the record sequence number needs to be >> decrypted, and for that purpose, the record header already >> has to be parsed. Hence, at the time of record decryption, >> the record header is already be present a modified, structured >> form, and retaining the corresponding modified binary form >> appears to create additional complexity which would be >> avoided if record protection would use the structured >> header presentation. >> > > I've implemented this for QUIC (I can't remember who at Mozilla did it for > DTLS) and it's not particularly difficult. > > > - Uniformity with other [D]TLS versions >> > > I don't find this argument at all persuasive. To the contrary: we should > break with DTLS 1.2 in any case where it's an improvement and not too > onerous. > > -Ekr > > >> >> >> Let me know what you think, >> >> 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 >> > --00000000000089632505a3d6fcdf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think there are two potential resolutions to your C= ID issue:

1. Cryptographically protect it as in https://github.com/= tlswg/dtls13-spec/pull/143
2. Forbid implicit CIDs (my prefer= ence) see: http= s://github.com/tlswg/dtls13-spec/issues/144

Wo= uld like to hear what others in the WG think.

-Ekr=


On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla <ekr@rtfm.com> wrote:
=

On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker <Hanno.Becker@arm.com> wrote:
=
Hi all,

To my understanding, DTL= S 1.3 defines AEAD additional data for record protection
as the record header as = seen on the wire. Quoting Draft 37, Section 4:

```
=C2=A0 =C2=A0The entire = header value shown in Figure 4 (but prior to record number
=C2=A0 =C2=A0encryption)= is used as as the additional data value for the AEAD
=C2=A0 =C2=A0function.= =C2=A0 For instance, if the minimal variant is used, the AAD is 2
=C2=A0 =C2=A0octets long= .=C2=A0 Note that this design is different from the additional
=C2=A0 =C2=A0data calcul= ation for DTLS 1.2 and for DTLS 1.2 with Connection ID.
```

I would like to suggest = that DTLS 1.3 uses a structured representation
of the record header ins= tead, as do all other versions of [D]TLS as
far as I understand.

I am not in favor of = this change as proposed. I think it is better to protect the data that is a= ctually on the wire than to allow for changes in the on-the-wire representa= tion that are not reflected in the integrity check.


The reasons for this are as follows, in decreasing= order of
my perception of importa= nce:

- Omission of Connection= ID

=C2=A0 Regarding the pre= sence of Connection IDs in multiple records within
=C2=A0 a single datagram= , Draft 37 says:

```
=C2=A0 =C2=A0Implementat= ions which send multiple records in the same datagram
=C2=A0 =C2=A0SHOULD omit= the connection id from all but the first record;
=C2=A0 =C2=A0receiving i= mplementations MUST assume that any subsequent records
=C2=A0 =C2=A0without con= nection IDs belong to the same assocatiation.
```

=C2=A0 This means that t= he Connection ID for non-initial records in a
=C2=A0 datagram containi= ng multiple records is _not_ part of the AEAD
=C2=A0 additional data f= or those records, which seems wrong. Concretely,
=C2=A0 one could inject = such non-initial records into other datagrams
=C2=A0 using different C= IDs, and the record protection wouldn't notice it.

This seems like a reasonable point, th= ough it's not clear to me that there is an actual problem here. I'd= be in favor of explicitly including the CID in the AD as well as the heade= r.


=C2=A0 One might argue t= hat CID shouldn't be part of the AEAD in the first
=C2=A0 place, but in any case, I= believe the treatment should be uniform
=C2=A0 and not distinguish betwe= en initial and non-initial records in=C2=A0=C2=A0
=C2=A0 a datagram.
<= /div>

We're not distinguishing it= . The AD is protecting the record on the wire.


- Modularity

=C2=A0 Decoupling the wi= re-presentation of the record header from
=C2=A0 record protection= allows to implement record protection and
=C2=A0 the choice of rec= ord header independently: One piece of
=C2=A0 the implementatio= n can take care of record protection -
=C2=A0 using the structu= red presentation of the record header - while
=C2=A0 another takes car= e of the wire-encoding. It is even possible
=C2=A0 to change the rec= ord header format in transit.
This seems like a defect, not a feature.


- Simplicity

=C2=A0 At first it seems= that using the record header as an
=C2=A0 unstructured bina= ry blob for AEAD makes things simpler,
=C2=A0 but I don't t= hink this is the case: Prior to record
=C2=A0 decryption, the r= ecord sequence number needs to be
=C2=A0 decrypted, and fo= r that purpose, the record header already
=C2=A0 has to be parsed.= Hence, at the time of record decryption,
=C2=A0 the record header= is already be present a modified, structured
=C2=A0 form, and retaini= ng the corresponding modified binary form
=C2=A0 appears to create= additional complexity which would be
=C2=A0 avoided if record= protection would use the structured
=C2=A0 header presentati= on.

I've imple= mented this for QUIC (I can't remember who at Mozilla did it for DTLS) = and it's not particularly difficult.


- Uniformity with other = [D]TLS versions

I = don't find this argument at all persuasive. To the contrary: we should = break with=C2=A0 DTLS 1.2 in any case where it's an improvement and not= too onerous.

-Ekr




Let me know what you thi= nk,

Best,
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000089632505a3d6fcdf-- From nobody Tue Apr 21 18:57:00 2020 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 0D4473A0A74 for ; Tue, 21 Apr 2020 18:56:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=N9bEfNSI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fyfj/6a+ 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 e-SeFU9HFSjw for ; Tue, 21 Apr 2020 18:56:57 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 224813A0A73 for ; Tue, 21 Apr 2020 18:56:57 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 6039A77F for ; Tue, 21 Apr 2020 21:56:56 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Tue, 21 Apr 2020 21:56:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=mAzWWQ/iEXRw0CcpYsIrU+NopJ1GuB7 zA83bdREozBQ=; b=N9bEfNSIuL2pRuVOcdIBfYJT+sKQuR0UQzr5eMsrZtjVwJe we3AS8tXAMNr11isOdP8+L+pQTJzJYhl7Nswgjg93REmF0kmXBnK6azCOOaQeL9o MECRTF8wM3INOWNwI5HJef2qjqMYRD0Pz66lT2ciK/ZcAVbhQYPOfnhUbDa6+iW4 67Vo/f4wGwOyotoz2YQwsr4gZWK6poQZQIhc3530DRPxFtl51p+FTIJNYWHdqh6t LnCqIE8S3W2Ot5AuFVoVWsYOgcr5YlB4tncksZTwB2EjW7CeOPS51XAXPviN6dOm fud3xgZfch0kBw+yLfqV57cWSC/lXb+hDTTW/Lg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=mAzWWQ /iEXRw0CcpYsIrU+NopJ1GuB7zA83bdREozBQ=; b=fyfj/6a+J0MDD7i30yCN8Q /OcfumqUhPaUdK8BJ6ktoGTQOYGcszVQy5pM745Y5hiD/FoLwLsL4m8ARYfxDrAy 6hOxYy0t8Loar/pQ0slHwCidGFVdp7Z+XAE2gIOc34d1etQRGQBLFOJEbUYBCy3N CFlepSEeRIoBwl52rHHBi5B/KbEiVmgGxjSLSe5vNiBwtWPmWr21U7pN7O2BAqWo 50W1/UgsvM9XxFBsCfTlaRpQWeDUkKSt+hi5voGDvxyF0GZoKAkekWerZbCqnrqO DxB8oY7afzCvW75xc+DisLG/4kiIM7nvM+peKbLKGblPCO95gI5T5IcatABnocPw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeeigdehvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgif sehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6D1B1180093; Tue, 21 Apr 2020 21:56:55 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <96ed3f4c-7ad4-4406-95c9-1e96b5a49eed@www.fastmail.com> In-Reply-To: References: Date: Tue, 21 Apr 2020 18:56:35 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Comments on draft-ietf-tls-external-psk-importer-04 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: Wed, 22 Apr 2020 01:56:59 -0000 Thanks for the feedback, Scott! Please see inline below. On Tue, Apr 21, 2020, at 6:57 AM, Hollenbeck, Scott wrote: > 2. Technical comments. > > a. Distinct identities? Sec. 3 states "Non-imported and imported PSKs > are distinct since their identities are different on the wire." We > have two concerns about this statement. First, the statement appears > to suggest that if two EPSKs have different identities, then they must > have different secret values. But couldn't two EPSKs have the same > secret value yet employ different identities for convenience? For > example, an endpoint might identify the same EPSK with a domain name in > some cases and with an IP address in others. This seems like a reasonable editorial improvement to make. I filed: https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/31 > Second, and more > fundamentally, the statement assumes that a non-imported EPSK, by > definition, cannot be misinterpreted as an imported PSK. But isn't the > identifier of a non-imported EPSK just an opaque string? A > non-imported EPSK identity could therefore have the same "bits on the > wire" as an IPSK identity, if the client and server employ an > identifier system that whose encoding happens to coincide with the > ImportedIdentity structure defined in the draft. ( > Moreover, the identifier of a resumption PSK is just an opaque string > -- so couldn't this also collide with ImportedIdentity values? Perhaps > we are missing something even more fundamental in our reading.) > ([draft-dt-tls-external-psk-guidance-01] covers similar issues in its > Sec. 6.1.2, "PSK Identity Collisions.") Yes, certainly it's possible for a non-imported EPSK to have an identity which matches the constructed identity of an imported PSK. We can't do anything to prevent applications from crafting such identities, so I'm inclined to just note this as a possibility, if anything. > b. Attack impact. If it's possible for an opaque identifier for a > non-imported EPSK identity to have the same encoding as an > ImportedIdentity value, then how does the server recognize > unambiguously that the opaque identifier is intended to be an imported > identity? The server could take an optimistic approach and assume that > an identifier that meets the ImportedIdentity syntax is probably an > imported identity, and run the code path for imported identities first. Yep, that's what I envisioned servers would do. > If that path fails, however -- either because the server doesn't > accept the EPSK or associated parameters, or because the binder value > is incorrect -- then the server may need to run the code path for > non-imported identities as a fallback, checking next to see if the > opaque string is recognized as an ordinary EPSK identity. But this > practice just puts more burden on a server against an attacker who > replays (or makes up) the PSKIdentity.identity value: two code paths > are exercised for the price of one attempted handshake. I don't think this is a particularly useful attack, though I do agree that it causes more work for the server. I'm curious to hear what others think. > c. Mitigations. One way to reduce the burden is to impose a new > requirement that the opaque string can only have the ImportedIdentity > syntax if the client (or server in the case of hints) indeed intends to > use the import mechanism. An ordinary EPSK could have any other value, > just not this kind. But this may not be compatible with the installed > base, especially with implementations that allow clients and servers to > specify arbitrary EPSK identities. (Consider the case where an > application adopts the imported identity syntax for the use intended in > this draft, and then decides to reuse the syntax for other purposes, > including ordinary EPSK identities.) > > Another way to ensure distinctness is to add a flag that indicates that > the PSK identity is an imported identity. But it's not clear where this > flag would go, given that the PskIdentity syntax isn't extensible. > Perhaps there could be an overall flag indicating that _all PSK > identities are imported identities? Or a new extension for imported > PSKs? Since this draft is meant to fix an annoyance in TLS 1.3, I think anything more than a different Identity encoding is overkill. I absolutely agree that the rigidity of PskIdentity is something we might want to fix. I'm just not sure that should be done here. > d. Key separation. Note that the foregoing discussion about EPSK > identifiers potentially colliding is separate from the question about > what happens if an IPSK happens to collide with a non-imported EPSK. > The draft handles this effectively with different inputs to the binder > derivation ("ext binder" vs. "imp binder"). But this happens after the > implementation has already decided whether to interpret the identifier > as external or imported. > > e. Incremental deployment. Section 6 states that " the derived PSK > will not be the same [as the underlying EPSK] since the importer > differentiates the PSK via the identity, target protocol and target key > KDF." However, the next statement does not follow directly: "Thus, > PSKs imported for TLS 1.3 are distinct from those used in TLS 1.2, and > thereby avoid cross-protocol collisions." Rather, the statement also > depends on the requirement in Section 3 that clients (and servers) > don't deliberately use EPSKs or IPSKs for other purposes, and the > security properties of the KDF that produces the IPSK (which ensures > that collisions don't occur accidentally). But there also seems to be > an implication in Section 6 that the use of the KDF in the TLS 1.3 > importer doesn't conflict with the cryptographic functions used for > obtaining the TLS 1.2 pre-master secret. If so, this distinction > should be spelled out. Hmm, not quite. The statement intends to say that if you need EPSK k into an importer and into TLS 1.2 then the resulting keys used in TLS 1.3 and 1.2 are different. I'm not sure further clarification is needed, though I'm happy to review suggestions if you have them! > Related to this, where Section 3 states, "Clients which import external > keys MUST NOT use either the external keys or the derived keys for any > other purpose," should "Clients" be "Clients and servers" or simply > "Endpoints"? Yep, that's a good editorial improvement. I filed this issue to track it: https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/30 Thanks again for your review and feedback! Best, Chris From nobody Tue Apr 21 23:26:09 2020 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 D19E33A0538 for ; Tue, 21 Apr 2020 23:26:07 -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=k44f8tk9; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=k44f8tk9 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 REQHSc5bUQg0 for ; Tue, 21 Apr 2020 23:26:04 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2053.outbound.protection.outlook.com [40.107.22.53]) (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 387073A0522 for ; Tue, 21 Apr 2020 23:26:03 -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=3LLAKwy3U5CiIOyD6USa0tLJBXOkt0sAmpMuL+dtQtI=; b=k44f8tk9pRDknktzZnZSEj0pEDXIVvfr8Xs25xmEE7zqskbAgw4qrHw6mKw3NFilJv2EBira6NrCvXk0JPcKYO3CdqrzzEXQt/kpIb1xwgSBiPG7/BRci9qBqS1zNk4IYXFkKZACly6oLcWtpj/fbdh4zijskKsQEEFQM5vBkO8= Received: from DB6PR07CA0184.eurprd07.prod.outlook.com (2603:10a6:6:42::14) by AM6PR08MB4295.eurprd08.prod.outlook.com (2603:10a6:20b:b7::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.27; Wed, 22 Apr 2020 06:26:00 +0000 Received: from DB5EUR03FT053.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:42:cafe::9f) by DB6PR07CA0184.outlook.office365.com (2603:10a6:6:42::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.6 via Frontend Transport; Wed, 22 Apr 2020 06:26:00 +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 DB5EUR03FT053.mail.protection.outlook.com (10.152.21.119) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.18 via Frontend Transport; Wed, 22 Apr 2020 06:26:00 +0000 Received: ("Tessian outbound 29c24b8a1b7a:v53"); Wed, 22 Apr 2020 06:26:00 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 121378ba573236df X-CR-MTA-TID: 64aa7808 Received: from 5fe0784f8c40.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 53C3BAF0-38B6-45F3-86D8-E48B1C00D476.1; Wed, 22 Apr 2020 06:25:55 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 5fe0784f8c40.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 22 Apr 2020 06:25:55 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ko2tXhH0NCOBgEDsjpJpNNOXs9g+3tC46WWX2mXHjWvG5V9LYxaFPMmxB/3ZZqTLZS/Dmzkd92AIULnZYwBuLbN2CY3wpakoGig40qFFVp3zaHmZOGMsh8Oz9iEm391gBSE6SolNdppSR3Fr6x1i0yLgic7cG3/XzHgMElk25HXZmFpGsEgFUml9848pwZujEevLSQNePczPB10cSVLqIFR1orqHDSggJVvCCJ9JCdQH0qROnPpcBeQEYP3sgzjjaM9ITRso48Ztqyq+FkBT0PkD5KcPxh/BQdjKJmSqwjncvdCgM1OMZpBLhMaIgEAe1m5CYLFtNAwA2wJ0dFwNsg== 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=3LLAKwy3U5CiIOyD6USa0tLJBXOkt0sAmpMuL+dtQtI=; b=KnuaJcm+XyebuMt8unf0BgslOSE+tkY3mrcZYTd9CBeOR1xW67jWIULzLKkLF5kUDIIlatVdIYXpw4yQjhNvtHx/47wq3nLmjjbXZUhOGi3WLnSIypMKGEA8K91WpjpUvS1NQHBPOyn2QbnaUzQNc5WD/Zwlzb7qeVgjWYvnBVp13DGRnP1eaqmqQNcf3k02rcPkJnQ57s1FspXWZvGs9t5R3TNg0BSveNZ1tWuwf6kgwx/IpKMYqCkIiughB6arULomDUT9MXU/t54NJqTPaspcC4N10GlD9BAXaXAukPJxcN1DmBb0b3t49co7V2L4t63IhajdpPUneAbD6zt1+A== 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=3LLAKwy3U5CiIOyD6USa0tLJBXOkt0sAmpMuL+dtQtI=; b=k44f8tk9pRDknktzZnZSEj0pEDXIVvfr8Xs25xmEE7zqskbAgw4qrHw6mKw3NFilJv2EBira6NrCvXk0JPcKYO3CdqrzzEXQt/kpIb1xwgSBiPG7/BRci9qBqS1zNk4IYXFkKZACly6oLcWtpj/fbdh4zijskKsQEEFQM5vBkO8= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6PR08MB2998.eurprd08.prod.outlook.com (2603:10a6:209:4e::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.28; Wed, 22 Apr 2020 06:25:53 +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.2921.030; Wed, 22 Apr 2020 06:25:53 +0000 From: Hanno Becker To: Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] DTLS 1.3 AEAD additional data Thread-Index: AQHWF+iN1gKILcDltkmRr5OfopCaAaiD3VMAgAB8FQCAAE7VmA== Date: Wed, 22 Apr 2020 06:25:53 +0000 Message-ID: References: , In-Reply-To: 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: 805c5412-0bfa-4d5f-037e-08d7e686068b x-ms-traffictypediagnostic: AM6PR08MB2998:|AM6PR08MB4295: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 03818C953D 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)(39860400002)(366004)(346002)(376002)(396003)(136003)(66946007)(52536014)(4326008)(2906002)(6916009)(186003)(5660300002)(33656002)(6506007)(53546011)(316002)(26005)(76116006)(66476007)(66556008)(64756008)(66446008)(9686003)(55016002)(7696005)(478600001)(86362001)(71200400001)(8676002)(19627405001)(8936002)(81156014)(966005); 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: yWE8UBkCNK3683c2Tpf/jnPx4LD09E6U4A8bQ3/vhgcwMDGJ8w9hd7+KbKMeje+s+5csV9ofTMOXdNQLMVuW0JPvRrY6EmqrIHsg6aAKjrsVIoosYWPL6IWlLP8MlzGjYBBGUrMI/MJBOI+0XZzM5XRsuUZ/ooyPc3IZhDvrTIMtkMgI+pwDIhTzifTfNyNix10S4odHc0GVXOEwILKwjmgAVEJ/NE2nq59KqFfbMUUxwT4zN79UXciwneRw5/Oi+eiHKTyyup6KTsqT+Wi0xp35JCjo3rlpEIzhnowEWZhgByi9/ZfC+cJJoDtk5OPk2alV5wlQXduaNoM+ElMpuR+3hvitjG5aGy+QmUqz0kttLJbIEfh0XJUSNCXtco96bRzzgdcXrzvzYy/9SAQuMCCLMy20YtpM0zro56PEEI0WwrLCEoEhZ8929aWbA40T9s65yU75uoih9B04iCIl5qSKLCmjrVg852NiuFyB2ek49ZAjgah79P2IFA5PMbk+DfcwwyzIICpAw5W6DO1FZw== x-ms-exchange-antispam-messagedata: Ya0Km5sPZz8oQID5MOwSGMikng0Z4P6xeglhuhHkoLLiVj8UU46rrIOaa69ZVQdyQOwJtka/OUgqCr9A5sZ07R0KFP1/WRv4vhGuQCkwAQ/uDGSZ2/x/ezFlrxJ51tBLdDo/08gZaRIKn7RngtREOg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB33184161239B6383EA7D776C9BD20AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB2998 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT053.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)(39860400002)(396003)(376002)(346002)(136003)(46966005)(82310400002)(6862004)(2906002)(316002)(86362001)(30864003)(9686003)(7696005)(966005)(81166007)(356005)(70586007)(478600001)(5660300002)(55016002)(52536014)(6506007)(82740400003)(186003)(70206006)(336012)(8936002)(81156014)(53546011)(26005)(19627405001)(33656002)(8676002)(47076004)(4326008); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 10c964b9-37c2-49ba-88d1-08d7e6860268 X-Forefront-PRVS: 03818C953D X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: opktSrPrZ9xXgp2QlHamS+m+nGk5XTZylP1BZU9tqVIGUA3ELVN1jaxWxHeyUhyG2ZPQtz+/ILhHrlKbmpcWKYwV7tbVSK4SPMEg2dCEVdFnNV3c9dCLoJZp9+IstsfL3qLSm5Hw0CQ2bZYpiXTWvVkOwqYETQxIiSTnFVpLasZLPFJAJrtfVJ2606NyqZXIV2Xn68dRQMsonf3Vjjbz2i2hE9H5mLYOppwykp+h5ZCXzSkstTgFYcTMYUeglN3nAkJcRMwgydRkfeBDFpIQnYrZPaSoWDcMX1oI18zuCXlsx3k2JBxOi70PEneQso63MAvLihI0WwUh8syMyGbpgbJdndyggnPkdMV9dAi3hvT41xpUf5NcZX2l5O1SuQw03V0RXXUbxLaR4wBcWc9YqOsi93bThecl7XAzDB4SDSdPG0vr8Jh0vB2QrZjYumcurumCh6wlnaQvPHd0yqEZ6WwY7ctf98zfNSXCJm1I49v71Amt9wIQSfSPKvDEajQMNaXoEtlgI0Pkn9XFrwt2KJyJLgRMNlSENjeMMZFH2WGhLMd54TnmCmeSxxlRuhiQ0i7N03jb+4fbm6lkmgoCyg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Apr 2020 06:26:00.5914 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 805c5412-0bfa-4d5f-037e-08d7e686068b 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: AM6PR08MB4295 Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Wed, 22 Apr 2020 06:26:08 -0000 --_000_AM6PR08MB33184161239B6383EA7D776C9BD20AM6PR08MB3318eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ekr, > 2. Forbid implicit CIDs (my preference) see: https://github.com/tlswg/dtl= s13-spec/issues/144 Considering the effort spent on shaving off bytes in the DTLS header, I think re-introducing the explicit CID should be avoided. It seems perfectly acceptable to me to have implicit header data which is protected via AAD. Moreover, coming back to protecting the logical header and not the on-the-wire header and hence allowing header compression after protection, I still consider this a feature and not a defect, and the CID elision is actually a useful example for this: The record protection layer can emit protected records regardless of how they are packed into datagrams, and the part of the code responsible for the latter is free to remove CIDs from the headers of non-initial records in case it fits more than one records into a single datagram. In contrast, requiring the record layer to know how the record will be placed into a datagram interleaves different layers and introduces unnecessary dependency and complexity. (The omission of the total record length is actually another example for th= is: It should be the datagram layer, not the record layer, which decides whethe= r the length needs to be explicit in the header or not). > 1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spe= c/pull/143 This seems to be a mixture of logical and on-the-wire representation, which moreover duplicates the CID in case it is explicitly present in the header. I uphold my preference for an entirely structured presentation of the header as AAD instead of the binary data and think it should be added to the list of options: 3. Compute AAD over logical presentation of record header. Looking forward to hearing other WG member's views, Hanno ________________________________ From: Eric Rescorla Sent: Wednesday, April 22, 2020 2:23 AM To: Hanno Becker Cc: tls@ietf.org Subject: Re: [TLS] DTLS 1.3 AEAD additional data I think there are two potential resolutions to your CID issue: 1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spec/= pull/143 2. Forbid implicit CIDs (my preference) see: https://github.com/tlswg/dtls1= 3-spec/issues/144 Would like to hear what others in the WG think. -Ekr On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla > wrote: On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker > wrote: Hi all, To my understanding, DTLS 1.3 defines AEAD additional data for record prote= ction as the record header as seen on the wire. Quoting Draft 37, Section 4: ``` The entire header value shown in Figure 4 (but prior to record number encryption) is used as as the additional data value for the AEAD function. For instance, if the minimal variant is used, the AAD is 2 octets long. Note that this design is different from the additional data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. ``` I would like to suggest that DTLS 1.3 uses a structured representation of the record header instead, as do all other versions of [D]TLS as far as I understand. I am not in favor of this change as proposed. I think it is better to prote= ct the data that is actually on the wire than to allow for changes in the o= n-the-wire representation that are not reflected in the integrity check. The reasons for this are as follows, in decreasing order of my perception of importance: - Omission of Connection ID Regarding the presence of Connection IDs in multiple records within a single datagram, Draft 37 says: ``` Implementations which send multiple records in the same datagram SHOULD omit the connection id from all but the first record; receiving implementations MUST assume that any subsequent records without connection IDs belong to the same assocatiation. ``` This means that the Connection ID for non-initial records in a datagram containing multiple records is _not_ part of the AEAD additional data for those records, which seems wrong. Concretely, one could inject such non-initial records into other datagrams using different CIDs, and the record protection wouldn't notice it. This seems like a reasonable point, though it's not clear to me that there = is an actual problem here. I'd be in favor of explicitly including the CID = in the AD as well as the header. One might argue that CID shouldn't be part of the AEAD in the first place, but in any case, I believe the treatment should be uniform and not distinguish between initial and non-initial records in a datagram. We're not distinguishing it. The AD is protecting the record on the wire. - Modularity Decoupling the wire-presentation of the record header from record protection allows to implement record protection and the choice of record header independently: One piece of the implementation can take care of record protection - using the structured presentation of the record header - while another takes care of the wire-encoding. It is even possible to change the record header format in transit. This seems like a defect, not a feature. - Simplicity At first it seems that using the record header as an unstructured binary blob for AEAD makes things simpler, but I don't think this is the case: Prior to record decryption, the record sequence number needs to be decrypted, and for that purpose, the record header already has to be parsed. Hence, at the time of record decryption, the record header is already be present a modified, structured form, and retaining the corresponding modified binary form appears to create additional complexity which would be avoided if record protection would use the structured header presentation. I've implemented this for QUIC (I can't remember who at Mozilla did it for = DTLS) and it's not particularly difficult. - Uniformity with other [D]TLS versions I don't find this argument at all persuasive. To the contrary: we should br= eak with DTLS 1.2 in any case where it's an improvement and not too onerou= s. -Ekr Let me know what you think, Best, 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls 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_AM6PR08MB33184161239B6383EA7D776C9BD20AM6PR08MB3318eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ekr,

> 2. Forbid implicit CIDs (my preference) see: https://github.com/t= lswg/dtls13-spec/issues/144

Considering the effort spent on shaving off bytes in the DTLS header,<= br>
I think re-introducing the explicit CID should be avoided. It seems
perfectly acceptable to me to have implicit header data which is
protected via AAD.

Moreover, coming back to protecting the logical header and not
the on-the-wire header and hence allowing header compression
after protection, I still consider this a feature and not a defect,
and the CID elision is actually a useful example for this: The record&= nbsp;
protection layer can emit protected records regardless of how they&nbs= p;
are packed into datagrams, and the part of the code responsible for&nb= sp;
the latter is free to remove CIDs from the headers of non-initial reco= rds 
in case it fits more than one records into a single datagram. 
In contrast, requiring the record layer to know how the record will&nb= sp;
be placed into a datagram interleaves different layers and introduces&= nbsp;
unnecessary dependency and complexity.

(The omission of the total record length is actually another example f= or this: 
It should be the datagram layer, not the record layer, which decides w= hether 
the length needs to be explicit in the header or not).

> 1. Cryp= tographically protect it as in https://github.com/tlswg/dtls13-spec/pull/143

This seems to be a mixture of logical and on-the-wire representation, = which
moreover duplicates the CID in case it is explicitly present in the he= ader.

I uphold my preference for an entirely structured presentation of
the header as AAD instead of the binary data and think it should
be added to the list of options:

3. Compute AAD over logical presentation of record header.

Looking forward to hearing other WG member's views,
Hanno
From: Eric Rescorla <ekr= @rtfm.com>
Sent: Wednesday, April 22, 2020 2:23 AM
To: Hanno Becker <Hanno.Becker@arm.com>
Cc: tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] DTLS 1.3 AEAD additional data
 
I think there are two potential resolutions to your CID issue:

1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spec/pull/143
2. Forbid implicit CIDs (my preference) see: https://github.com/tlswg/dtls13-spec/issues/144

Would like to hear what others in the WG think.

-Ekr


On Tue, Apr 21, 2020 at 10:59 AM Er= ic Rescorla <ekr@rtfm.com> wrote:=


On Tue, Apr 21, 2020 at 8:39 AM Han= no Becker <Han= no.Becker@arm.com> wrote:
Hi all,

To my understanding, DTL= S 1.3 defines AEAD additional data for record protection
as the record header as = seen on the wire. Quoting Draft 37, Section 4:

```
   The entire = header value shown in Figure 4 (but prior to record number
   encryption)= is used as as the additional data value for the AEAD
   function.&n= bsp; For instance, if the minimal variant is used, the AAD is 2
   octets long= .  Note that this design is different from the additional
   data calcul= ation for DTLS 1.2 and for DTLS 1.2 with Connection ID.
```

I would like to suggest = that DTLS 1.3 uses a structured representation
of the record header ins= tead, as do all other versions of [D]TLS as
far as I understand.

I am not in favor of this change as proposed. I think it is better to = protect the data that is actually on the wire than to allow for changes in = the on-the-wire representation that are not reflected in the integrity chec= k.


The reasons for this are= as follows, in decreasing order of
my perception of importa= nce:

- Omission of Connection= ID

  Regarding the pre= sence of Connection IDs in multiple records within
  a single datagram= , Draft 37 says:

```
   Implementat= ions which send multiple records in the same datagram
   SHOULD omit= the connection id from all but the first record;
   receiving i= mplementations MUST assume that any subsequent records
   without con= nection IDs belong to the same assocatiation.
```

  This means that t= he Connection ID for non-initial records in a
  datagram containi= ng multiple records is _not_ part of the AEAD
  additional data f= or those records, which seems wrong. Concretely,
  one could inject = such non-initial records into other datagrams
  using different C= IDs, and the record protection wouldn't notice it.

This seems like a reasonable point, though it's not clear to me that t= here is an actual problem here. I'd be in favor of explicitly including the= CID in the AD as well as the header.


  One might argue t= hat CID shouldn't be part of the AEAD in the first
  place, but in any case, I= believe the treatment should be uniform
  and not distinguish betwe= en initial and non-initial records in  
  a datagram.

We're not distinguishing it. The AD is protecting the record on the wi= re.


- Modularity

  Decoupling the wi= re-presentation of the record header from
  record protection= allows to implement record protection and
  the choice of rec= ord header independently: One piece of
  the implementatio= n can take care of record protection -
  using the structu= red presentation of the record header - while
  another takes car= e of the wire-encoding. It is even possible
  to change the rec= ord header format in transit.

This seems like a defect, not a feature.


- Simplicity

  At first it seems= that using the record header as an
  unstructured bina= ry blob for AEAD makes things simpler,
  but I don't think= this is the case: Prior to record
  decryption, the r= ecord sequence number needs to be
  decrypted, and fo= r that purpose, the record header already
  has to be parsed.= Hence, at the time of record decryption,
  the record header= is already be present a modified, structured
  form, and retaini= ng the corresponding modified binary form
  appears to create= additional complexity which would be
  avoided if record= protection would use the structured
  header presentati= on.

I've implemented this for QUIC (I can't remember who at Mozilla did it= for DTLS) and it's not particularly difficult.


- Uniformity with other = [D]TLS versions

I don't find this argument at all persuasive. To the contrary: we shou= ld break with  DTLS 1.2 in any case where it's an improvement and not = too onerous.

-Ekr




Let me know what you thi= nk,

Best,
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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_AM6PR08MB33184161239B6383EA7D776C9BD20AM6PR08MB3318eurp_-- From nobody Wed Apr 22 05:29:21 2020 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 5D3EB3A0B1B for ; Wed, 22 Apr 2020 05:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 RydUs4NnT8AG for ; Wed, 22 Apr 2020 05:29:18 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A3B3A0B17 for ; Wed, 22 Apr 2020 05:29:17 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id u15so2077468ljd.3 for ; Wed, 22 Apr 2020 05:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iOSObBmPdRk/bVzmRkfzoVOftpAvjSJ+B4ft+ys9OQ0=; b=VuQ6YEfDhSwGpGV+6PcFmpGIZZ+G/tn7h6Y5PzXk7P2Ux24n+ea9ymDNbZfy+mpKD2 ww9qox9gB3nVDOVnkXkY5YtZgofIWMVilT8Apdk41seokf3KtLdPFwaaHH2pKuXrxneV XFSq9oq05H8XYgnvSNgBh3VcVF0aPGm4aJ9row8OLo1AqiW5Owy0W4v2awETkkVXaoGO BFilwR6sIXVCe2+kaHbsm9GmafSqt28aydw19kf/rroyqnyCPNp7UEkDw7TYT0qPh0jG gxHjzSUc1bDkjTkBYMX6SM4LODt2jC9vCXQUM5BoxjFqjP+1/iN4lpZdfy49C8HrT/+y TyKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iOSObBmPdRk/bVzmRkfzoVOftpAvjSJ+B4ft+ys9OQ0=; b=QzvxQi2CyRLxY1aXMItUP4roZVuhCfqG7YLODi0pNZOvqFNlN5htSFkKBm88zHH4BJ +ISJoH47jowFSDI4HnM1B0+LuYoTfz4pDjAL3xab+nn5/6lbIwvOXSdNH2owxPS/Nzy/ b5921eyohaZAnauVdczvStSHlfrT9wTBZ3zdMF0Gq4PUI/JsNxHS7waBpXRqkHho+3/o KFbgN5cp+fQUVeBNmJQF0f71vyKD4Zob52/8vOSr9nanqmEYT5/BE5o+LuCA3WTLKK3M PV11eEg6cDUMuCOI9TzMmK28iPqEUq+5/edipdgCc7F2H3EGVF8aa5NDdT+wd4Nq6waY C/ng== X-Gm-Message-State: AGi0PuYmk9VZgLVNONBxx46Dl/KCzAMoC3WiDVlLc5VR45J/xFHPBPyh 5o0g4QTv2nkVcPnu1sOtfMzLCmkfABW2vFgI5SMBfg== X-Google-Smtp-Source: APiQypJeyzZBBcfjgnQ5dAAW1qv236UBJuCIWWyGMPKwZgB9MvRetAB5C6ktSyu3QfBoOCYSePXmoW8qyQsOFTQgTXc= X-Received: by 2002:a2e:b0ee:: with SMTP id h14mr16779136ljl.35.1587558555710; Wed, 22 Apr 2020 05:29:15 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 22 Apr 2020 05:28:39 -0700 Message-ID: To: Hanno Becker Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c6116205a3e04708" Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Wed, 22 Apr 2020 12:29:20 -0000 --000000000000c6116205a3e04708 Content-Type: text/plain; charset="UTF-8" On Tue, Apr 21, 2020 at 11:26 PM Hanno Becker wrote: > Hi Ekr, > > > 2. Forbid implicit CIDs (my preference) see: > https://github.com/tlswg/dtls13-spec/issues/144 > > Considering the effort spent on shaving off bytes in the DTLS header, > I think re-introducing the explicit CID should be avoided. It seems > perfectly acceptable to me to have implicit header data which is > protected via AAD. > This is only relevant if there is a common useful case in which you would need to put multiple DTLS records in the same datagram. Are you aware of such a case? > 1. Cryptographically protect it as in > https://github.com/tlswg/dtls13-spec/pull/143 > > This seems to be a mixture of logical and on-the-wire representation, which > moreover duplicates the CID in case it is explicitly present in the header. > Yes, so? I uphold my preference for an entirely structured presentation of > the header as AAD instead of the binary data and think it should > be added to the list of options: > > 3. Compute AAD over logical presentation of record header. > The security principle we decided on for TLS 1.3 was that the AEAD should cover what is actually on the wire. I would be strongly opposed to going back on that. -Ekr -Ekr Looking forward to hearing other WG member's views, > Hanno > ------------------------------ > *From:* Eric Rescorla > *Sent:* Wednesday, April 22, 2020 2:23 AM > *To:* Hanno Becker > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data > > I think there are two potential resolutions to your CID issue: > > 1. Cryptographically protect it as in > https://github.com/tlswg/dtls13-spec/pull/143 > 2. Forbid implicit CIDs (my preference) see: > https://github.com/tlswg/dtls13-spec/issues/144 > > Would like to hear what others in the WG think. > > -Ekr > > > On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla wrote: > > > > On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker wrote: > > Hi all, > > To my understanding, DTLS 1.3 defines AEAD additional data for record > protection > as the record header as seen on the wire. Quoting Draft 37, Section 4: > > ``` > The entire header value shown in Figure 4 (but prior to record number > encryption) is used as as the additional data value for the AEAD > function. For instance, if the minimal variant is used, the AAD is 2 > octets long. Note that this design is different from the additional > data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. > ``` > > I would like to suggest that DTLS 1.3 uses a structured representation > of the record header instead, as do all other versions of [D]TLS as > far as I understand. > > > I am not in favor of this change as proposed. I think it is better to > protect the data that is actually on the wire than to allow for changes in > the on-the-wire representation that are not reflected in the integrity > check. > > > The reasons for this are as follows, in decreasing order of > my perception of importance: > > - Omission of Connection ID > > Regarding the presence of Connection IDs in multiple records within > a single datagram, Draft 37 says: > > ``` > Implementations which send multiple records in the same datagram > SHOULD omit the connection id from all but the first record; > receiving implementations MUST assume that any subsequent records > without connection IDs belong to the same assocatiation. > ``` > > This means that the Connection ID for non-initial records in a > datagram containing multiple records is _not_ part of the AEAD > additional data for those records, which seems wrong. Concretely, > one could inject such non-initial records into other datagrams > using different CIDs, and the record protection wouldn't notice it. > > > This seems like a reasonable point, though it's not clear to me that there > is an actual problem here. I'd be in favor of explicitly including the CID > in the AD as well as the header. > > > > One might argue that CID shouldn't be part of the AEAD in the first > place, but in any case, I believe the treatment should be uniform > and not distinguish between initial and non-initial records in > a datagram. > > > We're not distinguishing it. The AD is protecting the record on the wire. > > > - Modularity > > Decoupling the wire-presentation of the record header from > record protection allows to implement record protection and > the choice of record header independently: One piece of > the implementation can take care of record protection - > using the structured presentation of the record header - while > another takes care of the wire-encoding. It is even possible > to change the record header format in transit. > > > This seems like a defect, not a feature. > > > - Simplicity > > At first it seems that using the record header as an > unstructured binary blob for AEAD makes things simpler, > but I don't think this is the case: Prior to record > decryption, the record sequence number needs to be > decrypted, and for that purpose, the record header already > has to be parsed. Hence, at the time of record decryption, > the record header is already be present a modified, structured > form, and retaining the corresponding modified binary form > appears to create additional complexity which would be > avoided if record protection would use the structured > header presentation. > > > I've implemented this for QUIC (I can't remember who at Mozilla did it for > DTLS) and it's not particularly difficult. > > > - Uniformity with other [D]TLS versions > > > I don't find this argument at all persuasive. To the contrary: we should > break with DTLS 1.2 in any case where it's an improvement and not too > onerous. > > -Ekr > > > > > Let me know what you think, > > 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 > > 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. > --000000000000c6116205a3e04708 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Apr 21, 2020 at 11:26 PM Hann= o Becker <Hanno.Becker@arm.com> wrote:
Hi Ekr,

Considering the effort spent on shaving off bytes in the DTLS header,<= br>
I think re-introducing the explicit CID should be avoided. It seems
perfectly acceptable to me to have implicit header data which is
protected via AAD.

This is only relevant if= there is a common useful case in which you would need to put multiple
DTLS records in the same datagram. Are you aware of such a case?

> = 1. Cryptographically protect it as in https://github.com/tlswg/dt= ls13-spec/pull/143

This seems to be a mixture of logical and on-the-wire representation, = which
moreover duplicates the CID in case it is explicitly present in the he= ader.

Yes, so?

<= div>
I uphold my preference for an entirely structured presentation of
the header as AAD instead of the binary data and think it should
be added to the list of options:

3. Compute AAD over logical presentation of record header.
=

The security principle we decided on= for TLS 1.3 was that the AEAD should cover what is
actually on t= he wire. I would be strongly opposed to going back on that.
<= br>
-Ekr


-Ekr
<= br>
Looking forward to hearing other WG member's views,
Hanno
Fro= m: Eric Rescorla <= ekr@rtfm.com>
Sent: Wednesday, April 22, 2020 2:23 AM
To: Hanno Becker <Hanno.Becker@arm.com>
Cc: tls@ietf.org <tls@ietf.org&g= t;
Subject: Re: [TLS] DTLS 1.3 AEAD additional data
=C2=A0
I think there are two potential resolutions to your CID issue:

1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spec/pull/143
2. Forbid implicit CIDs (my preference) see: https://github.com/tlswg/dtls13-spec/issues/144

Would like to hear what others in the WG think.

-Ekr


On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker <Hanno.Becker@arm.com= > wrote:
Hi all,

To my understanding, DTL= S 1.3 defines AEAD additional data for record protection
as the record header as = seen on the wire. Quoting Draft 37, Section 4:

```
=C2=A0 =C2=A0The entire = header value shown in Figure 4 (but prior to record number
=C2=A0 =C2=A0encryption)= is used as as the additional data value for the AEAD
=C2=A0 =C2=A0function.= =C2=A0 For instance, if the minimal variant is used, the AAD is 2
=C2=A0 =C2=A0octets long= .=C2=A0 Note that this design is different from the additional
=C2=A0 =C2=A0data calcul= ation for DTLS 1.2 and for DTLS 1.2 with Connection ID.
```

I would like to suggest = that DTLS 1.3 uses a structured representation
of the record header ins= tead, as do all other versions of [D]TLS as
far as I understand.

I am not in favor of this change as proposed. I think it is better to = protect the data that is actually on the wire than to allow for changes in = the on-the-wire representation that are not reflected in the integrity chec= k.


The reasons for this are= as follows, in decreasing order of
my perception of importa= nce:

- Omission of Connection= ID

=C2=A0 Regarding the pre= sence of Connection IDs in multiple records within
=C2=A0 a single datagram= , Draft 37 says:

```
=C2=A0 =C2=A0Implementat= ions which send multiple records in the same datagram
=C2=A0 =C2=A0SHOULD omit= the connection id from all but the first record;
=C2=A0 =C2=A0receiving i= mplementations MUST assume that any subsequent records
=C2=A0 =C2=A0without con= nection IDs belong to the same assocatiation.
```

=C2=A0 This means that t= he Connection ID for non-initial records in a
=C2=A0 datagram containi= ng multiple records is _not_ part of the AEAD
=C2=A0 additional data f= or those records, which seems wrong. Concretely,
=C2=A0 one could inject = such non-initial records into other datagrams
=C2=A0 using different C= IDs, and the record protection wouldn't notice it.

This seems like a reasonable point, though it's not clear to me th= at there is an actual problem here. I'd be in favor of explicitly inclu= ding the CID in the AD as well as the header.


=C2=A0 One might argue t= hat CID shouldn't be part of the AEAD in the first
=C2=A0 place, but in any case, I= believe the treatment should be uniform
=C2=A0 and not distinguish betwe= en initial and non-initial records in=C2=A0=C2=A0
=C2=A0 a datagram.

We're not distinguishing it. The AD is protecting the record on th= e wire.


- Modularity

=C2=A0 Decoupling the wi= re-presentation of the record header from
=C2=A0 record protection= allows to implement record protection and
=C2=A0 the choice of rec= ord header independently: One piece of
=C2=A0 the implementatio= n can take care of record protection -
=C2=A0 using the structu= red presentation of the record header - while
=C2=A0 another takes car= e of the wire-encoding. It is even possible
=C2=A0 to change the rec= ord header format in transit.

This seems like a defect, not a feature.


- Simplicity

=C2=A0 At first it seems= that using the record header as an
=C2=A0 unstructured bina= ry blob for AEAD makes things simpler,
=C2=A0 but I don't t= hink this is the case: Prior to record
=C2=A0 decryption, the r= ecord sequence number needs to be
=C2=A0 decrypted, and fo= r that purpose, the record header already
=C2=A0 has to be parsed.= Hence, at the time of record decryption,
=C2=A0 the record header= is already be present a modified, structured
=C2=A0 form, and retaini= ng the corresponding modified binary form
=C2=A0 appears to create= additional complexity which would be
=C2=A0 avoided if record= protection would use the structured
=C2=A0 header presentati= on.

I've implemented this for QUIC (I can't remember who at Mozill= a did it for DTLS) and it's not particularly difficult.


- Uniformity with other = [D]TLS versions

I don't find this argument at all persuasive. To the contrary: we = should break with=C2=A0 DTLS 1.2 in any case where it's an improvement = and not too onerous.

-Ekr




Let me know what you thi= nk,

Best,
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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.
--000000000000c6116205a3e04708-- From nobody Wed Apr 22 07:31:22 2020 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 73E4B3A0D05 for ; Wed, 22 Apr 2020 07:31:19 -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=A3fMoGU3; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=A3fMoGU3 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 jDug_TZHlMej for ; Wed, 22 Apr 2020 07:31:16 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20086.outbound.protection.outlook.com [40.107.2.86]) (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 AA0053A0CDB for ; Wed, 22 Apr 2020 07:31:15 -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=NLvtQxjIoKDhTD82yvhWzi08CpdCzNC0JRq3n4HJ1dU=; b=A3fMoGU3oxY/dV7GA5+Xm3DFPQx0KoCLQjfxKAI7q8tvP5NPGsJGvIPR6ueHmBxdOll6fsUsjIhtlCsTmGrXxVGlIDAU55nmPrA7EuXsNl9yOFTFIHU/KC7EuCyHczjgGTNA++Gh493XGCD1UEPaYc0yv2c1eDkQHCScNsCxZdQ= Received: from DB8PR06CA0017.eurprd06.prod.outlook.com (2603:10a6:10:100::30) by DB8PR08MB3994.eurprd08.prod.outlook.com (2603:10a6:10:a6::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Wed, 22 Apr 2020 14:31:12 +0000 Received: from DB5EUR03FT031.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:100:cafe::f0) by DB8PR06CA0017.outlook.office365.com (2603:10a6:10:100::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Wed, 22 Apr 2020 14:31: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 DB5EUR03FT031.mail.protection.outlook.com (10.152.20.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.18 via Frontend Transport; Wed, 22 Apr 2020 14:31:12 +0000 Received: ("Tessian outbound 43fc5cd677c4:v53"); Wed, 22 Apr 2020 14:31:12 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: c2d3830ebd57ffa5 X-CR-MTA-TID: 64aa7808 Received: from 63660c00f021.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 315B094F-1D8B-4CD5-9F2A-69028BA6818D.1; Wed, 22 Apr 2020 14:31:06 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 63660c00f021.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 22 Apr 2020 14:31:06 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BaT2XrxEjH0ha3TPj9O7qH6rpJUSSUnQMh/mvN7KO0FV+GjYNY9e/SXREZyz4ygFVgl25IyOZmiBm1V3FeIhx+GBQCuHvykR94Xr1XsaMuff7wKNUwUI8CxuoWnOui3vcOcvnGW9k05yyZ5CuzaGiSoNqQ/rnpHt6KkM95iuCUGmoZc+hOp6HTSWPKyHf2hzW3Hk42K5/oAbfx0HfIe7AA0zBB/c5cRfTTjDG+h5x0fKjXumhO9h1wNa5e3kwYdNkU+pltEoZIS6yFnlk8ChVQmis/aX5GOXxN+CErWlO5rRJURJRXWawg4Av2yQrjpGkfKJ31urVDxPSmGfvXQJjw== 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=NLvtQxjIoKDhTD82yvhWzi08CpdCzNC0JRq3n4HJ1dU=; b=DgzSvU79tw8xIKgggyCFMkC/esCyQFORqY9w3T4MJqsrGh0DV+JIc4T0eWDBM6V5w24Qw0VA9LTekKGQqBzpOhpQCT7vVGS+9KqzjsF975VmoflTb4TmI1pc5LYJGYd0t0h8vv+uxNzo4LGIivwf5vHF9Q8F2qjB1jNTYcte09zSJoxqugH+axSDITg+2zzSZwP26cO98yvu0fFxyHAgr/jcfV1RTFd5cdU8nBQKstvVlAmSC+N83QJVbhGORx0DT1E/ArtU8woepJmPsx0RrAFRyVkQk04363501csB8mqvysyPlc8ULz2fAqpcC0mn8CGERPY8bKHMeebmawJ27A== 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=NLvtQxjIoKDhTD82yvhWzi08CpdCzNC0JRq3n4HJ1dU=; b=A3fMoGU3oxY/dV7GA5+Xm3DFPQx0KoCLQjfxKAI7q8tvP5NPGsJGvIPR6ueHmBxdOll6fsUsjIhtlCsTmGrXxVGlIDAU55nmPrA7EuXsNl9yOFTFIHU/KC7EuCyHczjgGTNA++Gh493XGCD1UEPaYc0yv2c1eDkQHCScNsCxZdQ= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6PR08MB4852.eurprd08.prod.outlook.com (2603:10a6:20b:cc::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.26; Wed, 22 Apr 2020 14:31:05 +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.2921.030; Wed, 22 Apr 2020 14:31:05 +0000 From: Hanno Becker To: Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] DTLS 1.3 AEAD additional data Thread-Index: AQHWF+iN1gKILcDltkmRr5OfopCaAaiD3VMAgAB8FQCAAE7VmIAAawyAgAAHdS4= Date: Wed, 22 Apr 2020 14:31:05 +0000 Message-ID: References: , In-Reply-To: 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: e11e2fe4-12f1-4470-950d-08d7e6c9ce65 x-ms-traffictypediagnostic: AM6PR08MB4852:|DB8PR08MB3994: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 03818C953D 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)(366004)(136003)(396003)(39860400002)(376002)(346002)(9686003)(6506007)(76116006)(66946007)(8676002)(52536014)(26005)(316002)(66446008)(186003)(6916009)(81156014)(5660300002)(71200400001)(7696005)(64756008)(55016002)(478600001)(53546011)(66556008)(4326008)(19627405001)(966005)(33656002)(66476007)(8936002)(86362001)(2906002); 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: MBQPfd4kLUmwoN6A7ysW32a6UM5Ttwkuy3TP1UAjCIpE8xKHzk3CJV0s4NXxXqcS3nbU02CxgehnyvDfkEtVbPa4wdmn42tb+MvnUJ/i5yE2ShlVlLTINnKRG5VAikAb4ePG/fD04xMyEsVxwPGb0Dhv2cQs4LRQlCEmZ/37FprHFiF/CVjRZ+TAEFleliXoo8KtSmAXK9UgyDdVLA/HFSxuBm/zeivI2dUwbX6wyphQOLWkdnOav0wMWYJr+gX3XqC0ae9DxrFRLEdPTkI/EupW3bk2ww0wxUXaxSb+EBQt0jTjWm4yDLLHTRHjE32jhXh53+XBDpoccyUh7nKNIOLeHd+xa8BR4LHhy49ZGzzI+3C3S+D3PS1iYeYW4SJFGZ+gTbkPqYJd+ZW7OgsQJbAcofEpoWtlPon3eafA9/Vg6TjHMg005IrLKs0VJcfNhTRDVuIfVaRsC1cDCH3pywEDYg4eyo7pRuz77oHQkAvEP8ZFAnwBBzWcrTeIrAmqXjQOCSZ7ZeyTRhyuVwkrjg== x-ms-exchange-antispam-messagedata: IjfYG8/BseKTz31HO2qSBYCADeLYenVLB6iIY/QmYj3n9NP5lgGqWhgquJ7WuA0B9je9zVmBSyt4Ckd86dXdjutxITcis6asgJYhfWTGJVkJ/Z59v+4ZEkimA5waChDtvV60iAYbw60KA/7If2lbXg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3318D6A11587449627F6EA679BD20AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4852 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT031.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)(39860400002)(136003)(396003)(376002)(346002)(46966005)(86362001)(30864003)(81156014)(7696005)(8936002)(52536014)(2906002)(478600001)(8676002)(5660300002)(186003)(966005)(19627405001)(33656002)(9686003)(55016002)(356005)(6506007)(336012)(82740400003)(70206006)(316002)(6862004)(53546011)(70586007)(26005)(82310400002)(81166007)(47076004)(4326008); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 9cc3a31c-33f3-42d6-96d3-08d7e6c9ca7d X-Forefront-PRVS: 03818C953D X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: sK1ezUpLaDrmiG5jNZw+ObMjMtjnYo6PUkapVzJlIyLmQ/LeOuaPOl10FoYLqq3WPkeGp9wcxIXUdlepTjrCUOXDsNMlFjQGdHitOwDikY53fSO7jmKtwLLAIx30X6UuDtWGDAAYDPqJVSFPTBx8sytH/wYKm/qS02N1tO9pUOUB7pHAD0GI2xf+8RGwrYYPgCx6F03jnmMoYcEL4t6m4aCNDKoq7N4RUaXkDsAOQTVasYwrITpgOBm8VmTj5eltRT0JDz/djPz3QXgsu1T6fiUkoJ5PNJqGVtfBTfME5miWoNiHSgNgkTMiPa0ucuH8D0wZF3QHTbNBP4pSwN67QK6DVq2KCqpIKhv4GxfQbzIQe/CC7YNcYjpUrfqVjBi1R3AfkTzU4Hb1KSUck5Xfq30ZbtHV/WUfcz5/+JGGUMd7mwOc8oimEXSCDtSitKAcFPr0KIP+B7b7J7U+JHnDKRFIkXd+yZZD8yp0OqDI8BOrVnrKorVdfLz4BjhBtaWXNDCXC2dNIDTVTpBLcbp4uByF0bxI2oRfRaZ3jxjDSmnByY19thWM1J76xwqLeN8+xZOKs74Px+V73IQnrmEWcg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Apr 2020 14:31:12.1713 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e11e2fe4-12f1-4470-950d-08d7e6c9ce65 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: DB8PR08MB3994 Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Wed, 22 Apr 2020 14:31:20 -0000 --_000_AM6PR08MB3318D6A11587449627F6EA679BD20AM6PR08MB3318eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hey Ekr, I uphold my preference for an entirely structured presentation of the header as AAD instead of the binary data and think it should be added to the list of options: 3. Compute AAD over logical presentation of record header. The security principle we decided on for TLS 1.3 was that the AEAD should c= over what is actually on the wire. I would be strongly opposed to going back on that. I don't think TLS 1.3 constitutes a precedent in either direction here, sin= ce the wire-format and the logical representation are simply the same in TLS 1.3? A more comparable ca= se seems to be cTLS, where the current draft retains the logical presentation of the TLS 1.3 AAD= , but omits the entire record-header on the wire. cTLS is actually a good example: You have a com= pression layer which is orthogonal to the rest of the protocol (e.g. omitting HS data from= the wire but not the transcript, or omitting the record header from the wire but not the= AAD), and I think all the DTLS 1.3 header compression techniques should fall into the= same category. Considering the effort spent on shaving off bytes in the DTLS header, I think re-introducing the explicit CID should be avoided. It seems perfectly acceptable to me to have implicit header data which is protected via AAD. This is only relevant if there is a common useful case in which you would n= eed to put multiple DTLS records in the same datagram. Are you aware of such a case? I can see the following uses: 1) Replying to KeyUpdate with Ack;;KeyUpdate, or replying to RequestConnect= ionID with Ack;;NewConnectionId 2) Sending multiple (short) app records if the application protocol doesn't= provide its own framing. > 1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spe= c/pull/143 This seems to be a mixture of logical and on-the-wire representation, which moreover duplicates the CID in case it is explicitly present in the header. Yes, so? Isn't this less efficient and undoes the arguable benefit of the current so= lution that there's no need to piece together an AAD buffer manually, because now you'd have to= ? Best, Hanno Looking forward to hearing other WG member's views, Hanno ________________________________ From: Eric Rescorla > Sent: Wednesday, April 22, 2020 2:23 AM To: Hanno Becker > Cc: tls@ietf.org > Subject: Re: [TLS] DTLS 1.3 AEAD additional data I think there are two potential resolutions to your CID issue: 1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spec/= pull/143 2. Forbid implicit CIDs (my preference) see: https://github.com/tlswg/dtls1= 3-spec/issues/144 Would like to hear what others in the WG think. -Ekr On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla > wrote: On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker > wrote: Hi all, To my understanding, DTLS 1.3 defines AEAD additional data for record prote= ction as the record header as seen on the wire. Quoting Draft 37, Section 4: ``` The entire header value shown in Figure 4 (but prior to record number encryption) is used as as the additional data value for the AEAD function. For instance, if the minimal variant is used, the AAD is 2 octets long. Note that this design is different from the additional data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. ``` I would like to suggest that DTLS 1.3 uses a structured representation of the record header instead, as do all other versions of [D]TLS as far as I understand. I am not in favor of this change as proposed. I think it is better to prote= ct the data that is actually on the wire than to allow for changes in the o= n-the-wire representation that are not reflected in the integrity check. The reasons for this are as follows, in decreasing order of my perception of importance: - Omission of Connection ID Regarding the presence of Connection IDs in multiple records within a single datagram, Draft 37 says: ``` Implementations which send multiple records in the same datagram SHOULD omit the connection id from all but the first record; receiving implementations MUST assume that any subsequent records without connection IDs belong to the same assocatiation. ``` This means that the Connection ID for non-initial records in a datagram containing multiple records is _not_ part of the AEAD additional data for those records, which seems wrong. Concretely, one could inject such non-initial records into other datagrams using different CIDs, and the record protection wouldn't notice it. This seems like a reasonable point, though it's not clear to me that there = is an actual problem here. I'd be in favor of explicitly including the CID = in the AD as well as the header. One might argue that CID shouldn't be part of the AEAD in the first place, but in any case, I believe the treatment should be uniform and not distinguish between initial and non-initial records in a datagram. We're not distinguishing it. The AD is protecting the record on the wire. - Modularity Decoupling the wire-presentation of the record header from record protection allows to implement record protection and the choice of record header independently: One piece of the implementation can take care of record protection - using the structured presentation of the record header - while another takes care of the wire-encoding. It is even possible to change the record header format in transit. This seems like a defect, not a feature. - Simplicity At first it seems that using the record header as an unstructured binary blob for AEAD makes things simpler, but I don't think this is the case: Prior to record decryption, the record sequence number needs to be decrypted, and for that purpose, the record header already has to be parsed. Hence, at the time of record decryption, the record header is already be present a modified, structured form, and retaining the corresponding modified binary form appears to create additional complexity which would be avoided if record protection would use the structured header presentation. I've implemented this for QUIC (I can't remember who at Mozilla did it for = DTLS) and it's not particularly difficult. - Uniformity with other [D]TLS versions I don't find this argument at all persuasive. To the contrary: we should br= eak with DTLS 1.2 in any case where it's an improvement and not too onerou= s. -Ekr Let me know what you think, Best, 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls 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. 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_AM6PR08MB3318D6A11587449627F6EA679BD20AM6PR08MB3318eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hey Ekr,

I uphold my preference for an entirely structured= presentation of
the header as AAD instead of the binary data and = think it should
be added to the list of options:

3. Compute AAD over logical presentation of recor= d header.

The security principle we decided on for TLS 1.3 = was that the AEAD should cover what is
actually on the wire. I would be strongly opposed= to going back on that.

I don't think TLS 1.3 constitutes a precedent in = either direction here, since the wire-format and the 
logical representation are simply the same in TLS= 1.3? A more comparable case seems to be cTLS, 
where the current draft retains the logical prese= ntation of the TLS 1.3 AAD, but omits the entire 
record-header on the wire. cTLS is actually a goo= d example:  You have a compression layer 
which is orthogonal to the rest of the protocol (= e.g. omitting HS data from the wire but 
not the transcript, or omitting the record header= from the wire but not the AAD), and 
I think all the DTLS 1.3 header compression techn= iques should fall into the same category.

Considering the effort spent on shaving off bytes in the DTLS header,<= /div>
I think re-introducing the explicit CID should be avoided. It seems
perfectly acceptable to me to have implicit header data which is
protected via AAD.

This is only relevant if there is a common useful case in which you wo= uld need to put multiple
DTLS records in the same datagram. Are you aware of such a case?

I can see the following uses:
1) Replying to KeyUpdate with Ack;;KeyUpdate, or replying to RequestCo= nnectionID with Ack;;NewConnectionId
2) Sending multiple (short) app records if the application protocol do= esn't provide its own framing.

> 1. Cryptographically prote= ct it as in https://github.com/tlswg/dtls13-spec/pull/143

This seems to be a mixture of logical and on-the-wire representation, = which
moreover duplicates the CID in case it is explicitly present in the he= ader.

Yes, so?

Isn't this less efficient and undoes the arguable benefit of the curre= nt solution that there's 
no need to piece together an AAD buffer manually, because now you'd ha= ve to? 

Best,
Hanno


Looking forward to hearing other WG member's views,
Hanno
F= rom: Eric Rescorla <ekr@rtfm.com>
Sent: Wednesday, April 22, 2020 2:23 AM
To: Hanno Becker <Hanno.Becker@arm.com>
Cc: tls@ietf.org <tls@ietf.org&g= t;
Subject: Re: [TLS] DTLS 1.3 AEAD additional data
 
I think there are two potential resolutions to your CID issue:

1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spec/pull/143
2. Forbid implicit CIDs (my preference) see: https://github.com/tlswg/dtls13-spec/issues/144

Would like to hear what others in the WG think.

-Ekr


On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker <Hanno.Becker@arm.com= > wrote:
Hi all,

To my understanding, DTL= S 1.3 defines AEAD additional data for record protection
as the record header as = seen on the wire. Quoting Draft 37, Section 4:

```
   The entire = header value shown in Figure 4 (but prior to record number
   encryption)= is used as as the additional data value for the AEAD
   function.&n= bsp; For instance, if the minimal variant is used, the AAD is 2
   octets long= .  Note that this design is different from the additional
   data calcul= ation for DTLS 1.2 and for DTLS 1.2 with Connection ID.
```

I would like to suggest = that DTLS 1.3 uses a structured representation
of the record header ins= tead, as do all other versions of [D]TLS as
far as I understand.

I am not in favor of this change as proposed. I think it is better to = protect the data that is actually on the wire than to allow for changes in = the on-the-wire representation that are not reflected in the integrity chec= k.


The reasons for this are= as follows, in decreasing order of
my perception of importa= nce:

- Omission of Connection= ID

  Regarding the pre= sence of Connection IDs in multiple records within
  a single datagram= , Draft 37 says:

```
   Implementat= ions which send multiple records in the same datagram
   SHOULD omit= the connection id from all but the first record;
   receiving i= mplementations MUST assume that any subsequent records
   without con= nection IDs belong to the same assocatiation.
```

  This means that t= he Connection ID for non-initial records in a
  datagram containi= ng multiple records is _not_ part of the AEAD
  additional data f= or those records, which seems wrong. Concretely,
  one could inject = such non-initial records into other datagrams
  using different C= IDs, and the record protection wouldn't notice it.

This seems like a reasonable point, though it's not clear to me that t= here is an actual problem here. I'd be in favor of explicitly including the= CID in the AD as well as the header.


  One might argue t= hat CID shouldn't be part of the AEAD in the first
  place, but in any case, I= believe the treatment should be uniform
  and not distinguish betwe= en initial and non-initial records in  
  a datagram.

We're not distinguishing it. The AD is protecting the record on the wi= re.


- Modularity

  Decoupling the wi= re-presentation of the record header from
  record protection= allows to implement record protection and
  the choice of rec= ord header independently: One piece of
  the implementatio= n can take care of record protection -
  using the structu= red presentation of the record header - while
  another takes car= e of the wire-encoding. It is even possible
  to change the rec= ord header format in transit.

This seems like a defect, not a feature.


- Simplicity

  At first it seems= that using the record header as an
  unstructured bina= ry blob for AEAD makes things simpler,
  but I don't think= this is the case: Prior to record
  decryption, the r= ecord sequence number needs to be
  decrypted, and fo= r that purpose, the record header already
  has to be parsed.= Hence, at the time of record decryption,
  the record header= is already be present a modified, structured
  form, and retaini= ng the corresponding modified binary form
  appears to create= additional complexity which would be
  avoided if record= protection would use the structured
  header presentati= on.

I've implemented this for QUIC (I can't remember who at Mozilla did it= for DTLS) and it's not particularly difficult.


- Uniformity with other = [D]TLS versions

I don't find this argument at all persuasive. To the contrary: we shou= ld break with  DTLS 1.2 in any case where it's an improvement and not = too onerous.

-Ekr




Let me know what you thi= nk,

Best,
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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.
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_AM6PR08MB3318D6A11587449627F6EA679BD20AM6PR08MB3318eurp_-- From nobody Wed Apr 22 07:47:54 2020 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 1B0F93A0DE2 for ; Wed, 22 Apr 2020 07:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 5-USASerfJpo for ; Wed, 22 Apr 2020 07:47:49 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6323A0DDC for ; Wed, 22 Apr 2020 07:47:48 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id 198so1896330lfo.7 for ; Wed, 22 Apr 2020 07:47:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7A5YeVQze+TH2xkZPjF893Ye08jdgV4GyLsOyS4zcgs=; b=zoQhNu5WuWePfFZRPNOuCUzCO8bK7RbfzGV+JuhmPMfA7U586zspA+msIvCl8VT47e MrQOsv9/QyuwbBCjMrjlyMw26DJJEujTQ5SeflZOBsFHETQRbhBEBjmZpm40B04FGMRE iohvk5Gn+bFy2ut/dWY7EDwxBERFwggmRgbPERojb/hcF9AT2QmZGkuZpKSrLx9eNkex 3ugXUo1MVLdloFQppQLG2BvfM3ZJjyQ3Pc0fS1C+mjLR++mQTKMMaGeQybQYM+nFYrlX ZwE+NrwCqqS1cmVVUzJie1+/5RlWfUhGIVa1FCXHwdVbMrRgHQplOjldAI/TihG1PjI0 82Hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7A5YeVQze+TH2xkZPjF893Ye08jdgV4GyLsOyS4zcgs=; b=ehm3quLR2s+KDYue/7r0Cu/mP9McjnZ5PGuQikylU4/hHIeFz9rarSuB6pI+/q71qD pBxz26c+1FiV2x3IxHhLx6WLhAiXkNF5A123XO6+o/i1WQa3uzkcQWN4XHl7wMlHlV5/ jScOkBNsUIHuDFc7w6+/GxmHqJ5YlZVwcPv3zC+8VMyLD1KioXX+7MMjSwLvBZ0YXqW+ +hUOdRpc8oTqgOvB04v45zvvWoFjcMRavldB+lBxaYwTSal+oQNoGgAiVIinkOdwK4cT rH6LzktY19rDO79tHMD1G9ioBFZIStse1grW/UzFkCxekBH46pmt6NuZPOkCfE2zK1j1 fo2g== X-Gm-Message-State: AGi0Puae/eat/2HtdEzIH7b6nFF3qSZ697lwMULy8DcD7kdgikHqXCxO lru/GF6xkZtRpKcM3+qj4B8wvGyljhVW/zwZSSDpSw== X-Google-Smtp-Source: APiQypJ9lTO3dHqjnG1L/Xm6aCDSs3ELN2Vj3zIc+P/Dn1j+HJitXo/ZBX78lKYOJJqbuU8b8K4xPEFiSvonD0kKRpY= X-Received: by 2002:a19:f806:: with SMTP id a6mr17409850lff.201.1587566866717; Wed, 22 Apr 2020 07:47:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 22 Apr 2020 07:47:10 -0700 Message-ID: To: Hanno Becker Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000025ef9a05a3e237eb" Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Wed, 22 Apr 2020 14:47:53 -0000 --00000000000025ef9a05a3e237eb Content-Type: text/plain; charset="UTF-8" On Wed, Apr 22, 2020 at 7:31 AM Hanno Becker wrote: > > Considering the effort spent on shaving off bytes in the DTLS header, > > I think re-introducing the explicit CID should be avoided. It seems > > perfectly acceptable to me to have implicit header data which is > > protected via AAD. > > > This is only relevant if there is a common useful case in which you would > need to put multiple > DTLS records in the same datagram. Are you aware of such a case? > > > I can see the following uses: > 1) Replying to KeyUpdate with Ack;;KeyUpdate, or replying to > RequestConnectionID with Ack;;NewConnectionId > 2) Sending multiple (short) app records if the application protocol > doesn't provide its own framing. > Neither of these seem particularly compelling to me. The first happens very infrequently, and I'm not really aware of a lot of cases of the second. > > 1. Cryptographically protect it as in > https://github.com/tlswg/dtls13-spec/pull/143 > > > This seems to be a mixture of logical and on-the-wire representation, which > > moreover duplicates the CID in case it is explicitly present in the header. > > > Yes, so? > > > Isn't this less efficient > Trivially. and undoes the arguable benefit of the current solution that there's > no need to piece together an AAD buffer manually, because now you'd have > to? > I don't recall making that argument. -Ekr > Best, > Hanno > > > Looking forward to hearing other WG member's views, > Hanno > ------------------------------ > *From:* Eric Rescorla > *Sent:* Wednesday, April 22, 2020 2:23 AM > *To:* Hanno Becker > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data > > I think there are two potential resolutions to your CID issue: > > 1. Cryptographically protect it as in > https://github.com/tlswg/dtls13-spec/pull/143 > 2. Forbid implicit CIDs (my preference) see: > https://github.com/tlswg/dtls13-spec/issues/144 > > Would like to hear what others in the WG think. > > -Ekr > > > On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla wrote: > > > > On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker wrote: > > Hi all, > > To my understanding, DTLS 1.3 defines AEAD additional data for record > protection > as the record header as seen on the wire. Quoting Draft 37, Section 4: > > ``` > The entire header value shown in Figure 4 (but prior to record number > encryption) is used as as the additional data value for the AEAD > function. For instance, if the minimal variant is used, the AAD is 2 > octets long. Note that this design is different from the additional > data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. > ``` > > I would like to suggest that DTLS 1.3 uses a structured representation > of the record header instead, as do all other versions of [D]TLS as > far as I understand. > > > I am not in favor of this change as proposed. I think it is better to > protect the data that is actually on the wire than to allow for changes in > the on-the-wire representation that are not reflected in the integrity > check. > > > The reasons for this are as follows, in decreasing order of > my perception of importance: > > - Omission of Connection ID > > Regarding the presence of Connection IDs in multiple records within > a single datagram, Draft 37 says: > > ``` > Implementations which send multiple records in the same datagram > SHOULD omit the connection id from all but the first record; > receiving implementations MUST assume that any subsequent records > without connection IDs belong to the same assocatiation. > ``` > > This means that the Connection ID for non-initial records in a > datagram containing multiple records is _not_ part of the AEAD > additional data for those records, which seems wrong. Concretely, > one could inject such non-initial records into other datagrams > using different CIDs, and the record protection wouldn't notice it. > > > This seems like a reasonable point, though it's not clear to me that there > is an actual problem here. I'd be in favor of explicitly including the CID > in the AD as well as the header. > > > > One might argue that CID shouldn't be part of the AEAD in the first > place, but in any case, I believe the treatment should be uniform > and not distinguish between initial and non-initial records in > a datagram. > > > We're not distinguishing it. The AD is protecting the record on the wire. > > > - Modularity > > Decoupling the wire-presentation of the record header from > record protection allows to implement record protection and > the choice of record header independently: One piece of > the implementation can take care of record protection - > using the structured presentation of the record header - while > another takes care of the wire-encoding. It is even possible > to change the record header format in transit. > > > This seems like a defect, not a feature. > > > - Simplicity > > At first it seems that using the record header as an > unstructured binary blob for AEAD makes things simpler, > but I don't think this is the case: Prior to record > decryption, the record sequence number needs to be > decrypted, and for that purpose, the record header already > has to be parsed. Hence, at the time of record decryption, > the record header is already be present a modified, structured > form, and retaining the corresponding modified binary form > appears to create additional complexity which would be > avoided if record protection would use the structured > header presentation. > > > I've implemented this for QUIC (I can't remember who at Mozilla did it for > DTLS) and it's not particularly difficult. > > > - Uniformity with other [D]TLS versions > > > I don't find this argument at all persuasive. To the contrary: we should > break with DTLS 1.2 in any case where it's an improvement and not too > onerous. > > -Ekr > > > > > Let me know what you think, > > 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 > > 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. > > 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. > --00000000000025ef9a05a3e237eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable



This seems to be a mixture of logical and on-the-wire representation, = which
moreover duplicates the CID in case it is explicitly present in the he= ader.

Yes, so?

Isn't this less efficient

Trivially.


and undoes the arguable benefit of the current solution = that there's=C2=A0
no need to piece together an AAD buffer manually, because now you'= d have to?=C2=A0

<= div>=C2=A0I don't recall making that argument.

-Ekr


Best,
Hanno


Looking forward to hearing other WG member's views,
Hanno
From: Eric Rescorla <ekr@rtfm.com>
Sent: Wednesday, April 22, 2020 2:23 AM
To: Hanno Becker <Hanno.Becker@arm.com>
Cc: tls@ietf.org <tls@ietf.org&g= t;
Subject: Re: [TLS] DTLS 1.3 AEAD additional data
=C2=A0
I think there are two potential resolutions to your CID issue:

1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spec/pull/143
2. Forbid implicit CIDs (my preference) see: https://github.com/tlswg/dtls13-spec/issues/144

Would like to hear what others in the WG think.

-Ekr


On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker <Hanno.Becker@arm.com= > wrote:
Hi all,

To my understanding, DTL= S 1.3 defines AEAD additional data for record protection
as the record header as = seen on the wire. Quoting Draft 37, Section 4:

```
=C2=A0 =C2=A0The entire = header value shown in Figure 4 (but prior to record number
=C2=A0 =C2=A0encryption)= is used as as the additional data value for the AEAD
=C2=A0 =C2=A0function.= =C2=A0 For instance, if the minimal variant is used, the AAD is 2
=C2=A0 =C2=A0octets long= .=C2=A0 Note that this design is different from the additional
=C2=A0 =C2=A0data calcul= ation for DTLS 1.2 and for DTLS 1.2 with Connection ID.
```

I would like to suggest = that DTLS 1.3 uses a structured representation
of the record header ins= tead, as do all other versions of [D]TLS as
far as I understand.

I am not in favor of this change as proposed. I think it is better to = protect the data that is actually on the wire than to allow for changes in = the on-the-wire representation that are not reflected in the integrity chec= k.


The reasons for this are= as follows, in decreasing order of
my perception of importa= nce:

- Omission of Connection= ID

=C2=A0 Regarding the pre= sence of Connection IDs in multiple records within
=C2=A0 a single datagram= , Draft 37 says:

```
=C2=A0 =C2=A0Implementat= ions which send multiple records in the same datagram
=C2=A0 =C2=A0SHOULD omit= the connection id from all but the first record;
=C2=A0 =C2=A0receiving i= mplementations MUST assume that any subsequent records
=C2=A0 =C2=A0without con= nection IDs belong to the same assocatiation.
```

=C2=A0 This means that t= he Connection ID for non-initial records in a
=C2=A0 datagram containi= ng multiple records is _not_ part of the AEAD
=C2=A0 additional data f= or those records, which seems wrong. Concretely,
=C2=A0 one could inject = such non-initial records into other datagrams
=C2=A0 using different C= IDs, and the record protection wouldn't notice it.

This seems like a reasonable point, though it's not clear to me th= at there is an actual problem here. I'd be in favor of explicitly inclu= ding the CID in the AD as well as the header.


=C2=A0 One might argue t= hat CID shouldn't be part of the AEAD in the first
=C2=A0 place, but in any case, I= believe the treatment should be uniform
=C2=A0 and not distinguish betwe= en initial and non-initial records in=C2=A0=C2=A0
=C2=A0 a datagram.

We're not distinguishing it. The AD is protecting the record on th= e wire.


- Modularity

=C2=A0 Decoupling the wi= re-presentation of the record header from
=C2=A0 record protection= allows to implement record protection and
=C2=A0 the choice of rec= ord header independently: One piece of
=C2=A0 the implementatio= n can take care of record protection -
=C2=A0 using the structu= red presentation of the record header - while
=C2=A0 another takes car= e of the wire-encoding. It is even possible
=C2=A0 to change the rec= ord header format in transit.

This seems like a defect, not a feature.


- Simplicity

=C2=A0 At first it seems= that using the record header as an
=C2=A0 unstructured bina= ry blob for AEAD makes things simpler,
=C2=A0 but I don't t= hink this is the case: Prior to record
=C2=A0 decryption, the r= ecord sequence number needs to be
=C2=A0 decrypted, and fo= r that purpose, the record header already
=C2=A0 has to be parsed.= Hence, at the time of record decryption,
=C2=A0 the record header= is already be present a modified, structured
=C2=A0 form, and retaini= ng the corresponding modified binary form
=C2=A0 appears to create= additional complexity which would be
=C2=A0 avoided if record= protection would use the structured
=C2=A0 header presentati= on.

I've implemented this for QUIC (I can't remember who at Mozill= a did it for DTLS) and it's not particularly difficult.


- Uniformity with other = [D]TLS versions

I don't find this argument at all persuasive. To the contrary: we = should break with=C2=A0 DTLS 1.2 in any case where it's an improvement = and not too onerous.

-Ekr




Let me know what you thi= nk,

Best,
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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.
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.
--00000000000025ef9a05a3e237eb-- From nobody Wed Apr 22 09:23:39 2020 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 18A833A1037 for ; Wed, 22 Apr 2020 09:23:38 -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=UYLkhaiy; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=UYLkhaiy 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 r-HaEKtQyyCd for ; Wed, 22 Apr 2020 09:23:34 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70058.outbound.protection.outlook.com [40.107.7.58]) (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 CC48E3A102D for ; Wed, 22 Apr 2020 09:23:33 -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=Q1A1Wy0Dwh1jWKl7a+PT6217Cb8bs4/AAIbVvQKh6/w=; b=UYLkhaiy0OYIlFaO7itEsNDgjs5uLyaxP3Q+nBCnymStYTgl8Dl8jIlXhcRSuT6fWhUPYwyngUOa1ZHCm4H4bAIvQr8n4oXXsTvxxjhpA92CnYJUChxRETJCb6sKrS9Fis+nqu2hiJ/NWXE9YPqtQ/ZX85QebIzQrYGM/batFro= Received: from DB6PR0202CA0029.eurprd02.prod.outlook.com (2603:10a6:4:a5::15) by AM6PR08MB3862.eurprd08.prod.outlook.com (2603:10a6:20b:8c::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.27; Wed, 22 Apr 2020 16:23:30 +0000 Received: from DB5EUR03FT032.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:a5:cafe::82) by DB6PR0202CA0029.outlook.office365.com (2603:10a6:4:a5::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Wed, 22 Apr 2020 16:23:30 +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 DB5EUR03FT032.mail.protection.outlook.com (10.152.20.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.18 via Frontend Transport; Wed, 22 Apr 2020 16:23:30 +0000 Received: ("Tessian outbound 43fc5cd677c4:v53"); Wed, 22 Apr 2020 16:23:30 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: dc68b9283a574c9e X-CR-MTA-TID: 64aa7808 Received: from 34623c100c1f.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id C6950AA1-9C4A-4025-9CB9-F884DB1B4927.1; Wed, 22 Apr 2020 16:23:24 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 34623c100c1f.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 22 Apr 2020 16:23:24 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R7dvMFArZn1OH5UHqyElls//fmpxf04ssXazrVXh30TEgwT/Auv92Mo75dcp+NZJoP6AZtZvdod4BlBf03UGkB6iYwMfI2m8uCOlb2KMGC9ePlMjVDh+L/G+qEdD5LWWGUwLR1pIgxLKmkcQ7nSGFdP4sjc7tjxsBPv97wMNx3ebj93Ceb3/M2mrWV1Aq2ILvXViglKD7gK7VTbDE+ps7hV3Mev+VX0oq4Nlixzf42dhKiEuIejWbT+kFYAdOd5jpl86M7f4MMZQIZnjlvN8VbNOY3q4u8eivGh3yEsYNaRrp99PFzMEvejcUk+JUSEtInH6n2+/dS+0B8gx3+97wQ== 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=Q1A1Wy0Dwh1jWKl7a+PT6217Cb8bs4/AAIbVvQKh6/w=; b=FnQSZ6L+sAD7dLHhFziFUGcvIir5g1oFcfFmV5aKUQ75aZztU5taI9mwHaAyBmLWwd3NOmZaoUVPm637JvoCK9mkk9vz5wbcYL6J5CBtitso0aHT4I3iKUppsGz0IIeIuHlY/OULzUNRf99SZ8wdA33a2ECwboB7AzqO9Hg/vdUfhubafc5zsQnB0gzBuVoy71+v9/7yt5h62827/zXDFg6ARPYxb7dP/t5r//1Ld+ixf6B+xSrMeBeHUWgw348dDhbdK68QBhBGQfe/eghBC8k+t/r9912wiTxuHMjDAf23wDoxieTaQxfY5AlGGJNu3V8g1zY7h8vOSGrcSUie+A== 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=Q1A1Wy0Dwh1jWKl7a+PT6217Cb8bs4/AAIbVvQKh6/w=; b=UYLkhaiy0OYIlFaO7itEsNDgjs5uLyaxP3Q+nBCnymStYTgl8Dl8jIlXhcRSuT6fWhUPYwyngUOa1ZHCm4H4bAIvQr8n4oXXsTvxxjhpA92CnYJUChxRETJCb6sKrS9Fis+nqu2hiJ/NWXE9YPqtQ/ZX85QebIzQrYGM/batFro= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6PR08MB4769.eurprd08.prod.outlook.com (2603:10a6:20b:d0::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Wed, 22 Apr 2020 16:23:23 +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.2921.030; Wed, 22 Apr 2020 16:23:23 +0000 From: Hanno Becker To: Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] DTLS 1.3 AEAD additional data Thread-Index: AQHWF+iN1gKILcDltkmRr5OfopCaAaiD3VMAgAB8FQCAAE7VmIAAawyAgAAHdS6AAB8+AIAACQCR Date: Wed, 22 Apr 2020 16:23:23 +0000 Message-ID: References: , In-Reply-To: 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: 517655d2-2389-4dce-d7a5-08d7e6d97ed3 x-ms-traffictypediagnostic: AM6PR08MB4769:|AM6PR08MB3862: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 03818C953D 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:(4636009)(376002)(346002)(366004)(396003)(136003)(39860400002)(71200400001)(7696005)(6506007)(26005)(4326008)(186003)(316002)(8936002)(8676002)(81156014)(86362001)(53546011)(6916009)(66556008)(66476007)(52536014)(76116006)(5660300002)(33656002)(9686003)(66446008)(64756008)(2906002)(478600001)(55016002)(19627405001)(966005)(66946007); 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: gXpwWL/NKRDlFjLnoSIqdR//GdlZTfKdUCc42OsF29/0iDuR3Ly4ndlj3GysvugVH58P6HJNb6iAVMP+qDZvxAAMbMf/QCMsEeKW5wDQpE+L1fZOLG9ErQy4UpChYxwFY+wVtRVUzDQwmffe/NwJ4CQpocEx81XX2IhI7blWndEMCZHdzw0Wb/u2VpSNsu27fN6iw31EKpC7+jiI6iRcS5Bi7d/19e++ChkFIUuQ/gFAuRWQaLlj2W9HoeUC4DPlZSku52nGsjjqJkRsPPjRMLyWJUREbUJZn2nRT7s9FQFEQlTaETk7t2T5PjyxDIvF75N+k8xeWCUw+nMjyAsKuBtaT/WW9GOg2+Ydjolp3g62jk1h7REGVoeLK5MO74MWeuYV+cVRorlpOyzoxGV+bO4FQaFVOzlSx/nP7T22Oejru7EFKPX6XaYWA5wB3VYCIOeIJLS7w2VtLG7CmW2HKmryXnw7Ts6UXlkXdabBFOB2PmuGY07X2dwaCLEUpfr1Y4xae9dENT/y0OoYq+tprw== x-ms-exchange-antispam-messagedata: UysydkuFfW4yTqmzTgWy18n3XUkfzsuPSlQxldYvQJn9KPllINTF8vfeR+WqfHZy/Whk1RHzWq8CekzRH/WRFhiktjb1uZDbay8unrmUtK4i0Je5CE7cHGZicQ8dyaERpLH+vLFzudlno2B/J2F3RA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3318717D21E69A2373AC1ACE9BD20AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4769 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT032.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)(39860400002)(396003)(376002)(136003)(346002)(46966005)(7696005)(478600001)(82740400003)(356005)(6862004)(19627405001)(81166007)(4326008)(966005)(86362001)(8676002)(81156014)(52536014)(55016002)(9686003)(336012)(8936002)(2906002)(30864003)(26005)(6506007)(5660300002)(33656002)(316002)(70586007)(47076004)(53546011)(70206006)(186003)(82310400002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: b47ac96b-69bd-488b-99b5-08d7e6d97a89 X-Forefront-PRVS: 03818C953D X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: AEHYqJLM5GwJW7u+++xq4O++LDQgLKKcQqUstxgt8GWEKGXl8umJ8geIRzUvE0WgI8EhVbI8+7yJ/Z7PmMXj4GERz17aaygU1v+1s0wMbnn5kIilz7N9x59gU/icuPx7yHHQ/QBTpF16JHi8E0OhVcg+A/axx9a5DH0nY40iG711spFA2u/v0MRc+3U8OGaIGe9jGDHc4G/MaSabvrcjCjcmtZpoaAXsuaMU8CKVnE3jDXD7H+YPHPTCFny5hfy3jz2Y9tnEGh6KZBvJoqR0CgIjecog5OzY54Lzqj1JbYVwUIWpoXXm3SR01jqb7U+ZfJDmIsyXHAKbvoRr8bM6lKYwr46FSLr9un4YJYqm2yYyL2wu1y6JiygBI0+juQpXidPyEOMuHFmYswUkejWuVR4FZf3iQhW0wDnfjSb2wQmeW/COhsINZgfgtFG5+DctQNBiB9ccdq0zMudAtA9FnlxcTgYvHwjLnMy7194cYyAmgKhyCrYY0a8IVmipiA0sl75Y6m8DmIKnkCjc2E/fBIR+l0dmOxW07Ahnn2ND9GMvJ8/p7bqBcRxx56NYqJMINbixRAIPqjQyo5vgkyzJmA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Apr 2020 16:23:30.6248 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 517655d2-2389-4dce-d7a5-08d7e6d97ed3 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: AM6PR08MB3862 Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Wed, 22 Apr 2020 16:23:38 -0000 --_000_AM6PR08MB3318717D21E69A2373AC1ACE9BD20AM6PR08MB3318eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ekr, I still don't yet understand which concrete problems you see with the proposed solution. In particular, as mentioned in the last mail, I don'= t think there is a contradiction with any design choice for TLS 1.3 - in contrast, decoup= ling record header compression from record protection aligns with how cTLS proposes to compress TLS 1.3 without affecting any cryptographic computatio= ns and hence hopefully easing carrying over the security analysis of TLS 1.3. = This decoupling doesn't hold for the current DTLS 1.3 draft, and we seem to agree that in t= he case of CIDs, it has already led to one missing cryptographic binding. Anyway, let's wait for more opinions. Best, Hanno ________________________________ From: Eric Rescorla Sent: Wednesday, April 22, 2020 3:47 PM To: Hanno Becker Cc: tls@ietf.org Subject: Re: [TLS] DTLS 1.3 AEAD additional data On Wed, Apr 22, 2020 at 7:31 AM Hanno Becker > wrote: Considering the effort spent on shaving off bytes in the DTLS header, I think re-introducing the explicit CID should be avoided. It seems perfectly acceptable to me to have implicit header data which is protected via AAD. This is only relevant if there is a common useful case in which you would n= eed to put multiple DTLS records in the same datagram. Are you aware of such a case? I can see the following uses: 1) Replying to KeyUpdate with Ack;;KeyUpdate, or replying to RequestConnect= ionID with Ack;;NewConnectionId 2) Sending multiple (short) app records if the application protocol doesn't= provide its own framing. Neither of these seem particularly compelling to me. The first happens very= infrequently, and I'm not really aware of a lot of cases of the second. > 1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spe= c/pull/143 This seems to be a mixture of logical and on-the-wire representation, which moreover duplicates the CID in case it is explicitly present in the header. Yes, so? Isn't this less efficient Trivially. and undoes the arguable benefit of the current solution that there's no need to piece together an AAD buffer manually, because now you'd have to= ? I don't recall making that argument. -Ekr Best, Hanno Looking forward to hearing other WG member's views, Hanno ________________________________ From: Eric Rescorla > Sent: Wednesday, April 22, 2020 2:23 AM To: Hanno Becker > Cc: tls@ietf.org > Subject: Re: [TLS] DTLS 1.3 AEAD additional data I think there are two potential resolutions to your CID issue: 1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spec/= pull/143 2. Forbid implicit CIDs (my preference) see: https://github.com/tlswg/dtls1= 3-spec/issues/144 Would like to hear what others in the WG think. -Ekr On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla > wrote: On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker > wrote: Hi all, To my understanding, DTLS 1.3 defines AEAD additional data for record prote= ction as the record header as seen on the wire. Quoting Draft 37, Section 4: ``` The entire header value shown in Figure 4 (but prior to record number encryption) is used as as the additional data value for the AEAD function. For instance, if the minimal variant is used, the AAD is 2 octets long. Note that this design is different from the additional data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. ``` I would like to suggest that DTLS 1.3 uses a structured representation of the record header instead, as do all other versions of [D]TLS as far as I understand. I am not in favor of this change as proposed. I think it is better to prote= ct the data that is actually on the wire than to allow for changes in the o= n-the-wire representation that are not reflected in the integrity check. The reasons for this are as follows, in decreasing order of my perception of importance: - Omission of Connection ID Regarding the presence of Connection IDs in multiple records within a single datagram, Draft 37 says: ``` Implementations which send multiple records in the same datagram SHOULD omit the connection id from all but the first record; receiving implementations MUST assume that any subsequent records without connection IDs belong to the same assocatiation. ``` This means that the Connection ID for non-initial records in a datagram containing multiple records is _not_ part of the AEAD additional data for those records, which seems wrong. Concretely, one could inject such non-initial records into other datagrams using different CIDs, and the record protection wouldn't notice it. This seems like a reasonable point, though it's not clear to me that there = is an actual problem here. I'd be in favor of explicitly including the CID = in the AD as well as the header. One might argue that CID shouldn't be part of the AEAD in the first place, but in any case, I believe the treatment should be uniform and not distinguish between initial and non-initial records in a datagram. We're not distinguishing it. The AD is protecting the record on the wire. - Modularity Decoupling the wire-presentation of the record header from record protection allows to implement record protection and the choice of record header independently: One piece of the implementation can take care of record protection - using the structured presentation of the record header - while another takes care of the wire-encoding. It is even possible to change the record header format in transit. This seems like a defect, not a feature. - Simplicity At first it seems that using the record header as an unstructured binary blob for AEAD makes things simpler, but I don't think this is the case: Prior to record decryption, the record sequence number needs to be decrypted, and for that purpose, the record header already has to be parsed. Hence, at the time of record decryption, the record header is already be present a modified, structured form, and retaining the corresponding modified binary form appears to create additional complexity which would be avoided if record protection would use the structured header presentation. I've implemented this for QUIC (I can't remember who at Mozilla did it for = DTLS) and it's not particularly difficult. - Uniformity with other [D]TLS versions I don't find this argument at all persuasive. To the contrary: we should br= eak with DTLS 1.2 in any case where it's an improvement and not too onerou= s. -Ekr Let me know what you think, Best, 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls 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. 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. 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_AM6PR08MB3318717D21E69A2373AC1ACE9BD20AM6PR08MB3318eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Ekr,

I still don't yet understand which conc= rete problems you see with 
the proposed solution. In particular, as mentioned in the last mail, I don't = think there 
is a contradiction with any design  record header compression from record protection aligns with how cTLS 
proposes to compress TLS 1.3 without affecting any cryptographic computations
and hence hopefully easing carrying over the security= analysis of TLS 1.3. This decoupling 
doesn't hold for the current DTLS 1.3 draft, and we seem to agree that in the case of CIDs, 
it has already led to one missing cryptographic binding.

Anyway, let's wait for mor= e opinions.

Best,
Hanno

From: Eric Rescorla <ekr= @rtfm.com>
Sent: Wednesday, April 22, 2020 3:47 PM
To: Hanno Becker <Hanno.Becker@arm.com>
Cc: tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] DTLS 1.3 AEAD additional data
 


On Wed, Apr 22, 2020 at 7:31 AM Han= no Becker <Hanno.Becker@arm.com<= /a>> wrote:

Considering the effort spent on shaving off bytes in the DTLS header,<= /div>
I think re-introducing the explicit CID should be avoided. It seems
perfectly acceptable to me to have implicit header data which is
protected via AAD.

This is only relevant if there is a common useful case in which you wo= uld need to put multiple
DTLS records in the same datagram. Are you aware of such a case?

I can see the following uses:
1) Replying to KeyUpdate with Ack;;KeyUpdate, or replying to RequestCo= nnectionID with Ack;;NewConnectionId
2) Sending multiple (short) app records if the application protocol do= esn't provide its own framing.

Neither of these seem particularly compelling to me. The first happens= very infrequently, and I'm not really aware of a lot of cases of the secon= d.



Trivially.


and undoes the arguable benefit of the current solution that there's&n= bsp;
no need to piece together an AAD buffer manually, because now you'd ha= ve to? 

 I don't recall making that argument.

-Ekr


Best,
Hanno


Looking forward to hearing other WG member's views,
Hanno
From: Eric Rescorla <ekr@rtfm.com>
Sent: Wednesday, April 22, 2020 2:23 AM
To: Hanno Becker <Hanno.Becker@arm.com>
Cc: tls@ietf.org <tls@ietf.org&g= t;
Subject: Re: [TLS] DTLS 1.3 AEAD additional data
 
I think there are two potential resolutions to your CID issue:

1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spec/pull/143
2. Forbid implicit CIDs (my preference) see: https://github.com/tlswg/dtls13-spec/issues/144

Would like to hear what others in the WG think.

-Ekr


On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla <ekr@rtfm.com> wrote:


On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker <Hanno.Becker@arm.com= > wrote:
Hi all,

To my understanding, DTL= S 1.3 defines AEAD additional data for record protection
as the record header as = seen on the wire. Quoting Draft 37, Section 4:

```
   The entire = header value shown in Figure 4 (but prior to record number
   encryption)= is used as as the additional data value for the AEAD
   function.&n= bsp; For instance, if the minimal variant is used, the AAD is 2
   octets long= .  Note that this design is different from the additional
   data calcul= ation for DTLS 1.2 and for DTLS 1.2 with Connection ID.
```

I would like to suggest = that DTLS 1.3 uses a structured representation
of the record header ins= tead, as do all other versions of [D]TLS as
far as I understand.

I am not in favor of this change as proposed. I think it is better to = protect the data that is actually on the wire than to allow for changes in = the on-the-wire representation that are not reflected in the integrity chec= k.


The reasons for this are= as follows, in decreasing order of
my perception of importa= nce:

- Omission of Connection= ID

  Regarding the pre= sence of Connection IDs in multiple records within
  a single datagram= , Draft 37 says:

```
   Implementat= ions which send multiple records in the same datagram
   SHOULD omit= the connection id from all but the first record;
   receiving i= mplementations MUST assume that any subsequent records
   without con= nection IDs belong to the same assocatiation.
```

  This means that t= he Connection ID for non-initial records in a
  datagram containi= ng multiple records is _not_ part of the AEAD
  additional data f= or those records, which seems wrong. Concretely,
  one could inject = such non-initial records into other datagrams
  using different C= IDs, and the record protection wouldn't notice it.

This seems like a reasonable point, though it's not clear to me that t= here is an actual problem here. I'd be in favor of explicitly including the= CID in the AD as well as the header.


  One might argue t= hat CID shouldn't be part of the AEAD in the first
  place, but in any case, I= believe the treatment should be uniform
  and not distinguish betwe= en initial and non-initial records in  
  a datagram.

We're not distinguishing it. The AD is protecting the record on the wi= re.


- Modularity

  Decoupling the wi= re-presentation of the record header from
  record protection= allows to implement record protection and
  the choice of rec= ord header independently: One piece of
  the implementatio= n can take care of record protection -
  using the structu= red presentation of the record header - while
  another takes car= e of the wire-encoding. It is even possible
  to change the rec= ord header format in transit.

This seems like a defect, not a feature.


- Simplicity

  At first it seems= that using the record header as an
  unstructured bina= ry blob for AEAD makes things simpler,
  but I don't think= this is the case: Prior to record
  decryption, the r= ecord sequence number needs to be
  decrypted, and fo= r that purpose, the record header already
  has to be parsed.= Hence, at the time of record decryption,
  the record header= is already be present a modified, structured
  form, and retaini= ng the corresponding modified binary form
  appears to create= additional complexity which would be
  avoided if record= protection would use the structured
  header presentati= on.

I've implemented this for QUIC (I can't remember who at Mozilla did it= for DTLS) and it's not particularly difficult.


- Uniformity with other = [D]TLS versions

I don't find this argument at all persuasive. To the contrary: we shou= ld break with  DTLS 1.2 in any case where it's an improvement and not = too onerous.

-Ekr




Let me know what you thi= nk,

Best,
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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.
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.
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_AM6PR08MB3318717D21E69A2373AC1ACE9BD20AM6PR08MB3318eurp_-- From nobody Wed Apr 22 10:10:19 2020 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 D6E843A1080 for ; Wed, 22 Apr 2020 10:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=CiJMH0zk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YK9wNb74 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 JV8-BdppApgJ for ; Wed, 22 Apr 2020 10:10:16 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C20E3A1077 for ; Wed, 22 Apr 2020 10:10:16 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7FE205C0284 for ; Wed, 22 Apr 2020 13:10:15 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 22 Apr 2020 13:10:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=8Pz/c00i30KzE3byOeM07ro6pZLut1z shZ3mZYvgB5Q=; b=CiJMH0zkLf0L9Cs3xG+GRIEeg7o4vjck0sUCS9iI5m8l4Om BPPSFjsrEnAvKBUX2w6tl9Py7igyO4x2e3MTpoODkIDz2DRs6Fe8HOoMi5sTW6tz AobZjEa5PPJr+vg6nRXNmJy5CsR2U9mo1FL9DDzENHL1e9mjb666hQNbCABv6u34 rNmxFtxjaEvsgxGYNwPEx7y9SPSxk7RueNtls9L5uRY6FOCL3ECwR9qJusIziknX 6qRzbEtu2nthPyzh8eOmBnS4LcxCtYrgcw+96ryyZWCOVGwLFK0vrunmzg7QbmIM Pw4HHs/rvkinFXpD90GQ4VXFFGlv1JlPx1v7SOg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8Pz/c0 0i30KzE3byOeM07ro6pZLut1zshZ3mZYvgB5Q=; b=YK9wNb74a/0Bit3rRwQlt7 SC/E8Tm+zYq2+OGPKcX89bRXEZh7ouqbNWwEwU5f5u5c0XUpoRRXN1R4BWoUxK3r 7ZdCLRPIEvhRwxo78eCsjBuyRPZzEHor3M3RF8kW+Dh+oRW+F3gA55oy3SxgT+YE nFCqIO/e9jOaUkcKs8szKJEQ1rVmVFJjteBOyIrnL5DPWZhUtRnzT2TVWb6K2bty iFjZCbnagF6st21vVKlgBqahwoi07X6tEmXwXkrkcV0IGbu4D/pu69GPc5ZIYQxF Vt8eucjNepkPaPoUeBtLtvh+t5UAHhkmxyjBJrCYKCz5izki0mnJFrkT3sCDlatA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeejgddutdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C3553180091; Wed, 22 Apr 2020 13:10:14 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <9074c915-2482-46a2-be99-cdf72939ec7b@www.fastmail.com> In-Reply-To: <5baf193953c94e3093fda66c8e3baa4d@verisign.com> References: <5baf193953c94e3093fda66c8e3baa4d@verisign.com> Date: Wed, 22 Apr 2020 10:09:54 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Comments on draft-dt-tls-external-psk-guidance-01 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: Wed, 22 Apr 2020 17:10:18 -0000 Thanks for the feedback, Scott. Please see inline below. On Mon, Apr 20, 2020, at 7:26 AM, Hollenbeck, Scott wrote: > Here are a few comments gathered from Verisign Labs on > draft-dt-tls-external-psk-guidance-01: > > 1. Sec. 6, requirement 1 states "Low entropy keys are only secure > against active attack if a Password Authenticated Key Exchange (PAKE) > is used with TLS." "only secure ... if" may be too strong a statement, > because there could be other mechanisms for increasing the entropy of a > pre-shared key that do not meet the formal definition of a PAKE. > Moreover, as defined in draft-barnes-tls-pake, a PAKE repurposes the DH > key share to carry a transformed version of the EPSK, so it involves a > different architecture than the ordinary process for incorporating > EPSKs into the TLS key schedule that is assumed in most of the present > draft. > > If the goal of the present draft is to encompass PAKEs as well as the > ordinary process, then the scope of the draft should be broadened to > something like "handshakes based on EPSKs, whether through the ordinary > process of incorporating them into the key schedule, or through > alternate mechanisms such as PAKE where the DH key share is based on > the EPSK." > > Alternatively, the statement in requirement 1 could be rephrased as follows: > > "If only low-entropy keys are available, then key establishment > mechanisms such as Password Authenticated Key Exchange (PAKE) that > mitigate the risk of offline dictionary attacks MUST be employed. Note > that these mechanisms do not necessarily follow the same architecture > as the ordinary process for incorporating EPSKs described in this > draft." This seems like a reasonable proposal to me. Specifying integration with PAKEs is (or was intended to be) out of scope, and this clarifies the requirement without widening the scope. > 2. Sec. 6, requirement 2 states, "Each PSK MUST NOT be shared between > with more than two logical nodes." This "MUST NOT" is stronger than > the "NOT RECOMMENDED to share the same PSK between more than one client > and server" > In Sec. 7 and would exclude group PSK use cases that are acknowledged > in that section. The requirement is also inconsistent with this > statement in Appendix B of draft-ietf-tls-external-psk-importer: > > "Applications which require authenticating finer-grained roles while > still configuring a single shared PSK across all nodes can resolve this > mismatch either by exchanging roles over the TLS connection after the > handshake or by incorporating the roles of both the client and server > into the IPSK context string." > > If the intent is to restrict use to at most two nodes, then requirement > 2 should go even further and restrict use to one node in a TLS client > role, and one in a TLS server role. > > We would therefore suggest that requirement 2 be changed to something > like the following: > > "Unless other accommodations are made, each PSK MUST be restricted in > its use to at most two logical nodes: one logical node in a TLS client > role and one logical node in a TLS server role. (The two logical nodes > MAY be the same, in different roles.) Two acceptable accommodations > are described in [draft-ietf-tls-external-psk-importer]: exchanging > client and server identifiers over the TLS connection after the > handshake; and incorporating identifiers for both the client and the > server into the context string for an EPSK importer." > > (Note that we've changed "roles" to "identifiers" to align with Sec. 7) This is a *great* suggestion! Thank you for clarifying in ways we could not. I'll take it. > > Related to this, "logical node" should be defined somewhere, e.g., "For > purposes of this document, a logical node is a computing presence that > other parties can interact with via the TLS protocol. A logical node > could potentially be realized with multiple physical instances > operating under common administrative control, e.g., a server farm." > Alternatively, the term "endpoint," which is used elsewhere in this > document, could be used here as well (perhaps also avoiding the single > use of "agent"). Yep, defining "logical node" would be great. We should probably have a separate definition section up front to consolidate these terms in one place. We can work with your suggestions and make that happen. > 3. Sec. 7 recommends that that each node selects one globally unique > identifier for all PSK handshakes, but without giving rationale why > this approach is preferred for mitigating the attacks mentioned earlier > in the section. This may be limiting, because a logical node may > legitimately be known to different endpoints by different identifiers: > a domain name in some cases, an IPv4 address in other cases, and an > IPv6 address in still other cases. We would therefore recommend > relaxing this recommendation. Since it's merely a recommendation, I think we ought to keep it. It's a simple deployment model that solves issues. We could list your use case as a counter example as to when this recommendation may not be appropriate. Would that work? > 4. General. The draft makes no mention of certificate-based > authentication in connection with EPSKs, for instance as described in > in RFC 8773, "TLS 1.3 Extension for Certificate-based Authentication > with an External Pre-Shared Key." We understand that use of external > PSKs with certificates is out of scope for the design team. > Certificate-based authentication, potentially in combination with a DH > exchange, can improve the security properties of TLS handshakes based > on EPSKs and help protect against both rerouting attacks and > impersonation attacks. Is there any interest in adding some guiding > text to the document before it's adopted by the WG? We're willing to > provide text for consideration. Sure, we're absolutely open to contributions! You're right that it's out of scope, though it could be useful in an appendix, or wherever else you think it's appropriate. Best, Chris From nobody Wed Apr 22 12:29:15 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4BE3A003E; Wed, 22 Apr 2020 12:29:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Cc: tls-chairs@ietf.org, The IESG , tls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158758375111.29484.11612899425897675469@ietfa.amsl.com> Date: Wed, 22 Apr 2020 12:29:11 -0700 Archived-At: Subject: [TLS] WG Action: Rechartered Transport Layer Security (tls) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 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: Wed, 22 Apr 2020 19:29:12 -0000 The Transport Layer Security (tls) WG in the Security Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the WG Chairs. Transport Layer Security (tls) ----------------------------------------------------------------------- Current status: Active WG Chairs: Christopher Wood Joseph Salowey Sean Turner Assigned Area Director: Benjamin Kaduk Security Area Directors: Benjamin Kaduk Roman Danyliw Mailing list: Address: tls@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/tls Archive: https://mailarchive.ietf.org/arch/browse/tls/ Group page: https://datatracker.ietf.org/group/tls/ Charter: https://datatracker.ietf.org/doc/charter-ietf-tls/ The TLS (Transport Layer Security) working group was established in 1996 to standardize a 'transport layer' security protocol. The basis for the work was SSL (Secure Socket Layer) v3.0 [RFC6101]. The TLS working group has completed a series of specifications that describe the TLS protocol v1.0 [RFC2246], v1.1 [RFC4346], v1.2 [RFC5346], and v1.3 [RFC8446], and DTLS (Datagram TLS) v1.0 [RFC4347], v1.2 [RFC6347], and v1.3 [draft-ietf-tls-dtls13], as well as extensions to the protocols and ciphersuites. The working group aims to achieve three goals. First, improve the applicability and suitability of the TLS family of protocols for use in emerging protocols and use cases. This includes extensions or changes that help protocols better use TLS as an authenticated key exchange protocol, or extensions that help protocols better leverage TLS security properties, such as Exported Authenticators. Extensions that focus specifically on protocol extensibility are also in scope. This goal also includes protocol changes that reduce TLS resource consumption without affecting security. Extensions that help reduce TLS handshake size meet this criterion. The second working group goal is to improve security, privacy, and deployability. This includes, for example, Delegated Credentials and Encrypted SNI. Security and privacy goals will place emphasis on the following: - Encrypt the ClientHello SNI (Server Name Indication) and other application-sensitive extensions, such as ALPN (Application-Layer Protocol Negotiation). - Identify and mitigate other (long-term) user tracking or fingerprinting vectors enabled by TLS deployments and implementations. The third goal is to maintain current and previous version of the (D)TLS protocol as well as to specify general best practices for use of (D)TLS, extensions to (D)TLS, and cipher suites. This includes recommendations as to when a particular version should be deprecated. Changes or additions to older versions of (D)TLS whether via extensions or ciphersuites are discouraged and require significant justification to be taken on as work items. The working group will also place a priority in minimizing gratuitous changes to (D)TLS. Milestones: Jul 2020 - Submit "Deprecating MD5 and SHA-1 signature hashes in TLS 1.2" to the IESG Sep 2020 - Submit "Delegated Credentials for TLS" to the IESG Nov 2020 - Submit "TLS Ticket Requests" to the IESG Nov 2020 - Submit "A Flags Extension for TLS 1.3" to the IESG Jan 2021 - Submit "Importing External PSKs for TLS" to the IESG Mar 2021 - Submit "Encrypted Server Name Indication for TLS 1.3" to the IESG Mar 2021 - Submit "Batch Signing for TLS" to the IESG Jul 2021 - Submit "Semi-Static Diffie-Hellman Key Establishment for TLS 1.3" to the IESG Jul 2021 - Submit "Compact TLS 1.3" to the IESG Nov 2021 - Submit "Hybrid key exchange in TLS 1.3" to the IESG From nobody Wed Apr 22 16:34:54 2020 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 2C2983A0DC0 for ; Wed, 22 Apr 2020 16:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=i3NytNoX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=X3S3GKsa 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 Rz6WPcLXXjad for ; Wed, 22 Apr 2020 16:34:51 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3976E3A0D76 for ; Wed, 22 Apr 2020 16:34:51 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 478CE5C0228 for ; Wed, 22 Apr 2020 19:34:50 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 22 Apr 2020 19:34:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=KkIs94onKZ5xK+gFRpH7OwgxqY2tvwu DMsJWpK7A3VM=; b=i3NytNoXO90IfizDP0R/kkQv59uZZm8bClUerzZA9YUAc6F zQODIsdQoXxZNT0Eg77vmIsEVXvAAiJv+Z6wdJT+HAdjIdMRWWguQbsI5AeJuWoU 1Eaqch6BoW9a5+dLcwRQAoS3l/WUzF+ofK1wghRWCBCD8Dn/VHqzg70jfYoIHH/7 SwhCA8HMNGvqI8m2DZI9l1q1NN//iELENrqzJoIdBicyM1lSFLuXAT+qDzxONC2/ r49xkq4Zj1vrhj0GhusQ6SV+yOiv28WAt1000/Xt3FXPB6WdbJS+0/NiJysrnn5b tuPAwpCJrzZaeQWoNHgIbdcBKHPNJMuprCDdBNA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=KkIs94 onKZ5xK+gFRpH7OwgxqY2tvwuDMsJWpK7A3VM=; b=X3S3GKsaxPfM+TwTAKdaW9 BWK3+RAgh6n4HieoWDN5XtjCnlhGdXjLmUUAy0S0XyThF/F6HyE+CE4ecqUVcH1M HxSr9uBRA2FhupKAqUNmaFQacBj2QghsKYT7RDO2olUrRT1xSlMXNaAYlCJImBO4 FVc6o84zXOc1n99w42pvuQPOH7GjNchU1giJTviZemKdJYX1PKtOhA0g+207hB+M gv7mWBJ9qplHw5GGAT/u00n03As1/rRSZA0CQSb3QFMOY8NpanApFFhRZCPbTlY1 dnFC9rlzwGUhR3do6XlpCQf0wBRTAd6uC+ngVMjQmsZhwVZ8BN2Ve/eq0pzwdxxA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeekgddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomh dpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghi lhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E6E66180091; Wed, 22 Apr 2020 19:34:49 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 22 Apr 2020 16:34:29 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [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: Wed, 22 Apr 2020 23:34:53 -0000 Hi Hanno, I believe this (now merged) PR addresses your concerns: https://github.com/tlswg/dtls13-spec/pull/140 Best, Chris On Fri, Apr 3, 2020, at 5:08 AM, Hanno Becker wrote: > 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 > 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 > From nobody Wed Apr 22 16:54:29 2020 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 CBCA73A0E50 for ; Wed, 22 Apr 2020 16:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=d54M5ZI6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YHElL7j8 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 Rb3g9slb1mGf for ; Wed, 22 Apr 2020 16:54:24 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F713A0E54 for ; Wed, 22 Apr 2020 16:54:23 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 4ADD8424 for ; Wed, 22 Apr 2020 19:54:23 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 22 Apr 2020 19:54:23 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=fHVF2Awzv4lzi2inUfDmbs5dfh4P6E+ 1ORFt8vuKpjg=; b=d54M5ZI6/moyJI33pnNZaetcSSvVXNao0NZW+2NUX6hNP+L OypQebhTCnxDLYfR5FThAfn/PJd71UmPRKdDKZqGQ4uJ4gp3Ybqlykoc5jSDfiCo ebUBW/bKSu1+H3nVk3y0tBFCozf6UGPE2FT7VK0U1qlRUvixt0WElgtK5w+1HVr8 TMZnVkloEccLdUUaAJQJiBw9xATDRPp9xg34YSnZrAxx1stqrU5utXz9sLu6VH8K Vn2gaV2uWWtNsGfJb2+7/Yghuhz4Kltl+iRv7Fpmk+CM8vetq/0KD/UjlmGcA8fe B3C2Iu1m4gxzgeT3yIUqrK8CXr2k+MsN2JjAJMA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=fHVF2A wzv4lzi2inUfDmbs5dfh4P6E+1ORFt8vuKpjg=; b=YHElL7j81eM75CCpqpwqLz 56w5uoeEviwVvn0WlrmRvOXQWVxhJj+rLu+SZblHGMVInyXQZ8w7hAEql+MDCfBv M/MGA0CnLUCTYallhQcccpXWZ+PMw7MZ7dS3tJBZ75D4DvCaNemayfpJ77EN9d0T Ps1jOJMEDi8BEQQ0bGL261h4riJju5JyGgEQ41n8p51Oc/z0ESmugDZ6XPOXawzf kUwhK7lKK2TZ0L6k0kpC55GhsMqCtrJlLJYfzCRD8+lAhge9ZUX3yB/MzAwJrVSi m6feoUVb/4yFQ8vbMnfsfeNbx7CIravo/s4ctLq1OJymukLr62BO19Sk23WOKlCA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeekgddvgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhdpghhith hhuhgsrddrtghomhdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfr rghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 68F72180091; Wed, 22 Apr 2020 19:54:22 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> In-Reply-To: References: Date: Thu, 23 Apr 2020 09:53:59 +1000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Wed, 22 Apr 2020 23:54:27 -0000 I prefer Ekr's solution, but I would go with that being a recommendation (SHOULD) as opposed to a requirement (MUST). I was initially inclined toward doing nothing at all, but there is an attack of sorts that is worth avoiding here. Say that a connection spans two network paths. CID A is used on path A; CID B is used on path B. Let's assume that you need a connection ID to route (otherwise, why bother), but that the first record in each datagram is all that is needed for that purpose. The linkabliity confirmation attack allows an attacker that hypothesizes a correlation between CID A and CID Bto confirm that hypothesis. It relies on side channel leakage from endpoints, but as this only involves measuring application reactions, I'm going to assume that it is feasible to extract some signal. If an endpoint sends a datagram on path A that contains two records where the second record omits the connection ID, then an attacker can strip that second record out and copy it into a datagram sent on path B. With the current design, the receiver accepts that packet and maybe leaks some signal to the attacker that CID A and CID B really are the same connection. With Hanno's proposed fix, the receiver of that record will guess incorrectly that the datagram is bad and drop it, providing no signal about the relationship between the two CIDs. But Hanno's proposal is a terrible thing to have to implement. You have to assume that there is some way to recover which CID to use in decrypting any record. You might save some datagram-local state, but that's awkward. Stacks that I've worked on try very hard not to have state transmission between records for good reasons. So this would be a fairly bad complication. Separately, I hope that no one would be contemplating trial decryption for this, which would be terrible. So I'm inclined toward cautioning against omitting the connection ID when one is used. DTLS 1.3 already has fairly lightweight requirements around how linkability is avoided. Activity on new paths does not strictly require the use of a different CID, it's just a recommendation. Allowing endpoints to omit a CID is consistent with that, even if we don't recommend that. However, we do need to be careful to explain this risk so that people are aware of the consequences of omission. I would also point out that we attempt to avoid creating correlators so that attackers can't create hypotheses about linkability. Allowing confirmation of a hypothesis is not that bad when the existence of the hypothesis is itself what we are trying to avoid. Given the relative cost of performing this attack to other means of confirming the hypothesis - dropping packets and observing the response would be much easier in many cases - I don't think that this warrants a strong response. Cheers, Martin On Thu, Apr 23, 2020, at 02:23, Hanno Becker wrote: > Hi Ekr, > > I still don't yet understand which concrete problems you see with > the proposed solution. In particular, as mentioned in the last mail, I > don't think there > is a contradiction with any design choice for TLS 1.3 - in contrast, > decoupling > record header compression from record protection aligns with how cTLS > proposes to compress TLS 1.3 without affecting any cryptographic > computations > and hence hopefully easing carrying over the security analysis of TLS > 1.3. This decoupling > doesn't hold for the current DTLS 1.3 draft, and we seem to agree that > in the case of CIDs, > it has already led to one missing cryptographic binding. > > Anyway, let's wait for more opinions. > > Best, > Hanno > > *From:* Eric Rescorla > *Sent:* Wednesday, April 22, 2020 3:47 PM > *To:* Hanno Becker > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data > > > On Wed, Apr 22, 2020 at 7:31 AM Hanno Becker wrote: > > > >>> Considering the effort spent on shaving off bytes in the DTLS header, > >>> I think re-introducing the explicit CID should be avoided. It seems > >>> perfectly acceptable to me to have implicit header data which is > >>> protected via AAD. > >> > >> This is only relevant if there is a common useful case in which you would need to put multiple > >> DTLS records in the same datagram. Are you aware of such a case? > > > > I can see the following uses: > > 1) Replying to KeyUpdate with Ack;;KeyUpdate, or replying to RequestConnectionID with Ack;;NewConnectionId > > 2) Sending multiple (short) app records if the application protocol doesn't provide its own framing. > > Neither of these seem particularly compelling to me. The first happens > very infrequently, and I'm not really aware of a lot of cases of the > second. > > > > > >>> > 1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spec/pull/143 > >>> > >>> This seems to be a mixture of logical and on-the-wire representation, which > >>> moreover duplicates the CID in case it is explicitly present in the header. > >> > >> Yes, so? > > > > Isn't this less efficient > > Trivially. > > > > and undoes the arguable benefit of the current solution that there's > > no need to piece together an AAD buffer manually, because now you'd have to? > > I don't recall making that argument. > > -Ekr > > > > > Best, > > Hanno > > > > > >> Looking forward to hearing other WG member's views, > >> Hanno > >> *From:* Eric Rescorla > >> *Sent:* Wednesday, April 22, 2020 2:23 AM > >> *To:* Hanno Becker > >> *Cc:* tls@ietf.org > >> *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data > >> I think there are two potential resolutions to your CID issue: > >> > >> 1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spec/pull/143 > >> 2. Forbid implicit CIDs (my preference) see: https://github.com/tlswg/dtls13-spec/issues/144 > >> > >> Would like to hear what others in the WG think. > >> > >> -Ekr > >> > >> > >> On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla wrote: > >>> > >>> > >>> On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker wrote: > >>>> Hi all, > >>>> > >>>> To my understanding, DTLS 1.3 defines AEAD additional data for record protection > >>>> as the record header as seen on the wire. Quoting Draft 37, Section 4: > >>>> > >>>> ``` > >>>> The entire header value shown in Figure 4 (but prior to record number > >>>> encryption) is used as as the additional data value for the AEAD > >>>> function. For instance, if the minimal variant is used, the AAD is 2 > >>>> octets long.. Note that this design is different from the additional > >>>> data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. > >>>> ``` > >>>> > >>>> I would like to suggest that DTLS 1.3 uses a structured representation > >>>> of the record header instead, as do all other versions of [D]TLS as > >>>> far as I understand. > >>> > >>> I am not in favor of this change as proposed. I think it is better to protect the data that is actually on the wire than to allow for changes in the on-the-wire representation that are not reflected in the integrity check. > >>> > >>> > >>>> The reasons for this are as follows, in decreasing order of > >>>> my perception of importance: > >>>> > >>>> - Omission of Connection ID > >>>> > >>>> Regarding the presence of Connection IDs in multiple records within > >>>> a single datagram, Draft 37 says: > >>>> > >>>> ``` > >>>> Implementations which send multiple records in the same datagram > >>>> SHOULD omit the connection id from all but the first record; > >>>> receiving implementations MUST assume that any subsequent records > >>>> without connection IDs belong to the same assocatiation. > >>>> ``` > >>>> > >>>> This means that the Connection ID for non-initial records in a > >>>> datagram containing multiple records is _not_ part of the AEAD > >>>> additional data for those records, which seems wrong. Concretely, > >>>> one could inject such non-initial records into other datagrams > >>>> using different CIDs, and the record protection wouldn't notice it. > >>> > >>> This seems like a reasonable point, though it's not clear to me that there is an actual problem here. I'd be in favor of explicitly including the CID in the AD as well as the header. > >>>> > >>>> > >>>> One might argue that CID shouldn't be part of the AEAD in the first > >>>> place, but in any case, I believe the treatment should be uniform > >>>> and not distinguish between initial and non-initial records in > >>>> a datagram. > >>> > >>> We're not distinguishing it. The AD is protecting the record on the wire. > >>> > >>> > >>>> - Modularity > >>>> > >>>> Decoupling the wire-presentation of the record header from > >>>> record protection allows to implement record protection and > >>>> the choice of record header independently: One piece of > >>>> the implementation can take care of record protection - > >>>> using the structured presentation of the record header - while > >>>> another takes care of the wire-encoding. It is even possible > >>>> to change the record header format in transit. > >>> > >>> This seems like a defect, not a feature. > >>> > >>> > >>>> - Simplicity > >>>> > >>>> At first it seems that using the record header as an > >>>> unstructured binary blob for AEAD makes things simpler, > >>>> but I don't think this is the case: Prior to record > >>>> decryption, the record sequence number needs to be > >>>> decrypted, and for that purpose, the record header already > >>>> has to be parsed. Hence, at the time of record decryption, > >>>> the record header is already be present a modified, structured > >>>> form, and retaining the corresponding modified binary form > >>>> appears to create additional complexity which would be > >>>> avoided if record protection would use the structured > >>>> header presentation. > >>> > >>> I've implemented this for QUIC (I can't remember who at Mozilla did it for DTLS) and it's not particularly difficult. > >>> > >>> > >>>> - Uniformity with other [D]TLS versions > >>> > >>> I don't find this argument at all persuasive. To the contrary: we should break with DTLS 1.2 in any case where it's an improvement and not too onerous. > >>> > >>> -Ekr > >>> > >>>> > >>>> > >>>> > >>>> Let me know what you think, > >>>> > >>>> 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 > >> 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. > > 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. > 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 > From nobody Wed Apr 22 17:00:49 2020 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 D4E663A0E6A for ; Wed, 22 Apr 2020 17:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=CNrjm3nU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zXZUG57L 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 AsJ0LLBfqKSo for ; Wed, 22 Apr 2020 17:00:39 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2607A3A0E69 for ; Wed, 22 Apr 2020 17:00:39 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 54D325C0265 for ; Wed, 22 Apr 2020 20:00:38 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Wed, 22 Apr 2020 20:00:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=yqDi943dtjEqxmbhh5vupkcJD9vaF77 Cy9sOGMjFUeo=; b=CNrjm3nUyL5322Wbas2pVw9Q51ENBYMI8OhVNISXWp9wl3P iVvwhGi8Tu2If8f2WSWFYJotres6KM0HRU8Se44mNhsuVEmrcB04puXFS/mM/zfM MAoSZiBdvHeQbKRXTt7OYzpkihv+dCUKFiejhF7oPn+xv9jopHFIvaTeByBJ0cYe 95Hw8ZscCoR3XOFAuvClfxaC1TalD6IOKWKCznqnJIohQBbTEoXmm89EzW+Y8Mnt yOosCfTNvXwiOo1o5h2AmmRAZmdPpM3CxorTbwX3JG9tCeUlSQwRQAfHCWl+lUul j0uT+jNcM1CKcbrPZe43iQN4GVVtvWDuByKM/hA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=yqDi94 3dtjEqxmbhh5vupkcJD9vaF77Cy9sOGMjFUeo=; b=zXZUG57Lg/xMKO/vrHOrJn Ymx4htS7X0y/tm9aJJFtuJ2ks4Cn2QWlwgUOwdNI18tTb1VLKxwjBdg9b5pIQHYt 1uAZFgURayPUcTdI1jk+jSU7eTdH5cNjMH/ScpImkQxBwqnUd8VBZX7aOe7TxFZj 2P3H5wxSddxx7Vlhk3yGq/LjRq9O6lUpOnh2JcSPaVqtOrqHOtTVnmFKTOp2T1SW ttwGNNq3jf6RsVnXT76yVVp9ND3GKvMwVx0rfTrHo6w0t1w2lH7vr5GMmjamIfeH 4BSt/jp9y81vwLIsXbaalWtnWGROvXrcnv4gKq6uuXuPkObwpJKfh6jmUeD2U2Xw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeekgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomh dpghhithhhuhgsrddrtghomhdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnh gvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D0658180093; Wed, 22 Apr 2020 20:00:37 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> Date: Wed, 22 Apr 2020 17:00:17 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Thu, 23 Apr 2020 00:00:42 -0000 (no hat) A SHOULD is probably fine provided we document the possible implications and consequences of not abiding by it. And Martin laid out a number of them below. Best, Chris On Wed, Apr 22, 2020, at 4:53 PM, Martin Thomson wrote: > I prefer Ekr's solution, but I would go with that being a > recommendation (SHOULD) as opposed to a requirement (MUST). > > I was initially inclined toward doing nothing at all, but there is an > attack of sorts that is worth avoiding here. > > Say that a connection spans two network paths. CID A is used on path > A; CID B is used on path B. Let's assume that you need a connection ID > to route (otherwise, why bother), but that the first record in each > datagram is all that is needed for that purpose. > > The linkabliity confirmation attack allows an attacker that > hypothesizes a correlation between CID A and CID Bto confirm that > hypothesis. It relies on side channel leakage from endpoints, but as > this only involves measuring application reactions, I'm going to assume > that it is feasible to extract some signal. > > If an endpoint sends a datagram on path A that contains two records > where the second record omits the connection ID, then an attacker can > strip that second record out and copy it into a datagram sent on path > B. With the current design, the receiver accepts that packet and maybe > leaks some signal to the attacker that CID A and CID B really are the > same connection. With Hanno's proposed fix, the receiver of that > record will guess incorrectly that the datagram is bad and drop it, > providing no signal about the relationship between the two CIDs. > > But Hanno's proposal is a terrible thing to have to implement. You > have to assume that there is some way to recover which CID to use in > decrypting any record. You might save some datagram-local state, but > that's awkward. Stacks that I've worked on try very hard not to have > state transmission between records for good reasons. So this would be > a fairly bad complication. Separately, I hope that no one would be > contemplating trial decryption for this, which would be terrible. > > So I'm inclined toward cautioning against omitting the connection ID > when one is used. > > DTLS 1.3 already has fairly lightweight requirements around how > linkability is avoided. Activity on new paths does not strictly > require the use of a different CID, it's just a recommendation. > Allowing endpoints to omit a CID is consistent with that, even if we > don't recommend that. However, we do need to be careful to explain > this risk so that people are aware of the consequences of omission. > > I would also point out that we attempt to avoid creating correlators so > that attackers can't create hypotheses about linkability. Allowing > confirmation of a hypothesis is not that bad when the existence of the > hypothesis is itself what we are trying to avoid. Given the relative > cost of performing this attack to other means of confirming the > hypothesis - dropping packets and observing the response would be much > easier in many cases - I don't think that this warrants a strong > response. > > Cheers, > Martin > > On Thu, Apr 23, 2020, at 02:23, Hanno Becker wrote: > > Hi Ekr, > > > > I still don't yet understand which concrete problems you see with > > the proposed solution. In particular, as mentioned in the last mail, I > > don't think there > > is a contradiction with any design choice for TLS 1.3 - in contrast, > > decoupling > > record header compression from record protection aligns with how cTLS > > proposes to compress TLS 1.3 without affecting any cryptographic > > computations > > and hence hopefully easing carrying over the security analysis of TLS > > 1.3. This decoupling > > doesn't hold for the current DTLS 1.3 draft, and we seem to agree that > > in the case of CIDs, > > it has already led to one missing cryptographic binding. > > > > Anyway, let's wait for more opinions. > > > > Best, > > Hanno > > > > *From:* Eric Rescorla > > *Sent:* Wednesday, April 22, 2020 3:47 PM > > *To:* Hanno Becker > > *Cc:* tls@ietf.org > > *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data > > > > > > On Wed, Apr 22, 2020 at 7:31 AM Hanno Becker wrote: > > > > > >>> Considering the effort spent on shaving off bytes in the DTLS header, > > >>> I think re-introducing the explicit CID should be avoided. It seems > > >>> perfectly acceptable to me to have implicit header data which is > > >>> protected via AAD. > > >> > > >> This is only relevant if there is a common useful case in which you would need to put multiple > > >> DTLS records in the same datagram. Are you aware of such a case? > > > > > > I can see the following uses: > > > 1) Replying to KeyUpdate with Ack;;KeyUpdate, or replying to RequestConnectionID with Ack;;NewConnectionId > > > 2) Sending multiple (short) app records if the application protocol doesn't provide its own framing. > > > > Neither of these seem particularly compelling to me. The first happens > > very infrequently, and I'm not really aware of a lot of cases of the > > second. > > > > > > > > > >>> > 1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spec/pull/143 > > >>> > > >>> This seems to be a mixture of logical and on-the-wire representation, which > > >>> moreover duplicates the CID in case it is explicitly present in the header. > > >> > > >> Yes, so? > > > > > > Isn't this less efficient > > > > Trivially. > > > > > > > and undoes the arguable benefit of the current solution that there's > > > no need to piece together an AAD buffer manually, because now you'd have to? > > > > I don't recall making that argument. > > > > -Ekr > > > > > > > > Best, > > > Hanno > > > > > > > > >> Looking forward to hearing other WG member's views, > > >> Hanno > > >> *From:* Eric Rescorla > > >> *Sent:* Wednesday, April 22, 2020 2:23 AM > > >> *To:* Hanno Becker > > >> *Cc:* tls@ietf.org > > >> *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data > > >> I think there are two potential resolutions to your CID issue: > > >> > > >> 1. Cryptographically protect it as in https://github.com/tlswg/dtls13-spec/pull/143 > > >> 2. Forbid implicit CIDs (my preference) see: https://github.com/tlswg/dtls13-spec/issues/144 > > >> > > >> Would like to hear what others in the WG think. > > >> > > >> -Ekr > > >> > > >> > > >> On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla wrote: > > >>> > > >>> > > >>> On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker wrote: > > >>>> Hi all, > > >>>> > > >>>> To my understanding, DTLS 1.3 defines AEAD additional data for record protection > > >>>> as the record header as seen on the wire. Quoting Draft 37, Section 4: > > >>>> > > >>>> ``` > > >>>> The entire header value shown in Figure 4 (but prior to record number > > >>>> encryption) is used as as the additional data value for the AEAD > > >>>> function. For instance, if the minimal variant is used, the AAD is 2 > > >>>> octets long.. Note that this design is different from the additional > > >>>> data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. > > >>>> ``` > > >>>> > > >>>> I would like to suggest that DTLS 1.3 uses a structured representation > > >>>> of the record header instead, as do all other versions of [D]TLS as > > >>>> far as I understand. > > >>> > > >>> I am not in favor of this change as proposed. I think it is better to protect the data that is actually on the wire than to allow for changes in the on-the-wire representation that are not reflected in the integrity check. > > >>> > > >>> > > >>>> The reasons for this are as follows, in decreasing order of > > >>>> my perception of importance: > > >>>> > > >>>> - Omission of Connection ID > > >>>> > > >>>> Regarding the presence of Connection IDs in multiple records within > > >>>> a single datagram, Draft 37 says: > > >>>> > > >>>> ``` > > >>>> Implementations which send multiple records in the same datagram > > >>>> SHOULD omit the connection id from all but the first record; > > >>>> receiving implementations MUST assume that any subsequent records > > >>>> without connection IDs belong to the same assocatiation. > > >>>> ``` > > >>>> > > >>>> This means that the Connection ID for non-initial records in a > > >>>> datagram containing multiple records is _not_ part of the AEAD > > >>>> additional data for those records, which seems wrong. Concretely, > > >>>> one could inject such non-initial records into other datagrams > > >>>> using different CIDs, and the record protection wouldn't notice it. > > >>> > > >>> This seems like a reasonable point, though it's not clear to me that there is an actual problem here. I'd be in favor of explicitly including the CID in the AD as well as the header. > > >>>> > > >>>> > > >>>> One might argue that CID shouldn't be part of the AEAD in the first > > >>>> place, but in any case, I believe the treatment should be uniform > > >>>> and not distinguish between initial and non-initial records in > > >>>> a datagram. > > >>> > > >>> We're not distinguishing it. The AD is protecting the record on the wire. > > >>> > > >>> > > >>>> - Modularity > > >>>> > > >>>> Decoupling the wire-presentation of the record header from > > >>>> record protection allows to implement record protection and > > >>>> the choice of record header independently: One piece of > > >>>> the implementation can take care of record protection - > > >>>> using the structured presentation of the record header - while > > >>>> another takes care of the wire-encoding. It is even possible > > >>>> to change the record header format in transit. > > >>> > > >>> This seems like a defect, not a feature. > > >>> > > >>> > > >>>> - Simplicity > > >>>> > > >>>> At first it seems that using the record header as an > > >>>> unstructured binary blob for AEAD makes things simpler, > > >>>> but I don't think this is the case: Prior to record > > >>>> decryption, the record sequence number needs to be > > >>>> decrypted, and for that purpose, the record header already > > >>>> has to be parsed. Hence, at the time of record decryption, > > >>>> the record header is already be present a modified, structured > > >>>> form, and retaining the corresponding modified binary form > > >>>> appears to create additional complexity which would be > > >>>> avoided if record protection would use the structured > > >>>> header presentation. > > >>> > > >>> I've implemented this for QUIC (I can't remember who at Mozilla did it for DTLS) and it's not particularly difficult. > > >>> > > >>> > > >>>> - Uniformity with other [D]TLS versions > > >>> > > >>> I don't find this argument at all persuasive. To the contrary: we should break with DTLS 1.2 in any case where it's an improvement and not too onerous. > > >>> > > >>> -Ekr > > >>> > > >>>> > > >>>> > > >>>> > > >>>> Let me know what you think, > > >>>> > > >>>> 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 > > >> 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. > > > 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. > > 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 > From nobody Wed Apr 22 17:08:09 2020 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 D01283A0E82 for ; Wed, 22 Apr 2020 17:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ZnG7865Q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JcDkwsRT 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 Oosq5YlS8k-c for ; Wed, 22 Apr 2020 17:08:04 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF243A0E7B for ; Wed, 22 Apr 2020 17:08:04 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id AFFA1610; Wed, 22 Apr 2020 20:08:03 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 22 Apr 2020 20:08:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm2; bh=14 UuWznUAvJJ8/MPNCIzOMjIoM8a4X9w2DMmXMaDyL4=; b=ZnG7865QCP3V9w50dR q+YLjFOEN5/6pUg7FVm29w6qBgedXUBIDvdfMTZzyMf0DAchAZxgzi1mSjDJfPWj Y00qzYo7DlkyosRpvzPWuEJVoH4kHmWEqz3U+sPp/bwXi1j4VWTg+iUF6YsZhKlL 4AzV7pIVQ3Hb+AI6z+oTrZ4S+7pN1AFvQ/1gbbZt8b/LML50McP3KQUQEPr7t5J6 j0RZGJrXmQjq9jTx7q1i2lkNO4dGTCbufzU7Rip8CVzPxYmhFxMRquG79k8LKODc c2mzcXiPFSjRsFH9ieEAkHXpc2mzyykGQa7//MP86ISFa6YEGN0Tp1sJt/exENAZ FKMQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=14UuWznUAvJJ8/MPNCIzOMjIoM8a4X9w2DMmXMaDy L4=; b=JcDkwsRTOMW69C5mq34E6piWlV6jlT6gkkc+0xcGqtz8ayKvrROdXpQBi Qy1OBV2naEi+dc5fRk2JEaOq8DL8UIaQp7rRJuI+bjzrwct/O/DOr3E0tioAnR4w /EGZ3+X9BokcDAqom6HwYmY04Qx5NAEXw/HVU7+009SFnzXjSre+2VBgCYappS94 P3DHDATRgGYUBP+OELS+dgCaDoNC7BFTl29ei0p7zsLhjT4w7AvyTW8GmBhRi0zL s131slXhhTUibwD7U/+4xzrsOKT4tygprD0Ca3e4XcukYBXCsuzBC/FtEhYKY8T7 TKvOa+xldo2q5jXdP2/g9XL33agDQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeekgddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E466A180091; Wed, 22 Apr 2020 20:08:02 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <3aab08b9-d979-4952-85f6-62e993f6fb4b@www.fastmail.com> Date: Thu, 23 Apr 2020 10:07:40 +1000 From: "Martin Thomson" To: "Yoav Nir" Cc: tls@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WGLC for "A Flags Extension for TLS 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: Thu, 23 Apr 2020 00:08:07 -0000 On Wed, Apr 22, 2020, at 05:31, Yoav Nir wrote: > > Third, more substantially, and invalidating the above, I don't think= that we should make flags introduce a new style of negotiation just bec= ause it can. I would strongly prefer that this function as close as pos= sible to "empty ClientHello extension; empty EncryptedExtensions extensi= on". Aside from that, the utility of an advertisement from the server t= hat a client cannot respond to is pretty marginal. >=20 > If this is what the group prefers, I=E2=80=99m fine with it, but then = there=E2=80=99s=20 > never any point in sending an empty extension, either from the client=20= > of form the server. The absence of an individual flag is always implie= d=20 > from the absence of the extension. When you say "empty extension" here, do you mean "empty flags extension"= or are you speaking more generally? If the server can't add flags, then I agree that having the client send = an empty flags extension has little value. Same for the server sending = an empty flags extension in that case. =20 > > Are we confident that sending the same extension in both places is s= afe? I know that clients have to implement this and so should be able t= o test that this works, but it seems awkward. And it might not be neces= sary. It's also not sufficient, as we currently allow responses to Clie= ntHello extensions to appear in Certificate (and for CertificateRequest = to carry "requests" in the other direction). >=20 > I don=E2=80=99t think the two extensions ever carry the same flags. Ea= ch server=20 > side flag should be one of three: serverHello, encrpytedExtensions, or= =20 > neither (if we are not expecting a response) So the intersection of flags in different responses must be zero? i.e. = flags[ServerHello] & flags[EncryptedExtensions] =3D=3D 0 (and the same f= or any combination that we allow, including Certificate and NewSessionTi= cket, I guess). =20 > As for Certificate, I don=E2=80=99t see why we=E2=80=99d need to add b= it responses to=20 > Certificate. They can safely be sent in either serverHello or=20 > encryptedExtensions. The obvious thing here is when the extension applies on a per-certificat= e basis as opposed to the entire chain. But I don't have an example you= can use; see below. > I=E2=80=99m trying to come up with key exchange bits that might be use= ful. =20 > Perhaps a new, improved alternative to HKDF? Support for Quantum Key=20= > Exchange? This might require an understanding of the overall strategy. If the goa= l is to provide an analogue of a generic "empty extension", then sure, p= ut it in ServerHello. But put it in Certificate and NewSessionTicket to= o. But if you make this more narrowly applicable and say that you have = a different flags extension for each type of exchange (ClientHello -> Se= rverHello, ClientHello -> EncryptedExtensions, ClientHello -> NewSession= Ticket, ClientHello/CertificateRequest -> Certificate), then you might a= void answering this question for now. Right now, it seems like the obvious use here is for EncryptedExtensions= , so we could decide to defer that architectural question by saying that= it is limited to EncryptedExtensions for now. Then we can either expan= d the one flags extensions to allow it in NewSessionTicket when we need = to, or define a new one. From nobody Wed Apr 22 18:24:45 2020 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 1770A3A0FF3 for ; Wed, 22 Apr 2020 18:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 sdTYeFXAA6R4 for ; Wed, 22 Apr 2020 18:24:40 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4280E3A0FF4 for ; Wed, 22 Apr 2020 18:24:40 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id l11so3389015lfc.5 for ; Wed, 22 Apr 2020 18:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jBCZrJz9RZx6Fp6BuuidHMzgI/y3D3gbHkGrpLcf8R8=; b=xEPZyHi6l7MuJzpoAtc6XLjADstER5wTUHcW/yBe5kukPaVXOqEQ+14xHayNNx6d5d 30TCPCgY090oZy0c67UccOJa5Mui3PIkEmnUxuCS1/M04gs7zMMEDdajJ6SYG0wX2rTK jHJBvlptNYB/GUl2evHHQKaABABrYhTdjOITUU0NM4263a68alSMkMDVks0OzzeChBhx IvpNQeHbVSWwKvhbvNc2j0bAtu8E9QjuN0Fa8eDL38SsXP6rFhbW/MyGndngEX3eblUp iM6XfgBwGc6XcfqpaLJwb/dmvlnx8J2IOOaMxh+QmiWmVG3w/fVkLklB90qeCZ81WYNm Ue2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jBCZrJz9RZx6Fp6BuuidHMzgI/y3D3gbHkGrpLcf8R8=; b=UaIgJf14qbJoaZEyFjxeKKtQcQK8WNrGk0JntF7ANWhQvjvyNjMusIMW+KqKf8uFI1 Zed/ru1MlBuIbkFpYhRDyKnNaVnK7DJ61TAzc2lrUC3c5nR9qSVTUaaES+Bk1BqAy4eP KH4UFROoJJ1wcH48NMoyiaCJoZgAJLOau/fFXTVPrxkO3qjxsEes81FCho4deHmWB4mZ 50iZ0lbtu1TPzwxXHWhXkfSD+n41eqflelCLuxU69WGo7Ve/1XLSxiHv/SFKIUJ5ZUSf IKuaR9obcqF/aDNyj57cW/vrBwwITOQoLE0flGowDucOHQQj5dXjun6HA3SEWLIZAI8F k1gw== X-Gm-Message-State: AGi0PuaNYvbjIzZzxfy8KjFlOqXXFNEh6oYL0IWVpwwGmkh6LNk93cmy RCPDT7Om153dvy2211gPgI460GadP4trHt8uWRktFNaTkLI= X-Google-Smtp-Source: APiQypLif3I9r/WGZj9D5TYEer2hf7rHZ9V0lnvVZjNkZpey1r2csPRvPY/MkZKUkbAryqTApFWFRq8Ct3XLfU8cCdE= X-Received: by 2002:a19:f806:: with SMTP id a6mr791616lff.201.1587605078457; Wed, 22 Apr 2020 18:24:38 -0700 (PDT) MIME-Version: 1.0 References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> In-Reply-To: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> From: Eric Rescorla Date: Wed, 22 Apr 2020 18:24:02 -0700 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="000000000000bed22305a3eb1cf3" Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Thu, 23 Apr 2020 01:24:44 -0000 --000000000000bed22305a3eb1cf3 Content-Type: text/plain; charset="UTF-8" On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson wrote: > I prefer Ekr's solution, but I would go with that being a recommendation > (SHOULD) as opposed to a requirement (MUST). > Can you clarify where you think we should say SHOULD? -Ekr > I was initially inclined toward doing nothing at all, but there is an > attack of sorts that is worth avoiding here. > > Say that a connection spans two network paths. CID A is used on path A; > CID B is used on path B. Let's assume that you need a connection ID to > route (otherwise, why bother), but that the first record in each datagram > is all that is needed for that purpose. > > The linkabliity confirmation attack allows an attacker that hypothesizes a > correlation between CID A and CID Bto confirm that hypothesis. It relies > on side channel leakage from endpoints, but as this only involves measuring > application reactions, I'm going to assume that it is feasible to extract > some signal. > > If an endpoint sends a datagram on path A that contains two records where > the second record omits the connection ID, then an attacker can strip that > second record out and copy it into a datagram sent on path B. With the > current design, the receiver accepts that packet and maybe leaks some > signal to the attacker that CID A and CID B really are the same > connection. With Hanno's proposed fix, the receiver of that record will > guess incorrectly that the datagram is bad and drop it, providing no signal > about the relationship between the two CIDs. > > But Hanno's proposal is a terrible thing to have to implement. You have > to assume that there is some way to recover which CID to use in decrypting > any record. You might save some datagram-local state, but that's awkward. > Stacks that I've worked on try very hard not to have state transmission > between records for good reasons. So this would be a fairly bad > complication. Separately, I hope that no one would be contemplating trial > decryption for this, which would be terrible. > > So I'm inclined toward cautioning against omitting the connection ID when > one is used. > > DTLS 1.3 already has fairly lightweight requirements around how > linkability is avoided. Activity on new paths does not strictly require > the use of a different CID, it's just a recommendation. Allowing endpoints > to omit a CID is consistent with that, even if we don't recommend that. > However, we do need to be careful to explain this risk so that people are > aware of the consequences of omission. > > I would also point out that we attempt to avoid creating correlators so > that attackers can't create hypotheses about linkability. Allowing > confirmation of a hypothesis is not that bad when the existence of the > hypothesis is itself what we are trying to avoid. Given the relative cost > of performing this attack to other means of confirming the hypothesis - > dropping packets and observing the response would be much easier in many > cases - I don't think that this warrants a strong response. > > Cheers, > Martin > > On Thu, Apr 23, 2020, at 02:23, Hanno Becker wrote: > > Hi Ekr, > > > > I still don't yet understand which concrete problems you see with > > the proposed solution. In particular, as mentioned in the last mail, I > > don't think there > > is a contradiction with any design choice for TLS 1.3 - in contrast, > > decoupling > > record header compression from record protection aligns with how cTLS > > proposes to compress TLS 1.3 without affecting any cryptographic > > computations > > and hence hopefully easing carrying over the security analysis of TLS > > 1.3. This decoupling > > doesn't hold for the current DTLS 1.3 draft, and we seem to agree that > > in the case of CIDs, > > it has already led to one missing cryptographic binding. > > > > Anyway, let's wait for more opinions. > > > > Best, > > Hanno > > > > *From:* Eric Rescorla > > *Sent:* Wednesday, April 22, 2020 3:47 PM > > *To:* Hanno Becker > > *Cc:* tls@ietf.org > > *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data > > > > > > On Wed, Apr 22, 2020 at 7:31 AM Hanno Becker > wrote: > > > > > >>> Considering the effort spent on shaving off bytes in the DTLS header, > > >>> I think re-introducing the explicit CID should be avoided. It seems > > >>> perfectly acceptable to me to have implicit header data which is > > >>> protected via AAD. > > >> > > >> This is only relevant if there is a common useful case in which you > would need to put multiple > > >> DTLS records in the same datagram. Are you aware of such a case? > > > > > > I can see the following uses: > > > 1) Replying to KeyUpdate with Ack;;KeyUpdate, or replying to > RequestConnectionID with Ack;;NewConnectionId > > > 2) Sending multiple (short) app records if the application protocol > doesn't provide its own framing. > > > > Neither of these seem particularly compelling to me. The first happens > > very infrequently, and I'm not really aware of a lot of cases of the > > second. > > > > > > > > > >>> > 1. Cryptographically protect it as in > https://github.com/tlswg/dtls13-spec/pull/143 > > >>> > > >>> This seems to be a mixture of logical and on-the-wire > representation, which > > >>> moreover duplicates the CID in case it is explicitly present in the > header. > > >> > > >> Yes, so? > > > > > > Isn't this less efficient > > > > Trivially. > > > > > > > and undoes the arguable benefit of the current solution that there's > > > no need to piece together an AAD buffer manually, because now you'd > have to? > > > > I don't recall making that argument. > > > > -Ekr > > > > > > > > Best, > > > Hanno > > > > > > > > >> Looking forward to hearing other WG member's views, > > >> Hanno > > >> *From:* Eric Rescorla > > >> *Sent:* Wednesday, April 22, 2020 2:23 AM > > >> *To:* Hanno Becker > > >> *Cc:* tls@ietf.org > > >> *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data > > >> I think there are two potential resolutions to your CID issue: > > >> > > >> 1. Cryptographically protect it as in > https://github.com/tlswg/dtls13-spec/pull/143 > > >> 2. Forbid implicit CIDs (my preference) see: > https://github.com/tlswg/dtls13-spec/issues/144 .com/tlswg/dtls13-spec/issues/144> > > >> > > >> Would like to hear what others in the WG think. > > >> > > >> -Ekr > > >> > > >> > > >> On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla wrote: > > >>> > > >>> > > >>> On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker > wrote: > > >>>> Hi all, > > >>>> > > >>>> To my understanding, DTLS 1.3 defines AEAD additional data for > record protection > > >>>> as the record header as seen on the wire. Quoting Draft 37, Section > 4: > > >>>> > > >>>> ``` > > >>>> The entire header value shown in Figure 4 (but prior to record > number > > >>>> encryption) is used as as the additional data value for the AEAD > > >>>> function. For instance, if the minimal variant is used, the AAD is > 2 > > >>>> octets long.. Note that this design is different from the > additional > > >>>> data calculation for DTLS 1.2 and for DTLS 1.2 with Connection ID. > > >>>> ``` > > >>>> > > >>>> I would like to suggest that DTLS 1.3 uses a structured > representation > > >>>> of the record header instead, as do all other versions of [D]TLS as > > >>>> far as I understand. > > >>> > > >>> I am not in favor of this change as proposed. I think it is better > to protect the data that is actually on the wire than to allow for changes > in the on-the-wire representation that are not reflected in the integrity > check. > > >>> > > >>> > > >>>> The reasons for this are as follows, in decreasing order of > > >>>> my perception of importance: > > >>>> > > >>>> - Omission of Connection ID > > >>>> > > >>>> Regarding the presence of Connection IDs in multiple records within > > >>>> a single datagram, Draft 37 says: > > >>>> > > >>>> ``` > > >>>> Implementations which send multiple records in the same datagram > > >>>> SHOULD omit the connection id from all but the first record; > > >>>> receiving implementations MUST assume that any subsequent records > > >>>> without connection IDs belong to the same assocatiation. > > >>>> ``` > > >>>> > > >>>> This means that the Connection ID for non-initial records in a > > >>>> datagram containing multiple records is _not_ part of the AEAD > > >>>> additional data for those records, which seems wrong. Concretely, > > >>>> one could inject such non-initial records into other datagrams > > >>>> using different CIDs, and the record protection wouldn't notice it. > > >>> > > >>> This seems like a reasonable point, though it's not clear to me that > there is an actual problem here. I'd be in favor of explicitly including > the CID in the AD as well as the header. > > >>>> > > >>>> > > >>>> One might argue that CID shouldn't be part of the AEAD in the first > > >>>> place, but in any case, I believe the treatment should be uniform > > >>>> and not distinguish between initial and non-initial records in > > >>>> a datagram. > > >>> > > >>> We're not distinguishing it. The AD is protecting the record on the > wire. > > >>> > > >>> > > >>>> - Modularity > > >>>> > > >>>> Decoupling the wire-presentation of the record header from > > >>>> record protection allows to implement record protection and > > >>>> the choice of record header independently: One piece of > > >>>> the implementation can take care of record protection - > > >>>> using the structured presentation of the record header - while > > >>>> another takes care of the wire-encoding. It is even possible > > >>>> to change the record header format in transit. > > >>> > > >>> This seems like a defect, not a feature. > > >>> > > >>> > > >>>> - Simplicity > > >>>> > > >>>> At first it seems that using the record header as an > > >>>> unstructured binary blob for AEAD makes things simpler, > > >>>> but I don't think this is the case: Prior to record > > >>>> decryption, the record sequence number needs to be > > >>>> decrypted, and for that purpose, the record header already > > >>>> has to be parsed. Hence, at the time of record decryption, > > >>>> the record header is already be present a modified, structured > > >>>> form, and retaining the corresponding modified binary form > > >>>> appears to create additional complexity which would be > > >>>> avoided if record protection would use the structured > > >>>> header presentation. > > >>> > > >>> I've implemented this for QUIC (I can't remember who at Mozilla did > it for DTLS) and it's not particularly difficult. > > >>> > > >>> > > >>>> - Uniformity with other [D]TLS versions > > >>> > > >>> I don't find this argument at all persuasive. To the contrary: we > should break with DTLS 1.2 in any case where it's an improvement and not > too onerous. > > >>> > > >>> -Ekr > > >>> > > >>>> > > >>>> > > >>>> > > >>>> Let me know what you think, > > >>>> > > >>>> 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 > > >> 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. > > > 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. > > 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 > --000000000000bed22305a3eb1cf3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Apr 22, 2020 at 4:54 PM Marti= n Thomson <mt@lowentropy.net>= ; wrote:
I prefe= r Ekr's solution, but I would go with that being a recommendation (SHOU= LD) as opposed to a requirement (MUST).

Can you clarify where you think we should say SHOULD?

=
-Ekr


I was initially inclined toward doing nothing at all, but there is an attac= k of sorts that is worth avoiding here.

Say that a connection spans two network paths.=C2=A0 CID A is used on path = A; CID B is used on path B.=C2=A0 Let's assume that you need a connecti= on ID to route (otherwise, why bother), but that the first record in each d= atagram is all that is needed for that purpose.

The linkabliity confirmation attack allows an attacker that hypothesizes a = correlation between CID A and CID Bto confirm that hypothesis.=C2=A0 It rel= ies on side channel leakage from endpoints, but as this only involves measu= ring application reactions, I'm going to assume that it is feasible to = extract some signal.

If an endpoint sends a datagram on path A that contains two records where t= he second record omits the connection ID, then an attacker can strip that s= econd record out and copy it into a datagram sent on path B.=C2=A0 With the= current design, the receiver accepts that packet and maybe leaks some sign= al to the attacker that CID A and CID B really are the same connection.=C2= =A0 With Hanno's proposed fix, the receiver of that record will guess i= ncorrectly that the datagram is bad and drop it, providing no signal about = the relationship between the two CIDs.

But Hanno's proposal is a terrible thing to have to implement.=C2=A0 Yo= u have to assume that there is some way to recover which CID to use in decr= ypting any record.=C2=A0 You might save some datagram-local state, but that= 's awkward.=C2=A0 Stacks that I've worked on try very hard not to h= ave state transmission between records for good reasons.=C2=A0 So this woul= d be a fairly bad complication.=C2=A0 Separately, I hope that no one would = be contemplating trial decryption for this, which would be terrible.

So I'm inclined toward cautioning against omitting the connection ID wh= en one is used.=C2=A0

DTLS 1.3 already has fairly lightweight requirements around how linkability= is avoided.=C2=A0 Activity on new paths does not strictly require the use = of a different CID, it's just a recommendation. Allowing endpoints to o= mit a CID is consistent with that, even if we don't recommend that.=C2= =A0 However, we do need to be careful to explain this risk so that people a= re aware of the consequences of omission.

I would also point out that we attempt to avoid creating correlators so tha= t attackers can't create hypotheses about linkability.=C2=A0 Allowing c= onfirmation of a hypothesis is not that bad when the existence of the hypot= hesis is itself what we are trying to avoid.=C2=A0 Given the relative cost = of performing this attack to other means of confirming the hypothesis - dro= pping packets and observing the response would be much easier in many cases= - I don't think that this warrants a strong response.

Cheers,
Martin

On Thu, Apr 23, 2020, at 02:23, Hanno Becker wrote:
>=C2=A0 Hi Ekr,
>
>=C2=A0 I still don't yet understand which concrete problems you see= with
> the proposed solution. In particular, as mentioned in the last mail, I=
> don't think there
> is a contradiction with any design choice for TLS 1.3 - in contrast, <= br> > decoupling
> record header compression from record protection aligns with how cTLS =
> proposes to compress TLS 1.3 without affecting any cryptographic
> computations
> and hence hopefully easing carrying over the security analysis of TLS =
> 1.3. This decoupling
> doesn't hold for the current DTLS 1.3 draft, and we seem to agree = that
> in the case of CIDs,
> it has already led to one missing cryptographic binding.
>
> Anyway, let's wait for more opinions.
>
>=C2=A0 Best,
>=C2=A0 Hanno
>
> *From:* Eric Rescorla <ekr@rtfm.com>
> *Sent:* Wednesday, April 22, 2020 3:47 PM
> *To:* Hanno Becker <Hanno.Becker@arm.com>
> *Cc:* tls@ietf.org <tls@ietf.org&g= t;
> *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data
>
>
> On Wed, Apr 22, 2020 at 7:31 AM Hanno Becker <Hanno.Becker@arm.com> wrote: > >
> >>> Considering the effort spent on shaving off bytes in the = DTLS header,
> >>> I think re-introducing the explicit CID should be avoided= . It seems
> >>> perfectly acceptable to me to have implicit header data w= hich is
> >>> protected via AAD.
> >>
> >> This is only relevant if there is a common useful case in whi= ch you would need to put multiple
> >> DTLS records in the same datagram. Are you aware of such a ca= se?
> >
> > I can see the following uses:
> > 1) Replying to KeyUpdate with Ack;;KeyUpdate, or replying to Requ= estConnectionID with Ack;;NewConnectionId
> > 2) Sending multiple (short) app records if the application protoc= ol doesn't provide its own framing.
>
> Neither of these seem particularly compelling to me. The first happens=
> very infrequently, and I'm not really aware of a lot of cases of t= he
> second.
>
>
> >
> >>> > 1. Cryptographically protect it as in=C2=A0 https://github.com/tlswg/dtls13-spec/pull/143
> >>>
> >>> This seems to be a mixture of logical and on-the-wire rep= resentation, which
> >>> moreover duplicates the CID in case it is explicitly pres= ent in the header.
> >>
> >> Yes, so?
> >
> > Isn't this less efficient
>
> Trivially.
>
>
> > and undoes the arguable benefit of the current solution that ther= e's
> > no need to piece together an AAD buffer manually, because now you= 'd have to?
>
>=C2=A0 I don't recall making that argument.
>
> -Ekr
>
> >
> > Best,
> > Hanno
> >
> >
> >> Looking forward to hearing other WG member's views,
> >> Hanno
> >> *From:* Eric Rescorla <ekr@rtfm.com>
> >> *Sent:* Wednesday, April 22, 2020 2:23 AM
> >> *To:* Hanno Becker <Hanno.Becker@arm.com>
> >> *Cc:* tls@i= etf.org <tls@ietf.= org>
> >> *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data
> >> I think there are two potential resolutions to your CID issue= :
> >>
> >> 1. Cryptographically protect it as in=C2=A0 https://github.com/tlswg/dtls13-spec/pull/143
> >> 2. Forbid implicit CIDs (my preference) see:=C2=A0 https://github.com/tlswg/dtls13-spec/issues/144 <https://github..com/tlswg/dtls13-spec/issues/144>
> >>
> >> Would like to hear what others in the WG think.
> >>
> >> -Ekr
> >>
> >>
> >> On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla <ekr@rtfm.com> wrote:
> >>>
> >>>
> >>> On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker <Hanno.Becker@arm.com= > wrote:
> >>>> Hi all,
> >>>>
> >>>> To my understanding, DTLS 1.3 defines AEAD additional= data for record protection
> >>>> as the record header as seen on the wire. Quoting Dra= ft 37, Section 4:
> >>>>
> >>>> ```
> >>>>=C2=A0 The entire header value shown in Figure 4 (but = prior to record number
> >>>>=C2=A0 encryption) is used as as the additional data v= alue for the AEAD
> >>>>=C2=A0 function. For instance, if the minimal variant = is used, the AAD is 2
> >>>>=C2=A0 octets long.. Note that this design is differen= t from the additional
> >>>>=C2=A0 data calculation for DTLS 1.2 and for DTLS 1.2 = with Connection ID.
> >>>> ```
> >>>>
> >>>> I would like to suggest that DTLS 1.3 uses a structur= ed representation
> >>>> of the record header instead, as do all other version= s of [D]TLS as
> >>>> far as I understand.
> >>>
> >>> I am not in favor of this change as proposed. I think it = is better to protect the data that is actually on the wire than to allow fo= r changes in the on-the-wire representation that are not reflected in the i= ntegrity check.
> >>>
> >>>
> >>>> The reasons for this are as follows, in decreasing or= der of
> >>>> my perception of importance:
> >>>>
> >>>> - Omission of Connection ID
> >>>>
> >>>>=C2=A0 Regarding the presence of Connection IDs in mul= tiple records within
> >>>>=C2=A0 a single datagram, Draft 37 says:
> >>>>
> >>>> ```
> >>>>=C2=A0 Implementations which send multiple records in = the same datagram
> >>>>=C2=A0 SHOULD omit the connection id from all but the = first record;
> >>>>=C2=A0 receiving implementations MUST assume that any = subsequent records
> >>>>=C2=A0 without connection IDs belong to the same assoc= atiation.
> >>>> ```
> >>>>
> >>>>=C2=A0 This means that the Connection ID for non-initi= al records in a
> >>>>=C2=A0 datagram containing multiple records is _not_ p= art of the AEAD
> >>>>=C2=A0 additional data for those records, which seems = wrong. Concretely,
> >>>>=C2=A0 one could inject such non-initial records into = other datagrams
> >>>>=C2=A0 using different CIDs, and the record protection= wouldn't notice it.
> >>>
> >>> This seems like a reasonable point, though it's not c= lear to me that there is an actual problem here. I'd be in favor of exp= licitly including the CID in the AD as well as the header.
> >>>>
> >>>>
> >>>>=C2=A0 One might argue that CID shouldn't be part = of the AEAD in the first
> >>>>=C2=A0 place, but in any case, I believe the treatment= should be uniform
> >>>>=C2=A0 and not distinguish between initial and non-ini= tial records in
> >>>>=C2=A0 a datagram.
> >>>
> >>> We're not distinguishing it. The AD is protecting the= record on the wire.
> >>>
> >>>
> >>>> - Modularity
> >>>>
> >>>>=C2=A0 Decoupling the wire-presentation of the record = header from
> >>>>=C2=A0 record protection allows to implement record pr= otection and
> >>>>=C2=A0 the choice of record header independently: One = piece of
> >>>>=C2=A0 the implementation can take care of record prot= ection -
> >>>>=C2=A0 using the structured presentation of the record= header - while
> >>>>=C2=A0 another takes care of the wire-encoding. It is = even possible
> >>>>=C2=A0 to change the record header format in transit.<= br> > >>>
> >>> This seems like a defect, not a feature.
> >>>
> >>>
> >>>> - Simplicity
> >>>>
> >>>>=C2=A0 At first it seems that using the record header = as an
> >>>>=C2=A0 unstructured binary blob for AEAD makes things = simpler,
> >>>>=C2=A0 but I don't think this is the case: Prior t= o record
> >>>>=C2=A0 decryption, the record sequence number needs to= be
> >>>>=C2=A0 decrypted, and for that purpose, the record hea= der already
> >>>>=C2=A0 has to be parsed. Hence, at the time of record = decryption,
> >>>>=C2=A0 the record header is already be present a modif= ied, structured
> >>>>=C2=A0 form, and retaining the corresponding modified = binary form
> >>>>=C2=A0 appears to create additional complexity which w= ould be
> >>>>=C2=A0 avoided if record protection would use the stru= ctured
> >>>>=C2=A0 header presentation.
> >>>
> >>> I've implemented this for QUIC (I can't remember = who at Mozilla did it for DTLS) and it's not particularly difficult. > >>>
> >>>
> >>>> - Uniformity with other [D]TLS versions
> >>>
> >>> I don't find this argument at all persuasive. To the = contrary: we should break with DTLS 1.2 in any case where it's an impro= vement and not too onerous.
> >>>
> >>> -Ekr
> >>>
> >>>>
> >>>>
> >>>>
> >>>> Let me know what you think,
> >>>>
> >>>> Best,
> >>>> Hanno
> >>>>
> >>>>=C2=A0 IMPORTANT NOTICE: The contents of this email an= d any attachments are confidential and may also be privileged. If you are n= ot 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.
> >>>>=C2=A0 _______________________________________________=
> >>>>=C2=A0 TLS mailing list
> >>>> TLS= @ietf.org
> >>>> https://www.ietf.org/mailman/listinfo= /tls
> >>=C2=A0 IMPORTANT NOTICE: The contents of this email and any at= tachments are confidential and may also be privileged. If you are not the i= ntended 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.
> >=C2=A0 IMPORTANT NOTICE: The contents of this email and any attach= ments are
> confidential and may also be privileged. If you are not the intended <= br> > recipient, please notify the sender immediately and do not disclose th= e
> contents to any other person, use it for any purpose, or store or copy=
> the information in any medium. Thank you.
>=C2=A0 IMPORTANT NOTICE: The contents of this email and any attachments= are
> confidential and may also be privileged. If you are not the intended <= br> > recipient, please notify the sender immediately and do not disclose th= e
> 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
--000000000000bed22305a3eb1cf3-- From nobody Wed Apr 22 18:39:25 2020 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 85D4C3A095C for ; Wed, 22 Apr 2020 18:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=dWc8I7yL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Zst6jnDp 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 PTpPsU59ZKxj for ; Wed, 22 Apr 2020 18:39:22 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF9BA3A088F for ; Wed, 22 Apr 2020 18:39:22 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 4B677637; Wed, 22 Apr 2020 21:39:22 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Wed, 22 Apr 2020 21:39:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=3/k+uRPyyI6u3NnAbAycU9ndPWeH SoZcbdC092fOrOY=; b=dWc8I7yLsxAIZwaiR+9PIPvjfTau1PrzXOV0VQ8nh2im ZR/obWYny8E2r7cLQ/YYFaD+aY0Nt0eyYl/rHo02y7WwgyeAgCBAcrfj55yvby/h FOlxHbZHRRIgNzM0e9bBT/c+8Pj1w0Nv/BZqudjXjIFezR9gD6RS+SzWdgJuC+Kn Gak31UH/PBW0BAd/Yd7VZTd7DQ9OnkWJQ8qQfGN5qBKCSd1xov8h+/hW5iuMUKe4 YpoctRqXPg3UGuFiAioq1CSGBzd0fXC5yAe4LhfsGRs76tKeHXmYLk9kgPGn5tz2 vnJDjxWogDKpMa9JOYd0lpu73bTc4xPPc9vWwfKn6A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=3/k+uR PyyI6u3NnAbAycU9ndPWeHSoZcbdC092fOrOY=; b=Zst6jnDpZ6rYAX92DXsbQd KVObG8OJKcD7P72f5ZNsdI4QXvmgvgjP6HfnZS7yt8xsXWNV7G5K3mzOKu1ZGO/H Z22YBg+Rzg8o2uVP1OQhkEQWSs/wxjkgpt6ZFidPzCh0FP6mlezvD6FdfPubuYN9 Wt6k7ia3twheK69hePJtRHtMSg/dLwPS/ofBtaNPmF/G0WowdJjNfYGyOIVcqVLS tB1wpvpdoxQVi7ikb+h1cuUHSzLXwz911jxLycMNIgZAaXlb1G9riR5RXn4OSCUa ZW2HMi8Z2eddqu4NqAUXGtjEbZOn6xHf8HATC5XZ7FmC8C36mtlo5xOwrAs8DTBg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeekgdeghecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id AC892180091; Wed, 22 Apr 2020 21:39:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com> In-Reply-To: References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> Date: Thu, 23 Apr 2020 11:39:01 +1000 From: "Martin Thomson" To: "'Eric Rescorla'" Cc: "" Content-Type: text/plain Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Thu, 23 Apr 2020 01:39:25 -0000 On Thu, Apr 23, 2020, at 11:24, Eric Rescorla wrote: > On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson wrote: > > I prefer Ekr's solution, but I would go with that being a recommendation (SHOULD) as opposed to a requirement (MUST). > > Can you clarify where you think we should say SHOULD? The security considerations seems right. After the list of improvements over DTLS 1.2 CID. You would say that an endpoint that is asked to provide a CID SHOULD provide one in every record (with the compact header, etc...). If it does not, then it might be possible for an attacker to use that record to confirm guesses about linkability between two paths. Also, omitting the CID might make it hard to route datagrams. With all of this, you might want a section heading for all the CID stuff. From nobody Wed Apr 22 18:49:46 2020 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 DF1D33A1084 for ; Wed, 22 Apr 2020 18:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 emPLFKYsP6Lj for ; Wed, 22 Apr 2020 18:49:43 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49AF13A1083 for ; Wed, 22 Apr 2020 18:49:43 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id u6so4507526ljl.6 for ; Wed, 22 Apr 2020 18:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6dFdxugSmM7DeCZeizSXFRhU1/6/Nads1aJYN/LB9+w=; b=hwlx8IopBBQQ9C+GDn/ejDdFTUJNIik51GPnFKeEP6wrDCvegpVEwpISP1pXyD2WKj oJBnmlRxhRCmOB2a3e1E9VkkvDfo61MzqeXaX/YtSP08gXqmwdB3nt37KFq9INmMoWtg p+LqxdV24klxLzra9L4RBtOlFhV8Qvc1fc4W/Pv3kVEH269lCrw5O/mKhBWL3pK3Qw/+ YAxZ4EOqKO19bCs5VhmyHmzpJydz6u9SsDMDAaXf3scuazel1iibnSxMMowsay7gVV7w nLwHNMdQufrOZ3vZEwyz1BOUiMUGhfXmYXpAheofuDEDoC5wXAjmA8tE2q4oKr9tpBS9 WTeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6dFdxugSmM7DeCZeizSXFRhU1/6/Nads1aJYN/LB9+w=; b=gHUpLwIbd/iwLR8EHozq383OFCkkrXk8Alz9pme0V4kqAAQnNLuZJD2oWLkmJck8dp GN8VCoooEWNvYdWBuvRpto6NLZDEmy4G5Gn/mcnYspjEysCQ9zxLiTKePCog3J90L9/1 3qVkk4eysDsGC6sfXXpcs3ViMvGBNzX39VfmJQkGjnJ+4cN3jLDeIa2p1K4imzAGrhs9 oybTMlg9EzUm1Ckxxctk6D3AzJrWku8KCWkGemfLI0TfsdkKvtw2RzVByJsgjN/8oule Y+ZYRDGEZbqEcnGjYoEP1ehY7MfzaDzCV73cYq92iE6pYL4glPeS9FNeaGePr/YlZG/u YeAw== X-Gm-Message-State: AGi0PuZy8u+fgMvR7f5Phc5PmBUAcnql9eCtlfW4w/tWg0ZdoNHLRFNP c6brye+hkg/BzXHos9n0CYyzrXFuo5IqsDvgtmWpRQ== X-Google-Smtp-Source: APiQypJPMastLXeatO71uPaf/mDsm/IZ4N0ngXuN1mCI13pLrYot5VZ/yLzLkYD1jxVdFD6zyHtvpgNI9wMRUnip/HE= X-Received: by 2002:a2e:2414:: with SMTP id k20mr907590ljk.162.1587606581376; Wed, 22 Apr 2020 18:49:41 -0700 (PDT) MIME-Version: 1.0 References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com> In-Reply-To: <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com> From: Eric Rescorla Date: Wed, 22 Apr 2020 18:49:05 -0700 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="00000000000053ae2e05a3eb76b4" Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Thu, 23 Apr 2020 01:49:45 -0000 --00000000000053ae2e05a3eb76b4 Content-Type: text/plain; charset="UTF-8" OK but we would expect the peer to process CID-less records if they are coalesced? -Ekr On Wed, Apr 22, 2020 at 6:39 PM Martin Thomson wrote: > > > On Thu, Apr 23, 2020, at 11:24, Eric Rescorla wrote: > > On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson > wrote: > > > I prefer Ekr's solution, but I would go with that being a > recommendation (SHOULD) as opposed to a requirement (MUST). > > > > Can you clarify where you think we should say SHOULD? > > The security considerations seems right. After the list of improvements > over DTLS 1.2 CID. You would say that an endpoint that is asked to provide > a CID SHOULD provide one in every record (with the compact header, > etc...). If it does not, then it might be possible for an attacker to use > that record to confirm guesses about linkability between two paths. Also, > omitting the CID might make it hard to route datagrams. > > With all of this, you might want a section heading for all the CID stuff. > --00000000000053ae2e05a3eb76b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK but we would expect the peer to process CID-less r= ecords if they are coalesced?

-Ekr
<= br>

On Wed, Apr 22, 2020 at 6:39 PM Martin Thomson <mt@lowentropy.net> wrote:


On Thu, Apr 23, 2020, at 11:24, Eric Rescorla wrote:
> On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson <mt@lowentropy.net> wrote:
> > I prefer Ekr's solution, but I would go with that being a rec= ommendation (SHOULD) as opposed to a requirement (MUST).
>
> Can you clarify where you think we should say SHOULD?

The security considerations seems right.=C2=A0 After the list of improvemen= ts over DTLS 1.2 CID.=C2=A0 You would say that an endpoint that is asked to= provide a CID SHOULD provide one in every record (with the compact header,= etc...).=C2=A0 If it does not, then it might be possible for an attacker t= o use that record to confirm guesses about linkability between two paths.= =C2=A0 Also, omitting the CID might make it hard to route datagrams.

With all of this, you might want a section heading for all the CID stuff.
--00000000000053ae2e05a3eb76b4-- From nobody Wed Apr 22 21:03:09 2020 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 CFEF43A12F3 for ; Wed, 22 Apr 2020 21:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=cloudflare.com 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 5NuO9DNzc6Vn for ; Wed, 22 Apr 2020 21:03:05 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009833A12EF for ; Wed, 22 Apr 2020 21:03:04 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id g10so4353316uae.5 for ; Wed, 22 Apr 2020 21:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yQOQGnxgYCxf65E3vwtZlWS1b0WxGg7b3VUra7B0psk=; b=DvTqWz0vM0wcH1dwGtgaeYCyUZYZpLqWx1ISpFsCBxDBJuaZI2r6YDWKnaaenWphMk XpDYy0qpKqO3fKNuD80/LwuIhPxUHctipiqhpi9ijrSrrv/XB0MI6pcUajqv/2ZldnO6 DmK4lFiTilY72PWy0kSRSkNWGaSURUm12QHHU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yQOQGnxgYCxf65E3vwtZlWS1b0WxGg7b3VUra7B0psk=; b=kll9MEBr5+agyrb0eKehzU2EYsD7ZC/WpxkeYy1qSJP1SpOxYn4mDQx3nVEQJni/a7 35kJQAoXXdo0BrjUjCX5r7abEVhCyAGWvHJ8D/auN85zoXbPvOZ5sghACCzsDY6U7Mvz r5uX/yTSZBg4tWiZZbTW3it+Thao6Qg7hEf8Mn0AgrbER33xhW2d0brQoNuNLE7LGT5w VBesU7I8vLidP+STNtkhayZEt26PgQUCtKy8Wc/O+Fcj2CJveJWHmFBa0JnwPNj0OVdm iVmRBIvIpIZ+K77q0xqTKbnf7E9ZnUTu4PzuBHznVdXaSbiG3+us4rUDNYqibKzIFOjr tFJA== X-Gm-Message-State: AGi0PubZJ0iFhge46M8dmuWB035thOSZ3HpaE+8VAbKqlrIb8nbNThYu gl3ROr1eTZM2NRB2GZfhPom0jtBEG7OcDFiR9zChPA== X-Google-Smtp-Source: APiQypKq5NKsU48GmlAQN4kIyZ6s8tdtaejpNaj+Tke5PFBX/nmuasIR+dgV5WrlfKuwATakg+xWyZE4Bw/xqRm7JkA= X-Received: by 2002:a67:304c:: with SMTP id w73mr1538984vsw.212.1587614583528; Wed, 22 Apr 2020 21:03:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Wed, 22 Apr 2020 21:02:47 -0700 Message-ID: To: Jonathan Hammell Cc: TLS List Content-Type: multipart/alternative; boundary="0000000000004ad2f605a3ed5368" Archived-At: Subject: Re: [TLS] Review of draft-ietf-tls-subcerts-07 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: Thu, 23 Apr 2020 04:03:07 -0000 --0000000000004ad2f605a3ed5368 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jonathan, A (delayed) thank you for this helpful review. Your input will be incorporated into draft -08. Nick On Thu, Apr 2, 2020 at 6:31 PM Jonathan Hammell wrote: > The draft looks good. I have a few minor nits and suggestions. > > Section 3, Fourth bullet: s/TLS hadshake/TLS handshake > > Section 3, Fourth bullet: To eliminate possible confusion, what is > meant by "certificate=E2=80=99s working key" could be defined more precis= ely. > > Section 3.2, Last paragraph: s/Automated Certificate Managmeent > Encvironment/Automated Certificate Management Environment > > Section 3.2, Last paragraph: "It is possible to address the > short-lived certificate concerns above ..." seems to refer to text in > the Introduction. It is a bit far for use of "above" rather than > indicating the particular section. Even better would be to add some > text regarding the concerns to Section 3 or 3.1. > > Section 4: The definition of "valid_time" could mention that the value > must not exceed 7 days. > > Section 4: The phrase > "Minimizing their semantics in this way is intended to mitigate the > risk of cross protocol attacks involving delegated credentials." > could be improved by adding at least one way that the minimized > semantics mitigate such attacks. > > Section 6.1: The term "TLS private key" is used for the first time > here. In the rest of the document we see the term "delegated private > key"; are these the same? > > Section 6.1: The following phrase describes an important condition for > using delegated credentials: > "Thus, delegated credentials should not be used to send a delegation > to an untrusted party, but is meant to be used between parties that > have some trust relationship with each other." > I think it is important enough to include a similar statement when > describing the solution in Section 3. > > Section 6.4: s/cache the certificate chain an re-validate it/cache the > certificate chain and re-validate it > > > Best regards, > Jonathan > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000004ad2f605a3ed5368 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Jonathan,

A (delayed) thank you= for this helpful review. Your input will be incorporated into draft -08.

Nick

On Thu, Apr 2, 2020 at 6:31 PM Jonathan H= ammell <jfhamme.cccs@gmail.com= > wrote:
= The draft looks good.=C2=A0 I have a few minor nits and suggestions.

Section 3, Fourth bullet: s/TLS hadshake/TLS handshake

Section 3, Fourth bullet: To eliminate possible confusion, what is
meant by "certificate=E2=80=99s working key" could be defined mor= e precisely.

Section 3.2, Last paragraph: s/Automated Certificate Managmeent
Encvironment/Automated Certificate Management Environment

Section 3.2, Last paragraph: "It is possible to address the
short-lived certificate concerns above ..." seems to refer to text in<= br> the Introduction.=C2=A0 It is a bit far for use of "above" rather= than
indicating the particular section.=C2=A0 Even better would be to add some text regarding the concerns to Section 3 or 3.1.

Section 4: The definition of "valid_time" could mention that the = value
must not exceed 7 days.

Section 4: The phrase
"Minimizing their semantics in this way is intended to mitigate the risk of cross protocol attacks involving delegated credentials."
could be improved by adding at least one way that the minimized
semantics mitigate such attacks.

Section 6.1: The term "TLS private key" is used for the first tim= e
here. In the rest of the document we see the term "delegated private key"; are these the same?

Section 6.1: The following phrase describes an important condition for
using delegated credentials:
"Thus, delegated credentials should not be used to send a delegation to an untrusted party, but is meant to be used between parties that
have some trust relationship with each other."
I think it is important enough to include a similar statement when
describing the solution in Section 3.

Section 6.4: s/cache the certificate chain an re-validate it/cache the
certificate chain and re-validate it


Best regards,
Jonathan

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000004ad2f605a3ed5368-- From nobody Wed Apr 22 21:06:51 2020 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 49EA93A12F6 for ; Wed, 22 Apr 2020 21:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=cloudflare.com 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 kBt9pzXckspH for ; Wed, 22 Apr 2020 21:06:47 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8438C3A12F5 for ; Wed, 22 Apr 2020 21:06:47 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id v24so4358721uak.0 for ; Wed, 22 Apr 2020 21:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=53NqxMut/4DH/R+rMrp2gd5mVTvtcrtgHsiw6stnk9c=; b=Yuwd7Nr2IBEZRkEvNXh3jhg1pFd8DDkEhm/9BPiTaXQj062GRQ6YHYo2yM3jbMmE1/ 9padQacPJynU8reVO+66cupanBlQxjzgEXXSV4HhV9TM14b9je5NyBx1veaOmn2DndXI EVT6wjd20JKpIFbZk/QllyztG4IuSiPrMp5bY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=53NqxMut/4DH/R+rMrp2gd5mVTvtcrtgHsiw6stnk9c=; b=M6GsiqS0eQQubNwqPG1PKhxP3Sh80yiO80h5aJkmJhdj4jjR7BVtM9gHslEQvaxSlg ruPGgm60OJFL0v4qgGUEyZljALmgp3B31k2w0jDQaVLFQ3EFoc6+OCd9KkTdb/pJY35Y auzaYJxdf5g5nGmvRJuvrON0ZRxXEP4o1ZETCf3Vhlc+t3refbrJsPS29gFjDjymPx2C k3oeR36cnm5hhBSWWMlwLWQBhf6GrZw54nTnQgbbVsFSJJebohq7TLBrnPPGJcvSmLkX 4ParMYUXGzSvqIUq/+ZxOFgNNK08/1P9HFkpWcYwTa25i8JkhoSZdwtRvQUBVWI2x41P pE+Q== X-Gm-Message-State: AGi0PubgMCNHuM55Vuc+WBcjgAgM/g73r2fY/NViBNnaJkyvKQZfo5yt 1SnPVKM8TK6DFM5MYyW3IyR3m6A0X1EBnfPkzjFZ8tHD X-Google-Smtp-Source: APiQypJv3k4Fg1YISG05eXjVChlq7NiK/Qjx5u3pZZi8VqTJxGWH0O/Rp5n4qWjIFP19jNm/Afn8oAljwYNHfv9Au68= X-Received: by 2002:a67:f9d0:: with SMTP id c16mr1662959vsq.53.1587614806431; Wed, 22 Apr 2020 21:06:46 -0700 (PDT) MIME-Version: 1.0 References: <3BFEDA02-D5AD-4616-9BA6-7556A6A6049B@alipay.com> In-Reply-To: <3BFEDA02-D5AD-4616-9BA6-7556A6A6049B@alipay.com> From: Nick Sullivan Date: Wed, 22 Apr 2020 21:06:30 -0700 Message-ID: To: Paul Yang Cc: TLS List Content-Type: multipart/alternative; boundary="0000000000009405b805a3ed6060" Archived-At: Subject: Re: [TLS] Encoding of delegated credential distribution 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: Thu, 23 Apr 2020 04:06:50 -0000 --0000000000009405b805a3ed6060 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Paul, Thank you for your comment. I would consider the distribution of key material out of scope for this protocol. Since this is can be an asynchronous distribution channel between mutually trusting parties, implementations may vary. As mentioned below, ACME may be suitable here, but I don't think we should be prescriptive. I'll clarify this in the next draft. Nick On Wed, Apr 1, 2020 at 11:13 PM Paul Yang wrote: > Hi all, > > When reading the latest draft of delegated credentials, I didn=E2=80=99t = any > description about how to distribute a credential from the backend to > frontend. As described in the draft: > > Delegated credentials: > > Client Front-End Back-End > | |<--DC distribution->| > |----ClientHello--->| | > |<---ServerHello----| | > |<---Certificate----| | > |<---CertVerify-----| | > | ... | | > > Do we need to define some sorts of encoding schemes for the distribution> part? > > Regards, > > Paul Yang > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000009405b805a3ed6060 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Paul,

Thank=C2=A0you for your commen= t. I would consider the distribution of key material out of scope for this = protocol. Since this is can be an asynchronous distribution=C2=A0channel be= tween mutually trusting parties, implementations may vary. As mentioned bel= ow, ACME may be suitable here,=C2=A0but I don't think we should be pres= criptive. I'll clarify this in the next draft.

Nick

On Wed, Apr 1, 2020 at 11:13 PM Paul Yang <kaishen.yy=3D40alipay.com@dmarc.ietf.org&g= t; wrote:
Hi all= ,

When reading the latest draft of delegated credentials, I didn=E2=80=99t an= y description about how to distribute a credential from the backend to fron= tend. As described in the draft:

=C2=A0 =C2=A0Delegated credentials:

=C2=A0 =C2=A0Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Front-End=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Back-End
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<--DC distribution->|<= br> =C2=A0 =C2=A0 =C2=A0|----ClientHello--->|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
=C2=A0 =C2=A0 =C2=A0|<---ServerHello----|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= br> =C2=A0 =C2=A0 =C2=A0|<---Certificate----|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
=C2=A0 =C2=A0 =C2=A0|<---CertVerify-----|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
=C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|

Do we need to define some sorts of encoding schemes for the <DC distribu= tion> part?

Regards,

Paul Yang

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000009405b805a3ed6060-- From nobody Wed Apr 22 23:43:38 2020 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 857803A1575 for ; Wed, 22 Apr 2020 23:43:37 -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=mYcNM2r9; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=mYcNM2r9 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 CCTA5HRvxDDv for ; Wed, 22 Apr 2020 23:43:34 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2075.outbound.protection.outlook.com [40.107.21.75]) (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 2C6F43A1574 for ; Wed, 22 Apr 2020 23:43:33 -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=4WzTiaN/XjMnNAK0k682BfXDpb2zsknnUYYEnLRcsuM=; b=mYcNM2r9lMny0sk51Z52j9ak0rdKEHoCTAgk401e/vEdRCQm3BMnby+z2DE1xnSIHc8CSw0sxkMGY0bClHfA0rfSkoWeHnRdHGmwZHDXdNjgnq5G+EHRX3xSPWIUgkd7clZnaax0Wb4OnI0M3//7kGUvIahLTrylcfZBDcpXsxM= Received: from DB6PR07CA0055.eurprd07.prod.outlook.com (2603:10a6:6:2a::17) by VI1PR08MB3357.eurprd08.prod.outlook.com (2603:10a6:803:45::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.27; Thu, 23 Apr 2020 06:43:30 +0000 Received: from DB5EUR03FT003.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:2a:cafe::a1) by DB6PR07CA0055.outlook.office365.com (2603:10a6:6:2a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.7 via Frontend Transport; Thu, 23 Apr 2020 06:43:30 +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 DB5EUR03FT003.mail.protection.outlook.com (10.152.20.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Thu, 23 Apr 2020 06:43:30 +0000 Received: ("Tessian outbound d63670e9da8f:v53"); Thu, 23 Apr 2020 06:43:30 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 978f4bf6ff0417ba X-CR-MTA-TID: 64aa7808 Received: from 2d128a0d0783.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 425A641D-0404-4EFC-B1CA-9C1B97B61C86.1; Thu, 23 Apr 2020 06:43:25 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 2d128a0d0783.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 23 Apr 2020 06:43:25 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ks8vPKBbOsgfTKxS+h7E+Ak0Syn6JeprMXNULDu16y7bl0p7yrNqXfxw5COswUwuk9grIQ2IJylvNKI5wy1wkzXgg1j5jVPhUSb6bctyogNyGK/9a+D7T22iKEhqxGAYr2kUaYf4Ed2XvpJ+aAe9r7yXN3eLeV5t9JJbEyzQe17A4QQCh5c1s1RFt+FktwHfAMZ9F6iDC5ctgtXYQ9+mfL4tESvb8nQyAALHHxLlFEfIW48IIsb1SoJJa/X3tV8bBw9uKS9+YECRAwJM2rjo1R03vjJcMlKvooGsuWL9HzDHWNcBN97Z3zXKsYQB8sY9PuACoK7LfZhQwAoJr98H0A== 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=4WzTiaN/XjMnNAK0k682BfXDpb2zsknnUYYEnLRcsuM=; b=hLtXSOCmWteatJEqJGejp8inqW9DZFFHOno4UsQg7NZ38dmGR5KKOd798DRrj8x/aQIcfEjEylJLCbdbD7Vpg5tgFJxKxoGvvAOqoyauGNccMNGPc/cffmCPRl8cVUW143QKGj8ZDDTybxwfwprm3xvmaYhnjjF7t5mv+O0+r4CkL34ccKum/9YsflADNQIwvN+V5RVuWCem0Y7D5cDIjkUVrcQ/07ROAv3dFhM8RnjJ4QEQa8f8UDUFugDg7krI9DkY8sc+GTWCpU+PSr6gM7WG+KSIWGnAxl+wo45TqX8J07XAi8hltCfDxsn32h9QF/33unvYJDhxemsZvHZjmw== 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=4WzTiaN/XjMnNAK0k682BfXDpb2zsknnUYYEnLRcsuM=; b=mYcNM2r9lMny0sk51Z52j9ak0rdKEHoCTAgk401e/vEdRCQm3BMnby+z2DE1xnSIHc8CSw0sxkMGY0bClHfA0rfSkoWeHnRdHGmwZHDXdNjgnq5G+EHRX3xSPWIUgkd7clZnaax0Wb4OnI0M3//7kGUvIahLTrylcfZBDcpXsxM= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6SPR01MB0041.eurprd08.prod.outlook.com (2603:10a6:20b:29::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Thu, 23 Apr 2020 06:43:23 +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.2937.012; Thu, 23 Apr 2020 06:43:23 +0000 From: Hanno Becker To: Eric Rescorla , Martin Thomson CC: "" Thread-Topic: [TLS] DTLS 1.3 AEAD additional data Thread-Index: AQHWF+iN1gKILcDltkmRr5OfopCaAaiD3VMAgAB8FQCAAE7VmIAAawyAgAAHdS6AAB8+AIAACQCRgACPx4CAABkpAIAABDCAgAAC0ICAAEL8/A== Date: Thu, 23 Apr 2020 06:43:23 +0000 Message-ID: References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com>, In-Reply-To: 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.177.220.146] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 34df9693-417e-4d9e-18fd-08d7e751a2c4 x-ms-traffictypediagnostic: AM6SPR01MB0041:|VI1PR08MB3357: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8273;OLM:9508; x-forefront-prvs: 03827AF76E 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:(4636009)(136003)(39860400002)(376002)(346002)(396003)(366004)(19627405001)(8676002)(8936002)(110136005)(316002)(5660300002)(53546011)(6506007)(7696005)(2906002)(478600001)(71200400001)(81156014)(33656002)(52536014)(9686003)(4326008)(86362001)(55016002)(26005)(966005)(66556008)(64756008)(66946007)(76116006)(66446008)(186003)(66476007); 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: 9GtFttZAPcsGLy1+whbMjzwqeyMo0ylackk6Z5b7ngwsjIXlIxN04P8jOb4OanL8s1qRhUeJJuXjD7Y37KFtm5fJYt6t+6UVvXvAX+k3cuniv6r8j/Geql65TGVU2fpaKQVsnDDI4/9P76xAFe3DJFQAB4UmURK7cDKsQhUrP/ERZlBrvF55oJVLuypUSjRJe9Nqi+TSYV6wxZXUC8xc+cvgGyeE0Z5gKLKWgF4yF+V9fezOdy9qCMhEgVViGxu4S+3APmWOEgVI3PcEBDufHuDfHZ6vp10djaUmJif7G6FbHimVfrGdD/z1hHKKnvlHnvCnzcWURaCbndl8W9/khA1/x7qN67tDrgrTKGWaUmdU+ohBaTIa4wnjKzvGNrUyrOkk0z65MqcB6i+a6+28sY5Wvclg/M75FVvac2SdFwEVwPtdZ/XjIHDcrie1g//YLWTl+NV0KEje/b67vxBLOBAybE2mBRQQ/eTDY4VXeh8/NenMAE/bWRc7aTGE8yiJJ7rK1Y4fy1C5LZGa+7yHgQ== x-ms-exchange-antispam-messagedata: dV3vxf5foC4c6fHRafkS6bu865Kbe+dExRelQhK0h9e97PLarvZj8KPN5ObQ+KMAEoFrDWAgBW9S9BPT5uvoBnyVyttxOH87E6vu4mx9Goya/4NLatg4BtsCULUv7VVq3z+cUqvLUuGz9EirGmUfTg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3318D5881B8D2BEFF938F2B79BD30AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6SPR01MB0041 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT003.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)(376002)(136003)(39860400002)(346002)(396003)(46966005)(86362001)(2906002)(81156014)(4326008)(26005)(5660300002)(9686003)(33656002)(6506007)(55016002)(81166007)(70586007)(53546011)(356005)(82310400002)(52536014)(70206006)(186003)(8676002)(316002)(7696005)(478600001)(19627405001)(336012)(966005)(82740400003)(110136005)(47076004)(8936002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 11844a3a-a376-4a51-0d85-08d7e7519ea3 X-Forefront-PRVS: 03827AF76E X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QN97sC/F0YGSZ9SobIZaxBr3TDEND1E/ThHbbDp6BN8W2lrwSWkzxEkJ7KKrf/6OIdffbmHFCUd8xCt6rr/s9l2BpriSHXqfJWRuGoF0RgapP1gidp7wqLukiXw++NlScn5DKT6F7EMlvZ/dJimTEVmFG/x47c86OTPAWyRqfEc+4tZQIKDdRsmUIYLS56APdYH8Wdc9JISQIaMTqOV0K3SVnxNZuDwyDoD26a9GHvZCoK5m2Ork1HI4/gOD0W/OD2pYj9ccCnTq0IzwdAhOtqxlnP3f4vG7WDbO2LO2KkBp6HMCYQjZKhl5zg/ZF7g1aKO+CLESgFUu383AlC6ud3bWck6OUwYYwgV1zHxvFNaeyBFwqZIH7qGQvoP5N65ITuJ9W3uB6Txwfze54olG/1vNqQT285thaWLDniySItnddIeBM3vAfiHqUJ1hhqEAQ/nVy61fy8/LYs3Fz0YsMIapTO7DhkIl3d9kQVBn1oP6nksSWyVjFy0o6Hwc4PnCuVsWxY3c1YdasPRuoxSceIeVXQHcifZli56E3wJqApwDbn9uWK0VoALjDK1xO+R47kCygoy6VLcf0bmZPQkXLg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2020 06:43:30.5272 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 34df9693-417e-4d9e-18fd-08d7e751a2c4 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: VI1PR08MB3357 Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Thu, 23 Apr 2020 06:43:38 -0000 --_000_AM6PR08MB3318D5881B8D2BEFF938F2B79BD30AM6PR08MB3318eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey, Thanks for joining in, Martin and Chris. > But Hanno's proposal is a terrible thing to have to implement. You have = to assume that there is some way to recover which CID to use in decrypting = any record. You might save some datagram-local state, but that's awkward. = Stacks that I've worked on try very hard not to have state transmission be= tween records for good reasons. So this would be a fairly bad complication= . Separately, I hope that no one would be contemplating trial decryption f= or this, which would be terrible. Yes that's a fair point and also applies to Ekr's proposal https://github.c= om/tlswg/dtls13-spec/pull/143. Moreover, the same layer-mixing criticism applies to the draft as it stands as well a= s to the other proposed solution, as mentioned before: When you prepare a record, you need to know where it resides within a datag= ram in order to choose the best header and AAD: You need to know if it's non-initial within the datagram to decide if = you can omit the CID, and you need to know if it's terminal to decide if you can omit the length. In contrast, if you decouple the choice of header format from the AAD, reco= rd protection can be done prior to passing the record to the datagram layer. As mentioned initially, this not = only increases modularity within the stack, but also allows e.g. to change the header towards more aggressive co= mpression at the entry of a highly constrained network, which I believe is indeed a feature and not a "defect"= and increases suitability of DTLS 1.3 for the IoT. The CID maintenance for incoming records can be avoided when forbidding CID= elision, as suggested by Ekr. Comparing the state maintenance complications this avoids to the increase i= n header size it introduces, maybe that's the way to go, as the state maintenance indeed seems to be the bigge= r pain. However, even if CID elision is removed, I maintain the proposal to always = use the logical presentation of the header for AAD, for all the mentioned reasons: (a) No interleaving of record and d= atagram layer, (b) conceptual clarity and independence of [header] compression methods from cryptographic computation= s, as e.g. in cTLS, (c) dynamic choice of header depending on network paths. All those issues persist when = sticking to the on-the-wire AAD. What are your reservations towards this? Cheers, Hanno ________________________________ From: TLS on behalf of Eric Rescorla Sent: Thursday, April 23, 2020 2:49 AM To: Martin Thomson Cc: Subject: Re: [TLS] DTLS 1.3 AEAD additional data OK but we would expect the peer to process CID-less records if they are coa= lesced? -Ekr On Wed, Apr 22, 2020 at 6:39 PM Martin Thomson > wrote: On Thu, Apr 23, 2020, at 11:24, Eric Rescorla wrote: > On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson > wrote: > > I prefer Ekr's solution, but I would go with that being a recommendatio= n (SHOULD) as opposed to a requirement (MUST). > > Can you clarify where you think we should say SHOULD? The security considerations seems right. After the list of improvements ov= er DTLS 1.2 CID. You would say that an endpoint that is asked to provide a= CID SHOULD provide one in every record (with the compact header, etc...). = If it does not, then it might be possible for an attacker to use that reco= rd to confirm guesses about linkability between two paths. Also, omitting = the CID might make it hard to route datagrams. With all of this, you might want a section heading for all the CID stuff. 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_AM6PR08MB3318D5881B8D2BEFF938F2B79BD30AM6PR08MB3318eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hey,

Thanks for joining in, Martin and Chris.

> But Hanno'= s proposal is a terrible thing to have to implement.  You have to assume that th= ere is some way to recover which CID to use in decrypting any record. = You might save some datagram-local state, but that's awkward.  Stacks= that I've worked on try very hard not to have state transmission between records for good reasons.  So this would b= e a fairly bad complication.  Separately, I hope that no one would be = contemplating trial decryption for this, which would be terrible.

Yes th= at's a fair point and also applies to Ekr's proposal https://github.= com/tlswg/dtls13-spec/pull/143. Moreover, 
the sa= me layer-= mixing criticism applies to the draft as it stands as well as to the other = proposed solution, as mentioned before: 
When y= ou prepare a record, you need to know where it resides within <= span style=3D"color: rgb(0, 0, 0); font-size: 15px;">a datagram in order to choose the best header and 
AAD: You need to know if it's non-initial within the datagra= m to deci= de if you can omit the CID, and you need to know if 
it's terminal to decide if you can omit the length. 

In con= trast, if you decouple the choice of header format from the AAD, record pro= tection can be done prior to 
passin= g the record to the datagram layer. As mentioned initially, this not only i= ncreases modularity within the
stack,= but also allows e.g. to change the header towards more aggressive compress= ion at the entry of a highly
constr= ained network, which I believe is indeed a feature and not a "defect&q= uot; and increases suitability
of DTL= S 1.3 for the IoT.

The CI= D maintenance for incoming records can be avoided when forbidding CID elisi= on, as suggested by Ekr.
Compar= ing the state maintenance complications this avoids to the increase in head= er size it introduces, maybe&n= bsp;
that's= the way to go, as the state maintenance indeed seems to be the bigger pain= . 
Howeve= r, even if CID elision is removed, I maintain the proposal to always use the logical presentation of the h= eader
for AAD, for all the mentioned reasons: (a) No interleaving of record and datagram layer, (b) conceptual clarity and 
independence of [header] compression methods from cryptographic compu= tations, = as e.g. in cTLS, (c) dynamic 
choice of header depending on network paths. All those issues persist=  when&nbs= p;sticking to the on-the-wire AAD.
What a= re your reservations towards this?

Cheers= ,
Hanno<= /span>
From: TLS <tls-bounces@i= etf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
Sent: Thursday, April 23, 2020 2:49 AM
To: Martin Thomson <mt@lowentropy.net>
Cc: <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] DTLS 1.3 AEAD additional data
 
OK but we would expect the peer to process CID-less records if they ar= e coalesced?

-Ekr


On Wed, Apr 22, 2020 at 6:39 PM Mar= tin Thomson <mt@lowentropy.net&= gt; wrote:


On Thu, Apr 23, 2020, at 11:24, Eric Rescorla wrote:
> On Wed, Apr 22, 2020 at 4:54 PM Martin Thomson <mt@lowentropy.net> wrote:
> > I prefer Ekr's solution, but I would go with that being a recomme= ndation (SHOULD) as opposed to a requirement (MUST).
>
> Can you clarify where you think we should say SHOULD?

The security considerations seems right.  After the list of improvemen= ts over DTLS 1.2 CID.  You would say that an endpoint that is asked to= provide a CID SHOULD provide one in every record (with the compact header,= etc...).  If it does not, then it might be possible for an attacker to use that record to confirm guesses about linka= bility between two paths.  Also, omitting the CID might make it hard t= o route datagrams.

With all of this, you might want a section heading for all the CID stuff.
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_AM6PR08MB3318D5881B8D2BEFF938F2B79BD30AM6PR08MB3318eurp_-- From nobody Wed Apr 22 23:50:01 2020 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 3B01E3A1587 for ; Wed, 22 Apr 2020 23:49:59 -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=bv4q503u; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=bv4q503u 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 kAccKNacabQN for ; Wed, 22 Apr 2020 23:49:56 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00043.outbound.protection.outlook.com [40.107.0.43]) (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 8D0753A1584 for ; Wed, 22 Apr 2020 23:49:55 -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=29YfAIx+eLefcC6lbZ8EfbHm3Aw3oH841OvtJKqZP+4=; b=bv4q503u1BLTQ9q3vJQnemoBy5qlnzOXOSsuhr0jf1Z5pDQfZMToXHHaiJg5Lv6r8lQbAmrhqmIoIAfDdTpBwEB8UvP4J0saOLgAcK8FnFoC4ciALfwoTWMY2XhDFSpIsq7lfLzYmK+mG/u5g0af87Ul2qX1y1P3m8nBmi8ZfBc= Received: from AM6P193CA0069.EURP193.PROD.OUTLOOK.COM (2603:10a6:209:8e::46) by AM0PR08MB4180.eurprd08.prod.outlook.com (2603:10a6:208:12d::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Thu, 23 Apr 2020 06:49:52 +0000 Received: from VE1EUR03FT037.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8e:cafe::bc) by AM6P193CA0069.outlook.office365.com (2603:10a6:209:8e::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Thu, 23 Apr 2020 06:49:52 +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 VE1EUR03FT037.mail.protection.outlook.com (10.152.19.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Thu, 23 Apr 2020 06:49:52 +0000 Received: ("Tessian outbound 3a3e6dcbad0e:v53"); Thu, 23 Apr 2020 06:49:51 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 6730849d6fef137d X-CR-MTA-TID: 64aa7808 Received: from af7dabb82c06.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 3B505821-00EF-47AE-89EC-870F9C63AA20.1; Thu, 23 Apr 2020 06:49:46 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id af7dabb82c06.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 23 Apr 2020 06:49:46 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GGsabEx4VB5xmjhTj21AdpYy4CTqjn3j0WXwFJjof8V112xSGvW3MFNToznmfAdL0GZ7YNZz8O2mZ/zpreHJuqoPXNMkOegTBCI482J2vcL48mbI7rLuNLrV+chuo0Qpp8vhJK5o7eGb4GlJXcm0CSngvox96wnusm41r4pqCfCU6VnJb1rZTNiG5e9o8CDg5xZt8BEm3v8GySnonxnVV4LDQWf6iL2U3P5fC8ROG1uhuzAn8Qa1sFkZelQzTCYdf1iy5e+gJrS7Xn24G9nwzmxWXoaQcYSW3lwX9nEedqysiDty/rsSyvqXLv71y5SieHgFqMo+5d6L3rIUYlwaGA== 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=29YfAIx+eLefcC6lbZ8EfbHm3Aw3oH841OvtJKqZP+4=; b=XrxB6Z4SwxmRQLtX2KcPB5/5qhvANtN0nrmVLxFZZxlVXn0dMmAYFuCwhwdJXofbOw1wHu1vLwKaC9eFdHTbAT9sx8oXu/T7sJhg7Zh5PBLhN03h61lW+WMIOhcStmDdyPdLB4GNLe2fUAdDUF0HmJqFRptzD8+YVHliYzrbjDLeoP4OKeR37L6khaCfQi/VclHLGDkIXlPH9Iyxg5XxQuxNYoCxOmum8xiE1ERwL80SZZpSVMrJCS7G+J4vCIE7AVrybOZ21k/13nBsz7kW87DqFswLCqeX9IMhd4KhhmNtcDWmL7QFm92H8runT6H7sXhPH3y7VPBNdTIsb+Cs4w== 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=29YfAIx+eLefcC6lbZ8EfbHm3Aw3oH841OvtJKqZP+4=; b=bv4q503u1BLTQ9q3vJQnemoBy5qlnzOXOSsuhr0jf1Z5pDQfZMToXHHaiJg5Lv6r8lQbAmrhqmIoIAfDdTpBwEB8UvP4J0saOLgAcK8FnFoC4ciALfwoTWMY2XhDFSpIsq7lfLzYmK+mG/u5g0af87Ul2qX1y1P3m8nBmi8ZfBc= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6PR08MB4949.eurprd08.prod.outlook.com (2603:10a6:20b:ee::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Thu, 23 Apr 2020 06:49:44 +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.2937.012; Thu, 23 Apr 2020 06:49:44 +0000 From: Hanno Becker To: Christopher Wood , "tls@ietf.org" Thread-Topic: [TLS] On the two types of ACKs in DTLS 1.3 Thread-Index: AQHWCa+c/6zqL3NX202z6YHPiVC69KiF6cOAgAB387Q= Date: Thu, 23 Apr 2020 06:49:44 +0000 Message-ID: References: , In-Reply-To: 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.177.220.146] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 753a8e44-5346-4b63-9307-08d7e7528655 x-ms-traffictypediagnostic: AM6PR08MB4949:|AM0PR08MB4180: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 03827AF76E 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:(4636009)(366004)(376002)(346002)(39860400002)(396003)(136003)(86362001)(2906002)(8676002)(76116006)(66446008)(66556008)(66946007)(66476007)(64756008)(71200400001)(52536014)(5660300002)(81156014)(8936002)(966005)(19627405001)(9686003)(6506007)(186003)(26005)(478600001)(7696005)(55016002)(316002)(53546011)(33656002)(110136005); 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: picA5+7BedKI+354bfjvtJBuWg8F+BDgxkhtBe04WOGJxlFYfmcL6Z5ZkpX0lumu6cpyq1CZI4MB4FOq/kI/ZH/HWV2r6YlCzCN6qQbzUJUMqtSjWwrT64PPZEoFTxaAXdMd976csDMSTVIAffkt6OGNK4nezlSLRwM+LK++2U39KL/m5Wr24jneMrL1I49dFZIODPoKQkfyFXiU8Z/uBoKYvbckul9rJPPA9/JPTn6gRWOMyJrb4hyAiDRslDqKAWyQIIlqRnBwZ1kJ36ghFe405QEm5AoxNfGPHT9O+kXW3EcqGy6nBrneww+i4II6YvH2JXnhWi9pyakthHNAhltYF8TifZ0ZisRoNHUj2cvp4MSWzeN6g9FjTiUTj243ynARtCthEWTPogOBpLEulxZGuMAvUuuZ7pIXxsIJTn1BTwA+bGuDPSMdzoz8LcS35Zhp0Dz89Rsc2tGzClAH3lC4pgcyAk2rGhzurTbrRDWW1PBCSED8BMobabfTr4dtI6EsZ71oPCRbrrhSKuW1Pg== x-ms-exchange-antispam-messagedata: ZD7u9wFh7QnodewXO3nKX/ZS8JnswfCpijx6jsZowIh5LaTheBMe63ujgc8QtGwuu+pFptJlIdKZ5ThwpTH+z6lSZzLJHBBfKk4gkMyJfcWUGo7cEVutMwb4C9WLqsmY1olb2Z1WQHPqez2qDeabuQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB33181AE7A270DBF7AF08BD789BD30AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4949 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT037.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:(4636009)(346002)(376002)(39860400002)(136003)(396003)(46966005)(82740400003)(316002)(966005)(110136005)(33656002)(478600001)(336012)(9686003)(36906005)(55016002)(186003)(19627405001)(8936002)(81156014)(52536014)(47076004)(70206006)(7696005)(8676002)(70586007)(81166007)(82310400002)(356005)(86362001)(26005)(30864003)(6506007)(5660300002)(2906002)(53546011); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: c3917dc9-dff6-4961-dd1b-08d7e75281cc X-Forefront-PRVS: 03827AF76E X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jTmW2laGflTV3RJItSRu1/oSAQ9ztfZm/YFw/nv8jdlhySN+7C5xbI9DgxhSAS0VbEhPjhSs4Z4MpiShk1I6w6rmxZiURFLeRAhZcGm8HkMXZ6jEVFdC+cUgy+IS6GOmTIj+uBrFKSRS2OE2W9xEMgkGIcg4gHUV1Q6xINYAZwp472/P8x5AMAd5bXf6OTfuHs5Jp4r2+n2owt2BnA5qOize6zz7KwZE6DylOvF3vLaTFxDFPoiC2rSowSCCFctUeML7G6r0E53RAK14/zeheeBz+BDKUBNCTjFaKoTzy6OPYDIymBdA+53TCrAC8waoy8d+apw/e/k+M+YfStxYXwm319s7iDxwig2tMMwk/ebdaipO+JGu1BZCAyh5VFteGLA8T/S7NCbDZV9lLoP1q9XhuJj0Qw1AWVlOwscLOotSxK10xp9jNge2z+/45ASA+cbHp2BrAVtRwMUenKVlqrHKGGtpOvbN+1PlMTk1JBuo7Ryj01hdo14zs9k+apIAFY8TB+I+eN4bMzCpz+RLI0fAufqnlQUp8UsPjUww44ofDCvv4rTUKy8q+NliS/j/eyf+iSIhKf4NkhqOmhopEw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2020 06:49:52.1924 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 753a8e44-5346-4b63-9307-08d7e7528655 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: AM0PR08MB4180 Archived-At: Subject: Re: [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: Thu, 23 Apr 2020 06:50:00 -0000 --_000_AM6PR08MB33181AE7A270DBF7AF08BD789BD30AM6PR08MB3318eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chris, Thanks for your reply. No, the PR does not address the issue described belo= w, because it keeps the use of a single kind of ACK for the two different purp= oses (a) retransmission requests [optional] and (b) acknowledgement of completio= n [mandatory]. However, it clearly describes this double-use of ACKs, which a= lready is a good thing IMO. However, as mentioned, given the late stage of standardization, I merely wa= nted to have this point raised and perhaps discussed, but didn't expect a change in= the end. Unfortunately, there doesn't seem to be much interest in this, so I think o= ne can put this to the records. Cheers, Hanno ________________________________ From: TLS on behalf of Christopher Wood Sent: Thursday, April 23, 2020 12:34 AM To: TLS@ietf.org Subject: Re: [TLS] On the two types of ACKs in DTLS 1.3 Hi Hanno, I believe this (now merged) PR addresses your concerns: https://github.com/tlswg/dtls13-spec/pull/140 Best, Chris On Fri, Apr 3, 2020, at 5:08 AM, Hanno Becker wrote: > 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 > 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 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_AM6PR08MB33181AE7A270DBF7AF08BD789BD30AM6PR08MB3318eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Chris,

Thanks for your reply. No, the PR does not address the issue described belo= w, 
because it keeps the use of a single ki= nd of ACK for the two different purposes 
(a) retransmission requests [optional] = and (b) acknowledgement of completion
[mandatory]. However, it clearly describes this double-use of ACKs, which already 
is a good thing IMO.

However, as mentioned, given the late stage of standardization, I merely wa= nted to
have this point raised and perhaps discussed, but didn't expect a change in= the end.
Unfortunately, there doesn't seem to be much interest in this, so I think o= ne can put this
to the records.

Cheers,
Hanno
From: TLS <tls-bounces@i= etf.org> on behalf of Christopher Wood <caw@heapingbits.net>
Sent: Thursday, April 23, 2020 12:34 AM
To: TLS@ietf.org <tls@ietf.org>
Subject: Re: [TLS] On the two types of ACKs in DTLS 1.3
 
Hi Hanno,

I believe this (now merged) PR addresses your concerns:

   http= s://github.com/tlswg/dtls13-spec/pull/140

Best,
Chris

On Fri, Apr 3, 2020, at 5:08 AM, Hanno Becker wrote:
>  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<= br> > 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<= br> > aspect discussed earlier regarding handshake-level vs. record-level AC= Ks
> (https://mailarchive.ietf.org/arch/msg/tls/O0pghTnz_8q1AiHSeMS= zxZg30RM/)
>
> 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 SHOUL= D 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 implementatio= n
>  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<= br> >  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 'positiv= e'
>  in that they indicate completion of a handshake, and they are >  mandatory in that a handshake will not complete unless they are<= br> >  used. In particular, an implementation MUST support those kinds<= br> >  of ACKs.
>
> At the moment, both kinds of ACKs are handled in the same way on the w= ire,
> and in order to even distinguish them an implementation has to maintai= n
> 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 treat= ed
> differently, and in particular easily distinguishable on the wire, the= n
> migration from a pair of DTLS 1.2 + TLS 1.3 stack to a minimal com= pliant
> DTLS 1.3 would only require implementing 'completion-ACKs', which, sin= ce
> they convey only a single bit of information, can in principle have a<= br> > 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
> confidential and may also be privileged. If you are not the intended <= br> > recipient, please notify the sender immediately and do not disclose th= e
> 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
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_AM6PR08MB33181AE7A270DBF7AF08BD789BD30AM6PR08MB3318eurp_-- From nobody Thu Apr 23 00:40:34 2020 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 B47B83A1652 for ; Thu, 23 Apr 2020 00:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Sa02MuPa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=z3LCO5ZZ 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 8_9oWxcwbJj9 for ; Thu, 23 Apr 2020 00:40:30 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C70323A1651 for ; Thu, 23 Apr 2020 00:40:30 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1E8325C01A8; Thu, 23 Apr 2020 03:40:30 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Thu, 23 Apr 2020 03:40:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=C8Ud/FHTGIoMN0l033vfZx3G7gMs k3kHUzOiwMCYl2c=; b=Sa02MuPaTjn37MMx9xslqToQ88VzuZ1ulxvGtF47UGOE DOfBcgPKdtAzRAhOFzeHFELXnLWESx12rOSzQZwZhVnS1vsQV4WU0mo2HEcDOqTC 1ZNx4jMKNrsv4smPOG5jncvNgtn2qNnl79aG3Dt/xqk4106q2INcPhNprmjcvqap 96qzHzwTOv2Qk/Yg0SqxbGC4OCiyxPq7nyUTDnQVYGlk5586CBhmi43/5zGn7JVj WonUF/8HdVCUTyXmhq7gD2w+GbpUNITXIlAjSQCNoMFEG8vzyDUwz4ywm1Iz/kn3 o6pkPHPI8tPvT5i55oxjG2rwYT+w0BRN6QNgmGXwEA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=C8Ud/F HTGIoMN0l033vfZx3G7gMsk3kHUzOiwMCYl2c=; b=z3LCO5ZZBs+tGE7wcRJ6GX ATY7EixLPmUdbEBze7lNJ/qNB3UvTizA/s77kQH9Q/I5prYgFzcTG7IL3YkZvCao cjpa4BQkaopeXvhMe/a2+sZXqUFNJ4S8Lg1mF7qOI7adw51bHFq/0ZebrtiSNKT3 cdWnd6/CaHyix/4obawsVfyZjd2RAYyrqc/IFbRjgi5ESz7aL5tSko251Mm6rMgt h+Pu/2vpuNqP3bVTLm6gEgov4yFvtStjhfVFL8eb49HA/yw5AF+Cn9LMDczA7kIN dn790Cdrxr6HU8q57Hr5FkaaAL1cIUwist9RMZSUz7Ek2TFFj9W8QaFpnXtNwzQQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeekgddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuff homhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8A5C7180091; Thu, 23 Apr 2020 03:40:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <1e6201d6-a078-4137-898d-d1554c22aa10@www.fastmail.com> In-Reply-To: References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com> Date: Thu, 23 Apr 2020 17:40:09 +1000 From: "Martin Thomson" To: "Hanno Becker" , "'Eric Rescorla'" Cc: "" Content-Type: text/plain Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Thu, 23 Apr 2020 07:40:33 -0000 On Thu, Apr 23, 2020, at 11:49, Eric Rescorla wrote: > OK but we would expect the peer to process CID-less records if they are > coalesced? I guess so. If we allowed them to drop them, then we're close to saying MUST NOT omit. On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote: > > But Hanno's proposal is a terrible thing to have to implement. You > have to assume that there is some way to recover which CID to use in > decrypting any record. You might save some datagram-local state, but > that's awkward. Stacks that I've worked on try very hard not to have > state transmission between records for good reasons. So this would be a > fairly bad complication. Separately, I hope that no one would be > contemplating trial decryption for this, which would be terrible. > > Yes that's a fair point and also applies to Ekr's proposal > https://github.com/tlswg/dtls13-spec/pull/143. I don't see how. If you are talking about marshaling costs, that's a constant problem, but we haven't found that to be an issue in practice. From my perspective, it's the old DTLS records with a pseudo-header that are hard to construct; the new format is far easier to construct for sending (assuming that you don't try to shave the sequence number length down dynamically, but that's a new option our stack doesn't try to use). Yours is a sending-side concern, and that seems to be subjective, because I think that sending is easier without a pseudo-header. My concerns were about receiving. > The CID maintenance for incoming records can be avoided when forbidding > CID elision, as suggested by Ekr. > Comparing the state maintenance complications this avoids to the > increase in header size it introduces, maybe > that's the way to go, as the state maintenance indeed seems to be the > bigger pain. > However, even if CID elision is removed, I maintain the proposal to > always use the logical presentation of the header > for AAD, for all the mentioned reasons: (a) No interleaving of record > and datagram layer, (b) conceptual clarity and > independence of [header] compression methods from cryptographic > computations, as e.g. in cTLS, (c) dynamic > choice of header depending on network paths. All those issues persist > when sticking to the on-the-wire AAD. > What are your reservations towards this? I'm sorry, I don't follow your argument. The authenticated logical header being different than what is sent on the wire is a bug in my opinion. Authenticating all the bytes you send makes the protocol simpler and less error prone. From nobody Thu Apr 23 01:11:37 2020 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 7FBAE3A16C2 for ; Thu, 23 Apr 2020 01:11:35 -0700 (PDT) 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=6JdRXv0M; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=6JdRXv0M 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 b13mlElJDcxb for ; Thu, 23 Apr 2020 01:11:33 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2049.outbound.protection.outlook.com [40.107.22.49]) (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 8A8FE3A16C4 for ; Thu, 23 Apr 2020 01:11:32 -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=3DMa9lqRmQtZvNWDjHMU83fpcZbL5SIEXhQWGqVMvmk=; b=6JdRXv0MXq5sTrxfa2J2KPCcPqKW0jWcEdAeiBr8/u9rtH+HFJgf8KBEY+5KR8pwqGgffiZk+1ZSjMHekwZ/dpxnfnehu0Ll0HgzErIVRxIJlzb02HxOiZvrHGShCjzD86HQrsBvHTJH9g94j0HSqwz+ZwwShcZdMqCnJMVTFTY= Received: from AM6PR08CA0040.eurprd08.prod.outlook.com (2603:10a6:20b:c0::28) by AM7PR08MB5461.eurprd08.prod.outlook.com (2603:10a6:20b:10e::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Thu, 23 Apr 2020 08:11:30 +0000 Received: from AM5EUR03FT010.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:c0:cafe::1c) by AM6PR08CA0040.outlook.office365.com (2603:10a6:20b:c0::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Thu, 23 Apr 2020 08:11:30 +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 AM5EUR03FT010.mail.protection.outlook.com (10.152.16.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.18 via Frontend Transport; Thu, 23 Apr 2020 08:11:29 +0000 Received: ("Tessian outbound 43fc5cd677c4:v53"); Thu, 23 Apr 2020 08:11:29 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: d4784a29477cc743 X-CR-MTA-TID: 64aa7808 Received: from 2bc1dac5af49.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 5B4F2047-CEBB-4B7D-BC87-FEF12BB408ED.1; Thu, 23 Apr 2020 08:11:24 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 2bc1dac5af49.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 23 Apr 2020 08:11:24 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=feZmwZA/890uz6SbkutT7oYHX1F3nV6HxZUMIaCBlaoZlivqPiIfgkVxZbO8ajWVkLbiPW84QBwO4eoA0Y2GRzBX58Q3fuJ6a8CUZ6t4krf8/UiXXRYa9K7uQLexTjmZblyCbWYTGex7DmhWfcUgmPOHLP8f084XG9dJRBVr6HH8Pl21mvfPFBWVA3aUZU4M+FBzk1dGaorEHMo4FGsSWYDoGfdugNGMeuwpr0g4te7QNZdoQdu2ZFlvtRZySkKNlfMXABtVIXfnW500NV4V4xKIp7Fj8KhKeH5IxToel2IQoML0/6hDTgoX8mGzUUtie68I5ByMkZpfSw/wTYCdhA== 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=3DMa9lqRmQtZvNWDjHMU83fpcZbL5SIEXhQWGqVMvmk=; b=a6NoAieY/9V9CEf+qwQboNMa9My+ZbFIlTserr+tcHMpFPHmPBdRxPKENu9sOTJM/LAQoQ2Jk8TDoITJ27ZjZVY0z9vniNJdqNLmoTw4gwGEY/5+G4ulx9rK46zotgkmSUrP4meavl8/hv7RHH/k1Q2kNs/MsDLBHackvyz7qjPJWcif8CU8Tttyb/vpgvWk/G2mes9Cppb8qgC0nsxLnCBVd3VFrkPlJCTuEo9F7XQ3rAZr9bfxFChksto2pxMmIwon94EticFNMVypUkA4mJO4RWu44xl8TnwGilDTMWjC8x8OV9d7J0KYeSc4M+WQ+TCmYgq3XAMO2Lxf4mO8qQ== 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=3DMa9lqRmQtZvNWDjHMU83fpcZbL5SIEXhQWGqVMvmk=; b=6JdRXv0MXq5sTrxfa2J2KPCcPqKW0jWcEdAeiBr8/u9rtH+HFJgf8KBEY+5KR8pwqGgffiZk+1ZSjMHekwZ/dpxnfnehu0Ll0HgzErIVRxIJlzb02HxOiZvrHGShCjzD86HQrsBvHTJH9g94j0HSqwz+ZwwShcZdMqCnJMVTFTY= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6PR08MB3735.eurprd08.prod.outlook.com (2603:10a6:20b:81::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25; Thu, 23 Apr 2020 08:11:23 +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.2937.012; Thu, 23 Apr 2020 08:11:23 +0000 From: Hanno Becker To: Martin Thomson , 'Eric Rescorla' CC: "" Thread-Topic: [TLS] DTLS 1.3 AEAD additional data Thread-Index: AQHWF+iN1gKILcDltkmRr5OfopCaAaiD3VMAgAB8FQCAAE7VmIAAawyAgAAHdS6AAB8+AIAACQCRgACPx4CAABkpAIAABDCAgAAC0ICAAEL8/IAAHxqAgAAFja4= Date: Thu, 23 Apr 2020 08:11:22 +0000 Message-ID: References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com> , <1e6201d6-a078-4137-898d-d1554c22aa10@www.fastmail.com> In-Reply-To: <1e6201d6-a078-4137-898d-d1554c22aa10@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: [86.177.220.146] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 88eef4a2-50ad-43ab-0038-08d7e75ded58 x-ms-traffictypediagnostic: AM6PR08MB3735:|AM7PR08MB5461: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 03827AF76E 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)(396003)(39860400002)(376002)(346002)(136003)(366004)(19627405001)(5660300002)(9686003)(55016002)(478600001)(966005)(33656002)(52536014)(7696005)(86362001)(4326008)(186003)(81156014)(6506007)(2906002)(64756008)(316002)(66946007)(66556008)(66446008)(66476007)(8676002)(8936002)(71200400001)(76116006)(110136005)(26005); 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: 8S8CKwbucnk+zWnME5n99R7UN4hs9VojJw0t4BbU+vUSYB6lxITnLwl46UDWsMSTv77mOIo6LmaAH16iHfHNRPOaBWjDbJhtiYSFNiF4N1ElhNrE9OVDmSH0uU6fyGkHJVhm0PT6XqtOmg9PmLLlcbxalBGD335CsDvwoZWW4mrkL0Zx5PjAT46MU76yPiRG710SXmZX7ne07kD8f+Fw6unju/P51xFxDz5rz9AuD635IqQwLycn1wmsmjpUXqZcj4S75EeaMNpqIqqGoCWd3stUVC4mt4Cp/5+yUDZx7TOGcbPBaQYo8h+IdjWNNedqkAWAYlSFpcidsa8sQ8iLKxdZ4qD/LO3Uz4QTVnieKhJgIwbRJ+91KGzQSK9Dm936zkzGcngOeXSHLeG4S6i5pIzwunnJ7CbtLwRllkm1gnYXRs3T050miwkGriN7N8fkPzq/THIj2flUQbvJsqxk2ptY0V4hm5AQtNJmJMFevE/RJ68Jl5KObSuE0rRgGQeiC7UmorooM3YoBSqkd7nrKg== x-ms-exchange-antispam-messagedata: Dd5+6OJaXRJM8l9H+rOzg0y2ILO2dLhM8oB9EPX6LR61jdxxYRhMQCqiWNUM6/Zg0FeSj5KLDlql5fMBZajlt9nq4DwLuYYkl+ZVd7KQQvNqevHhfmXL8EhgXr2J5HDA/NPVyPLVNCeciMSTc1oY+A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB33189D58D3342BCD68D91F299BD30AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3735 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT010.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:(4636009)(136003)(396003)(39860400002)(346002)(376002)(46966005)(186003)(47076004)(7696005)(9686003)(966005)(81156014)(336012)(5660300002)(8936002)(19627405001)(55016002)(26005)(33656002)(6506007)(478600001)(316002)(110136005)(2906002)(82310400002)(356005)(81166007)(82740400003)(86362001)(4326008)(52536014)(70586007)(36906005)(70206006)(8676002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 9f72befe-ab95-4862-52ad-08d7e75de96a X-Forefront-PRVS: 03827AF76E X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ZTG3OHwZ/OCEvWjDjD2buL7R3FVqX367HEvL+4/99Kd/ahZBhkhTIlbphHLYMvj1tT8bHsDNU0wIB1tKRtMbW8Vxy2ruikH7j3W1G55/9iuRl11c8maF+bmFqJHlA4wxEeCO+Xd0e4g1aQG4txFgxNTSLJfFUMaTifowX/5+w094bx5YdxDJ17gi0X9P6TvbRcpsrrhDwQrmGEl1pxv51EZxYf6JiIxFJJf6+0VLgCte4eXR+v1JT8Dco9yXE6ixV/3t4nsrbxm+kMRhDzyssHnrkeUHyUdkSv0pwi0LaxLJuRYauN+jwOAYlDXvx6T3hIqcBearFDYuDKPlNYdI5ew7YQ7VrSpIh6+XICESHaYv0eYHEyx1KjXSjHXL6MQWtceVQQ14q5RRd/L+8TdoMiO9hhZ0kPcHAK82vKk+yJCKttNXhNHAgTsSTfE5zEsYpQBPs6CfTJp0suHq+Y8r3Q5/M3M45mYAn4pIph3Cym9CEcbiwONQ9XZm/gh7pJ9+KFJUwvmb4KuxpSUzn/gl/b5qO07Sc4/jrH54jAHnp/MeH3a2PHCuhP6mDKwrC9jgCS1sCdnPVHIhgfN5AqToEg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2020 08:11:29.5286 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 88eef4a2-50ad-43ab-0038-08d7e75ded58 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: AM7PR08MB5461 Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Thu, 23 Apr 2020 08:11:36 -0000 --_000_AM6PR08MB33189D58D3342BCD68D91F299BD30AM6PR08MB3318eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Martin, On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote: > > But Hanno's proposal is a terrible thing to have to implement. You > have to assume that there is some way to recover which CID to use in > decrypting any record. You might save some datagram-local state, but > that's awkward. Stacks that I've worked on try very hard not to have > state transmission between records for good reasons. So this would be a > fairly bad complication. Separately, I hope that no one would be > contemplating trial decryption for this, which would be terrible. > > Yes that's a fair point and also applies to Ekr's proposal > https://github.com/tlswg/dtls13-spec/pull/143. I don't see how. If you are talking about marshaling costs, that's a const= ant problem, but we haven't found that to be an issue in practice. From my= perspective, it's the old DTLS records with a pseudo-header that are hard = to construct; the new format is far easier to construct for sending (assumi= ng that you don't try to shave the sequence number length down dynamically,= but that's a new option our stack doesn't try to use). You criticize that an implicit CID which is still included in the AAD requi= res state on the receiver when processing multiple records within a single = datagram, which is true. I'm saying that the same holds for the PR 143 whic= h adds the implicit CID to the AAD even if it's not in the header. In that = sense, this (valid) issue exists on both cases. Yours is a sending-side concern, and that seems to be subjective, because I= think that sending is easier without a pseudo-header. My concerns were ab= out receiving. There is nothing subjective here: You cannot make full use of the compressi= on features such as length omission independently of the underlying datagra= m layer, because you have to know that the record you're sending will be th= e last. So clearly sending is _harder_ if you have to decide on the header = format already during record protection, while if you can protect the recor= d on the basis of the logical header data alone, choice of header format an= d choice of packing into datagrams can be handled entirely independently. > The CID maintenance for incoming records can be avoided when forbidding > CID elision, as suggested by Ekr. > Comparing the state maintenance complications this avoids to the > increase in header size it introduces, maybe > that's the way to go, as the state maintenance indeed seems to be the > bigger pain. > However, even if CID elision is removed, I maintain the proposal to > always use the logical presentation of the header > for AAD, for all the mentioned reasons: (a) No interleaving of record > and datagram layer, (b) conceptual clarity and > independence of [header] compression methods from cryptographic > computations, as e.g. in cTLS, (c) dynamic > choice of header depending on network paths. All those issues persist > when sticking to the on-the-wire AAD. > What are your reservations towards this? I'm sorry, I don't follow your argument. What exactly? The authenticated logical header being different than what is sent on the w= ire is a bug in my opinion. Authenticating all the bytes you send makes th= e protocol simpler and less error prone. So far, there hasn't been any substance to the claim that authenticating th= e logical header is a "bug" or "defect", while in (a)-(c) above I provide m= ultiple reasons why it is in fact beneficial. 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_AM6PR08MB33189D58D3342BCD68D91F299BD30AM6PR08MB3318eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Martin,

On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote= :
>  > But Hanno's proposal is a terrible= thing to have to implement. You
> have to assume that there is some way to reco= ver which CID to use in
> decrypting any record. You might save some da= tagram-local state, but
> that's awkward. Stacks that I've worked on tr= y very hard not to have
> state transmission between records for good r= easons. So this would be a
> fairly bad complication. Separately, I hope t= hat no one would be
> contemplating trial decryption for this, whic= h would be terrible.
>
> Yes that's a fair point and also applies to E= kr's proposal
> https://github.com/tlswg/dtls13-spec/pull/143.

I don't see how.  If you are talking about ma= rshaling costs, that's a constant problem, but we haven't found that to be = an issue in practice.  From my perspective, it's the old DTLS records = with a pseudo-header that are hard to construct; the new format is far easier to construct for sending (assuming that you d= on't try to shave the sequence number length down dynamically, but that's a= new option our stack doesn't try to use).

You criticize that an implicit CID which is still = included in the AAD requires state on the receiver when processing multiple= records within a single datagram, which is true. I'm saying that the same = holds for the PR 143 which adds the implicit CID to the AAD even if it's not in the header. In that sense, thi= s (valid) issue exists on both cases. 

Yours is a sending-side concern, and that seems to= be subjective, because I think that sending is easier without a pseudo-hea= der.  My concerns were about receiving.

There is nothing subjective here: You cannot make = full use of the compression features such as length omission independently = of the underlying datagram layer, because you have to know that the record = you're sending will be the last. So clearly sending is _harder_ if you have to decide on the header format alr= eady during record protection, while if you can protect the record on the b= asis of the logical header data alone, choice of header format and choice o= f packing into datagrams can be handled entirely independently. 

> The CID maintenance for incoming records can = be avoided when forbidding
> CID elision, as suggested by Ekr.
> Comparing the state maintenance complications= this avoids to the
> increase in header size it introduces, maybe =
> that's the way to go, as the state maintenanc= e indeed seems to be the
> bigger pain.
> However, even if CID elision is removed, I ma= intain the proposal to
> always use the logical presentation of the he= ader
> for AAD, for all the mentioned reasons: (a) N= o interleaving of record
> and datagram layer, (b) conceptual clarity an= d
> independence of [header] compression methods = from cryptographic
> computations, as e.g. in cTLS, (c) dynamic
> choice of header depending on network paths. = All those issues persist
> when sticking to the on-the-wire AAD.
> What are your reservations towards this?

I'm sorry, I don't follow your argument.

What exactly?

The authenticated logical header being different t= han what is sent on the wire is a bug in my opinion.  Authenticating a= ll the bytes you send makes the protocol simpler and less error prone.

So far, there hasn't been any substance to t= he claim that authenticating the logical header is a "bug" or &qu= ot;defect", while in (a)-(c) above I provide multiple reasons why it is in fact beneficial.

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_AM6PR08MB33189D58D3342BCD68D91F299BD30AM6PR08MB3318eurp_-- From nobody Thu Apr 23 01:26:23 2020 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 8CECA3A16EC for ; Thu, 23 Apr 2020 01:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=T8ToHL1V; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rZYibsCd 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 IFXQulClBQpU for ; Thu, 23 Apr 2020 01:26:19 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DBA3A16EA for ; Thu, 23 Apr 2020 01:26:18 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 565B95C0196; Thu, 23 Apr 2020 04:26:18 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Thu, 23 Apr 2020 04:26:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=CunbMT/bt/ftidNp7yp492DQTgz+ n0DtxWzvPSLzoeU=; b=T8ToHL1V2ctSwL4HC9ij44Lq9RciyBuorUJR+jaQWw/b kemOJSK6Kmf214BZkRgCw/gJuRQ0+4OmRbP8aWZfehlBYqK/0reWloVKVSNNmeVb iylIx+tJNmLCyV32KYwZxFCLoTMXGrI1gMz7hqv5c5WLDzHKmOs3NAM2RD8IZpY4 dAsUpynvwV8tx2+zVaMExeTm4Y/a/jaZi4lgBR+M7Z+Fjt6WFi9MP96Zr0ZhZy10 LhWcfx53lKOwNUhtO0tjaH4VQEt9X5tIJYH7nZ2zUgsFihsR8GEHXCet2AQw5IkP Wps7Tw4GecKHXv3H78cbRL83qnsb3wjq4pZUrUzSBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=CunbMT /bt/ftidNp7yp492DQTgz+n0DtxWzvPSLzoeU=; b=rZYibsCdMkvX56kK7IH6Ak VkULAG+BsYdvhrH2xbOuB4OIdSScL+m6t8E+UnrsX3k4bhbqM2/bR5wzxY2fecpt AaY1mPHdR2pzQrjScH5Dfw2m/+8JGhNrE5X7EFgd+9LOQGgy9aUHwbOqj0oG2Jov aE4y59iV4ncXAX5XFPS0M74uzMjj1edG8EsNxcjKrUmJ4D5HYLvBcdIyP2Z4zH8M ynuBM/ojtdyBMBNawuLgqUGk9sS1lwpBDYMDuBSxpuvtCeXQMFt3FhCSoqf0gE0l +l7rGaO2aQ3yTetovlUiuX+MtroLlErxuSDvfGKhe/XGhLjFZUSsEAjBLFADXSrg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeelgddtfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigv nhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CD97E180093; Thu, 23 Apr 2020 04:26:17 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com> <1e6201d6-a078-4137-898d-d1554c22aa10@www.fastmail.com> Date: Thu, 23 Apr 2020 18:25:57 +1000 From: "Martin Thomson" To: "Hanno Becker" , "'Eric Rescorla'" Cc: "" Content-Type: text/plain Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Thu, 23 Apr 2020 08:26:21 -0000 On Thu, Apr 23, 2020, at 18:11, Hanno Becker wrote: > You criticize that an implicit CID which is still included in the AAD > requires state on the receiver when processing multiple records within > a single datagram, which is true. I'm saying that the same holds for > the PR 143 which adds the implicit CID to the AAD even if it's not in > the header. In that sense, this (valid) issue exists on both cases. Right, but that is why I don't like 143.. > There is nothing subjective here: You cannot make full use of the > compression features such as length omission independently of the > underlying datagram layer, because you have to know that the record > you're sending will be the last. So clearly sending is _harder_ if you > have to decide on the header format already during record protection, > while if you can protect the record on the basis of the logical header > data alone, choice of header format and choice of packing into > datagrams can be handled entirely independently. Those are new, optional features, so I'm assuming that any costs associated with exercising them justify any complexity. > > The authenticated logical header being different than what is sent on the wire is a bug in my opinion. Authenticating all the bytes you send makes the protocol simpler and less error prone. > > So far, there hasn't been any substance to the claim that > authenticating the logical header is a "bug" or "defect", while in > (a)-(c) above I provide multiple reasons why it is in fact beneficial. I don't agree with your reasoning. As far as a bug, let me just say that having to allocate and construct a pseudo-header separate to the actual header is work that no longer has to be done. So receiver logic is easier. From nobody Thu Apr 23 05:00:19 2020 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 C660B3A198E for ; Thu, 23 Apr 2020 05:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.82, 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=LdoYeV2T; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=LdoYeV2T 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 dFtgFYrQYwrP for ; Thu, 23 Apr 2020 05:00:15 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60063.outbound.protection.outlook.com [40.107.6.63]) (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 D6A743A0A3E for ; Thu, 23 Apr 2020 05:00:14 -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=AnDW2QWgLWxkZgMbqitPuhH6gw7g1bhZ6DAAcJYVeUY=; b=LdoYeV2TmWIguLkCuMAN3Av0Mr1rR51TU3rJuKZcT50E1xaMa6R/2ZXx8+zr3S/XA707J/Ev7jLsu1nuRv5QNaH7kkZoTpNwSEamKx+nszBnzIaSm8ajL57tKSQdd5r7HMW0a+qkVa2gq7H5oZyjNtlGyT7l4rannCJm/EAnDsg= Received: from DB6PR07CA0106.eurprd07.prod.outlook.com (2603:10a6:6:2c::20) by AM0PR08MB3412.eurprd08.prod.outlook.com (2603:10a6:208:dc::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Thu, 23 Apr 2020 12:00:11 +0000 Received: from DB5EUR03FT044.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:2c:cafe::42) by DB6PR07CA0106.outlook.office365.com (2603:10a6:6:2c::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.9 via Frontend Transport; Thu, 23 Apr 2020 12:00:11 +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 DB5EUR03FT044.mail.protection.outlook.com (10.152.21.167) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Thu, 23 Apr 2020 12:00:11 +0000 Received: ("Tessian outbound d63670e9da8f:v53"); Thu, 23 Apr 2020 12:00:11 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 32d80d0190cb60ca X-CR-MTA-TID: 64aa7808 Received: from ad1928893607.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id ABC29D97-AB94-4A24-BCB0-5920799030FF.1; Thu, 23 Apr 2020 12:00:06 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id ad1928893607.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 23 Apr 2020 12:00:06 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K5zUftqc24RPqwCWpf7/7qxCTAphvfM3tPRsOsLiwGLW+KX5WdwT+fYtKPXmhuey2ZOFF4C8HJyJEqYkXBWwIAyrxAcBBri64Wt5TY0Zf5Hsa7C9BbO8SenAj30zy/FtPY5og+dS73XSmVuMgoaqcM2tQysdaS5eIedCWOGdNcQDa0q1dtNN87ooPwDuv6HK63BMk0DMnCcbI2J41EkOnKRm9eRi1mwhbe/Bv0eyOrN6c3Cc7eNhDQbJgB8KPV2T6/S2V5lAL0vW5iVeqGDmDfxfNq070DhOn3E61Gcvl6pK/EZwQPcGQzeFI52a/lFaXEtIx6HL2DX+cpzkgHsciQ== 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=AnDW2QWgLWxkZgMbqitPuhH6gw7g1bhZ6DAAcJYVeUY=; b=oHIj5uHPnu3ReWe0XV3TmsFzYYlCjLODbdN9g8egx8bCaPW1LSmKyiRPfBWYFiXn6EYM34yAEoLAaMxrvkpYTjcePADpU9IdaiEoiKXtMoGDS56XG8y443cLO7Vzs0EEb7yqOleh2EvsyjFd1n70G/xe+1xkJ0MqjIptQXBj6vST9wy4patYIwKVPZUozMd54L7Nw4s/2mvklq/RRkcZ+m8dkWk9fVOJlZsk7lLGv/xEm0CX6nDUq8Z0MTpJeZMauf5Y9gXOPOK7mPLJFusyaaMJa/a0MVVSKEGURpMxmx+NVuulFN1lnsn1cTiSugClf3tHDkzptRBsFkoW5OnorQ== 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=AnDW2QWgLWxkZgMbqitPuhH6gw7g1bhZ6DAAcJYVeUY=; b=LdoYeV2TmWIguLkCuMAN3Av0Mr1rR51TU3rJuKZcT50E1xaMa6R/2ZXx8+zr3S/XA707J/Ev7jLsu1nuRv5QNaH7kkZoTpNwSEamKx+nszBnzIaSm8ajL57tKSQdd5r7HMW0a+qkVa2gq7H5oZyjNtlGyT7l4rannCJm/EAnDsg= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB4293.eurprd08.prod.outlook.com (2603:10a6:20b:be::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Thu, 23 Apr 2020 12:00:04 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::b08c:a849:e63d:6150]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::b08c:a849:e63d:6150%7]) with mapi id 15.20.2921.032; Thu, 23 Apr 2020 12:00:04 +0000 From: Thomas Fossati To: Martin Thomson , "TLS@ietf.org" Thread-Topic: [TLS] DTLS 1.3 AEAD additional data Thread-Index: AQHWF+iN1gKILcDltkmRr5OfopCaAaiD3VMAgAB8FQCAAE7VmIAAawyAgAAHdS6AAB8+AIAACQCRgACPx4CAANufAA== Date: Thu, 23 Apr 2020 12:00:03 +0000 Message-ID: References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> In-Reply-To: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: cc552cb8-4e31-4100-ffbc-08d7e77de038 x-ms-traffictypediagnostic: AM6PR08MB4293:|AM6PR08MB4293:|AM0PR08MB3412: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:9508; x-forefront-prvs: 03827AF76E X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(39860400002)(396003)(346002)(376002)(8676002)(2616005)(5660300002)(8936002)(2906002)(86362001)(26005)(110136005)(53546011)(33656002)(81156014)(6506007)(186003)(316002)(478600001)(91956017)(36756003)(66476007)(66556008)(64756008)(71200400001)(6512007)(6486002)(66446008)(66946007)(4326008)(76116006); 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: 5MXsUvzEnJtCfqUiOJY7xzmz423hVW8+zgGLngZuvSXriY4uGF7qPfCOEQgiNY1TvYms0wIPBNH373h1Y6gg/SVLdDwJ5AUJS/qS+daNSeZFiRcACWEcn3YuaSfp3ML3vFY2dKHSiVbHoYqDsywSCQZ8eydpTFfCRxvKho1dYNP9BdyAP9wDgf1eXEGAYXOG5CHGLz1UUsA3K4BTKqdgCIaRcWuCXBOQ7BU1RfVJJRuyoFpgTPDqCnpAX9jhcLz/MXus/J7JQmCNX3t5fY5pI38eeh7asEapeM9rPx87/VTZduBe//QoILrFsaJ5iB+qiqr+DGef9UWxvi5cW3ef5Dtkbe2oaNLFklxBKJALp04ByoFLXjOtYnWUcuZmqq8mftEp5CJJMe25658Wlu923c1D7Ei/1YMWFD5eJaFPHADD+QUz0GOMVi0MFbMPqMuO x-ms-exchange-antispam-messagedata: MWKJFmNDzSEhcI/NyAgcKrgrLIn/qtzbsq2J7Yj4dDNBPd4hDgfik7y8yjSgI7tBEgv1k3niAg2PzDEmqtW32d9JCA7STk8athn6aoWQFmkgcj3dkpcOd8N4RbQ2i/4ENZ+oXmjvuvGbt63DSpEBwg== Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4293 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT044.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:(4636009)(136003)(39860400002)(376002)(346002)(396003)(46966005)(186003)(70206006)(70586007)(6506007)(478600001)(2616005)(6486002)(53546011)(36756003)(26005)(6512007)(86362001)(110136005)(4326008)(8936002)(356005)(82310400002)(8676002)(316002)(5660300002)(33656002)(81156014)(81166007)(2906002)(336012)(82740400003)(47076004); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 82a34dd0-01de-41c0-53d8-08d7e77ddbd2 X-Forefront-PRVS: 03827AF76E X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: T9Iz/kfzupzoRfRMC5CbXWs9QgYw562nuwuQN1Fxtnc9JMHcIXD8x0r1NJgvB/9XWK/OgQDNnsMmVBgEaKJzHOsoknKIAai1YA0cdK1/Yh+cIzzrK4nzR6OCyPC40AU7qeVAYz3QhLBfRx5WI/3d4Dscu5ey2DBpq8kKt7BMwmfcAIZ40vy0mz+FnpZHu0xlZEVZHgYVr36Tf3VSs6LWR9PvtEr+H8T/XUys9tsNISVaKLImITgrG64eLTA8eSvWt8effg/ioCsVpYfKBUsr87x8dyUpuXF4Zqe+qkTgZE/REh2cIEMpQIAMvOlHoEG2XJaOhKeZAoZWUhGtlCV0c4FPvkWYed5rpT4GDuajNyygLverTUlSKafWD0H0R4Ye9EFWuqTV8VQYLLDXRo7woavxxHnX0ujMvv4ZDJOarP7sIYGsvYo7uThFRrKv+yZ6eOqWQ8qtyxQxZrMRANpV9WE/WjiSx6bBYG2bKbPbjV2cFjEQ5hsN7ykMb4u6G7ML0q5b9IVY/orDE1p2LwGTiQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2020 12:00:11.4904 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cc552cb8-4e31-4100-ffbc-08d7e77de038 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: AM0PR08MB3412 Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Thu, 23 Apr 2020 12:00:18 -0000 SnVzdCBvbmUgY29tbWVudC4NCg0KT24gMjMvMDQvMjAyMCwgMDA6NTQsICJNYXJ0aW4gVGhvbXNv biIgPG10QGxvd2VudHJvcHkubmV0PiB3cm90ZToNCj4gQnV0IEhhbm5vJ3MgcHJvcG9zYWwgaXMg YSB0ZXJyaWJsZSB0aGluZyB0byBoYXZlIHRvIGltcGxlbWVudC4gIFlvdQ0KPiBoYXZlIHRvIGFz c3VtZSB0aGF0IHRoZXJlIGlzIHNvbWUgd2F5IHRvIHJlY292ZXIgd2hpY2ggQ0lEIHRvIHVzZSBp bg0KPiBkZWNyeXB0aW5nIGFueSByZWNvcmQuICBZb3UgbWlnaHQgc2F2ZSBzb21lIGRhdGFncmFt LWxvY2FsIHN0YXRlLCBidXQNCj4gdGhhdCdzIGF3a3dhcmQuICBTdGFja3MgdGhhdCBJJ3ZlIHdv cmtlZCBvbiB0cnkgdmVyeSBoYXJkIG5vdCB0byBoYXZlDQo+IHN0YXRlIHRyYW5zbWlzc2lvbiBi ZXR3ZWVuIHJlY29yZHMgZm9yIGdvb2QgcmVhc29ucy4gIFNvIHRoaXMgd291bGQgYmUNCj4gYSBm YWlybHkgYmFkIGNvbXBsaWNhdGlvbi4NCg0KVGhlIGNvc3Qgb2Yga2VlcGluZyBwZXItZGF0YWdy YW0gc3RhdGUgb24gdGhlIHJlY2VpdmluZyBlbmQgc2VlbSB2ZXJ5DQpsb3cgdG8gbWUuICBBbmQg dGhhdCB3b3VsZCBiZSB0aGUgb25seSBjb3N0IG92ZXJhbGwsIGJlY2F1c2Ugb24gdGhlDQpzZW5k aW5nIHNpZGUgdGhlcmUncyBub25lLiAgQW5kIHRoaXMgaXMgaW4gY29udHJhc3QgdG8gdGhlIGhp Z2hlciBzZW5kZXINCmNvbXBsZXhpdHkgaW4gdGhlIGN1cnJlbnQgZHJhZnQuICBBbHNvLCBvbmNl IHlvdSBzdGFydCBrZWVwaW5nDQpwZXItZGF0YWdyYW0gc3RhdGUsIHlvdSBtaWdodCBhcyB3ZWxs IHN0YXNoIGFzIG11Y2ggYXMgcG9zc2libGUgaW4gaXQNCmFuZCBmb3IgZXhhbXBsZSBjb21wcmVz cyBzZXF1ZW5jZSBudW1iZXJzIGFzIHdlbGwgYXMganVzdCB0aGUgQ0lELg0KDQpTbywgaWYgdGhh dCBpcyB0aGUgb25seSBibG9ja2VyIFdSVCBIYW5ubydzIHByb3Bvc2FsLCBJJ2QgYmUgaGFwcHkg dG8NCnRyYWRlIHRoYXQgb2ZmIGZvciB0aGUgbmljZSBwcm9wZXJ0aWVzIGl0IGNvbWVzIHdpdGgu DQoNCj4gU2VwYXJhdGVseSwgSSBob3BlIHRoYXQgbm8gb25lIHdvdWxkIGJlIGNvbnRlbXBsYXRp bmcgdHJpYWwgZGVjcnlwdGlvbg0KPiBmb3IgdGhpcywgd2hpY2ggd291bGQgYmUgdGVycmlibGUu DQoNClN1cmVseSBub3QuDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlz IGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28g YmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhl IGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9y IHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4N Cg== From nobody Thu Apr 23 08:10:59 2020 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 71BD53A0A04 for ; Thu, 23 Apr 2020 08:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com 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 DwmK_9o8Kto5 for ; Thu, 23 Apr 2020 08:10:55 -0700 (PDT) Received: from mail3.verisign.com (mail3.verisign.com [72.13.63.32]) (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 31C873A09FA for ; Thu, 23 Apr 2020 08:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=9674; q=dns/txt; s=VRSN; t=1587654657; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=7XaOTJ3kINdKHOwcsO74Ne4NFaO/+ATkv/f2Js3NMsc=; b=RFvVMgplV8rWBcy+45NKVLhJAaZThB7hdYLT+kN9QU/ndDd85l/4ITj9 Q+EBjf7zPEzzPF1UewidNNKkHhRzPBRM4zweYAiNHRgXSWRf9n8OPt0iG Tbu8qDU8ll5pX5H8DTFBLkruqN0Eh6Gne5rapg3WFO20nQU7haP3eFBws xuHBgQP3GDXyWE0HnrQb+/xfxCABpmwZtTk4oSEmDgPw1e50SJ17onvCF 1fOMx1RYdMQ8DzhEjPsptdTuMWFzIV3y9jUggfmrAMrlQOqmpZrkxyN2f 6aRGWz8alC42+NLVtSO6aRf9uT/b36POK2IN+BDIVHtB3P/wLQ0xqVsnP A==; IronPort-SDR: ZQThQWbLF2/QGl5igDquxJsLoSOGtkI7LN1VeqMvEGqMYw9dqxI5Meht00lWQOuhnEHdj9XEDH QPXZUxxxxUPkZpI/1FFX+wZEUwBRg6f+jYE40DM7zfEnfRN1rQyfXsuOHGXNHVfmnkMRXHo3ss Z48wY00qHwxmgyZ6ELHbkKesdYHPkqqW+tfSQNNt5hi5y5+h/lusOYyQbSWRXyZaVvBawtRILT bXklHLDCacs4pUtNrOP8/6dzXislQpV5MtuY/z19E+aJ4OO62w4YUVzBCha2JZ1dcAU6S7ZkaC BiI= X-IronPort-AV: E=Sophos;i="5.73,307,1583193600"; d="scan'208";a="1336586" IronPort-PHdr: =?us-ascii?q?9a23=3ATnmRFxQ5YQ2gjmHuTeb6hlmidtpsv+yvbD5Q0Y?= =?us-ascii?q?Iujvd0So/mwa6zbBaN2/xhgRfzUJnB7Loc0qyK6v2mBT1Lv8bJmUtBWaQEbw?= =?us-ascii?q?UCh8QSkl5oK+++Imq/EsTXaTcnFt9JTl5v8iLzG0FUHMHjew+a+SXqvnYdFR?= =?us-ascii?q?rlKAV6OPn+FJLMgMSrzeCy/IDYbxlViDanbr5+MRW7oR/eu8QSjodvK6U8wQ?= =?us-ascii?q?bVr3VVfOhb2XlmLk+JkRbm4cew8p9j8yBOtP8k6sVNT6b0cbkmQLJBFDgpPH?= =?us-ascii?q?w768PttRnYUAuA/WAcXXkMkhpJGAfK8hf3VYrsvyTgt+p93C6aPdDqTb0xRD?= =?us-ascii?q?+v4btnRAPuhSwaMTMy7WPZhdFqjK9DoByvuQFxw5Labo+WOvpxfKLdcs8VS2?= =?us-ascii?q?VORctRSzVBAoGgY4cTE+YNI+BVpJT9qVsUqhu+ABGhCO3txD9Pgn/22bM10+?= =?us-ascii?q?I6Hg7YwAMgHMoCu2nJotrpM6cSTfy1wKfVxjjEdPNW2TD96IzMch8/p/GDRq?= =?us-ascii?q?x/ftbSyUQ0CQPKkE+QqY3+PzOU2eQNtXKX4PZnVeKqkmMqrRx6rDaoxscpkI?= =?us-ascii?q?bJh4QVx0jY+iV424Y6Odq4RFRnbt6jFZtcryGaN5dqQsM6WGFltjw1xqMIuZ?= =?us-ascii?q?KlcigKx5UnxwLfa/yaaIeE+A7sVOGUITp+mXlre6q/ig6v/US80OHwS8u53V?= =?us-ascii?q?hQoiZYktTBuGoB2hPQ58SfV/dx4l2t1SuN2gzP8O1IPE85mKnBJ5I8wbM9kI?= =?us-ascii?q?cYv17ZES/sgkr2ibebdkAj+ue19evqeq7mppqAN49sjQH+L7gultS/AesmNg?= =?us-ascii?q?gOWHCW9Pmg2rP74EH2QK1EgPI3naXFrZzWP9obqbK+Aw9PyoYv8QywACq83N?= =?us-ascii?q?QGh3kHN1RFdAibgIjuPlHCOPH4DfGhjFSwiDpn2uzKMqf8DpjPIHXPiqrtcL?= =?us-ascii?q?Zz5kJGxwc+zshT55dOBbEAJPLzVFXxtNvdDhIhKAy0w+HnCNF51owAX2KAGb?= =?us-ascii?q?GWP7/RsVKT+OIgPfOMZI4OuDb8JPgl4eTigmM+mV8YZaWpx4cYaGikHvR6JE?= =?us-ascii?q?WUeWbjjc0PEGoRvgoxUvbliEWDUT5VaHa9RKM85i0gCI68C4fMWJytiqSb3C?= =?us-ascii?q?inBp1WenxGCleUHHn2cYuKRuwBaCOMLc99nDwIT7+hS5Uu1ULmiAivgbFuMc?= =?us-ascii?q?LU9yQAtJTs3tlp/KvVmA14vWh/Btu102yEV2BykWkJWyRw2q1j9wg1gGun6o?= =?us-ascii?q?B5juBWU9tJ6LkBBjseDrbdwvB0TdfoVVSSUM2OTQPsYtKiBTw3RN86wJtGWE?= =?us-ascii?q?16B8noxkTY3y2uB7ITnbGAB7Qq/7jdxHn+IYB2zHOQh/pptEUvXsYabT7uva?= =?us-ascii?q?V47QWGX4M=3D?= X-IPAS-Result: =?us-ascii?q?A2HzAABXr6Fe/zCZrQpcAQkbAQEBAQEBAQUBAQERAQEDA?= =?us-ascii?q?wEBAYF7gxaBMQqVLIEBmHGBKzwKAQEBAQEBAQEBBwEjDAQBAQKEQgKCSjgTA?= =?us-ascii?q?gMBAQsBAQEFAQEBAQEFAwEBAQKGPwyCOyJ3PAk5AQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQQCDVRJAQEdAQEBAQIBOhoqBwQCAQgRB?= =?us-ascii?q?AEBARUJEDIdCAEBBAEQAgiDH4JcL7BPgieEOQGBFYRzBoE4iW2CZoFCPoERg?= =?us-ascii?q?hJJNT6CZwKBHhoBFFeFMgSODCqJNIo4jwN2AweCRYgMj2MlglmIVJE+j3WJQ?= =?us-ascii?q?ZM4AgQCBAUCFYFpgXlwgzlQGA2RPxiDUIpWSCwNjiWBEAEB?= Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 23 Apr 2020 11:10:53 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1913.005; Thu, 23 Apr 2020 11:10:53 -0400 From: "Hollenbeck, Scott" To: "caw@heapingbits.net" , "TLS@ietf.org" Thread-Topic: [EXTERNAL] Re: [TLS] Comments on draft-ietf-tls-external-psk-importer-04 Thread-Index: AdYX4WFdhLPIgsQ4RUymyBbaAf5mxQAiWZWAAEVqU+A= Date: Thu, 23 Apr 2020 15:10:53 +0000 Message-ID: References: <96ed3f4c-7ad4-4406-95c9-1e96b5a49eed@www.fastmail.com> In-Reply-To: <96ed3f4c-7ad4-4406-95c9-1e96b5a49eed@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Comments on draft-ietf-tls-external-psk-importer-04 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: Thu, 23 Apr 2020 15:10:58 -0000 > -----Original Message----- > From: TLS On Behalf Of Christopher Wood > Sent: Tuesday, April 21, 2020 9:57 PM > To: TLS@ietf.org > Subject: [EXTERNAL] Re: [TLS] Comments on draft-ietf-tls-external-psk- > importer-04 > > Thanks for the feedback, Scott! Please see inline below. > > On Tue, Apr 21, 2020, at 6:57 AM, Hollenbeck, Scott wrote: > > 2. Technical comments. > > > > a. Distinct identities? Sec. 3 states "Non-imported and imported PSKs > > are distinct since their identities are different on the wire." We > > have two concerns about this statement. First, the statement appears > > to suggest that if two EPSKs have different identities, then they must > > have different secret values. But couldn't two EPSKs have the same > > secret value yet employ different identities for convenience? For > > example, an endpoint might identify the same EPSK with a domain name > > in some cases and with an IP address in others. > > This seems like a reasonable editorial improvement to make. I filed: > > https://secure-web.cisco.com/1WQM3tDUuuSkXPZ- > qwaA2YKrAcqlkOAsqUSqvQThf6zv7T7Gi7ofekeY-6UPrqcF1k5cW- > i8pc5KYZ8GDkbBhgNSydezOTkChVTOsIlACtvE0hnca9DN7D056URvddDaO54LI > jMM4o4hOFRlCHReLnVJ4g90Pm0foS9AAaeBQK2w1oTQNJrx9B6EqDlIvn3- > Sh3oF_cBDlKk0XXLyJYWRZRflbYw3Tg1Ga8HPzfUZf- > qJqqQquKG5sEsl_vdKIQbyIVGSYJVTTx6x- > viXGJXTsQ/https%3A%2F%2Fgithub.com%2Ftlswg%2Fdraft-ietf-tls-external- > psk-importer%2Fissues%2F31 Thanks! > > Second, and more > > fundamentally, the statement assumes that a non-imported EPSK, by > > definition, cannot be misinterpreted as an imported PSK. But isn't > > the identifier of a non-imported EPSK just an opaque string? A > > non-imported EPSK identity could therefore have the same "bits on the > > wire" as an IPSK identity, if the client and server employ an > > identifier system that whose encoding happens to coincide with the > > ImportedIdentity structure defined in the draft. ( Moreover, the > > identifier of a resumption PSK is just an opaque string > > -- so couldn't this also collide with ImportedIdentity values? > > Perhaps we are missing something even more fundamental in our > > reading.) ([draft-dt-tls-external-psk-guidance-01] covers similar > > issues in its Sec. 6.1.2, "PSK Identity Collisions.") > > Yes, certainly it's possible for a non-imported EPSK to have an identity = which > matches the constructed identity of an imported PSK. We can't do anything > to prevent applications from crafting such identities, so I'm inclined to= just > note this as a possibility, if anything. A note would be fine. > > b. Attack impact. If it's possible for an opaque identifier for a > > non-imported EPSK identity to have the same encoding as an > > ImportedIdentity value, then how does the server recognize > > unambiguously that the opaque identifier is intended to be an imported > > identity? The server could take an optimistic approach and assume > > that an identifier that meets the ImportedIdentity syntax is probably > > an imported identity, and run the code path for imported identities fir= st. > > Yep, that's what I envisioned servers would do. > > > If that path fails, however -- either because the server doesn't > > accept the EPSK or associated parameters, or because the binder value > > is incorrect -- then the server may need to run the code path for > > non-imported identities as a fallback, checking next to see if the > > opaque string is recognized as an ordinary EPSK identity. But this > > practice just puts more burden on a server against an attacker who > > replays (or makes up) the PSKIdentity.identity value: two code paths > > are exercised for the price of one attempted handshake. > > I don't think this is a particularly useful attack, though I do agree tha= t it causes > more work for the server. I'm curious to hear what others think. > > > c. Mitigations. One way to reduce the burden is to impose a new > > requirement that the opaque string can only have the ImportedIdentity > > syntax if the client (or server in the case of hints) indeed intends > > to use the import mechanism. An ordinary EPSK could have any other > > value, just not this kind. But this may not be compatible with the > > installed base, especially with implementations that allow clients and > > servers to specify arbitrary EPSK identities. (Consider the case where > > an application adopts the imported identity syntax for the use > > intended in this draft, and then decides to reuse the syntax for other > > purposes, including ordinary EPSK identities.) > > > > Another way to ensure distinctness is to add a flag that indicates > > that the PSK identity is an imported identity. But it's not clear > > where this flag would go, given that the PskIdentity syntax isn't exten= sible. > > Perhaps there could be an overall flag indicating that _all PSK > > identities are imported identities? Or a new extension for imported > > PSKs? > > Since this draft is meant to fix an annoyance in TLS 1.3, I think anythin= g more > than a different Identity encoding is overkill. I absolutely agree that t= he > rigidity of PskIdentity is something we might want to fix. I'm just not s= ure > that should be done here. Agreed, this would be a larger discussion. Just wanting to be sure the con= cern was noted in the document. > > d. Key separation. Note that the foregoing discussion about EPSK > > identifiers potentially colliding is separate from the question about > > what happens if an IPSK happens to collide with a non-imported EPSK. > > The draft handles this effectively with different inputs to the binder > > derivation ("ext binder" vs. "imp binder"). But this happens after > > the implementation has already decided whether to interpret the > > identifier as external or imported. > > > > e. Incremental deployment. Section 6 states that " the derived PSK > > will not be the same [as the underlying EPSK] since the importer > > differentiates the PSK via the identity, target protocol and target > > key KDF." However, the next statement does not follow directly: > > "Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS > > 1.2, and thereby avoid cross-protocol collisions." Rather, the > > statement also depends on the requirement in Section 3 that clients > > (and servers) don't deliberately use EPSKs or IPSKs for other > > purposes, and the security properties of the KDF that produces the IPSK > (which ensures > > that collisions don't occur accidentally). But there also seems to be > > an implication in Section 6 that the use of the KDF in the TLS 1.3 > > importer doesn't conflict with the cryptographic functions used for > > obtaining the TLS 1.2 pre-master secret. If so, this distinction > > should be spelled out. > > Hmm, not quite. The statement intends to say that if you need EPSK k into= an > importer and into TLS 1.2 then the resulting keys used in TLS 1.3 and 1.2= are > different. I'm not sure further clarification is needed, though I'm happy= to > review suggestions if you have them! Agree with that as the goal. Here's our concern in brief. If our understa= nding is correct, prior to this draft, the client could use an EPSK k in tw= o ways: * as input to the TLS 1.2 PRF (based on any hash function) * as input to the TLS 1.3 key schedule via HKDF-extract (based on a single = hash function) Following this draft, the client could use k in two ways: * as input to the TLS 1.2 PRF (based on any hash function) [same as before] * as input to the importer function via HKDF-extract (based on a single has= h function) So there is still a potential cryptographic overlap in the use of k between= TLS 1.2 and TLS 1.3. The imported keys don't have this overlap, because t= hey're separated from one another and from the underlying EPSK through the = use of the importer function. But doesn't the security proof for k still n= eed to take into account that the input to HKDF-extract might also be input= to the TLS 1.2 PRF (with the same or a different hash function)? In other words, if it was a problem for the security proof that k could be = input to the PRF and to HKDF-extract before the draft, isn't it still a pro= blem afterwards? The conclusion that there are no cross-protocol collision= s depends on the specifics of the TLS 1.2 PRF and how it's used, compared t= o HKDF-extract. We're not suggesting there is any attack here, just trying to understand th= e design actually addresses the statement in the introduction that k "could= possibly be re-used in two different contexts with the same hash functions= during key derivation". > > Related to this, where Section 3 states, "Clients which import > > external keys MUST NOT use either the external keys or the derived > > keys for any other purpose," should "Clients" be "Clients and servers" > > or simply "Endpoints"? > > Yep, that's a good editorial improvement. I filed this issue to track it: > > https://secure-web.cisco.com/14iqE- > IvKyzMIbRcXgwccUfg1Jfmjd0IBwnplgFvO9aogfaXjAswuQPiy8YhPoMSDQq52 > Clal4RRXTdAVhGMJ3zbqgPzm4PJnDmtl- > lbzJXYMcF_nmRwuIbN_zYzA2BmaTCC1TTsoffzPhT_SmO68N- > GEumtgGhjOKtrvJT0VT52ut_WJuoT0SDe8HNNuUnVr2FDmhr9FPeSA0VwR4B > vKmC- > E1V1WC0XCizBO3AcSsTsOSmQsu6vjV0ZVc5Z4c9zdlgjdY0fEiEVyC98ShPswiQ/h > ttps%3A%2F%2Fgithub.com%2Ftlswg%2Fdraft-ietf-tls-external-psk- > importer%2Fissues%2F30 Great! > Thanks again for your review and feedback! Welcome! Scott From nobody Thu Apr 23 08:16:08 2020 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 563BA3A0A12 for ; Thu, 23 Apr 2020 08:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com 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 qlUKDW0oUAmS for ; Thu, 23 Apr 2020 08:16:02 -0700 (PDT) Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (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 0D3023A0A10 for ; Thu, 23 Apr 2020 08:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=7563; q=dns/txt; s=VRSN; t=1587654962; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=rZarEefj5GvWLJxKcv+6R63M600IiUZVbEYLfP9wE5s=; b=I67+9IGZlDbbLocZAE2+1B3NOROhDbqXJIyv8/zaIk8w94/2dsZCq+Cy 6Kd6odgIOco21QV+MxItbSJceHtvldurZBZ0+82pAA05n5dZ6VL9RHRVs ge75kgwT/62PNr/eQ/+ZM4e6HNKlyhxuHGZmXakPXq3DXajmyYgTb0tPE DtL7U143dcSCGJ24uU1pZbVofxnYP7Sq1WYOdllDg8RD6sRjPw7Dnrfs+ ChoJPDKv1Rq+kWz/GQPk5m95H1Oat7dVBpN956yTynzjGDkaKuuyO8eao vNwrU+EsSkTXFY6BzzTywxvcZ4eCGbRp73SjFCd3rsUBO1JJi0i6qHvBK w==; IronPort-SDR: xmwqORC7JYkzcXHjqAvmhjppNTrwKDrrBLUd6lBz4Toi2Uks3rs6oLmyF5LqPNoAG1l2EI3WvY kp8axzCFDpeI4lphDWawS7rL25tQkn2idGvJ3o8f35FjfW2M8qHyLj3bN5pLypHM7moUtsf+4I saPrI+EhJ+dPsehkThllJIoMQW/yqF28Hj6jW2FRTVqd7X6L73KfXbs2ZXuAW3d3Mm1dre56GJ iKY7BLm2h6xDCghVtLrNkY0kIt02TjoGwzvUT7ERFMYrB3lrXetGKg1G3kYCFB+BAE6BxJlDE0 beo= X-IronPort-AV: E=Sophos;i="5.73,307,1583211600"; d="scan'208";a="1217037" IronPort-PHdr: =?us-ascii?q?9a23=3AWGqPeR2EyYOk0irEsmDT+DRfVm0co7zxezQtwd?= =?us-ascii?q?8ZseMWKPad9pjvdHbS+e9qxAeQG9mCtrQY2qGI4ujJYi8p2d65qncMcZhBBV?= =?us-ascii?q?cuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx?= =?us-ascii?q?7xKRR6JvjvGo7Vks+7y/2+94fcbglVhDexe7x/IRG5oQjQssQdnJdvJLs2xh?= =?us-ascii?q?bVuHVDZv5YxXlvJVKdnhb84tm/8Zt++ClOuPwv6tBNX7zic6s3UbJXAjImM3?= =?us-ascii?q?so5MLwrhnMURGP5noHXWoIlBdDHhXI4wv7Xpf1tSv6q/Z91SyHNsD4Ubw4RT?= =?us-ascii?q?Kv5LptRRT1iikIKiQ5/XnXhMJukaxbvByvqR9xw4HWYYGaKPVwcazGcNMGXG?= =?us-ascii?q?pBXNpdWzBdDo+iaYYEEuoPPfxfr4n4v1YCoxmwBQ6oBOPr1DBIgGT50rMm3O?= =?us-ascii?q?QiCQ3NwREuEM4JsHTIsNX5OroZXOeuzKnIyjXDa/dW1in76IfTbB8uvfKMUK?= =?us-ascii?q?luccXP00kvFhjFjlSfqYzjJT+ayuMNs22C4udmSOmhiHYnphlsrjSz3Msgl4?= =?us-ascii?q?vEi4wPxlzZ9Sh0zpw5KNK7RUJjfNKoDIFcuzyYOodqWM8uXm5ltSUgxrEbup?= =?us-ascii?q?O2ejUBxo49yB7FcfOHdpCF4hfkVOmMPzh1nGlleLejhxaq9kig1/H8WtG00F?= =?us-ascii?q?lUqipFlcHBu20R2RLL98SISuNz8Eig1jqTygzf8P9ELlwzlarBM54t2KQ/mY?= =?us-ascii?q?cJvUTdBC/2g0P2gLWKeUUj/+ik8+XnYrP4qZ+AL4J4lx3yPr4zlsG9D+k0KB?= =?us-ascii?q?UCUmiV9Oim27Du/lX1QLBQgf03lqnZvoraJcMepqOhGA9V0oEj6xK7Dzi41t?= =?us-ascii?q?QXhmcII05GeB+ckYjmJUvOIPHjDfe+jFSsli1nyOzBPr3kGpnNNGTMkK/9fb?= =?us-ascii?q?Zh7E5R0BY8wspR5p9PCrEOPuj8WlfwtNzeAR82KA20w/r8CNln0IMRR36PCL?= =?us-ascii?q?eDMKzOqV+I+v4vI+6UaY8JvDb9MOMo5//wgn8ll18RZ66p3YEYaCPwIvMzaU?= =?us-ascii?q?6QflLsj94ZEGEFtAsiV6rshUHIGWpYbmmaX681/jA9B4inEZyFQI2x1vjJlj?= =?us-ascii?q?u/BbVXa3xITFeWHj2gI5mAQN8NZT6cZMh7nWpXe6KmTtpr9RaqsAL8wbdsLa?= =?us-ascii?q?6cwSYfqY6pnIxu5+rXkRw0/zF/DOyD3nuMVGB7mCUDQDpgj/M3mlB01lrWif?= =?us-ascii?q?swuPdfD9EGv/4=3D?= X-IPAS-Result: =?us-ascii?q?A2HOAgAesKFe/zCZrQpmHAEBAQEBBwEBEQEEBAEBgXuER?= =?us-ascii?q?wqVLJtZCgEBAQEBAQEBAQcBLwQBAYREAoJKOBMCAwEBCwEBAQUBAQEBAQUDA?= =?us-ascii?q?QEBAoYTCDCCOyKDaQEBAQECATpLBAIBCBEBAwEBARgGEDIXBggBAQQBEgiFe?= =?us-ascii?q?7B+gieFT4R5gTiJbYJmgUI+gRGDED6EJRFnhSIEjh0/iQ6KOI59fAMHgkWXb?= =?us-ascii?q?yWCWYhUkT6PdZx5AgQCBAUCFYFpgXlwUIJpUBgNjhyRYXSMfSaBD4EQAQE?= Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Thu, 23 Apr 2020 11:15:59 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1913.005; Thu, 23 Apr 2020 11:15:59 -0400 From: "Hollenbeck, Scott" To: "caw@heapingbits.net" , "tls@ietf.org" Thread-Topic: [EXTERNAL] Re: [TLS] Comments on draft-dt-tls-external-psk-guidance-01 Thread-Index: AdYXH6KSBS1BAI8XTwWXm/Rvqwo8MQByrvgAACXMJHA= Date: Thu, 23 Apr 2020 15:15:59 +0000 Message-ID: <16d1dd1b028e4428868a61e3c891e43e@verisign.com> References: <5baf193953c94e3093fda66c8e3baa4d@verisign.com> <9074c915-2482-46a2-be99-cdf72939ec7b@www.fastmail.com> In-Reply-To: <9074c915-2482-46a2-be99-cdf72939ec7b@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Comments on draft-dt-tls-external-psk-guidance-01 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: Thu, 23 Apr 2020 15:16:07 -0000 > -----Original Message----- > From: TLS On Behalf Of Christopher Wood > Sent: Wednesday, April 22, 2020 1:10 PM > To: TLS@ietf.org > Subject: [EXTERNAL] Re: [TLS] Comments on draft-dt-tls-external-psk- > guidance-01 > > Thanks for the feedback, Scott. Please see inline below. > > On Mon, Apr 20, 2020, at 7:26 AM, Hollenbeck, Scott wrote: > > Here are a few comments gathered from Verisign Labs on > > draft-dt-tls-external-psk-guidance-01: > > > > 1. Sec. 6, requirement 1 states "Low entropy keys are only secure > > against active attack if a Password Authenticated Key Exchange (PAKE) > > is used with TLS." "only secure ... if" may be too strong a > > statement, because there could be other mechanisms for increasing the > > entropy of a pre-shared key that do not meet the formal definition of a > PAKE. > > Moreover, as defined in draft-barnes-tls-pake, a PAKE repurposes the > > DH key share to carry a transformed version of the EPSK, so it > > involves a different architecture than the ordinary process for > > incorporating EPSKs into the TLS key schedule that is assumed in most > > of the present draft. > > > > If the goal of the present draft is to encompass PAKEs as well as the > > ordinary process, then the scope of the draft should be broadened to > > something like "handshakes based on EPSKs, whether through the > > ordinary process of incorporating them into the key schedule, or > > through alternate mechanisms such as PAKE where the DH key share is > > based on the EPSK." > > > > Alternatively, the statement in requirement 1 could be rephrased as > follows: > > > > "If only low-entropy keys are available, then key establishment > > mechanisms such as Password Authenticated Key Exchange (PAKE) that > > mitigate the risk of offline dictionary attacks MUST be employed. > > Note that these mechanisms do not necessarily follow the same > > architecture as the ordinary process for incorporating EPSKs described > > in this draft." > > This seems like a reasonable proposal to me. Specifying integration with > PAKEs is (or was intended to be) out of scope, and this clarifies the > requirement without widening the scope. Agreed. > > 2. Sec. 6, requirement 2 states, "Each PSK MUST NOT be shared between > > with more than two logical nodes." This "MUST NOT" is stronger than > > the "NOT RECOMMENDED to share the same PSK between more than one > > client and server" > > In Sec. 7 and would exclude group PSK use cases that are acknowledged > > in that section. The requirement is also inconsistent with this > > statement in Appendix B of draft-ietf-tls-external-psk-importer: > > > > "Applications which require authenticating finer-grained roles while > > still configuring a single shared PSK across all nodes can resolve > > this mismatch either by exchanging roles over the TLS connection after > > the handshake or by incorporating the roles of both the client and > > server into the IPSK context string." > > > > If the intent is to restrict use to at most two nodes, then > > requirement > > 2 should go even further and restrict use to one node in a TLS client > > role, and one in a TLS server role. > > > > We would therefore suggest that requirement 2 be changed to something > > like the following: > > > > "Unless other accommodations are made, each PSK MUST be restricted in > > its use to at most two logical nodes: one logical node in a TLS > > client role and one logical node in a TLS server role. (The two > > logical nodes MAY be the same, in different roles.) Two acceptable > > accommodations are described in > > [draft-ietf-tls-external-psk-importer]: exchanging client and server > > identifiers over the TLS connection after the handshake; and > > incorporating identifiers for both the client and the server into the = context > string for an EPSK importer." > > > > (Note that we've changed "roles" to "identifiers" to align with Sec. > > 7) > > This is a *great* suggestion! Thank you for clarifying in ways we could n= ot. I'll > take it. Glad to be able to add clarity here. > > Related to this, "logical node" should be defined somewhere, e.g., > > "For purposes of this document, a logical node is a computing presence > > that other parties can interact with via the TLS protocol. A logical > > node could potentially be realized with multiple physical instances > > operating under common administrative control, e.g., a server farm." > > Alternatively, the term "endpoint," which is used elsewhere in this > > document, could be used here as well (perhaps also avoiding the single > > use of "agent"). > > Yep, defining "logical node" would be great. We should probably have a > separate definition section up front to consolidate these terms in one pl= ace. > We can work with your suggestions and make that happen. OK. > > 3. Sec. 7 recommends that that each node selects one globally unique > > identifier for all PSK handshakes, but without giving rationale why > > this approach is preferred for mitigating the attacks mentioned > > earlier in the section. This may be limiting, because a logical node > > may legitimately be known to different endpoints by different identifie= rs: > > a domain name in some cases, an IPv4 address in other cases, and an > > IPv6 address in still other cases. We would therefore recommend > > relaxing this recommendation. > > Since it's merely a recommendation, I think we ought to keep it. It's a s= imple > deployment model that solves issues. > > We could list your use case as a counter example as to when this > recommendation may not be appropriate. Would that work? Yes. > > 4. General. The draft makes no mention of certificate-based > > authentication in connection with EPSKs, for instance as described in > > in RFC 8773, "TLS 1.3 Extension for Certificate-based Authentication > > with an External Pre-Shared Key." We understand that use of external > > PSKs with certificates is out of scope for the design team. > > Certificate-based authentication, potentially in combination with a DH > > exchange, can improve the security properties of TLS handshakes based > > on EPSKs and help protect against both rerouting attacks and > > impersonation attacks. Is there any interest in adding some guiding > > text to the document before it's adopted by the WG? We're willing to > > provide text for consideration. > > Sure, we're absolutely open to contributions! You're right that it's out = of > scope, though it could be useful in an appendix, or wherever else you thi= nk > it's appropriate. We'd recommend adding a sentence to the introduction that certificate-based= authentication is out of scope, with a reference to RFC 8773 for details. = This could be combined with a statement that PAKE is also outside of scope= . Suggestion: "The design team effort that produced this document was limited in scope t= o the PSK techniques specified in TLS 1.3 when using high-entropy PSKs. Ot= her approaches can also be beneficial in certain situations, but were out o= f scope. For example, Password Authenticated Key Exchange (PAKE) technique= s [[ref]] can be used to establish a TLS session with low-entropy PSKs, and= certificate-based authentication can be combined with PSKs (and possibly w= ith a Diffie-Hellman exchange) to help protect against both rerouting attac= ks and impersonation attacks [RFC 8773]." Scott From nobody Thu Apr 23 10:45:31 2020 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 C41D33A0D9E for ; Thu, 23 Apr 2020 10:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=ghedini.me 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 uTuMR73Szsfl for ; Thu, 23 Apr 2020 10:45:26 -0700 (PDT) Received: from blastoise.ghedini.me (blastoise.ghedini.me [45.32.158.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29EB93A0D9D for ; Thu, 23 Apr 2020 10:45:24 -0700 (PDT) Received: from localhost (unknown [IPv6:2a02:8010:6241:1:ac3a:6185:15e7:ef83]) by blastoise.ghedini.me (Postfix) with ESMTPSA id DCC0FDF47D; Thu, 23 Apr 2020 17:45:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1587663918; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fiCCho1ZolUz69w/Qox74ebOhZsEDHccUcKb/T9a6Mc=; b=Qk6IqeokLlqxeFBf9Qr/l3hR0hIwqFTjGla18/CPuTJsrWNus0aJkCvstThYTUO/baPrMB D+yVQ4nMM50/7M9gVElHD6KbnTU6Slg7tAdYQVhZEoGUzT3AqgNmz7qevQqq1/XYUl3Ca+ mI3FJ702huoDFAr/t/dQ9rpq+dwfaUU= Date: Thu, 23 Apr 2020 18:45:13 +0100 From: Alessandro Ghedini To: David Benjamin Cc: Ilari Liusvaara , "" Message-ID: <20200423174513.GA11390@sokka.flat11.house> References: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> <315F2BCF-11E0-4FBD-8420-865F29A66AD1@akamai.com> <20191123134005.GA1224585@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate 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: Thu, 23 Apr 2020 17:45:29 -0000 On Sun, Nov 24, 2019 at 11:27:26AM -0500, David Benjamin wrote: > On Sat, Nov 23, 2019 at 8:40 AM Ilari Liusvaara > wrote: > > > On Fri, Nov 22, 2019 at 08:18:47PM +0100, Hubert Kario wrote: > > > On Friday, 22 November 2019 03:25:24 CET, David Benjamin wrote: > > > > On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich wrote: > > > > > > > > > > ... > > > > > SHA-1 signature hashes in TLS 1.2" draft available > > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/. > > > > > Please review the document and send your comments to the list by > > 2359 UTC > > > > > on 13 December 2019. > > > > > > > > > > I just re-read this. Looks good. Perhaps a sentence of rationale in > > ... > > > > > > > > To that end, the combination of client advice in sections 2 and 4 is a > > bit > > > > odd. Section 2 uses SHOULD NOT include MD5 and SHA-1, but section 4 > > says > > > > the client MUST NOT accept the MD5 SHA-1, even if it included it. Why > > would > > > > the client include it in that case? It seems the two should either > > both be > > > > MUST NOT or both be SHOULD NOT. > > > > > > because it also influences certificate selection, and getting a > > certificate > > > signed with SHA-1 isn't an automatically disqualifying property? > > > (it may be an intermediate CA that's not used, it may be an explicitly > > > trusted > > > certificate, etc.) > > > > If you don't want SHA-1 exchange signatures, you darn sure do not want > > actual SHA-1 certificates that are not trust anchors anyway. And because > > TLS 1.2 does not have separate lists for exchange signatures and > > certificate signatures, the client needs to withdraw advertisment for > > both in order to not send a misleading offer. > > > > Right, I had a longer discussion of the certificate-but-not-TLS case but > omitted it. :-) Basically what Ilari said. In particular, I believe older > versions of Schannel will, despite being able to sign SHA-256, > preferentially sign SHA-1 if the client offers it. This is inconvenient > when it comes to predicting breakage but is perfectly consistent with the > client's offer. When I last looked at this a few years ago, this accounted > for a nontrivial portion of SHA-1-negotiating servers on the web, so > rejecting SHA-1 while still advertising it is probably not the best > strategy. > > Fortunately, we've already distrusted SHA-1 X.509 signatures on the web, so > hopefully that will simplify things. There is a risk that some servers' > trust anchors' (otherwise irrelevant) signatures are SHA-1 and they are > trying to match it against the signature algorithms list, but I expect the > SHA-1-preferring servers to be the deciding concern. Issues with > trust-anchor-checking servers can likely be worked around by configuring > the server to not send the trust anchor, which is desirable anyway. > > (All of this may not apply to non-web deployments, of course.) > > > > And I expect that in practice, not sending SHA-1 in > > signature_algorithms would cause very little breakage on top of what > > is already broken due to using SHA-1 exchange signatures. > > > > So I think both should be MUST NOT. So, based on this discussion, I made the following PR to change this to MUST NOT https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/5 Thanks for the review! Cheers From nobody Thu Apr 23 10:47:35 2020 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 3B8CF3A0DA7 for ; Thu, 23 Apr 2020 10:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=ghedini.me 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 JRd72Ao6mNfN for ; Thu, 23 Apr 2020 10:47:29 -0700 (PDT) Received: from blastoise.ghedini.me (blastoise.ghedini.me [45.32.158.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698683A0DA6 for ; Thu, 23 Apr 2020 10:47:29 -0700 (PDT) Received: from localhost (unknown [IPv6:2a02:8010:6241:1:ac3a:6185:15e7:ef83]) by blastoise.ghedini.me (Postfix) with ESMTPSA id 5E7EEDF538; Thu, 23 Apr 2020 17:47:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1587664042; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mN0Hu+D5HPOmjQSekf7shlZ2ilTmgaxy2fDJQ3FdHRU=; b=W33R8IeJLNIu4TUyhAgutoQeOA9EkNteYPxZVsakD/0ZWu2hgYEPDg/O6B1t43ZzXatd8L HCfgcuJarusJ7PvCACfaVRozhyTQVMGFUjOkb2veWgOHm5ES4RQwLOttQNsZa7poVNE+yP nTKn3CtYTBp5Uy+hnYxQJ7TWRW4x0H0= Date: Thu, 23 Apr 2020 18:47:18 +0100 From: Alessandro Ghedini To: Karthik Bhargavan Cc: Ilari Liusvaara , tls@ietf.org Message-ID: <20200423174718.GB11390@sokka.flat11.house> References: <508EEDF7-73D2-4BE6-AFBA-710E5A5AB41F@sn3rd.com> <315F2BCF-11E0-4FBD-8420-865F29A66AD1@akamai.com> <20191123134005.GA1224585@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate 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: Thu, 23 Apr 2020 17:47:34 -0000 On Sat, Nov 23, 2019 at 05:32:36PM +0100, Karthik Bhargavan wrote: > This is a bit of a shameless plug, but I think it is important to cite papers that show that the use of weak hash functions for TLS signatures is actually exploitable. > > As far as I know, the last round of deprecating MD5 in TLS signatures was triggered by the SLOTH attack: > > https://www.mitls.org/pages/attacks/SLOTH > > The associated paper explains how weak hash functions can allow an attacker to break protocols like TLS, SSH, etc. > > https://www.mitls.org/downloads/transcript-collisions.pdf > > This probably deserves to be added to the references of this draft. > > @inproceedings{BhargavanL16, > author = {Karthikeyan Bhargavan and Gaetan Leurent}, > title = {Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH}, > booktitle = {Proceedings of the {ISOC} Network and Distributed System Security Symposium ({NDSS} '16)}, > month = {Feb}, > year = {2016}, > url = { > http://www.mitls.org/downloads/transcript-collisions.pdf > } > } Thanks, I made https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/6 to add a reference to this paper as well. Cheers From nobody Thu Apr 23 13:49:23 2020 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 A71D43A13AD for ; Thu, 23 Apr 2020 13:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 ovMZpG72mrZn for ; Thu, 23 Apr 2020 13:49:20 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31D0F3A13AC for ; Thu, 23 Apr 2020 13:49:20 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id w145so5894480lff.3 for ; Thu, 23 Apr 2020 13:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=xXz2I2VY8AJ+nNm+VefRaQxzSMIFiwxrAsmRwZ4EVwQ=; b=fHFywDQB2/ZotrfNtCrsA1Es1drS+Zv4bCgu1p7jtx0XGCN2ZWGGB45nXsVtvrbOVn alUD7CamDWc5Uq8450NWtSvL5kSCMDBoQdQUCnFRZrEQB2il22SqtS5xvKm8kfpueigs ovAd09v1BySyLKOBjfE+zI7nEsbf1+qsNnbjnkb+TqzOk7WvtbTBTOx5jJl8xcKRGhbi 71QeKs/RAyrvrDhq795CTH5YWHk1/R8oTmwNritOLoC8c8VawyUjsueoSykabJ5eu0PT H9m5GuEGJ3sark53qce/xPJJcDuEAjWB8WCYG2OT59BqHOhhSyC+ADt6whtFrwredCGp W72A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xXz2I2VY8AJ+nNm+VefRaQxzSMIFiwxrAsmRwZ4EVwQ=; b=Wdj8ddAIDA5EQxdXaEKiUbRk+IEi0XRvekCQMBufc+1rezuEECAKG6GZtSlB15easD T/JIxCTGCGhaos5A+vvQIEnqQh45tvcNEsDd7UBr3CbwzIkQe4j8LuFGtHkSCSwPtj8w tnYoKZqns+dJBpPrTlNitxncOMdQciKkgMHpqDZdamQULegAt60icdiIv75OB15v980E zpXxgcJwcUAeZZGEIFMPfHmkB1bTl4a5l33nTlYa1LwS+1pObdOh1C4zjUnlvIwBSqGd 7ilCplcyvbZnSWiuor+sp1K1kodI+rm29LcBNekp5Yp+0nVYWoUlSgFG3afgzk43DnBp l+Gg== X-Gm-Message-State: AGi0PuY8PHuD2MEHBPBVRu071+ei7wiTwDLw7JZvC8ByDyypORFqUyXH 3r2TGjhbbFDaJtYIrkjMxiRSuq+pmGptGbUKIBO5wdpy9909zA== X-Google-Smtp-Source: APiQypIcpizrzcvk1t1LOAfgKPmX4Ea05QmlmONkQCJxGZ5ZjMPGf+XTctvoIoNje2ERiOaItsrG2/QvGRqoZp3gYpc= X-Received: by 2002:a19:230c:: with SMTP id j12mr3632687lfj.109.1587674958237; Thu, 23 Apr 2020 13:49:18 -0700 (PDT) MIME-Version: 1.0 From: Eric Rescorla Date: Thu, 23 Apr 2020 13:48:42 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000e7a51805a3fb61df" Archived-At: Subject: [TLS] Implicit ACKs in post-handshake 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: Thu, 23 Apr 2020 20:49:22 -0000 --000000000000e7a51805a3fb61df Content-Type: text/plain; charset="UTF-8" Hi folks, As I was going through the ACK clarifications, I noticed that we were requiring explicit ACKs for everything other than post-handshake client auth, where we allow implicit ACK. This obviously works, but given that (1) we expect explicit ACK from the client if there is a user-consent delay and (2) it's the only one, what would people think of using implicit ACKs only for the handshake itself. -Ekr --000000000000e7a51805a3fb61df Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

As I was going through the ACK clarificat= ions, I noticed that we were
requiring explicit ACKs for everything othe= r than post-handshake
client auth, where we allow implicit ACK. This obv= iously works,
but given that (1) we expect explicit ACK from the client = if there
is a user-consent delay and (2) it's the only one, what wou= ld people
think of using implicit ACKs only for the handshake itself.
-Ekr


--000000000000e7a51805a3fb61df-- From nobody Thu Apr 23 14:18:39 2020 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 F0E813A13F8 for ; Thu, 23 Apr 2020 14:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 utOXlEbzwKqQ for ; Thu, 23 Apr 2020 14:18:29 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5F43A1412 for ; Thu, 23 Apr 2020 14:18:28 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id 131so5918227lfh.11 for ; Thu, 23 Apr 2020 14:18:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=H01mJDs0IzDLhjsBbrk0wPdqJ90Aj2vglMgqPppWNcE=; b=pFFQaFNlkmacAOi8hM1Ri3pDv+VndDuiHWnf4MHD0T/DsU2O7vmK+CdiJ2i1RXbWHD sEnzBSkHK+RGLX8Z7cGa6ErbYScjFg2X+9ZKpU/R+yHrzIs8mEkIWv0keJLgy5q05wIP wUnQw9GHPe7jroeycobz/hUEep4rhKqMmrBUQUXKPt+oRYzACpMq+SGouF8MNCiBeMOf UoCJ9+9fzSCY1iONuXMuEfJR0K1BpFyUz3WFEviMEXnfHUAVD7Q6/GAhetHdydZWTj3/ z7Bux8x/jlqPf6qhLmXyh79Ruh/LPDf0ouCYG8RWGMLLxEoocCmUEKRRwHGtkylJ6mk8 WHkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=H01mJDs0IzDLhjsBbrk0wPdqJ90Aj2vglMgqPppWNcE=; b=ZwgwYIGMHTKAb5JnO5MRxrTudzJ0OK47ifhHRV6k5IBU33VZgTAHGo/Aa/m2qIan6v odOs1MrSRypYXEftUusM7uA5i2ORJdvoEn799PhuxJ84CdJg3x14teOKf4jMT3qAEhCu +cfdDMQ0yWaJzKbX2T2cxZYhP/VuqMKwTOEPh+ySAHSe6IfAO2MzNPKTeWdBA8OdYRAC nv56EYRt+4PNb4EAjQ2E0iCrUBbZlhR/joJ7IC2F+PRq73LX6BkvinM9phQPUjTwpZUK 37NvmCXQfiAzXaByik78h4e5N2dSWrZH25Hn5+hMJDZOCpuBavc6t/zgEyTpoETOtjL0 WwXg== X-Gm-Message-State: AGi0PuZlf6RuTdYaf5x12ATFa4f64dZtqUr+1eSGVTtnebH68u3omUbS SZnXOLhwm4dnF3nVY91SS4LXxk/ZNhdErPN5FJXLAM9aUhM= X-Google-Smtp-Source: APiQypIuzrB0co0MQp8py8o20AH+X28R4pWNpnA0RHSoLGofZ6j00J/ADx4Mx8kurDvYiu/dFnYvz37Wk6/+6Lh9lRQ= X-Received: by 2002:a19:f806:: with SMTP id a6mr3688430lff.201.1587676706755; Thu, 23 Apr 2020 14:18:26 -0700 (PDT) MIME-Version: 1.0 References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com> <1e6201d6-a078-4137-898d-d1554c22aa10@www.fastmail.com> In-Reply-To: <1e6201d6-a078-4137-898d-d1554c22aa10@www.fastmail.com> From: Eric Rescorla Date: Thu, 23 Apr 2020 14:17:50 -0700 Message-ID: To: Martin Thomson Cc: Hanno Becker , "" Content-Type: multipart/alternative; boundary="0000000000001fea0905a3fbca3a" Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Thu, 23 Apr 2020 21:18:38 -0000 --0000000000001fea0905a3fbca3a Content-Type: text/plain; charset="UTF-8" On Thu, Apr 23, 2020 at 12:40 AM Martin Thomson wrote: > On Thu, Apr 23, 2020, at 11:49, Eric Rescorla wrote: > > OK but we would expect the peer to process CID-less records if they are > > coalesced? > > I guess so. If we allowed them to drop them, then we're close to saying > MUST NOT omit. > Yeah, I would make three points 1. Allowing implicit CIDs is very recent (it was introduced in -34) 2. The CID specification explicitly prohibits it for DTLS 1.2. 3. I haven't really heard a very compelling argument for this and I note that QUIC forbids it [and in fact has much worse problems when you mix epochs because the long header is so long] So, given that the simplest and most consistent thing is to simply forbid it: can someone make an argument for why this is important to permit? -Ekr > On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote: > > > But Hanno's proposal is a terrible thing to have to implement. You > > have to assume that there is some way to recover which CID to use in > > decrypting any record. You might save some datagram-local state, but > > that's awkward. Stacks that I've worked on try very hard not to have > > state transmission between records for good reasons. So this would be a > > fairly bad complication. Separately, I hope that no one would be > > contemplating trial decryption for this, which would be terrible. > > > > Yes that's a fair point and also applies to Ekr's proposal > > https://github.com/tlswg/dtls13-spec/pull/143. > > I don't see how. If you are talking about marshaling costs, that's a > constant problem, but we haven't found that to be an issue in practice. > From my perspective, it's the old DTLS records with a pseudo-header that > are hard to construct; the new format is far easier to construct for > sending (assuming that you don't try to shave the sequence number length > down dynamically, but that's a new option our stack doesn't try to use). > > Yours is a sending-side concern, and that seems to be subjective, because > I think that sending is easier without a pseudo-header. My concerns were > about receiving. > > > The CID maintenance for incoming records can be avoided when forbidding > > CID elision, as suggested by Ekr. > > Comparing the state maintenance complications this avoids to the > > increase in header size it introduces, maybe > > that's the way to go, as the state maintenance indeed seems to be the > > bigger pain. > > However, even if CID elision is removed, I maintain the proposal to > > always use the logical presentation of the header > > for AAD, for all the mentioned reasons: (a) No interleaving of record > > and datagram layer, (b) conceptual clarity and > > independence of [header] compression methods from cryptographic > > computations, as e.g. in cTLS, (c) dynamic > > choice of header depending on network paths. All those issues persist > > when sticking to the on-the-wire AAD. > > What are your reservations towards this? > > I'm sorry, I don't follow your argument. > > The authenticated logical header being different than what is sent on the > wire is a bug in my opinion. Authenticating all the bytes you send makes > the protocol simpler and less error prone. > --0000000000001fea0905a3fbca3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 23, 2020 at 12:40 AM Mart= in Thomson <mt@lowentropy.net&g= t; wrote:
On Thu= , Apr 23, 2020, at 11:49, Eric Rescorla wrote:
> OK but we would expect the peer to process CID-less records if they ar= e
> coalesced?

I guess so.=C2=A0 If we allowed them to drop them, then we're close to = saying MUST NOT omit.

Yeah, I would mak= e three points

1. Allowing implicit CIDs is ve= ry recent (it was introduced in -34)
2. The CID specificatio= n explicitly prohibits it for DTLS 1.2.
3. I haven't really h= eard a very compelling argument for this and I note that QUIC forbids it [a= nd in fact has much worse problems when you mix epochs because the long hea= der is so long]

So, given that the simplest an= d most consistent thing is to simply forbid it: can someone make an argumen= t for why this is important to permit?

-Ekr


On Thu, Apr 23, 2020, at 16:43, Hanno Becker wrote:
>=C2=A0 > But Hanno's proposal is a terrible thing to have to imp= lement. You
> have to assume that there is some way to recover which CID to use in <= br> > decrypting any record. You might save some datagram-local state, but <= br> > that's awkward. Stacks that I've worked on try very hard not t= o have
> state transmission between records for good reasons. So this would be = a
> fairly bad complication. Separately, I hope that no one would be
> contemplating trial decryption for this, which would be terrible.
>
> Yes that's a fair point and also applies to Ekr's proposal > https://github.com/tlswg/dtls13-spec/pull/143.=

I don't see how.=C2=A0 If you are talking about marshaling costs, that&= #39;s a constant problem, but we haven't found that to be an issue in p= ractice.=C2=A0 From my perspective, it's the old DTLS records with a ps= eudo-header that are hard to construct; the new format is far easier to con= struct for sending (assuming that you don't try to shave the sequence n= umber length down dynamically, but that's a new option our stack doesn&= #39;t try to use).

Yours is a sending-side concern, and that seems to be subjective, because I= think that sending is easier without a pseudo-header.=C2=A0 My concerns we= re about receiving.

> The CID maintenance for incoming records can be avoided when forbiddin= g
> CID elision, as suggested by Ekr.
> Comparing the state maintenance complications this avoids to the
> increase in header size it introduces, maybe
> that's the way to go, as the state maintenance indeed seems to be = the
> bigger pain.
> However, even if CID elision is removed, I maintain the proposal to > always use the logical presentation of the header
> for AAD, for all the mentioned reasons: (a) No interleaving of record =
> and datagram layer, (b) conceptual clarity and
> independence of [header] compression methods from cryptographic
> computations, as e.g. in cTLS, (c) dynamic
> choice of header depending on network paths. All those issues persist =
> when sticking to the on-the-wire AAD.
> What are your reservations towards this?

I'm sorry, I don't follow your argument.

The authenticated logical header being different than what is sent on the w= ire is a bug in my opinion.=C2=A0 Authenticating all the bytes you send mak= es the protocol simpler and less error prone.
--0000000000001fea0905a3fbca3a-- From nobody Thu Apr 23 14:23:11 2020 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 D0E383A13F2 for ; Thu, 23 Apr 2020 14:23:09 -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=RF21Qr5p; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=RF21Qr5p 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 oC_SQ-PH74UT for ; Thu, 23 Apr 2020 14:23:06 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2075.outbound.protection.outlook.com [40.107.22.75]) (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 3200C3A13F1 for ; Thu, 23 Apr 2020 14:23:05 -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=rr2oV/uxmDIMjOP/QGzWFfp8g/6yRIzsAZmvgSwbyKw=; b=RF21Qr5pMXmH9E9ERQePPH6z4eop7K3vzMfk/FINp/BapK5h361CMVgP6XoS3Eyfja0vRsBDaJeyZd9uM7b097Xe0aEdyF1IiRzJx58dvXpS5ijWG+rsggKGRayvtYKj/kkAY0ExHh0Y9DTO9MJwfc864tAqTLUQKd3JGAjLmLQ= Received: from AM6P194CA0071.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:84::48) by DBBPR08MB4555.eurprd08.prod.outlook.com (2603:10a6:10:cb::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Thu, 23 Apr 2020 21:23:03 +0000 Received: from AM5EUR03FT046.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:84:cafe::c1) by AM6P194CA0071.outlook.office365.com (2603:10a6:209:84::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Thu, 23 Apr 2020 21:23:03 +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 AM5EUR03FT046.mail.protection.outlook.com (10.152.16.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Thu, 23 Apr 2020 21:23:03 +0000 Received: ("Tessian outbound 43fc5cd677c4:v53"); Thu, 23 Apr 2020 21:23:02 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 48dff7dba696f958 X-CR-MTA-TID: 64aa7808 Received: from 4c30b2f6b037.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 349A3207-0189-472C-84FF-C038C3CBF465.1; Thu, 23 Apr 2020 21:22:57 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 4c30b2f6b037.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 23 Apr 2020 21:22:57 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kVUKJ0MMPDew58uZitp0omF3x4+IVXs7NIaca7YkqNpbPBXVWDbzJRSuEMv7AzrNdV8D0++r5/QtX/Hm8ex8cECuQDvTBLQ43JRgK151/X0BljrIwmBhmF2Eyw8DHe7gY1+wu/P0vMYv8YJ4O9qj+b9GLmE3dV2ZUvlV6HR+qvveLXuajWMzKmvVLAvKQRnkT28JKZT3OSWPTDINSEYWfO922pg5oAn/oEvjLNbNf7dtVtOdwd14tcNS2Xsv/kj7kLxX4Sa6OOxUelVOCVV5o6qEQT9K1XdNgGl+SlALf81kKuz2SD3qHHrrUB/ah8lG+GDMk93U/O7xYTBnH/7wSw== 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=rr2oV/uxmDIMjOP/QGzWFfp8g/6yRIzsAZmvgSwbyKw=; b=jQ6PwUgFw3l5/LCOXyO7neh5LsIdrsZpRALkp0FyK51U+2kKdQtyqzEJWVeLzuPcVZR25mNPs7s6VlASTDC5TVCsF8RoD4J96E65KTmRu/AU2F3ZiIsngL0sUS3ixOXr96V1hCvhO6OdDnn1W/0ARwx4EEGcDkpHCf4IsmBXGZ+vMFKZOyB+RZa2vbbvwAlF1qkJRge+4+mSsUquFuqHcD7CsG0EEMelhYBcgCeNtDFOoP8XB34WrlyL4CFnziRkffp1Vime/htxVX2HB7dHZGJ02DME9WkdUVwKcVmMEQM5cfP8ayv1M5CHi2VzI+5tOWmfXiL9K2rDjAB2+/x57Q== 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=rr2oV/uxmDIMjOP/QGzWFfp8g/6yRIzsAZmvgSwbyKw=; b=RF21Qr5pMXmH9E9ERQePPH6z4eop7K3vzMfk/FINp/BapK5h361CMVgP6XoS3Eyfja0vRsBDaJeyZd9uM7b097Xe0aEdyF1IiRzJx58dvXpS5ijWG+rsggKGRayvtYKj/kkAY0ExHh0Y9DTO9MJwfc864tAqTLUQKd3JGAjLmLQ= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6PR08MB3685.eurprd08.prod.outlook.com (2603:10a6:20b:6f::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Thu, 23 Apr 2020 21:22:56 +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.2937.012; Thu, 23 Apr 2020 21:22:56 +0000 From: Hanno Becker To: Eric Rescorla , "" Thread-Topic: [TLS] Implicit ACKs in post-handshake Thread-Index: AQHWGbC15u+KRnP0Uk2OoxM6jRtSIaiHNaG6 Date: Thu, 23 Apr 2020 21:22:55 +0000 Message-ID: References: In-Reply-To: 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: 12d370a5-07fe-43df-2910-08d7e7cc81a7 x-ms-traffictypediagnostic: AM6PR08MB3685:|DBBPR08MB4555: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 03827AF76E 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)(396003)(366004)(346002)(136003)(376002)(39860400002)(81156014)(66946007)(86362001)(110136005)(316002)(2906002)(8936002)(53546011)(478600001)(52536014)(7696005)(8676002)(66476007)(64756008)(71200400001)(6506007)(19627405001)(55016002)(66446008)(66556008)(76116006)(33656002)(5660300002)(186003)(26005)(9686003)(491001); 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: nqbuVLofi8x/Z6aYSTwlBE13nRVJcZYgCA1T5SMDrAIJTYI4Kn6YjwZgh3AObwSuKkdY5F02xngkA0E2I59NR73W58+GzyVVWcHoz8zUCacHsxBBR6+mShCY+pCX91Vayr3tI8yPvx5TRYBFKv3qsbVwOrvDnR6vBeLtrozoX7mw4YCMaZPFzOtnlqPDAPVVjCizPZ2fmQUd9YvHYlRdH3+NVHOax51ipsuPZA7vpg68Eye8GbYkGYgJSxZiYp7u3SGqGNouioS8wRlMATONcEYkefkP7bGXNgEKNcXQ89ihgTRfiDChisGXDNidcPX8/fDzMfh/WuPiLYrOnQk8pg6c08VCuN0hweQSA1yZ2UT01UCeKEEPcX/XaRDGk/0ha+OFCUeMSm1HPFDE2NNE9LKeH7bF0pgoPKkuvFDmB+RSRbHWEuCMCWWC/fmR1sTzUpJKkBH1MX3itW1KCo9tDqMz4Urr3XLgo+VaOhikTvI= x-ms-exchange-antispam-messagedata: l3mM2Z7fQTDMi5hsxBpARs4ueRlvE+98C/tJ8gBmJd66hXwR9vd6PFr0WfIaYPVrLp70QYLJx2faqqVVlYgB7bgoTwF96j7ItjLch3WJh/ZZMSDGLAKcebfBe9eL4LtCB0hVNT0WSPIc+M0FC90Oxw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB331828BC62552C177CEE4D369BD30AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3685 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT046.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)(346002)(39860400002)(136003)(396003)(376002)(46966005)(9686003)(26005)(356005)(186003)(8936002)(55016002)(33656002)(82310400002)(8676002)(5660300002)(81156014)(82740400003)(36906005)(110136005)(478600001)(81166007)(336012)(7696005)(316002)(19627405001)(53546011)(70586007)(86362001)(70206006)(47076004)(52536014)(6506007)(2906002)(491001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 2c05363c-3997-4ee3-2fb8-08d7e7cc7d7a X-Forefront-PRVS: 03827AF76E X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YcE6VSEPvU68BtTHcexEvwQgbiGnionEYL9hS3wDuQ7tJElR26cDWJzCwinOc6JbpqpxfiY5pRNcu5N3QX/0g9qkH63ZWt91FjMMNJqhWujEbGwF/G2L9ah8jkI+StNrgNQc5XQR5umLDtgPb9jxYctd50272+2tYL+s/DsX98N6dzVxCqTWRa5SdfxLROG7uUaN39SnWpbuszgeVnQ5Kgs5mIytsL0GyKFyguD+ZzjjIgeMfZXi4AVxnGIHP5rnWdrkc4ynBhHPBcdN+A3EWSFyeJMzFm+WeI+hHDsQcc5QdN1w8Z/Mqo+FkmJZpIm2a0KLDBzTjJPS2WqApEUISLHdNAL5t9T4SzK5mk1GelIUJ960N6FxX29ybmKwjbWsoqf1GRGup2xldOcXp+yMfm9aGGyF1jQBrq8HTZKgk9oZUys87i53XICvrde80hIom0nQ8w8+Tq26xFcxm8mnnoErKne8QdJOK7c3CkIo8HATh6JLhhSG5CguI4R0n5GxESpKq2AQSjZH3Z3IW4rhbO4AWdWj9lnHj63epR4Cti0= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2020 21:23:03.0025 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 12d370a5-07fe-43df-2910-08d7e7cc81a7 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: DBBPR08MB4555 Archived-At: Subject: Re: [TLS] Implicit ACKs in post-handshake 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: Thu, 23 Apr 2020 21:23:10 -0000 --_000_AM6PR08MB331828BC62552C177CEE4D369BD30AM6PR08MB3318eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ekr, Do you see some simplifications resulting from this? On first thought I'd think that since implementations are already able to h= andle implicit ACKs, it doesn't come at extra cost to allow their use for post-HS client-a= uth, too. In contrast, it seems that if the client's Certificate message no longer implicitly acknowledges the CertificateRequest, there's need to explicitly explain the state machine transition upon receipt of the Certificate messag= e prior to receiving an ACK for the CertificateRequest. Overall I feel that there is no need for change here, but I might miss some= thing. Best, Hanno ________________________________ From: TLS on behalf of Eric Rescorla Sent: Thursday, April 23, 2020 9:48 PM To: Subject: [TLS] Implicit ACKs in post-handshake Hi folks, As I was going through the ACK clarifications, I noticed that we were requiring explicit ACKs for everything other than post-handshake client auth, where we allow implicit ACK. This obviously works, but given that (1) we expect explicit ACK from the client if there is a user-consent delay and (2) it's the only one, what would people think of using implicit ACKs only for the handshake itself. -Ekr 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_AM6PR08MB331828BC62552C177CEE4D369BD30AM6PR08MB3318eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Ekr,

Do you see some simplifications resulting from this? 

On first thought I'd think = that since implementations are already able to handle implicit
ACKs, it doesn't come at extra cost to allow their use for post-HS client-auth, too.

In contrast, it seems that if the client's Certificate message no longer
implicitly acknowledges the CertificateRequest, there's need to explicitly<= /div>
explain the state machine transition up= on receipt of the Certificate message
prior to receiving an ACK for the Certificat= eRequest.

Overall I feel that there is no need for change here, but I might miss some= thing.

Best,
Hanno

From: TLS <tls-bounces@i= etf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
Sent: Thursday, April 23, 2020 9:48 PM
To: <tls@ietf.org> <tls@ietf.org>
Subject: [TLS] Implicit ACKs in post-handshake
 
Hi folks,

As I was going through the ACK clarifications, I noticed that we were
requiring explicit ACKs for everything other than post-handshake
client auth, where we allow implicit ACK. This obviously works,
but given that (1) we expect explicit ACK from the client if there
is a user-consent delay and (2) it's the only one, what would people
think of using implicit ACKs only for the handshake itself.

-Ekr


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_AM6PR08MB331828BC62552C177CEE4D369BD30AM6PR08MB3318eurp_-- From nobody Thu Apr 23 14:26:37 2020 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 DAF083A1405 for ; Thu, 23 Apr 2020 14:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 NzFXV4VxaTgK for ; Thu, 23 Apr 2020 14:26:26 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 041683A13F5 for ; Thu, 23 Apr 2020 14:26:26 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id b2so7783843ljp.4 for ; Thu, 23 Apr 2020 14:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i+dYmDCVkmUuJ3s5EDAnuiWofHMMKb0g6VflP0K0BzA=; b=akGYmeHagXof2dISIWSlD+SMNdYe5xOSMc/et9BFeAYBhaO897pWjMnJsLP823QcTl BOZ4tVhVK6Mgk/ShjjYSoDPHpZu7n/mr92JJyDbIRI14CzLTXK4BTm2W4RV0AFeakfNw xAQ8chaWc5dEaVlIR6XCX2bGlgwPGqwEPUxr4BpzFaum+kB7Zgw2gRwwOUPBwY1602Rx XS2xzULR4ZGjWv65ZQteoYbKqTgZnEvz9hNRndWZgk57Ts9hIaGVGlWeSklnSw4El8uo 38kGurN03c86gaCLpt/YuGN2WbVnILwYh8iSiHsi3ElnT1AK/N2TCttENtggmy7y6smf Pq6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i+dYmDCVkmUuJ3s5EDAnuiWofHMMKb0g6VflP0K0BzA=; b=SiGpwxXoLo+aiLdoW4bEChZCc/RX8HPvFRt7n7iSxiAn9MeYaPljCYpAIaM43tiS1l GHghJgd69ghG5/ApYg3O+Drrh0Sc5PZr710wwlvtbsxXNJQGaCmfX/jhSOoWwcyHSOi5 guScW+6mismGtrg1LqsGku8cFMWWyhYsQVvW5Z9Gq3nmQZ3fgxkI+1nm5frAK33mJa/I AYsGu1J9G+CRj+cdKKkil94LsUfwaeczaZw2drW9wKhRZ7fc1q4G03K5KdqRtw1qU4oZ 9fXWQt3BHZKOO3oi6pXGr8LL9MVY/4FCBiZ2t0VlrdsXVb317suOiEPoQ0+aUkKPc2Pv fbRg== X-Gm-Message-State: AGi0Puar6rmSiHkSM28yc8EourIfC78hNO3nMND9iHovErBpBjWowlhh F4Nh9mgDtMTySqJS3iXWULdPY9C4xvz80RzoSg0IOw== X-Google-Smtp-Source: APiQypLO+xttkruTqDexP3SRzziRHgQOpeKj+Lfe4hg0WLR37yiBjI47xR6id3eRnJhOqW25ZZ9RfU3JX0lGIV3Coqw= X-Received: by 2002:a2e:b0ee:: with SMTP id h14mr3748293ljl.35.1587677184257; Thu, 23 Apr 2020 14:26:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Thu, 23 Apr 2020 14:25:48 -0700 Message-ID: To: Hanno Becker Cc: "" Content-Type: multipart/alternative; boundary="00000000000096029a05a3fbe63e" Archived-At: Subject: Re: [TLS] Implicit ACKs in post-handshake 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: Thu, 23 Apr 2020 21:26:30 -0000 --00000000000096029a05a3fbe63e Content-Type: text/plain; charset="UTF-8" I don't feel strongly about it, and not changing anything is certainly easier. It just felt out of place and I wanted to flag it. -Ekr On Thu, Apr 23, 2020 at 2:23 PM Hanno Becker wrote: > Hi Ekr, > > Do you see some simplifications resulting from this? > > On first thought I'd think that since implementations are already able to > handle implicit > ACKs, it doesn't come at extra cost to allow their use for post-HS > client-auth, too. > > In contrast, it seems that if the client's Certificate message no longer > implicitly acknowledges the CertificateRequest, there's need to explicitly > explain the state machine transition upon receipt of the Certificate > message > prior to receiving an ACK for the CertificateRequest. > > Overall I feel that there is no need for change here, but I might miss > something. > > Best, > Hanno > > ------------------------------ > *From:* TLS on behalf of Eric Rescorla < > ekr@rtfm.com> > *Sent:* Thursday, April 23, 2020 9:48 PM > *To:* > *Subject:* [TLS] Implicit ACKs in post-handshake > > Hi folks, > > As I was going through the ACK clarifications, I noticed that we were > requiring explicit ACKs for everything other than post-handshake > client auth, where we allow implicit ACK. This obviously works, > but given that (1) we expect explicit ACK from the client if there > is a user-consent delay and (2) it's the only one, what would people > think of using implicit ACKs only for the handshake itself. > > -Ekr > > > 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. > --00000000000096029a05a3fbe63e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't feel strongly about it, and not changing = anything is certainly easier. It just felt out of place and I wanted to fla= g it.

-Ekr


=
On Thu= , Apr 23, 2020 at 2:23 PM Hanno Becker <Hanno.Becker@arm.com> wrote:
Hi Ekr,

Do you see some simplifications resulting from this?=C2=A0

On first thought=C2=A0I'd think=C2=A0that since implementations are already able to handle implicit
ACKs, it doesn't come at extra cost to allow their=C2=A0use for post-HS client-auth, too.

In contrast, it seems that if the client's Certificate message no longe= r
implicitly acknowledges the CertificateRequest, there's need to explici= tly
explain the state machine=C2=A0transition upon receipt = of the Certificate message
prior to receiving an ACK for the CertificateRequest.

Overall I feel that there is no need for change here, but I might miss some= thing.

Best,
Hanno

Fro= m: TLS <tl= s-bounces@ietf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
Sent: Thursday, April 23, 2020 9:48 PM
To: <tls@ietf.o= rg> <tls@ietf.o= rg>
Subject: [TLS] Implicit ACKs in post-handshake
=C2=A0
Hi folks,

As I was going through the ACK clarifications, I noticed that we were
requiring explicit ACKs for everything other than post-handshake
client auth, where we allow implicit ACK. This obviously works,
but given that (1) we expect explicit ACK from the client if there
is a user-consent delay and (2) it's the only one, what would people think of using implicit ACKs only for the handshake itself.

-Ekr


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.
--00000000000096029a05a3fbe63e-- From nobody Thu Apr 23 16:30:50 2020 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 CA35E3A09E1 for ; Thu, 23 Apr 2020 16:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=e6JVWw9F; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=q4wxiWkv 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 L9seYgk8qsH0 for ; Thu, 23 Apr 2020 16:30:47 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536EC3A09DB for ; Thu, 23 Apr 2020 16:30:47 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 75FFD4DA for ; Thu, 23 Apr 2020 19:30:46 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute1.internal (MEProxy); Thu, 23 Apr 2020 19:30:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=KRe2aki7L85HnviSTbrdySycyS2bvx7Pk3/lppfBTXM=; b=e6JVWw9F 1UDlIf/L64G3AVMEHOy2yP1Ow2RyTyY7jSKAOdJwmTNwF8kY6e9Pm9HNWX7WHiwe HDHQZuW5MImK9p4Oil5WJI7h2P/ysoWBjlulE+E0kcYV/X9oKNG93EhlbSkDiXVb zSeidctlEBTMJG5TxDtgnEycgxSIGSqEje7mb8ALlxobMhcdT7YdGIwMGtcKK8Eu PPYVJYzsnDg/kLFuD7973jKhtLa2LmYWFtMG7YYqtu8Je+2FdiP+o23XTyTGrBk8 WjwjXlvqBusesTqkmswThoEawd3PucpBcheXWTgExsd/MGv9+O9id3RnMK8p1hcp 14Pf0fW9FLxOnQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=KRe2aki7L85HnviSTbrdySycyS2bv x7Pk3/lppfBTXM=; b=q4wxiWkv1nQSN4sG43S/xXDBdoxMHSPsCl379Y8xv+9nn WCB9ydlSgQNPWwJ2eiY4WNVTcLXNnlTyrDabGy+cQw0FL4Kez18Hw+rjabgo/Q9o O2d0mCODD7Na3dKHKCNFRiEV9oLH0Z+BX3PCV8PzRs1c5wTxH1f67+4pgDD2u8+r QJtfZpWzFXERKtdmV7rV1fml6B3p87kZab+MqFasm//pVx2xDzMPYxtMrF/tleOi PzLhQaq/UZ0w2F7nCb6bxZNRQ5zXsgTnGS1hL71wio5GvFaDLkafl8rVc5cEvOoK vSgTKUxZChngy8SimfeZ0k0btjbIJOTD3JO/YpZ7g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrhedtgddvtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfieshhgv rghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomhenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehh vggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9E858180091; Thu, 23 Apr 2020 19:30:45 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <786abd25-5fc7-46f4-90c4-511a648d0450@www.fastmail.com> Date: Thu, 23 Apr 2020 16:30:25 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: [TLS] ECHO padding review and some open issues 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: Thu, 23 Apr 2020 23:30:49 -0000 In preparation for next week's virtual interim session on ECHO, I'd like to draw your attention to the following issues and PRs we'll be discussing. First, there's a PR up for padding [https://github.com/tlswg/draft-ietf-tls-esni/pull/209]. This PR describes a padding algorithm for clients that roughly works as follows. Clients compute the amount of ClientHelloInner padding based on padding for each inner CH extension. Some extensions might take server hints as input to this computation. In our case, we only have one such extension and hint: the SNI and ECHOConfig.max_name_len. Once done, round the total padding to the nearest 32B value. It also suggests that other handshake messages should be padded, yet elides details. (We previously didn't specify padding for anything beyond the CH message, so this isn't a change.) Is this PR ready to go? If not, why not? What would you change, and why? (Concrete suggestions are highly encouraged!) Note also that this is currently only a recommended padding algorithm. Implementations are therefore free to do what they wish. Is this acceptable? Do we need to be more prescriptive? Food for thought! After that PR, there's a pile of issues that need attention and discussion. Please have a look at the list below and comment on whether you think they're worth addressing. - ECHOConfigContents.extensions [https://github.com/tlswg/draft-ietf-tls-esni/issues/217] - ECHOConfig vs HTTPSSVC [https://github.com/tlswg/draft-ietf-tls-esni/issues/219, https://github.com/tlswg/draft-ietf-tls-esni/issues/216] - GREASE indistinguishability [https://github.com/tlswg/draft-ietf-tls-esni/issues/177] - HPKE code points [https://github.com/tlswg/draft-ietf-tls-esni/issues/218] - Tunnel TLS 1.2 and below [https://github.com/tlswg/draft-ietf-tls-esni/issues/214] These are the last major outstanding issues against the document. I hope we can move forward after we resolve them, one way or another. Thanks, Chris (no hat) From nobody Thu Apr 23 16:38:08 2020 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 A79413A0A40 for ; Thu, 23 Apr 2020 16:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=cs.tcd.ie 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 lyBlH52MAo9Y for ; Thu, 23 Apr 2020 16:38:03 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4C03A0A3F for ; Thu, 23 Apr 2020 16:38:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AB026BE2E; Fri, 24 Apr 2020 00:38:00 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSndH8k9oNWb; Fri, 24 Apr 2020 00:37:58 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 705B2BE2C; Fri, 24 Apr 2020 00:37:58 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1587685078; bh=y0gQRgBnx4hP1e0GdQ5Wi8jPCKgnhc5Z4taOcnduSNY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=CqNHokqgwnHJNg42ViuLVkpTZGL5ieWnXQwpagYCQqnWRRnUAyccqi+QmcLQUPuka Z5psvbL2Ze6F9IiEtbX0SF0W4XyWt3MclXcgl1cxY5lrAUTR/QPOZ4HTD9WXw3Xquf frUtM5V1zfMEY7+Oxe1eA3/zoPTGoQfv+w+nyRAM= To: Christopher Wood , "TLS@ietf.org" References: <786abd25-5fc7-46f4-90c4-511a648d0450@www.fastmail.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <54d8ea7b-ca79-55f4-281e-aedca296c649@cs.tcd.ie> Date: Fri, 24 Apr 2020 00:37:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <786abd25-5fc7-46f4-90c4-511a648d0450@www.fastmail.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="KxcDjyMAdTRGJXBDq34fkjVDjbd5qhB0d" Archived-At: Subject: Re: [TLS] ECHO padding review and some open issues 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: Thu, 23 Apr 2020 23:38:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --KxcDjyMAdTRGJXBDq34fkjVDjbd5qhB0d Content-Type: multipart/mixed; boundary="ikVxsU0HwegvE0uX28gHtNt3GjyXlFst6"; protected-headers="v1" From: Stephen Farrell To: Christopher Wood , "TLS@ietf.org" Message-ID: <54d8ea7b-ca79-55f4-281e-aedca296c649@cs.tcd.ie> Subject: Re: [TLS] ECHO padding review and some open issues References: <786abd25-5fc7-46f4-90c4-511a648d0450@www.fastmail.com> In-Reply-To: <786abd25-5fc7-46f4-90c4-511a648d0450@www.fastmail.com> --ikVxsU0HwegvE0uX28gHtNt3GjyXlFst6 Content-Type: multipart/mixed; boundary="------------BE88542B0E16D13513C2202B" Content-Language: en-US This is a multi-part message in MIME format. --------------BE88542B0E16D13513C2202B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sorry - I have one more I wanted to raise as an issue. Will do that tomorrow and send a mail, Cheers, S. On 24/04/2020 00:30, Christopher Wood wrote: > In preparation for next week's virtual interim session on ECHO, I'd lik= e to draw your attention to the following issues and PRs we'll be discuss= ing.=20 >=20 > First, there's a PR up for padding [https://github.com/tlswg/draft-ietf= -tls-esni/pull/209]. This PR describes a padding algorithm for clients th= at roughly works as follows. Clients compute the amount of ClientHelloInn= er padding based on padding for each inner CH extension. Some extensions = might take server hints as input to this computation. In our case, we onl= y have one such extension and hint: the SNI and ECHOConfig.max_name_len. = Once done, round the total padding to the nearest 32B value. It also sugg= ests that other handshake messages should be padded, yet elides details. = (We previously didn't specify padding for anything beyond the CH message,= so this isn't a change.) >=20 > Is this PR ready to go? If not, why not? What would you change, and why= ? (Concrete suggestions are highly encouraged!) Note also that this is cu= rrently only a recommended padding algorithm. Implementations are therefo= re free to do what they wish. Is this acceptable? Do we need to be more p= rescriptive? Food for thought! >=20 > After that PR, there's a pile of issues that need attention and discuss= ion. Please have a look at the list below and comment on whether you thin= k they're worth addressing.=20 >=20 > - ECHOConfigContents.extensions [https://github.com/tlswg/draft-ietf-tl= s-esni/issues/217] > - ECHOConfig vs HTTPSSVC [https://github.com/tlswg/draft-ietf-tls-esni/= issues/219, https://github.com/tlswg/draft-ietf-tls-esni/issues/216] > - GREASE indistinguishability [https://github.com/tlswg/draft-ietf-tls-= esni/issues/177] > - HPKE code points [https://github.com/tlswg/draft-ietf-tls-esni/issues= /218] > - Tunnel TLS 1.2 and below [https://github.com/tlswg/draft-ietf-tls-esn= i/issues/214] >=20 > These are the last major outstanding issues against the document. I hop= e we can move forward after we resolve them, one way or another. >=20 > Thanks, > Chris (no hat) >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------BE88542B0E16D13513C2202B Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------BE88542B0E16D13513C2202B-- --ikVxsU0HwegvE0uX28gHtNt3GjyXlFst6-- --KxcDjyMAdTRGJXBDq34fkjVDjbd5qhB0d Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6iJtUACgkQWrL68XsX K+qfPQ/+JymzLupptwWECC4SsDL6ztAqyo/L+VmUdVWM4ehcAHgcxwxbvyWr6t3X e6FFyQriu0KbrGvohlkWqB9a96+GBMd9l34y995EqwffiDXwc0yaaR2+VSZSfSwa fp6sbGa45AzYz4TmN/f7A3wVuAva4RTloCO/oNeGMl+fwVVad9NYupjqJc5lYIZP u9czEC/JoxEfi3LLB5FrNZWlH99jTZUh5mlfwX2khNqxu2OI7z1cikxXIkT4GX5Q 9Jn4hHCrNJTJNkuV3v/qc3vGEvdjp4OEq2SaG/T7u+bg16mFjJYICacO+pLv4StA nE2GlydGLK/RrneTnp+Kldiwo6DsFaUya4r/jvUo/0GC9domxx2jdR6iVS/ubSVU acchxyLsWppXyQlUWx3focXiT2ErHrReF0zuPebl61Ykjn4cvwrCuHtvCVxAqBQx HMXDnT0tS3N+heNjzpGJEUuiWO8OTNfDjIS6cI5vY7TzYbuYbb2ilklutu7HgVf1 YwwnIVhdWIWJX0GNp0089Y3x0QCLEiT5M4bqcsgcjyWA+xBpocYxoG7RThFIFEwa LpvQSZQLLoqW/8BNBVrMWDytRl0zuSehjoGcRNHIpWpH4g/rPi8pVU1fvTp6fWe2 vcGzl8zWscm/Th6/ty/QpyDbplqMx3Ni2dY9eEhD4h//Iu0Y9Lk= =PbGq -----END PGP SIGNATURE----- --KxcDjyMAdTRGJXBDq34fkjVDjbd5qhB0d-- From nobody Thu Apr 23 16:58:20 2020 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 BD2C33A0AA8 for ; Thu, 23 Apr 2020 16:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=FIko5nEq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VL1f7Hzj 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 mqZxl-hIezjJ for ; Thu, 23 Apr 2020 16:58:16 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737CE3A0A98 for ; Thu, 23 Apr 2020 16:57:59 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id E5E374B1 for ; Thu, 23 Apr 2020 19:57:57 -0400 (EDT) Received: from imap7 ([10.202.2.57]) by compute2.internal (MEProxy); Thu, 23 Apr 2020 19:57:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=8ATzOMyO/Q0XmKsUCXfRiiSBzZWXoud g31FMtLzp/VI=; b=FIko5nEqGy5D0/kKABAUFyq19tDJzZKCykhGI77TouFm/g5 THVvl4ojYFM562if9QHPEZfBpBwOc0jbbRcMQVUj4JBRYmxKAlPjtxkVp8+7qQ2S +YAQCA2lJ36h1APiC9e7PanrHrCPemNQoD0Cg47oaKBNqZN+TnRDpIiryaSWrtPc r8Ic3tJV+eQobqRabb05qdO3TogOrKqt0TjEcxD7Vjgnaj7E69hVKDXAEhHeqmiy uy0b+LeEMRVuKuz7SvJ3V/RzhtZpsR3A9pwmD78TqTqFTRAXnkUPSwjyR6AKYJfJ t1+BGtfS07Z/PhYNFBcVR3H0ltH8gN0FpFk8h0w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8ATzOM yO/Q0XmKsUCXfRiiSBzZWXoudg31FMtLzp/VI=; b=VL1f7HzjOOpUsK3xROtRN7 +f0SeD4Jdo1NVSriZ4dph/rxFmqolwUnJ0VnxfccdLMrLjpEO6ViRISHslJNkdz+ xPs14Y2p64VvdAGNyPRUwgl03svalFJDK+OYejPcgfM9x4OyCiXzeNFSi4qIaQfR 7+aWK76/l/gzls/6HBR+iU0nUxjswM+WHdq1XdWfRXAucjhtAUXDiAIldWgrXobN WcmvhmGCdIeE54ASNi875ttTq36VxVcSvhN8K9LH4/M+VIvuvrVUNDkGbhs6rlj2 KR7c7aTWjGHszUCmpED/hNGdY+g/EHbMlsYRL5KfTwBA+EBNd2pT7u/ilUd3TNSw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrhedtgddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhht rhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3601E180091; Thu, 23 Apr 2020 19:57:57 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <04c48f22-4475-42fc-bbc9-980523875319@www.fastmail.com> In-Reply-To: References: Date: Fri, 24 Apr 2020 09:57:36 +1000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] Implicit ACKs in post-handshake 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: Thu, 23 Apr 2020 23:58:18 -0000 What makes this case interesting is the non-machine time that might exist between receiving CertificateRequest and sending Certificate. In most of the exchanges, we expect there to be an answer that is immediately available, so that the implicit ACK works. Here we have to recognize that ACK might need to be sent anyway if the Certificate message is going to take time to source. If we don't have something already, it might pay to at least mention that if there are significant delays involved in preparing a response, an ACK SHOULD be sent rather than relying on implicit acknowledgment. On Fri, Apr 24, 2020, at 07:25, Eric Rescorla wrote: > I don't feel strongly about it, and not changing anything is certainly > easier. It just felt out of place and I wanted to flag it. > > -Ekr > > > > On Thu, Apr 23, 2020 at 2:23 PM Hanno Becker wrote: > > Hi Ekr, > > > > Do you see some simplifications resulting from this? > > > > On first thought I'd think that since implementations are already able to handle implicit > > ACKs, it doesn't come at extra cost to allow their use for post-HS client-auth, too. > > > > In contrast, it seems that if the client's Certificate message no longer > > implicitly acknowledges the CertificateRequest, there's need to explicitly > > explain the state machine transition upon receipt of the Certificate message > > prior to receiving an ACK for the CertificateRequest. > > > > Overall I feel that there is no need for change here, but I might miss something. > > > > Best, > > Hanno > > > > *From:* TLS on behalf of Eric Rescorla > > *Sent:* Thursday, April 23, 2020 9:48 PM > > *To:* > > *Subject:* [TLS] Implicit ACKs in post-handshake > > Hi folks, > > > > As I was going through the ACK clarifications, I noticed that we were > > requiring explicit ACKs for everything other than post-handshake > > client auth, where we allow implicit ACK. This obviously works, > > but given that (1) we expect explicit ACK from the client if there > > is a user-consent delay and (2) it's the only one, what would people > > think of using implicit ACKs only for the handshake itself. > > > > -Ekr > > > > > > 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 > From nobody Thu Apr 23 17:23:43 2020 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 501583A0A6A for ; Thu, 23 Apr 2020 17:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 kVfqs-PAdH5G for ; Thu, 23 Apr 2020 17:23:40 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2353A0B90 for ; Thu, 23 Apr 2020 17:23:38 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id a21so8146252ljb.9 for ; Thu, 23 Apr 2020 17:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=457wEjZpwbRUzwverDO5Rr3fZ+cl4OFVLWtFnSb5AX4=; b=rPvHQSYApZPJmR+SubL5+/xT188pWxZdoMcQRHNE1U/UoeOflZTn2/z8oowPNkkKI1 5QO0ho8o8B03U33eD4zjivs0VEcpg55NmINXagFj/UBMB96bkTa09WwPl2ElQrAPq5ik /Cl0+Blvqq6AzxMuCpMmX9Q2mFTdliR9vZVzi3ZFD2fMArAiLVXAb6r9nbhuVDqR0zXE rDOQz6LA2WoQhNxuMJIC4biLBhOdUCpJtrW8bSvBQi6froyXHJkcU59QYcI1O/h0Yh5+ SlmDMJOrr0mKSRCe+ymvDHouIs5M5R76B0NvG4yY0IyAb2LUSN4BaI8KF3aU1/+dMV59 JwvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=457wEjZpwbRUzwverDO5Rr3fZ+cl4OFVLWtFnSb5AX4=; b=eX6mh1LBr7BHT8XwdJCcs4zhr7zgSY7RcXn5Hve2pgWQdJSf+tx7GCiZ59G5590pGx 6Swy2iEHNaeFdivZjJijcr2qiI0hLGSuEzaaablazyNSm0FPfjaEoENWiyv5xeFYH/xH PQeT0p1y7aZMHPfRe59dGyvTRykmpF7mUN9MekuKBUyD221SdWV6WouVhGH0aVePiyEN XZWjR1VV7udOvLonbxvMjdQigm+Tt3vnKxZhoKIIl4PCE0Tyoq9FDZNzSjBPRLCOdqTi 8Ml85qd3AsCKWkH/9Hfr0fTNsniz77u09Q0kA+GcMc6nHaA32AJrM3smKxBFGin/NzL1 anYQ== X-Gm-Message-State: AGi0Puah7jeiYOEdC2AHgJjB+eqvTkLYf4/sJiY8sNJtK7+NTN+7oQnu ZJ4E3fXxWK+bEIZQuYfFMaUafqc8E5O6yjHRy36jWMGlAuU= X-Google-Smtp-Source: APiQypKuf4yEos6RW2AamaYNpI/Zp7thON6smkIs31rGH3n5R+lQsj40YC+dhJ0aRMitBBv0Acmb37o1Cis1TVaTdrA= X-Received: by 2002:a2e:2414:: with SMTP id k20mr3969946ljk.162.1587687816857; Thu, 23 Apr 2020 17:23:36 -0700 (PDT) MIME-Version: 1.0 References: <04c48f22-4475-42fc-bbc9-980523875319@www.fastmail.com> In-Reply-To: <04c48f22-4475-42fc-bbc9-980523875319@www.fastmail.com> From: Eric Rescorla Date: Thu, 23 Apr 2020 17:23:00 -0700 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/alternative; boundary="000000000000569bb805a3fe6048" Archived-At: Subject: Re: [TLS] Implicit ACKs in post-handshake 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, 24 Apr 2020 00:23:42 -0000 --000000000000569bb805a3fe6048 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 23, 2020 at 4:58 PM Martin Thomson wrote: > What makes this case interesting is the non-machine time that might exist > between receiving CertificateRequest and sending Certificate. > > In most of the exchanges, we expect there to be an answer that is > immediately available, so that the implicit ACK works. Here we have to > recognize that ACK might need to be sent anyway if the Certificate message > is going to take time to source. > > If we don't have something already, it might pay to at least mention that > if there are significant delays involved in preparing a response, an ACK > SHOULD be sent rather than relying on implicit acknowledgment. > That text is already there, thanks to Hanno. -Ekr > On Fri, Apr 24, 2020, at 07:25, Eric Rescorla wrote: > > I don't feel strongly about it, and not changing anything is certainly > > easier. It just felt out of place and I wanted to flag it. > > > > -Ekr > > > > > > > > On Thu, Apr 23, 2020 at 2:23 PM Hanno Becker > wrote: > > > Hi Ekr, > > > > > > Do you see some simplifications resulting from this? > > > > > > On first thought I'd think that since implementations are already > able to handle implicit > > > ACKs, it doesn't come at extra cost to allow their use for post-HS > client-auth, too. > > > > > > In contrast, it seems that if the client's Certificate message no > longer > > > implicitly acknowledges the CertificateRequest, there's need to > explicitly > > > explain the state machine transition upon receipt of the Certificate > message > > > prior to receiving an ACK for the CertificateRequest. > > > > > > Overall I feel that there is no need for change here, but I might > miss something. > > > > > > Best, > > > Hanno > > > > > > *From:* TLS on behalf of Eric Rescorla < > ekr@rtfm.com> > > > *Sent:* Thursday, April 23, 2020 9:48 PM > > > *To:* > > > *Subject:* [TLS] Implicit ACKs in post-handshake > > > Hi folks, > > > > > > As I was going through the ACK clarifications, I noticed that we were > > > requiring explicit ACKs for everything other than post-handshake > > > client auth, where we allow implicit ACK. This obviously works, > > > but given that (1) we expect explicit ACK from the client if there > > > is a user-consent delay and (2) it's the only one, what would people > > > think of using implicit ACKs only for the handshake itself. > > > > > > -Ekr > > > > > > > > > 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 > --000000000000569bb805a3fe6048 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 23, 2020 at 4:58 PM Marti= n Thomson <mt@lowentropy.net>= ; wrote:
What ma= kes this case interesting is the non-machine time that might exist between = receiving CertificateRequest and sending Certificate.

In most of the exchanges, we expect there to be an answer that is immediate= ly available, so that the implicit ACK works.=C2=A0 Here we have to recogni= ze that ACK might need to be sent anyway if the Certificate message is goin= g to take time to source.

If we don't have something already, it might pay to at least mention th= at if there are significant delays involved in preparing a response, an ACK= SHOULD be sent rather than relying on implicit acknowledgment.

That text is already there, thanks to Hanno.

-Ekr


On Fri, Apr 24, 2020, at 07:25, Eric Rescorla wrote:
> I don't feel strongly about it, and not changing anything is certa= inly
> easier. It just felt out of place and I wanted to flag it.
>
> -Ekr
>
>
>
> On Thu, Apr 23, 2020 at 2:23 PM Hanno Becker <Hanno.Becker@arm.com> wrote: > >=C2=A0 Hi Ekr,
> >
> >=C2=A0 Do you see some simplifications resulting from this?
> >
> >=C2=A0 On first thought I'd think that since implementations a= re already able to handle implicit
> >=C2=A0 ACKs, it doesn't come at extra cost to allow their use = for post-HS client-auth, too.
> >
> >=C2=A0 In contrast, it seems that if the client's Certificate = message no longer
> >=C2=A0 implicitly acknowledges the CertificateRequest, there's= need to explicitly
> >=C2=A0 explain the state machine transition upon receipt of the Ce= rtificate message
> > prior to receiving an ACK for the CertificateRequest.
> >
> >=C2=A0 Overall I feel that there is no need for change here, but I= might miss something.
> >
> >=C2=A0 Best,
> >=C2=A0 Hanno
> >
> > *From:* TLS <tls-bounces@ietf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
> > *Sent:* Thursday, April 23, 2020 9:48 PM
> > *To:* <tls@i= etf.org> <tls@i= etf.org>
> > *Subject:* [TLS] Implicit ACKs in post-handshake
> > Hi folks,
> >
> >=C2=A0 As I was going through the ACK clarifications, I noticed th= at we were
> >=C2=A0 requiring explicit ACKs for everything other than post-hand= shake
> >=C2=A0 client auth, where we allow implicit ACK. This obviously wo= rks,
> >=C2=A0 but given that (1) we expect explicit ACK from the client i= f there
> >=C2=A0 is a user-consent delay and (2) it's the only one, what= would people
> >=C2=A0 think of using implicit ACKs only for the handshake itself.=
> >
> >=C2=A0 -Ekr
> >
> >
> >=C2=A0 IMPORTANT NOTICE: The contents of this email and any attach= ments are confidential and may also be privileged. If you are not the inten= ded 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
--000000000000569bb805a3fe6048-- From nobody Thu Apr 23 22:32:13 2020 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 31AE33A0BF1 for ; Thu, 23 Apr 2020 22:32:11 -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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com 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 5LEnVuvMhnCl for ; Thu, 23 Apr 2020 22:32:09 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07B133A0BEE for ; Thu, 23 Apr 2020 22:32:02 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id m67so9019104qke.12 for ; Thu, 23 Apr 2020 22:32:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Pqt9g/VLt0mb7bPp3dhPWn4gIqufVZt0iEw8iFLmW/Q=; b=yawwTRhwI8w/6UPlHdEUaySp23xk51KqduW2yZ5A2vAxvF4UganA01aVBRA5AlrIM8 jrzAD/DzFIcGKaQ9NgWxZJ846Y05zXWiOp7Xl8MLaT9p2zxzGzjVMUasT/6DwPR7fONS Gk8BXwwN+xay/LTbZq82oP7ZRvBXBByi7ivMlKlzZOBFr7Pe7bTTGgD9k4dePT9FFh7P 0C9Nn27IqAelklhTxje7w4L983DaAWcUzqjjKzNSEOgI8bLQ14f9z13UQhGU+oRwPQe6 nsLPcJWhi/JkhnC/L8wUiw7hQgxBj4J0iV5coGn3vbrxs6Hd0iWjHu3eckGrQOEbNnbG xI4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Pqt9g/VLt0mb7bPp3dhPWn4gIqufVZt0iEw8iFLmW/Q=; b=bszFX8WUBzgDSti4C/iIfPZO5ExT0G4VCFZoHj9gKYV36IZn0PRYuL/Bz8nT07/64+ MrB8TRdPFSjJAku8sIgEmgxvt1ssSUzeisVJZD7rb/mvVeHG38B+6FAalqXOPMQy/qc1 JERdTN4lRu5CffBi3U5SAmcW4O6HF8mk7YkwQus3MCdxsPaaBV4q/v8mxSnU3LYshdsP 2l2H3YqJTnL0i44cwWaPZLCvj1qOUB6QSP9qDBXh/VsDNfNmXKCPXsaRF/7PgdOaz5G5 VW6esl6VmuN5G872Ww4sWdKNAhwtS1+IuiTh1yuFS9wgabThg8PM3yBd3vXr2wtbknuh 2WVA== X-Gm-Message-State: AGi0PubivbT2PObjzJXa/S9VMDkZ6Py3oPevEY/kpadSj2YNztoqAO87 TlRzICjdV//imwnpdckQMYyBXqllavZXYKdtmw8GezDPwdw= X-Google-Smtp-Source: APiQypJv0k3Kv1M6Eu9XqheJgV/Txj+jH6GZ/IeSpLzjfv1Bx0aK4BRmOl4HI8sRZG4wQDknMmKVaunXePPYdi9ElDY= X-Received: by 2002:a37:9c44:: with SMTP id f65mr673317qke.332.1587706321375; Thu, 23 Apr 2020 22:32:01 -0700 (PDT) MIME-Version: 1.0 From: Joseph Salowey Date: Thu, 23 Apr 2020 22:31:50 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="0000000000004b412305a402af7a" Archived-At: Subject: [TLS] TLS Virtual Interim on 4/27 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, 24 Apr 2020 05:32:12 -0000 --0000000000004b412305a402af7a Content-Type: text/plain; charset="UTF-8" The TLS virtual interim will take place on 2020-04-27 19:00 - 21:00 UTC. You can find more information on the IETF upcoming meeting page [1]. The chairs are looking for volunteers for notetaker and jabber scribe. Please let us know if you will be able to help with these tasks. [1] https://datatracker.ietf.org/meeting/upcoming --0000000000004b412305a402af7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The TLS virtual interim will take=C2=A0place on=C2=A02020-= 04-27 19:00 - 21:00 UTC.=C2=A0 You can find more information on the IETF up= coming meeting page [1].=C2=A0 =C2=A0

The chairs are loo= king for volunteers for notetaker and jabber scribe.=C2=A0 Please let us kn= ow if you will be able to help with these tasks.

--0000000000004b412305a402af7a-- From nobody Fri Apr 24 01:31:50 2020 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 2D3293A0FCD for ; Fri, 24 Apr 2020 01:31:48 -0700 (PDT) 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, 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=n0zhmuO+; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=n0zhmuO+ 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 SaMQAXHnOVai for ; Fri, 24 Apr 2020 01:31:45 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40085.outbound.protection.outlook.com [40.107.4.85]) (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 E88F43A0FC5 for ; Fri, 24 Apr 2020 01:31:44 -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=bo8V5HCw8f9Ue5f4zi1pnMAiOnske9UZYmYSCoKZdow=; b=n0zhmuO+47kjSD5PdCs4oUmeAdUAJk7GsMV6NtHkZVltP4KNXusqV/TwDQkt/JW1NaQXzRo4G23FOc4EH3LxE9XUSu3vxdnOuX/BAw/yFStYCubMftgfU98tPZhQgEzhexymVNJYeth/Ipv4kknKG9LgDYe5ekKHgqeDRSzCKGQ= Received: from AM6P194CA0001.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:90::14) by VI1PR08MB3757.eurprd08.prod.outlook.com (2603:10a6:803:b5::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.25; Fri, 24 Apr 2020 08:31:38 +0000 Received: from AM5EUR03FT021.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:90:cafe::5d) by AM6P194CA0001.outlook.office365.com (2603:10a6:209:90::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Fri, 24 Apr 2020 08:31:38 +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 AM5EUR03FT021.mail.protection.outlook.com (10.152.16.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Fri, 24 Apr 2020 08:31:38 +0000 Received: ("Tessian outbound cbb03e3a1db0:v53"); Fri, 24 Apr 2020 08:31:38 +0000 X-CR-MTA-TID: 64aa7808 Received: from 2594576b912e.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F7267266-4638-4953-B6C1-41AE332D0A9E.1; Fri, 24 Apr 2020 08:31:33 +0000 Received: from EUR02-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 2594576b912e.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 24 Apr 2020 08:31:33 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mOPbc+dkMGrhaVULOm8Klu/qG/c2ZwdjUpfuKcP9fODHKE3LFNH92MML0flFEqQ6ems0Z5aCeoWYFwZjM3TWZJTwLGrRf2X+Lq1pjRAuy4nJLURPR/XrOMFryhXeiAxvVB1EdtmbDKY2NyChPuY4HOMmwHKGLJAnFXNJsV9kNPkyIL+MQAs/0e6mXbAJv/yJ4v8978wYD+d+DynsWye/NCU9UpTwhg8QBwPZxhYLYd9MVRCTM4Hsz6CniE/Sr3Wy2LuCVyGZQjKyeV6DSgGgZtGrM15AxumbL3CG8spjuwuJ8TUtvv4ZziHku5od8D0i2J6QKadOgZc77cT7Iy1WIQ== 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=bo8V5HCw8f9Ue5f4zi1pnMAiOnske9UZYmYSCoKZdow=; b=GalS6hR4AMX332UY+AVKB0tpQB/r5h795rQvUz8Hf/XUCVA+kYEqxzXFm+SZz5Co+pTUWl+qCqGnDWBNSTfP687pDQakZr8z6mvbYW9ucf6xYF5PxKTCxO4/O/ZlHbhjLFsM5+khRcekr5WvW7ewDi1cXLPAaIKfNmJnQx14WN+KNKjW9QooIY1InXwdZCGCHonPDUYXCWyKa5PDhbsluHQ5ImDm2Yd1v9TsE6O3pO3MjePrOg/r8PdA7Dqmpvd41FM6QgrrR4ySdTPG2GVC47kk8je/CvaLstmoG4GotlxfQsjnV0rGoQRXCHYCU2CpeaJjwtezgxw49514mjop4w== 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=bo8V5HCw8f9Ue5f4zi1pnMAiOnske9UZYmYSCoKZdow=; b=n0zhmuO+47kjSD5PdCs4oUmeAdUAJk7GsMV6NtHkZVltP4KNXusqV/TwDQkt/JW1NaQXzRo4G23FOc4EH3LxE9XUSu3vxdnOuX/BAw/yFStYCubMftgfU98tPZhQgEzhexymVNJYeth/Ipv4kknKG9LgDYe5ekKHgqeDRSzCKGQ= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3539.eurprd08.prod.outlook.com (2603:10a6:208:e2::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Fri, 24 Apr 2020 08:31:29 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::f501:c93e:1c20:8bee]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::f501:c93e:1c20:8bee%6]) with mapi id 15.20.2937.012; Fri, 24 Apr 2020 08:31:29 +0000 From: Hannes Tschofenig To: Martin Thomson , "tls@ietf.org" Thread-Topic: Attack description ... was RE: [TLS] DTLS 1.3 AEAD additional data Thread-Index: AdYaEN5kUL952VkXRUaptIdjWQF8VA== Date: Fri, 24 Apr 2020 08:31:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: a9970946-5d80-431c-b72a-72c46374ead8.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.118.138] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1c960929-e035-4108-493e-08d7e829e818 x-ms-traffictypediagnostic: AM0PR08MB3539:|VI1PR08MB3757: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 03838E948C X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(136003)(396003)(366004)(39860400002)(346002)(81156014)(110136005)(316002)(2906002)(5660300002)(66946007)(64756008)(66556008)(66476007)(66446008)(7696005)(8676002)(8936002)(71200400001)(186003)(86362001)(966005)(76116006)(478600001)(30864003)(33656002)(52536014)(55016002)(9686003)(53546011)(26005)(6506007); 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: Pp/zYdoTzKaDF+IX/vMxZrXycFiK7lgR3hdZgiRCnyVthwtGyRIpxay5bnGbvJzsjIJqJUCv0WAVn7NO60HmzO0n8NYopzlqQb0zSZY4eBDWEPzCQCQQS3quSSAiCFvmlgwPD39lG50dOafdeHTlV3Xuc0WcugSCmqWCUrf3pdHm3IbwYYx3y80XcgdjzhmxKR/vKRm/9xM8G3dDWAeGUl/OJnAqVT5BU+CthegQQtNLQ0YwsnO+NBDp4X/yX3TuiXrDE6oaWWgZiFkk+I9OQv1fh0/xMv2d4AN9tNfqcxTP6dGBSJYyQORSI8brfpf4rGTSHhRWFFEFABz8olenWailDcrjWPa3YYFS0Os5y4DHEHAnUzADyhSqYl+pISv+H+Njc06Bc3ScuGT82DKXdJqsGnjChVYdMHaxHRjAGSv1avoaCMlM6WES6BS1gWHOh2Ui6ussRN2FQRuECDAc3RxN2xzHtLziBfj1bfweh/JXEXa2bUMJ4My6puQ9s/8V9UFBFoW5GxavoU2gGV4pwA== x-ms-exchange-antispam-messagedata: rO1zMY3eM1COkvmhmgy+pNSpfbwtOWuzlvtFU+1HNPEUAqKn6VtEuvvdXmQf0f06DwfkOxSwVCy1hkZDA1Ae2odc+RraZFR7PTF2YHKxLeU23mRbc8QSHyF/FOsRwgwGoBo/b3jTL/Dv3G1E56M8Sw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3539 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT021.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)(136003)(376002)(346002)(396003)(39860400002)(46966005)(55016002)(86362001)(26005)(52536014)(70206006)(9686003)(33656002)(81156014)(186003)(336012)(8936002)(966005)(47076004)(5660300002)(356005)(81166007)(82310400002)(70586007)(36906005)(2906002)(7696005)(53546011)(30864003)(82740400003)(316002)(478600001)(8676002)(6506007)(110136005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 7df5115d-5b0e-4242-dcb5-08d7e829e321 X-Forefront-PRVS: 03838E948C X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bH3jPuu+8oEFO5qyT1WY1XvTAa3Kt5n1gyrJ3IZQKyCsiFt49Wgn2kv0oV3fvB/68+sCYH4PjOLA5fBRT32JonGD9tVFJsGFbuWj4vme9x73fyOJpToVW+AHAcLyTtwHP1p5Gbc6wmeiNPG2JskeKHdt96ZLarKQb/I3YjQEml5rFDU1qlFvSPHDIpupENSI6uXy7kvK+A8K6g7LMOXyRARi1XjFAUR4U0DyRhOAqK56Q6RTKy02ugiMt7NksRpUJ21cZFdTUoe2hGYxXzLizhJQ9af8Bp4rqOS6yZFwEbJTuuySjA/78yp07PnGA9hW40HfvLMCaE9lGmNdCC5pNiY25DZJMTmoXIoX0e4o+2mUtZo+rUiHBi2gx8n9OlxQR9yNeWGmPVlcgSpzFlQNNXt9nAoUtBFA2SyP6w4bu9/QeEzEWcvtr6qJfC/7uByfEoAqCEKE8kqbVtft9ZFxv9LgcPMAQiqmtwOjiIWuzmc7Ale9Aa+S607CnVNbrAiv2pJty9tkjoSoBCqMLPJcXl2vAOncM2SWHm+FUh+UJMtqPGVg34uC/Nw6InnfA7eSNsUftmXr5nzZwpi1C5EKug== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2020 08:31:38.0663 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1c960929-e035-4108-493e-08d7e829e818 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: VI1PR08MB3757 Archived-At: Subject: [TLS] Attack description ... was RE: DTLS 1.3 AEAD additional data 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, 24 Apr 2020 08:31:48 -0000 Hi Martin, I have a few questions regarding the attack you mentioned below. I would like to understand whether it relates to the topic of how the addit= ional data is constructed and what is included. > Say that a connection spans two network paths. CID A is used on path A; = CID B is used on path B. I guess you are considering a scenario where a device, of the lifetime of t= he communication with another peer, changes from CID A to CID B. Is this correct? > Let's assume that you need a connection ID to route (otherwise, why bothe= r), but that the first record in each datagram is all that is needed for th= at purpose. What do you mean by "route" here? The CID was primarily introduced to allow= the receiving party to correctly find the correct security context to veri= fy and decrypt the packet. > If an endpoint sends a datagram on path A that contains two records where= the second record omits the connection ID, then an attacker can strip that= second record out and copy it into a datagram sent on path B. With the cu= rrent design, the receiver accepts that packet and maybe leaks some signal = to the attacker that CID A and CID B really are the same connection. If you copy the record that does not contain the CID and send it to the pee= r independently then with the current text in the spec the packet will be d= ropped. Ciao Hannes -----Original Message----- From: TLS On Behalf Of Martin Thomson Sent: Thursday, April 23, 2020 1:54 AM To: tls@ietf.org Subject: Re: [TLS] DTLS 1.3 AEAD additional data I prefer Ekr's solution, but I would go with that being a recommendation (S= HOULD) as opposed to a requirement (MUST). I was initially inclined toward doing nothing at all, but there is an attac= k of sorts that is worth avoiding here. Say that a connection spans two network paths. CID A is used on path A; CI= D B is used on path B. Let's assume that you need a connection ID to route= (otherwise, why bother), but that the first record in each datagram is all= that is needed for that purpose. The linkabliity confirmation attack allows an attacker that hypothesizes a = correlation between CID A and CID Bto confirm that hypothesis. It relies o= n side channel leakage from endpoints, but as this only involves measuring = application reactions, I'm going to assume that it is feasible to extract s= ome signal. If an endpoint sends a datagram on path A that contains two records where t= he second record omits the connection ID, then an attacker can strip that s= econd record out and copy it into a datagram sent on path B. With the curr= ent design, the receiver accepts that packet and maybe leaks some signal to= the attacker that CID A and CID B really are the same connection. With Ha= nno's proposed fix, the receiver of that record will guess incorrectly that= the datagram is bad and drop it, providing no signal about the relationshi= p between the two CIDs. But Hanno's proposal is a terrible thing to have to implement. You have to= assume that there is some way to recover which CID to use in decrypting an= y record. You might save some datagram-local state, but that's awkward. S= tacks that I've worked on try very hard not to have state transmission betw= een records for good reasons. So this would be a fairly bad complication. = Separately, I hope that no one would be contemplating trial decryption for= this, which would be terrible. So I'm inclined toward cautioning against omitting the connection ID when o= ne is used. DTLS 1.3 already has fairly lightweight requirements around how linkability= is avoided. Activity on new paths does not strictly require the use of a = different CID, it's just a recommendation. Allowing endpoints to omit a CID= is consistent with that, even if we don't recommend that. However, we do = need to be careful to explain this risk so that people are aware of the con= sequences of omission. I would also point out that we attempt to avoid creating correlators so tha= t attackers can't create hypotheses about linkability. Allowing confirmati= on of a hypothesis is not that bad when the existence of the hypothesis is = itself what we are trying to avoid. Given the relative cost of performing = this attack to other means of confirming the hypothesis - dropping packets = and observing the response would be much easier in many cases - I don't thi= nk that this warrants a strong response. Cheers, Martin On Thu, Apr 23, 2020, at 02:23, Hanno Becker wrote: > Hi Ekr, > > I still don't yet understand which concrete problems you see with the > proposed solution. In particular, as mentioned in the last mail, I > don't think there is a contradiction with any design choice for TLS > 1.3 - in contrast, decoupling record header compression from record > protection aligns with how cTLS proposes to compress TLS 1.3 without > affecting any cryptographic computations and hence hopefully easing > carrying over the security analysis of TLS 1.3. This decoupling > doesn't hold for the current DTLS 1.3 draft, and we seem to agree that > in the case of CIDs, it has already led to one missing cryptographic > binding. > > Anyway, let's wait for more opinions. > > Best, > Hanno > > *From:* Eric Rescorla > *Sent:* Wednesday, April 22, 2020 3:47 PM > *To:* Hanno Becker > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data > > > On Wed, Apr 22, 2020 at 7:31 AM Hanno Becker wrote= : > > > >>> Considering the effort spent on shaving off bytes in the DTLS > >>> header, I think re-introducing the explicit CID should be avoided. > >>> It seems perfectly acceptable to me to have implicit header data > >>> which is protected via AAD. > >> > >> This is only relevant if there is a common useful case in which you > >> would need to put multiple DTLS records in the same datagram. Are you = aware of such a case? > > > > I can see the following uses: > > 1) Replying to KeyUpdate with Ack;;KeyUpdate, or replying to > > RequestConnectionID with Ack;;NewConnectionId > > 2) Sending multiple (short) app records if the application protocol doe= sn't provide its own framing. > > Neither of these seem particularly compelling to me. The first happens > very infrequently, and I'm not really aware of a lot of cases of the > second. > > > > > >>> > 1. Cryptographically protect it as in > >>> > https://github.com/tlswg/dtls13-spec/pull/143 > >>> > >>> This seems to be a mixture of logical and on-the-wire > >>> representation, which moreover duplicates the CID in case it is expli= citly present in the header. > >> > >> Yes, so? > > > > Isn't this less efficient > > Trivially. > > > > and undoes the arguable benefit of the current solution that there's > > no need to piece together an AAD buffer manually, because now you'd hav= e to? > > I don't recall making that argument. > > -Ekr > > > > > Best, > > Hanno > > > > > >> Looking forward to hearing other WG member's views, Hanno > >> *From:* Eric Rescorla > >> *Sent:* Wednesday, April 22, 2020 2:23 AM > >> *To:* Hanno Becker > >> *Cc:* tls@ietf.org > >> *Subject:* Re: [TLS] DTLS 1.3 AEAD additional data I think there > >> are two potential resolutions to your CID issue: > >> > >> 1. Cryptographically protect it as in > >> https://github.com/tlswg/dtls13-spec/pull/143 > >> 2. Forbid implicit CIDs (my preference) see: > >> https://github.com/tlswg/dtls13-spec/issues/144 > >> > >> > >> Would like to hear what others in the WG think. > >> > >> -Ekr > >> > >> > >> On Tue, Apr 21, 2020 at 10:59 AM Eric Rescorla wrote: > >>> > >>> > >>> On Tue, Apr 21, 2020 at 8:39 AM Hanno Becker w= rote: > >>>> Hi all, > >>>> > >>>> To my understanding, DTLS 1.3 defines AEAD additional data for > >>>> record protection as the record header as seen on the wire. Quoting = Draft 37, Section 4: > >>>> > >>>> ``` > >>>> The entire header value shown in Figure 4 (but prior to record > >>>> number > >>>> encryption) is used as as the additional data value for the AEAD > >>>> function. For instance, if the minimal variant is used, the AAD > >>>> is 2 octets long.. Note that this design is different from the > >>>> additional data calculation for DTLS 1.2 and for DTLS 1.2 with Conn= ection ID. > >>>> ``` > >>>> > >>>> I would like to suggest that DTLS 1.3 uses a structured > >>>> representation of the record header instead, as do all other > >>>> versions of [D]TLS as far as I understand. > >>> > >>> I am not in favor of this change as proposed. I think it is better to= protect the data that is actually on the wire than to allow for changes in= the on-the-wire representation that are not reflected in the integrity che= ck. > >>> > >>> > >>>> The reasons for this are as follows, in decreasing order of my > >>>> perception of importance: > >>>> > >>>> - Omission of Connection ID > >>>> > >>>> Regarding the presence of Connection IDs in multiple records > >>>> within a single datagram, Draft 37 says: > >>>> > >>>> ``` > >>>> Implementations which send multiple records in the same datagram > >>>> SHOULD omit the connection id from all but the first record; > >>>> receiving implementations MUST assume that any subsequent records > >>>> without connection IDs belong to the same assocatiation. > >>>> ``` > >>>> > >>>> This means that the Connection ID for non-initial records in a > >>>> datagram containing multiple records is _not_ part of the AEAD > >>>> additional data for those records, which seems wrong. Concretely, > >>>> one could inject such non-initial records into other datagrams > >>>> using different CIDs, and the record protection wouldn't notice it. > >>> > >>> This seems like a reasonable point, though it's not clear to me that = there is an actual problem here. I'd be in favor of explicitly including th= e CID in the AD as well as the header. > >>>> > >>>> > >>>> One might argue that CID shouldn't be part of the AEAD in the > >>>> first place, but in any case, I believe the treatment should be > >>>> uniform and not distinguish between initial and non-initial > >>>> records in a datagram. > >>> > >>> We're not distinguishing it. The AD is protecting the record on the w= ire. > >>> > >>> > >>>> - Modularity > >>>> > >>>> Decoupling the wire-presentation of the record header from > >>>> record protection allows to implement record protection and the > >>>> choice of record header independently: One piece of the > >>>> implementation can take care of record protection - using the > >>>> structured presentation of the record header - while another > >>>> takes care of the wire-encoding. It is even possible to change > >>>> the record header format in transit. > >>> > >>> This seems like a defect, not a feature. > >>> > >>> > >>>> - Simplicity > >>>> > >>>> At first it seems that using the record header as an > >>>> unstructured binary blob for AEAD makes things simpler, but I > >>>> don't think this is the case: Prior to record decryption, the > >>>> record sequence number needs to be decrypted, and for that > >>>> purpose, the record header already has to be parsed. Hence, at > >>>> the time of record decryption, the record header is already be > >>>> present a modified, structured form, and retaining the > >>>> corresponding modified binary form appears to create additional > >>>> complexity which would be avoided if record protection would use > >>>> the structured header presentation. > >>> > >>> I've implemented this for QUIC (I can't remember who at Mozilla did i= t for DTLS) and it's not particularly difficult. > >>> > >>> > >>>> - Uniformity with other [D]TLS versions > >>> > >>> I don't find this argument at all persuasive. To the contrary: we sho= uld break with DTLS 1.2 in any case where it's an improvement and not too o= nerous. > >>> > >>> -Ekr > >>> > >>>> > >>>> > >>>> > >>>> Let me know what you think, > >>>> > >>>> Best, > >>>> Hanno > >>>> > >>>> IMPORTANT NOTICE: The contents of this email and any attachments ar= e confidential and may also be privileged. If you are not the intended reci= pient, please notify the sender immediately and do not disclose the content= s to any other person, use it for any purpose, or store or copy the informa= tion in any medium. Thank you. > >>>> _______________________________________________ > >>>> 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 recipi= ent, 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 informati= on in any medium. Thank you. > > 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. > 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 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. From nobody Fri Apr 24 02:05:18 2020 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 3FD503A1080 for ; Fri, 24 Apr 2020 02:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 rNJ9XvrRHOuA for ; Fri, 24 Apr 2020 02:05:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B1F3A107E for ; Fri, 24 Apr 2020 02:05:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DA5B2F40710; Fri, 24 Apr 2020 02:05:04 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200424090504.DA5B2F40710@rfc-editor.org> Date: Fri, 24 Apr 2020 02:05:04 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6120) 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, 24 Apr 2020 09:05:16 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6120 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: 1 Original Text ------------- the underlying transport is a reliable, in-order data stream Corrected Text -------------- the underlying transport layer is a reliable, in-order stream delivery service or the underlying transport protocol is a reliable, in-order stream delivery service or similar Notes ----- Similar elsewhere Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Apr 24 02:06:35 2020 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 2745C3A108C for ; Fri, 24 Apr 2020 02:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 bIEediGji-Ha for ; Fri, 24 Apr 2020 02:06:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 024B83A1086 for ; Fri, 24 Apr 2020 02:06:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id ED757F40716; Fri, 24 Apr 2020 02:06:24 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200424090624.ED757F40716@rfc-editor.org> Date: Fri, 24 Apr 2020 02:06:24 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6121) 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, 24 Apr 2020 09:06:34 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6121 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: 1 Original Text ------------- cryptographic modes Corrected Text -------------- cryptographic algorithms Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Apr 24 02:08:25 2020 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 104683A107E for ; Fri, 24 Apr 2020 02:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 j1T3rMYoh8RB for ; Fri, 24 Apr 2020 02:08:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E513A1086 for ; Fri, 24 Apr 2020 02:08:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B5E9FF4071F; Fri, 24 Apr 2020 02:08:11 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200424090811.B5E9FF4071F@rfc-editor.org> Date: Fri, 24 Apr 2020 02:08:11 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6122) 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, 24 Apr 2020 09:08:23 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6122 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: 1.2 Original Text ------------- The key derivation functions have been redesigned. Corrected Text -------------- The key derivation function has been redesigned. Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Apr 24 02:15:40 2020 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 E82833A10A2 for ; Fri, 24 Apr 2020 02:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 uWeKi14Ux1QS for ; Fri, 24 Apr 2020 02:15:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 926653A109C for ; Fri, 24 Apr 2020 02:15:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8669EF40722; Fri, 24 Apr 2020 02:15:22 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200424091522.8669EF40722@rfc-editor.org> Date: Fri, 24 Apr 2020 02:15:22 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC8446 (6123) 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, 24 Apr 2020 09:15:39 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6123 -------------------------------------- Type: Technical Reported by: Ben Smyth Section: 2 Original Text ------------- The handshake protocol allows peers to negotiate a protocol version, select cryptographic algorithms, optionally authenticate each other, and establish shared secret keying material. Corrected Text -------------- Notes ----- Only client authentication is optional (albeit, server authentication is implicit for PSK-only key exchange mode) Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Apr 24 02:19:05 2020 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 018F23A10B2 for ; Fri, 24 Apr 2020 02:19:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4EHFfLv_NVww for ; Fri, 24 Apr 2020 02:19:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EEF03A10B3 for ; Fri, 24 Apr 2020 02:18:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 32D03F40722; Fri, 24 Apr 2020 02:18:39 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200424091839.32D03F40722@rfc-editor.org> Date: Fri, 24 Apr 2020 02:18:39 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6124) 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, 24 Apr 2020 09:19:04 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6124 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: 2 Original Text ------------- In the Key Exchange phase, the client sends the ClientHello (Section 4.1.2) message, which contains a random nonce (ClientHello.random); its offered protocol versions; a list of symmetric cipher/HKDF hash pairs; either a set of Diffie-Hellman key shares (in the "key_share" (Section 4.2.8) extension), a set of pre-shared key labels (in the "pre_shared_key" (Section 4.2.11) extension), or both; and potentially additional extensions. Corrected Text -------------- In the Key Exchange phase, the client sends the ClientHello (Section 4.1.2) message, which contains a random nonce (ClientHello.random); its offered protocol versions; a list of symmetric cipher/Hash algorithm pairs; either a set of Diffie-Hellman key shares (in the "key_share" (Section 4.2.8) extension), a set of pre-shared key labels (in the "pre_shared_key" (Section 4.2.11) extension), or both; and potentially additional extensions. or In the Key Exchange phase, the client sends the ClientHello (Section 4.1.2) message, which contains a random nonce (ClientHello.random); its offered protocol versions; a list of symmetric cipher/Hash algorithm (to be used with HKDF) pairs; either a set of Diffie-Hellman key shares (in the "key_share" (Section 4.2.8) extension), a set of pre-shared key labels (in the "pre_shared_key" (Section 4.2.11) extension), or both; and potentially additional extensions. Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Apr 24 02:22:42 2020 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 1C0573A11A2 for ; Fri, 24 Apr 2020 02:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ktpeDUZlkcSi for ; Fri, 24 Apr 2020 02:22:31 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DD833A1133 for ; Fri, 24 Apr 2020 02:22:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 211A3F40710; Fri, 24 Apr 2020 02:22:12 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200424092212.211A3F40710@rfc-editor.org> Date: Fri, 24 Apr 2020 02:22:12 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6125) 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, 24 Apr 2020 09:22:40 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6125 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: GLOBAL Original Text ------------- PSKs are referred to as out-of-band and external Corrected Text -------------- Referring to PSKs as either out-of-band xor external would help at least one reader Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Apr 24 02:41:31 2020 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 04D543A113C for ; Fri, 24 Apr 2020 02:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 y6lOQa-6lkgl for ; Fri, 24 Apr 2020 02:41:27 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D070F3A1137 for ; Fri, 24 Apr 2020 02:41:27 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BE5B7F4070F; Fri, 24 Apr 2020 02:41:19 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200424094119.BE5B7F4070F@rfc-editor.org> Date: Fri, 24 Apr 2020 02:41:19 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6126) 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, 24 Apr 2020 09:41:29 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6126 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: 4.1.1 Original Text ------------- Note that if the PSK can be used without (EC)DHE, then non-overlap in the "supported_groups" parameters need not be fatal, as it is in the non-PSK case discussed in the previous paragraph. Corrected Text -------------- Note that if the PSK can be used without (EC)DHE, then non-overlap in the "supported_groups" parameters need not be fatal, as it is in the non-PSK case discussed in the previous paragraph, because PSK-only key exchange mode does not need supported_groups. Notes ----- If "the PSK can be used without (EC)DHE", then PSK-only key exchange mode can be used, which doesn't require supported_groups. This is perhaps worthy of explanation. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Apr 24 02:50:12 2020 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 C71733A1155 for ; Fri, 24 Apr 2020 02:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ezGm7uvST6Vx for ; Fri, 24 Apr 2020 02:50:05 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09E7C3A1164 for ; Fri, 24 Apr 2020 02:50:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EB1C9F40710; Fri, 24 Apr 2020 02:49:54 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200424094954.EB1C9F40710@rfc-editor.org> Date: Fri, 24 Apr 2020 02:49:54 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6127) 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, 24 Apr 2020 09:50:10 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6127 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: 4.1.2. Original Text ------------- If a "key_share" extension was supplied in the HelloRetryRequest, replacing the list of shares with a list containing a single KeyShareEntry from the indicated group. Corrected Text -------------- If a "key_share" extension was supplied in the HelloRetryRequest, replacing the list of shares with a list containing a single KeyShareEntry from the indicated group. Note: A "key_share" extension may not be supplied in a HelloRetryRequest message when a server receives an "early_data" (Section 4.2.10). Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Apr 24 02:56:08 2020 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 B57A93A117C for ; Fri, 24 Apr 2020 02:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 9gUdkK41khMN for ; Fri, 24 Apr 2020 02:56:05 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383183A1179 for ; Fri, 24 Apr 2020 02:56:05 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1A90AF4070D; Fri, 24 Apr 2020 02:55:57 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200424095557.1A90AF4070D@rfc-editor.org> Date: Fri, 24 Apr 2020 02:55:57 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6128) 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, 24 Apr 2020 09:56:07 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6128 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: GLOBAL Original Text ------------- terminate and abort are used interchangeable, but this isn't explained until after such use. In Section 6.2, we have: In the rest of this specification, when the phrases "terminate the connection" and "abort the handshake" are used without a specific alert it means that the implementation SHOULD send the alert indicated by the descriptions below. Corrected Text -------------- Perhaps explain terminology earlier. At the very least, in Section 6.2, open the above sentence with "Throughout this specification" Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Apr 24 03:10:14 2020 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 675863A11D7 for ; Fri, 24 Apr 2020 03:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=e5GQjfHP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jFz2z/p3 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 rkn9CMMzkMsU for ; Fri, 24 Apr 2020 03:10:09 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E5C3A11D5 for ; Fri, 24 Apr 2020 03:10:09 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id E10D85C0966; Fri, 24 Apr 2020 06:10:08 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Fri, 24 Apr 2020 06:10:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=p9sU1+u7R4pC+O1ELShhtnZ6luzLgWi /2GUx/vGjaMU=; b=e5GQjfHP+32RDVH4w0QlvhU+gbUur7gvB/TnNXz+Oc7C+UF ODCy5AJbXFCfKNRW6BIyQauWrw7dUQ/c5un+59VsGqEA8qnZvT5lI/tu9ebYGaOz M6iDAYIKI+/onkQI6ql/150biDz3VOZLCyMqcK0kYlqTFGD/x3lFihijQYAIyN6d DOw/A2CNOKEMQBrY/46T40fAqOHKa/kS55/U3KU4YhymSromPunvZrTnu3v8xuCZ TH0C/bp+as3EANVFL1xAtgtGDTw0+vtRZrAALY5dzsL+haDf8JKB+doCrC1UYqyJ iVybX+pZPV1f2wKGQSLYgNA6KXCtUYiIuDdQUdg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=p9sU1+ u7R4pC+O1ELShhtnZ6luzLgWi/2GUx/vGjaMU=; b=jFz2z/p3S1/+EUhyxf47xs TNSUnl+UTAN5rwhzDMmTWyRvew1Aa4u9cO/eHpZ50vrH+bBEmmgcq94kXK0qGjur WrfkjqtkmcHpCGWGv5ZK8MCAij0jV3jDGVCD3sAADCTMFFUjYkAuFFAsTlOBulhT lxjrD/cX0hcxIFF94wJqH1PSY8gL2N/SG03Q7mN7c49MPK+WFwJyBh0G/tn+qjaV bk2+VcrT3ZC1Z5A2QIHhMds1KrUwTDQnPtt9cQuZHrer5HOjE6SUvA1C+NOnM5Ak E6b+aAP8i9l329gShChr0d01tcR03fvmL3XOlaxrd/qnXQHX56WiVn48sLn/LwwQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrhedugddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderreejnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucevlh hushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigv nhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 90FBAE0157; Fri, 24 Apr 2020 06:10:08 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <96dc0590-e4e0-4e38-a39a-80a13a98e33a@www.fastmail.com> In-Reply-To: References: Date: Fri, 24 Apr 2020 20:09:49 +1000 From: "Martin Thomson" To: "Hannes Tschofenig" , "tls@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?Attack_description_=2E=2E=2E_was_RE=3A__DTLS_1?= =?utf-8?q?=2E3_AEAD_additional_data?= 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, 24 Apr 2020 10:10:12 -0000 Hi Hannes, Let me see if I can clarify then :) On Fri, Apr 24, 2020, at 18:31, Hannes Tschofenig wrote: > > Say that a connection spans two network paths. CID A is used on path > A; CID B is used on path B. > I guess you are considering a scenario where a device, of the lifetime > of the communication with another peer, changes from CID A to CID B. > Is this correct? I don't think that DTLS really says what the CID is for, but this particular attack depends on being able to shift records from a datagram containing a record that has CID A to a datagram containing a record with CID B. So this depends on either concurrent use of the two CIDs, or moving a record from before a change in CID to after a change. Imagine that you have record 1 and 2 in the same datagram, with record 1 having CID A and record 2 having no explicit CID (but for the same connection, as required). Then record 3 is sent with CID B (maybe on a different path). The attacker can remove record 2 from the first datagram and add it to the second. If the attacker can determine whether record 2 was consumed, it can confirm that CID A and CID B are for the same connection. > > Let's assume that you need a connection ID to route (otherwise, why > bother), but that the first record in each datagram is all that is > needed for that purpose. > What do you mean by "route" here? The CID was primarily introduced to > allow the receiving party to correctly find the correct security > context to verify and decrypt the packet. by "route" I am trying to be generic. In QUIC, the CID is used by cooperating middleboxes to select server instances. But as you say, it is also used to identify which connection (and the right keys) to pick from potentially many choices, without necessarily using addressing information (which might have changed). To me, that's all just routing, whether between boxes, or threads, or connections. > > If an endpoint sends a datagram on path A that contains two records where the second record omits the connection ID, then an attacker can strip that second record out and copy it into a datagram sent on path B. With the current design, the receiver accepts that packet and maybe leaks some signal to the attacker that CID A and CID B really are the same connection. > > If you copy the record that does not contain the CID and send it to the > peer independently then with the current text in the spec the packet > will be dropped. Probably, yeah. That's why you need to find a record with the other CID to pair it with. Besides, the "attack" is trying to link CID A and CID B, and having the record consumed without linking to either doesn't tell the attacker much (except perhaps that the CID wasn't needed for routing purposes). From nobody Fri Apr 24 04:04:24 2020 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 D740A3A074D for ; Fri, 24 Apr 2020 04:04:21 -0700 (PDT) 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=Dj4KUMos; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=Dj4KUMos 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 ifa8btW-OfMT for ; Fri, 24 Apr 2020 04:04:18 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140075.outbound.protection.outlook.com [40.107.14.75]) (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 359D43A064A for ; Fri, 24 Apr 2020 04:04:17 -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=RqsiOF4GQdpLJaGay1s+7eSKPX4GJXPIBokzmNVkUQ8=; b=Dj4KUMosuMAQ88q8cG+ILq5H079S8GiRRAFbD0GOS5EknP8Zxb+h617GD6Pty6xuMrWM38tsLzDQKKY7baYAx5lz6aWgTM2wQkPqhxVJr7/YiY7dZXD+Y5ckTvrOf8gMdQUQx1dnbjTlWJGfnn2xw3gjKBt8SNofXqZqh0Igw6U= Received: from AM5PR04CA0009.eurprd04.prod.outlook.com (2603:10a6:206:1::22) by AM0SPR01MB0077.eurprd08.prod.outlook.com (2603:10a6:208:170::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Fri, 24 Apr 2020 11:04:15 +0000 Received: from VE1EUR03FT034.eop-EUR03.prod.protection.outlook.com (2603:10a6:206:1:cafe::99) by AM5PR04CA0009.outlook.office365.com (2603:10a6:206:1::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Fri, 24 Apr 2020 11:04:15 +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 VE1EUR03FT034.mail.protection.outlook.com (10.152.18.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Fri, 24 Apr 2020 11:04:14 +0000 Received: ("Tessian outbound 43fc5cd677c4:v53"); Fri, 24 Apr 2020 11:04:14 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: bffa249c10f28ccb X-CR-MTA-TID: 64aa7808 Received: from 8be6173aab00.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F45121CF-8680-490E-BB4E-66DE74D44FC5.1; Fri, 24 Apr 2020 11:04:08 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 8be6173aab00.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 24 Apr 2020 11:04:08 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fhEeIRywsphw8q1xVfRX9XLKMFw9xbzazZ6C9SWhYPOa+KwBrYT5zYF2U1OpgWGWSwYibmj5bPVsOCQe3qVdVi3XINbdKZmzjof7W2vgsjEMPX7hu/RE1oh/kVRDHWYlEdcHlp4dOyfBcPdQyERJNXUbdRNtCZa8a5rLLAdvF4iOyhYqwgK7Y0rmN9myK7aIu2MjUdCFmL82Ixq2+GDHVwGXhY/3W4yCaACq3bMf/+QMK2Fin+irihp9p/dzAxZzUpNtZMVkvDOyFG17l//mvE/AqAVZyEj5D4MWqaACMcwGEQIlD+UZvECLhjmHIRaRfTEx2s62l47N/tr9WeVsUw== 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=RqsiOF4GQdpLJaGay1s+7eSKPX4GJXPIBokzmNVkUQ8=; b=SZhG2ejfRdcO1PbwpGofkIIK3ZUsO7iUb3HiJgjvkFp5U1PYOuogodrXzuMOjikTvrsJT1MmqNPM+PZ0rzzlciIo/+meOudsf+B7r2gLumORzVwnvGOCW8PVhDAn1xLJcjo5V2E+DZShFPnGKL8Ys4hi1DnV8D4Q0kCE6WDRSNAZvohsGB/VnNfiYxnAZ/Q/eoIomiA+jsJDrMFU0mx4w/zTtQE0g0ucdKtpdvTm/ICM0BdYqBTlaoYKCbnG0uRL7zl6PU6t00UjbIBkHvhsTiNZsHpz0csZ19irSgq25q5UB32m5fB87PXt6O2EOMwV96bWJmArTC+Pllww1d+Clw== 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=RqsiOF4GQdpLJaGay1s+7eSKPX4GJXPIBokzmNVkUQ8=; b=Dj4KUMosuMAQ88q8cG+ILq5H079S8GiRRAFbD0GOS5EknP8Zxb+h617GD6Pty6xuMrWM38tsLzDQKKY7baYAx5lz6aWgTM2wQkPqhxVJr7/YiY7dZXD+Y5ckTvrOf8gMdQUQx1dnbjTlWJGfnn2xw3gjKBt8SNofXqZqh0Igw6U= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB4066.eurprd08.prod.outlook.com (2603:10a6:208:125::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Fri, 24 Apr 2020 11:04:06 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::f501:c93e:1c20:8bee]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::f501:c93e:1c20:8bee%6]) with mapi id 15.20.2937.012; Fri, 24 Apr 2020 11:04:06 +0000 From: Hannes Tschofenig To: "tls@ietf.org" Thread-Topic: Choice of Additional Data Computation Thread-Index: AdYaKASVCp3JPFQuSaOSMkwtz/VZZw== Date: Fri, 24 Apr 2020 11:04:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 22aff622-40ad-4417-af39-1918751016f9.0 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.118.138] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 957906d6-4120-4dd3-3816-08d7e83f39e8 x-ms-traffictypediagnostic: AM0PR08MB4066:|AM0SPR01MB0077: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:10000; x-forefront-prvs: 03838E948C X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(366004)(136003)(39860400002)(346002)(76116006)(6506007)(5660300002)(7696005)(26005)(66446008)(8676002)(55016002)(2906002)(86362001)(9686003)(66476007)(64756008)(66556008)(66946007)(52536014)(8936002)(478600001)(186003)(81156014)(33656002)(6916009)(316002)(71200400001); 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: /cZ26ONePjXEhtPM5yMFdz/mnYU/59fyMlUPkJ3UGw8WbaDM/GpCZv1pNUWjK+/8ATg5RthDVuSyynfH4zF0EB+5NqPksPIJNiKDz+2d/9/s8Qzw/O2017LH5JxOSm7/pmol4VYd9JwKkqOwvGNipjl6T1GiEjLjQtka5JXu2JwMG5d1EhPj9ZUJqqfsOK/KibsPZJ9ryIGNiLplivAFAm/LHgan3t+RA0oJTzjwodccw1MTbwauZUMXZ9K2q8EqD4GcvzK0wqaA99jKB7gooXZIvgCvnfZLqT1261O6B1gluhbFLDrWPTVRJRLpxgcfPSc7xbhg6Myg2yxOaLNBaL5l+yQxuSB4G/EIvZnw32a6EKG05ER/Gh1i4QLNjpiHsJWCGxhIznb2FV+pTJWD2pIWPc7PZIy4F6/IGczeSl9FNJrDz2iKewELCYASqqY1 x-ms-exchange-antispam-messagedata: 3iExkFCFzL+Eb/Q39Crs5e61Na/QSPRfZSM/973UoaxOQ09CoJi1aR2cUjIaqI3VQPKdmCZZSxpAmonp7YTcljO97xdGLKDGlM6EZZDxcmSEcwcFyhXLVmqvnA1uUWB7V+bpxG46uToLctZO3YXooQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB371694E826FA10D25F2BA53EFAD00AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4066 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT034.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:(4636009)(396003)(136003)(346002)(376002)(39860400002)(46966005)(82740400003)(52536014)(478600001)(47076004)(82310400002)(36906005)(2906002)(316002)(81166007)(336012)(356005)(6506007)(86362001)(7696005)(33656002)(8936002)(8676002)(186003)(5660300002)(70586007)(26005)(55016002)(70206006)(6916009)(81156014)(9686003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 2a260f86-5dfd-4dca-c582-08d7e83f3500 X-Forefront-PRVS: 03838E948C X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: cZ10ZhJ/Q3hLvR9LIPggqJESDJSO+taC6RlW6RO0I6OL2+bvUiPygFPhShl9SM9bXlO8ycAweF8m3mctVFvehzrkMsOzRd+VdoPlTXnvji1rNLFhkY+C2XkrI8vfszbC/cFuHrVumddj3H39ExRGYE16r5gpcD8jcs28eTsJH5uuoT/EtMzohP1Gs4E86EJvJPRZMB6B4WE/pPk8xQ5NlmkwoAa4wBjASwvZw29OCWLpzQMwS4VIbWGetdDUbUJ8AkSL/btTKK1I81CT4ycQXXq3YppUlmzo++4S+nSeoL7rXrE7zbgKEEOaQ/yh5/WdwxCPA96YGruJugf5yAq/JXbj5ZAmMWV6f5wglCSgOa94Ip9FLlc1tdFdEoIZJkhWEgir4IXWpu/oPldrC2BFYQgwlj286KMochLt0KbrFq363iwQOBctJeAgXS041HcFZbFnlX54P2KjggIGxWFuHTbgh15ikSOMntSfKTzMXXWsCnB7pYlXBi0bTj1UnSwiT7gBRiWBYQ7icDWUY5bU9g== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2020 11:04:14.7288 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 957906d6-4120-4dd3-3816-08d7e83f39e8 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: AM0SPR01MB0077 Archived-At: Subject: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 11:04:22 -0000 --_000_AM0PR08MB371694E826FA10D25F2BA53EFAD00AM0PR08MB3716eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, the thread on the AEAD commutation in DTLS 1.3 and the construction of the = additional data raised two interesting questions. I believe those would ben= efit from a formal analysis or at least a security investigation. Here are the questions: 1. Generic question: Should the construction of the additional data be d= ependent on what is transmitted over the wire or should it be based on a "p= seudo header"? DTLS 1.2 uses a pseudo header and DTLS 1.3 the data transmit= ted over the wire in the additional data calculation. 2. Specific question: Should the CID be included in the additional data = calculation, particularly for the case where it is only implicitly sent? As= ked differently, are there attacks possible? Your feedback would be appreciated to advance the discussion. I believe the= re is a chance to provide generic guidance for security protocol designers = here. Ciao Hannes 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_AM0PR08MB371694E826FA10D25F2BA53EFAD00AM0PR08MB3716eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

the thread on the AEAD commutation in DTLS 1.3 and t= he construction of the additional data raised two interesting questions. I = believe those would benefit from a formal analysis or at least a security i= nvestigation.

 

Here are the questions:

 

  1. Generic question: Should the construction of the additional data be d= ependent on what is transmitted over the wire or should it be based on a &#= 8220;pseudo header”? DTLS 1.2 uses a pseudo header and DTLS 1.3 the data transmitted over the wire in the additional d= ata calculation.
  2. Specific question: Should the CID be included in the = additional data calculation, particularly for the case where it is only imp= licitly sent? Asked differently, are there attacks possible?

 

Your feedback would be appreciated to advance the di= scussion. I believe there is a chance to provide generic guidance for secur= ity protocol designers here.

 

Ciao

Hannes

 

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_AM0PR08MB371694E826FA10D25F2BA53EFAD00AM0PR08MB3716eurp_-- From nobody Fri Apr 24 06:07:23 2020 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 B869C3A0CC0 for ; Fri, 24 Apr 2020 06:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmx.net 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 Pq1VLkZ3-4GT for ; Fri, 24 Apr 2020 06:07:20 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBB33A0CBC for ; Fri, 24 Apr 2020 06:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1587733636; bh=wF3KxI1u0dafCffoCPFYyfNNWz1xzu5aENHx5fedgZY=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=d2R8CjXf+gMmxJLQQTKk4sQFh2rDDbGKNLavkEEd+4xVnTB0IBQKPAyI/ulbG9UYo NWQPe5SRfquH80p+6qw6KVmzIGHLN6vM/Ga1tapr+4jZleIzzIMrTm2BSAElorcsKE RPBASQP41JI848mLiHDR/kJAUBCumH2Zr7tesNxM= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([178.10.206.187]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MbirE-1ivO7W0bGQ-00dIA1; Fri, 24 Apr 2020 15:07:16 +0200 To: Hannes Tschofenig , "tls@ietf.org" References: From: Achim Kraus Message-ID: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> Date: Fri, 24 Apr 2020 15:07:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:WheUExxnSfZVsJj6G5j+wED6ee10blZligDCKGiHO07KlDH4JNQ 4sqXNV6p8JwZFOv8poZNwscuBhZxcHQ4DAbHLU1cxvrLeOdY3hy6T0YXWYnkw/oCNdVqFdu 8/f3oZRAiKAz+mcO4a92gsCcGiXMwEHbSk+4Idq16hG/cYWhaaS64uhoYNRJbuneNFEmV7I XPZRJQoWhSFOerDBjX78A== X-UI-Out-Filterresults: notjunk:1;V03:K0:BOv+BbJ8BfU=:SI2xWMeBtzt0Aa1t+nXZbv cwtQx9fbr3wQpXA0JobTfm0LfMrglNE3Z54LuwAMqqbczr2hmij2CY0PfzZCr4lQY4xBhMRLj 3liQD8eTq5DFfMjoVhd+xC4m+DgEZzajJY3oT6Ys0UdXRAjRLUkbdHa16wgtKkHV3pmQPmcbv NHM5KlZ6caFE2Gy227f3W6BPVXzFBPLuJ9AZBy9JSELqpzDFna6Ahm1cI1FE8oZmW/hFCkNqN kpwAv7LGhqpjtxmS3Opx06cTIsmyJF7a1T8WlZ5h7ewB5kpAMHh2kGARn64GJJXBylLN3DAcb iI5QFjC5CsSM20L365fWVh9k4SiG+o0urE288X5kFCHqRPaR8+VRwvcMtOMvSv2wLM4m/F6El ceODxdKgRjQiCz3sP0q/zHqNILy+7D7bZSfmnj5BAkQDUr5D4L4ADbSTaIOqABw40MBD6+u9d ZDqqGdq1O7tB0GVfdy1vd4xtaeM8qY1r/hdC4NjozV3BQb/lcJvPv3Td34Xm6mX3gl7+T7oxV HMKGyCUxT+0l04whq0u5q/rSzlGlcxgL/9mj4825IhIVa4OIhe9gEAeMDZQbdIr5qG1ISA6S4 tFFGUMd0AAD3sOlUD7oe/QB490tFv08O2dy6bUn9jLUCM35tMmvH/34wtvIi4ICgtUn6J6hn1 51OUQiMQw+O1zB92IIJSljRZcBqf57P7rzjdirupsEGL4obQn2RbGYck1DXZQmYs9i8/ftBEx TA9lC6sTfF04cnlgjGImh6Jz0PBjDDeuf0sQ89u8t+qaJYwz+8SnBWAFdqwGek4NvYtzg6mSO vctCj1jSfctQN2kQSFRGEkP8iWUXnTm6mlmu8EBfbAD8ueyZyln3ltHiqzQBAki5bmDfcKhpU RjugrpoIdXYkdXRav2xs3c8xThwc2hvF/kc4TE20w+5C4ttuKznoYtDyXc/2TQ525Iar4eGIG 4MSrOrUYansZcfEAgwkkaJlKxLuWMFtFmI/gn0ZKHjSCDHnJEl5V5lPK7Ba4d9GePBZU/jhPI RLWFGFw8RjpH9h+XVWol0EWCQgh9C4XiKcJj2E6wqY8teM2r5K9GlRE264LYiKuahg7yciKYO JCoMz9EynEB3B7IKeqjq4nX+2nhRXgoMzYTDHAuGvTRMAkORH9unN1dJQkOb+beS2694VFtxY sUvKYP6FqdN2vPYRUwQB8gLUuafUQNoqy9yUItT3eAXNOOADQyMVLHpW4zy0jSFxC9TS3zEOU k9WDlvaXFXVikDvXy Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 13:07:22 -0000 Hi Hannes, Hi list, as input for the discussion: https://github.com/tlswg/dtls-conn-id/issues/25 A longer "comment-flow", the conclusion was, the CID is on the wire, so it's in the MAC. (ekr: "authenticating the whole header is just good practice.") My arguments was, that the CID is always included in the MAC, either explicit, or implicit (implicit, because the CID selects the "mac-keys" or "cipher-keys" and gets included equal to the address:port before). best regards Achim Am 24.04.20 um 13:04 schrieb Hannes Tschofenig: > Hi all, > > the thread on the AEAD commutation in DTLS 1.3 and the construction of > the additional data raised two interesting questions. I believe those > would benefit from a formal analysis or at least a security investigatio= n. > > Here are the questions: > > 1. Generic question: Should the construction of the additional data be > dependent on what is transmitted over the wire or should it be based > on a =93pseudo header=94? DTLS 1.2 uses a pseudo header and DTLS 1.3= the > data transmitted over the wire in the additional data calculation. > 2. Specific question: Should the CID be included in the additional data > calculation, particularly for the case where it is only implicitly > sent? Asked differently, are there attacks possible? > > Your feedback would be appreciated to advance the discussion. I believe > there is a chance to provide generic guidance for security protocol > designers here. > > Ciao > > Hannes > > 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 > From nobody Fri Apr 24 06:47:25 2020 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 78FFB3A00C9 for ; Fri, 24 Apr 2020 06:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmx.net 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 x72plOAvXGY5 for ; Fri, 24 Apr 2020 06:47:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2E23A00D4 for ; Fri, 24 Apr 2020 06:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1587736032; bh=qcZU/UA9aWzmAoLbxpJG5uUAKN2Qfosyxh1P+ltyIzc=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=cx+xVhp1Au0Tmk14IAyY9RYFItqdxyBmZH4EUwxApaOX2C//eTD2iE0aNuv+siCXk b1zztQvwSirh8HV5SrnftiWZuxcAuFev1aAzmHqMTYyJiojCHT6cAu7SKBg0Y6tFQQ Cg/F3g5Ll+gs1lLEBX9HMMBx9h0UFz02LgaIRhv0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([178.10.206.187]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1ML9uK-1jixYb419m-00IBke; Fri, 24 Apr 2020 15:47:12 +0200 To: Martin Thomson , Hannes Tschofenig , "tls@ietf.org" References: <96dc0590-e4e0-4e38-a39a-80a13a98e33a@www.fastmail.com> From: Achim Kraus Message-ID: Date: Fri, 24 Apr 2020 15:47:10 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <96dc0590-e4e0-4e38-a39a-80a13a98e33a@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:dUEAb4C19fngelYJuiDW35lhRUajCAT1KOJRGvZoLx7sSbnIaVM HUKy37EgWhQFCeTrU08z0sinUrIcw/OwUPGC6sTnsAaedBXKE+hxCEH4Zh0qWNNnmaAaAOd t8DkUq+twxOo0ogEIXJfzEphORBTT5eXV/UzPiBdXaMVC41bGdUiHFxzKd5Gw2JxZzse2fw 4aseJR9l3bz5qWMwCSNcA== X-UI-Out-Filterresults: notjunk:1;V03:K0:FBk8inDdNps=:LQeSXvKpMDDRDWlrLLkuqA BzxoxsLjESVQhblCihcMOcu3RGMVb2tnfKoaFXXWaUiubyRMzXqSYtcg0JliiNSKadpgPxIrC OEUAOcSwCzLeQArrxEmyrMcerhj/hN37WzQyWK5BRSyLaWBamLhQu0so8rW625/zScj74YR1O u4/qVHZyuIsLuWqoNy1YybpYjiPvLsu+slODJvI38j/cfxaLZ1BhtcA41xqrhK4QR5uT7dDjs yOr1kO/tN4FH9+tTg+ALkI743gBe9RruNAIaxQf5Hm7LyyQXHNKeV33SuX00pGuJ6880iVSsl eMqjh60xc9D8f0fOEhozAk14qD4EIdP9+I5aNEltkCVY5L/mBDxIL7Y/ll5dU7qqjS/L1lXSD +EuaXR4uZAkTiSTK2Upc9ZPIoVJME1BwmRkCDsiZ49AHv9jR80y/AayUS0M1+cWj/7I2tI7/z 5ytSgu70SdfPyu3RL0SGYwGS0HmgKhbs/Prc0oO/tXq0VRviYEStjH0ssqQ3RcTmT990NJ9BL w9UV7+TDNtQvLl0IGmIQckbFhewISESW2g8sk7lQ2Cp+CC58v+hnGFUapa6IPopx5FYZk/Mrn bv6elUycHVsKsTEz3XAzrGaYcmynM0d8ifBQlQAAUcNiN8XVORgY4+LcIfZgkY8azQS1O6/At dnDo2w8DIbxtnP0DV3p8emE6CzQ9zgSRUe1o2QB31ZyQ4UQOd/GX2MBZcAqR0ERdSPr9P8xRU SxmoGahuG5FZlKnLH3YhOt/1cMKPuO++Tk3b1t/E7VLGbHHTWsbx/A96dQ49WbUXEaNkk8GS5 OHAVjBiikffM9YbotFS1LhnTu21tbpc+KpK9I3XNQTMVbP7qLm49YmMVys7x7feM7GBDMlnbe Q8Ddr/9HQHR0/ZaNmsWr0ozKh55W4LhwyiZ3ZCFVIYTx7cv4nWgd8jIlLCMWpIn4pY9TrC2/V MASelZmlcEPfrB27OjrLim8F3FssSvbTIKqtZuLzRvbTTuNwPt7BDcS1Whhaszn5UdCwksf4v HhhAYmq9m4HKxSjqfN34nnYAezrIkUfJwiG6bzYGH8wNekQN/dy2mI55wPe4MtH6WiGqUzYua HkUFfq620/rDyWc/whgwMIW5RRyq+aeSnOPabKfjKoZ7WA83BOR7DeEMsbbJ8oGTNIAneXepH UVKGtdcpsI90Dq8KtTAeYE6cS2aWSmFNHYx3PFKcm+gzP5ihKVM7uGG4o0Xcxsq/XAXTb7gQ7 3PdtrJXl6XRbaVdf0 Archived-At: Subject: Re: [TLS] Attack description ... was RE: DTLS 1.3 AEAD additional data 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, 24 Apr 2020 13:47:24 -0000 Hi Martin, > So this depends on either concurrent use of the two CIDs, with that and the "routing based on cid", I would raise the question, if the usage of the cid turns into a swiss-army-knife? Therefore it may get larger, and so it gets attractive, to use it only on the first record, but leave it out on follow up records. So, is that the idea? Use a large CID to include more information? > or moving a record from before a change in CID to after a change. I'm still not common to DTLS 1.3. With DTLS 1.2 a resumption- or full-handshake will result in a new context. So for me moving the record will fail. best regards Achim Am 24.04.20 um 12:09 schrieb Martin Thomson: > Hi Hannes, > > Let me see if I can clarify then :) > > On Fri, Apr 24, 2020, at 18:31, Hannes Tschofenig wrote: >>> Say that a connection spans two network paths. CID A is used on path >> A; CID B is used on path B. >> I guess you are considering a scenario where a device, of the lifetime >> of the communication with another peer, changes from CID A to CID B. >> Is this correct? > > I don't think that DTLS really says what the CID is for, but this partic= ular attack depends on being able to shift records from a datagram contain= ing a record that has CID A to a datagram containing a record with CID B. = So this depends on either concurrent use of the two CIDs, or moving a rec= ord from before a change in CID to after a change. > > Imagine that you have record 1 and 2 in the same datagram, with record 1= having CID A and record 2 having no explicit CID (but for the same connec= tion, as required). Then record 3 is sent with CID B (maybe on a differen= t path). The attacker can remove record 2 from the first datagram and add= it to the second. If the attacker can determine whether record 2 was con= sumed, it can confirm that CID A and CID B are for the same connection. > >>> Let's assume that you need a connection ID to route (otherwise, why >> bother), but that the first record in each datagram is all that is >> needed for that purpose. >> What do you mean by "route" here? The CID was primarily introduced to >> allow the receiving party to correctly find the correct security >> context to verify and decrypt the packet. > > by "route" I am trying to be generic. In QUIC, the CID is used by coope= rating middleboxes to select server instances. But as you say, it is also= used to identify which connection (and the right keys) to pick from poten= tially many choices, without necessarily using addressing information (whi= ch might have changed). To me, that's all just routing, whether between b= oxes, or threads, or connections. > >>> If an endpoint sends a datagram on path A that contains two records wh= ere the second record omits the connection ID, then an attacker can strip = that second record out and copy it into a datagram sent on path B. With t= he current design, the receiver accepts that packet and maybe leaks some s= ignal to the attacker that CID A and CID B really are the same connection. >> >> If you copy the record that does not contain the CID and send it to the >> peer independently then with the current text in the spec the packet >> will be dropped. > > Probably, yeah. That's why you need to find a record with the other CID= to pair it with. Besides, the "attack" is trying to link CID A and CID B= , and having the record consumed without linking to either doesn't tell th= e attacker much (except perhaps that the CID wasn't needed for routing pur= poses). > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Apr 24 07:48:59 2020 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 1AC693A08EE for ; Fri, 24 Apr 2020 07:48:27 -0700 (PDT) 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, 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=opXmPbnv; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=opXmPbnv 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 5LPzX-SOEl6h for ; Fri, 24 Apr 2020 07:48:19 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20089.outbound.protection.outlook.com [40.107.2.89]) (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 8F6913A08ED for ; Fri, 24 Apr 2020 07:48:18 -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=tato57+kxceN064+taRCASajl8woJxY13zvZijR98Nk=; b=opXmPbnvd3lbOe9IAfdS6dshgf/mGQSxvJw1RgEtCDkfe0xDKf40J9nwlK96LysPnU+fhh2j1Ix/2Ufx0Dw3mNSh5w1UZOjZ1nFHWDmzwrnOpFv3/Xw0r8jzpQXwunn/RogveJK2FR1LHeSQiaWKEqM6T3OMANUtyAdzquhfhDg= Received: from AM0PR02CA0084.eurprd02.prod.outlook.com (2603:10a6:208:154::25) by DB8PR08MB4188.eurprd08.prod.outlook.com (2603:10a6:10:b0::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Fri, 24 Apr 2020 14:48:15 +0000 Received: from AM5EUR03FT056.eop-EUR03.prod.protection.outlook.com (2603:10a6:208:154:cafe::2e) by AM0PR02CA0084.outlook.office365.com (2603:10a6:208:154::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Fri, 24 Apr 2020 14:48:15 +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 AM5EUR03FT056.mail.protection.outlook.com (10.152.17.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Fri, 24 Apr 2020 14:48:14 +0000 Received: ("Tessian outbound cbb03e3a1db0:v53"); Fri, 24 Apr 2020 14:48:14 +0000 X-CR-MTA-TID: 64aa7808 Received: from f195d79c5ffe.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A964638A-D481-46F6-9431-7BF3410DB340.1; Fri, 24 Apr 2020 14:48:09 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id f195d79c5ffe.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 24 Apr 2020 14:48:09 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mdUEp+0BQVRJ8mKLiwZnioqKvuUxXBHv9IfF/qixZB716Bm+pf4LM+luhogp6qEWx70fHMceWDYTPUUaYOvfAzs3IC9WtAxAUW2T9nTSLSKDdRZQXTXRv0PUPX5xo0J3A+mOtBuwo+Hi0NYqxhX4GdiqFznu8QcutPLrmEp6FG6keU98wYtfo20PVPqKiG9C8qYSDqgg+FwXaYvnhf/XFpU6MV8sE3qTJfGR/JB/UwjpkY7l5lJiO0JGojH2zN4zeueX9tQtNoG0uEF8Bl0Ny5xj8IraP1TUISq3b2LqQdFUUGcPSfbA3YjupoQApBKjsG9zKzn7wTRcv8FQTgrs7A== 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=tato57+kxceN064+taRCASajl8woJxY13zvZijR98Nk=; b=I6qV5Rnhi+3bNh+GQjF3qVxs72PUTWmH1+/hhD7i4oC+wUz5FksdlKPTCGGu2R+/tedJi1AWY7HeFAauLY6l89A7XH/eIHXtcuvgEETWfiBh8kgWJkJu8jg5fN7vxZoy66hfAz5KA5hFBLrKhhMfbW/Ykm9FWJzsBVbsUTCSJ1jjQs8AjatXsj7zH7AQ2YptgSe4tiEOYexblYu/c1Fe1chN5UkyPIO4os3Q2jI7bTMcz+hnbUcxpRcW0XSReZKes1cl+o8su6HqZPh0O+ZLEKT/uUfZE9zI7N11cqTdEoKuPS8qQa1cVlBbX6BtYUtToEar0DHqpeDV+d+TD6cgog== 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=tato57+kxceN064+taRCASajl8woJxY13zvZijR98Nk=; b=opXmPbnvd3lbOe9IAfdS6dshgf/mGQSxvJw1RgEtCDkfe0xDKf40J9nwlK96LysPnU+fhh2j1Ix/2Ufx0Dw3mNSh5w1UZOjZ1nFHWDmzwrnOpFv3/Xw0r8jzpQXwunn/RogveJK2FR1LHeSQiaWKEqM6T3OMANUtyAdzquhfhDg= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB4019.eurprd08.prod.outlook.com (2603:10a6:208:128::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Fri, 24 Apr 2020 14:48:08 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::f501:c93e:1c20:8bee]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::f501:c93e:1c20:8bee%6]) with mapi id 15.20.2937.012; Fri, 24 Apr 2020 14:48:08 +0000 From: Hannes Tschofenig To: Achim Kraus , "tls@ietf.org" Thread-Topic: [TLS] Choice of Additional Data Computation Thread-Index: AdYaKASVCp3JPFQuSaOSMkwtz/VZZwAEUEsAAAN7oaA= Date: Fri, 24 Apr 2020 14:48:07 +0000 Message-ID: References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> In-Reply-To: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: a401ae8a-ec7d-4bb1-8459-57c1c5ea7c18.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.118.138] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: b4f398d1-a7ce-4cca-bc19-08d7e85e84cf x-ms-traffictypediagnostic: AM0PR08MB4019:|DB8PR08MB4188: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 03838E948C X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(346002)(366004)(39860400002)(136003)(66556008)(64756008)(316002)(478600001)(66946007)(66446008)(5660300002)(966005)(71200400001)(76116006)(52536014)(26005)(7696005)(6506007)(53546011)(186003)(66476007)(110136005)(8676002)(81156014)(33656002)(8936002)(2906002)(9686003)(86362001)(55016002); 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: PPNUT3+nYUgnNzCH+YuMEOXknfv40EhPpgMa6hV+stJa3atR3Sv0Fl/FraVMSpqkQDU/qcXGpBowm1sd7mKQ8RWugrc43PDPP5ZvNHJnCaRL8fzJdrFgl1jLkxYSVPXmJk9NOiAHURZhZJAHp/txgw6BH5WnjBBbG/hLLIOnDIOJl7VzKvjS2E4sXWs8DWFvD/1aI4lbAV3hwclgw/9NDJJ4YMsXIbNEfD1mRnbtvpg+xGxWSNvgQnMXeCCwM+hTKmexK0jYVoSzO0RtFSciFZ7BHhU7ohVtJHrQelb7qhI6GL/D2D26exLw8Izm/7pvUGsFv3L2xnqNGBCVAY/N97bZANH6cwmpiC7Kbv+/hm1P/3tBMJxOiEsjJmx71H6lUHTE+peDMgDQm7lHhBhdoQw4FcxCoIU4U1BDxfxQbmfNaK5UjBtqjePfihEaR/WwYU3K+v3Mi+VHcqSk5lyfsfTWD/bABDYcZM0H5t2xk+xrRbWeNoyLbZa65mBQo9m8p82F9glg1n03cb9KPARy0w== x-ms-exchange-antispam-messagedata: YsOF4FAP4iIEm/wPzeeAnlO4Gd4jq9s5MKmdQQHTQo+9Wasg3S1CjCDLfBdm9Uq0AFpMEE678jE1sr2o5JY4W948RqykWEQ3hJNkZB9HP+9WS1uRaJN21GVfitaPxBS9E/7eNn6+LCs1YMrM7v1zzA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4019 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT056.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:(4636009)(136003)(396003)(376002)(39860400002)(346002)(46966005)(9686003)(110136005)(81156014)(2906002)(53546011)(26005)(86362001)(6506007)(70206006)(8936002)(966005)(7696005)(70586007)(33656002)(316002)(5660300002)(8676002)(55016002)(478600001)(47076004)(336012)(82310400002)(36906005)(186003)(81166007)(52536014)(82740400003)(356005); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: e4aec7cd-e8ca-46ed-1aa5-08d7e85e80bd X-Forefront-PRVS: 03838E948C X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: TlnwPbs7qoEeS6BIG9d67mmA2hMZ5GzzMn5trE1ECGTeC8uc6v+AZ8pn9KM5Hf8thC/669dF5w2Au4M39sEgUaRM/PTnW8sxG0ZT2SW7SVHknouBkJlbJ7Mt+64el6rUvKE2aMawL8BQO7rJ+Zwl3UoIe0UvFJl59LebSZf0Q2Y+OESFe7sGgAPjxMPVzjC+SOY9vG7vFpk0bgarQ0UWkX0gD5ggdbCceec0vkqXKGs2dHTcsyvBzjQ9B2ESSxZamH8nnuvrzRImyeof4bZeR1kCXgU9zbhy4BUSpGF/jNH792G+lFJsxqTPkgZlcq3K2cA0aNsLei3ds6oOeEd4k5Mzpp6OFp+AaB+Awo4sGiOgC4ms2QWq+5hoNQDT+L5p5hWcAvcpSkw3sTfn4p0TCDQa8DYBqGbWsvznTeGVy4v311Y8zAtkPJXcfeEYSdbXiJ24sLtEujkavTnZ0Ie+0NOokKRSFA1oD21W/fAYVZcKqgzo/Yh/J+hExPlwNwc6QP7aaVOCg9XHaCzruxIpsNYKn3iQOJCK0H2N3/CkHHfPTaUtzNQCxAF1/jOyjsqcCQhV7CuscQ3pbpdqO7MDTg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2020 14:48:14.8231 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b4f398d1-a7ce-4cca-bc19-08d7e85e84cf 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: DB8PR08MB4188 Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 14:48:28 -0000 Hi Achim, My point is that we made decisions based on the best of our knowledge (and = personal preferences) but I am wondering whether formal methods can tell us= whether there is a preferred way. Ciao Hannes -----Original Message----- From: Achim Kraus Sent: Friday, April 24, 2020 3:07 PM To: Hannes Tschofenig ; tls@ietf.org Subject: Re: [TLS] Choice of Additional Data Computation Hi Hannes, Hi list, as input for the discussion: https://github.com/tlswg/dtls-conn-id/issues/25 A longer "comment-flow", the conclusion was, the CID is on the wire, so it'= s in the MAC. (ekr: "authenticating the whole header is just good practice.") My arguments was, that the CID is always included in the MAC, either explic= it, or implicit (implicit, because the CID selects the "mac-keys" or "cipher-keys" and gets included equal to the address:port before). best regards Achim Am 24.04.20 um 13:04 schrieb Hannes Tschofenig: > Hi all, > > the thread on the AEAD commutation in DTLS 1.3 and the construction of > the additional data raised two interesting questions. I believe those > would benefit from a formal analysis or at least a security investigation= . > > Here are the questions: > > 1. Generic question: Should the construction of the additional data be > dependent on what is transmitted over the wire or should it be based > on a "pseudo header"? DTLS 1.2 uses a pseudo header and DTLS 1.3 the > data transmitted over the wire in the additional data calculation. > 2. Specific question: Should the CID be included in the additional data > calculation, particularly for the case where it is only implicitly > sent? Asked differently, are there attacks possible? > > Your feedback would be appreciated to advance the discussion. I > believe there is a chance to provide generic guidance for security > protocol designers here. > > Ciao > > Hannes > > 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 > 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. From nobody Fri Apr 24 08:35:21 2020 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 7F2233A0D42 for ; Fri, 24 Apr 2020 08:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-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=cs.tcd.ie 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 tdoCgBFcJi30 for ; Fri, 24 Apr 2020 08:35:16 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827503A0D44 for ; Fri, 24 Apr 2020 08:35:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6D8E0BE2C; Fri, 24 Apr 2020 16:35:14 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Un4o843wy2a; Fri, 24 Apr 2020 16:35:12 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 06DBDBE20; Fri, 24 Apr 2020 16:35:12 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1587742512; bh=2AlBEM3u/fOt2yQrHhLOPdPFfwlamlHFcetpDHxD/mk=; h=Subject:From:To:References:Date:In-Reply-To:From; b=rvnwtzwhFNdeg+0Iw5yFFs69IrcEESSsUwLFLBMfIOgV0uKft3YHdfQBhWOFQDrve 9XzEt11PtR/wCa5MyIQE+ut7SCwN6fDSSIhIUebHQYh7rM8+g2qgMZT5OMR7iXxXF8 th7Las4eaPFOyF3YX9MskN5xyHNSd8Z+7XDxDvss= From: Stephen Farrell To: Christopher Wood , "TLS@ietf.org" References: <786abd25-5fc7-46f4-90c4-511a648d0450@www.fastmail.com> <54d8ea7b-ca79-55f4-281e-aedca296c649@cs.tcd.ie> Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <61d4956d-8507-ff01-72f2-4707aebf1a66@cs.tcd.ie> Date: Fri, 24 Apr 2020 16:35:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <54d8ea7b-ca79-55f4-281e-aedca296c649@cs.tcd.ie> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pzGd6qupyj7kzj6FWTNSbzfIlNaKmuq5y" Archived-At: Subject: Re: [TLS] ECHO padding review and some open issues 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, 24 Apr 2020 15:35:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pzGd6qupyj7kzj6FWTNSbzfIlNaKmuq5y Content-Type: multipart/mixed; boundary="NF6GckzWaCeNslfIpxRC99M3QG8Kzol3M"; protected-headers="v1" From: Stephen Farrell To: Christopher Wood , "TLS@ietf.org" Message-ID: <61d4956d-8507-ff01-72f2-4707aebf1a66@cs.tcd.ie> Subject: Re: [TLS] ECHO padding review and some open issues References: <786abd25-5fc7-46f4-90c4-511a648d0450@www.fastmail.com> <54d8ea7b-ca79-55f4-281e-aedca296c649@cs.tcd.ie> In-Reply-To: <54d8ea7b-ca79-55f4-281e-aedca296c649@cs.tcd.ie> --NF6GckzWaCeNslfIpxRC99M3QG8Kzol3M Content-Type: multipart/mixed; boundary="------------B9365569B4168CC95D9F85E1" Content-Language: en-US This is a multi-part message in MIME format. --------------B9365569B4168CC95D9F85E1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 24/04/2020 00:37, Stephen Farrell wrote: >=20 > Sorry - I have one more I wanted to raise as an issue. Will > do that tomorrow and send a mail, >=20 I've done that now. [1] We did have some list mails on this earlier but it kinda tailed off rather than got resolved. Cheers, S. [1] https://github.com/tlswg/draft-ietf-tls-esni/issues/223 --------------B9365569B4168CC95D9F85E1 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------B9365569B4168CC95D9F85E1-- --NF6GckzWaCeNslfIpxRC99M3QG8Kzol3M-- --pzGd6qupyj7kzj6FWTNSbzfIlNaKmuq5y Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl6jBy4ACgkQWrL68XsX K+p/EQ/+K33wAytrasLlWSa8d0FVHpNMRF+V1ZhhI416vSH5ymSdbozNPAEuKWJc aQs55XkEjCojknJMZo0JPFsqhJNHthi6zYfH126GSf/8ADJ2+WW7P4A7FbVVZqpV oPRDtGKbOnCAQ+WnIirpR326w4/OCG4ueAOoUuq1epORPnBPeBd869JLHSkQs1AX 98CxRDLvWm2KLslT8unQu/wymnazhi5suS8cMGrsxsyl7Ro9ohsFPffh2+fGssZq j7ACMiT4bP5YhZAdBodEXz6C7qJUB4x6x0fipYwe+MtShaesWh2WiUOImZVChpxZ XZUJ0yu9Zyac72xjNGa3p81QL9uFeH9AqH3x1dwRuGiRk4z2AADOgMxJI8vVeekN TRW6BLHgMJG/jwbO8UWs64pwJwzKc3a9MKJTS5PzaOTHwlErRhBs4gtagD61Y0GY lQmg274lmI9Qa2Rpg1mSrwDRZh/jEs1ZhomJokYBvuQVrHH97uKuRr7UvibKi09H bEOMi8+a1wST2DtGOghyO9Y70AVN3WzK7gM/+ZxX/Xp4sFHOyZdhE8erOg8v5t92 F2GoQ4UcgtfRfINLgREQ49Pjyy0GZdB0CW2l0viXbkR2LvBWl4XmrmGnjuVQu2v0 LrY3wfmMFCVDt0ZJ9qvX7bFPHzdjjn4W4m1kqjmvxm3NeQoAAu4= =5pdU -----END PGP SIGNATURE----- --pzGd6qupyj7kzj6FWTNSbzfIlNaKmuq5y-- From nobody Fri Apr 24 08:57:14 2020 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 DD0993A0A22 for ; Fri, 24 Apr 2020 08:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3xXsEXidBq-u for ; Fri, 24 Apr 2020 08:57:11 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 714A03A0DF8 for ; Fri, 24 Apr 2020 08:57:06 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id e26so13224157otr.2 for ; Fri, 24 Apr 2020 08:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=urjY7VHsv9QYCLvY61L9Oka0E3d3b0NrWrqzwOETjCM=; b=qqaEficYRI367U5wS17eHdVg65Vmj49KB+7PNp8PUSVWn+UCu+jJN7WDpAtI7Lypgx dMJiN+IjacoC8glDkMkprDZuRHEMGzyqoga9XaXrd3UQHyQF1EpCUgOUzOxppPUaiLSB DtRM4BYAKovg/t+n1DH2bV0WXg1uYQBAanz6FdapuJ4/A7mUAcxulTBTIkMeg9JBVA63 6OsupeHIBgWY5L8g5dsVviQJrAIJHvLLEDkd8J/UTYrrmWUtdqx80YiRLlsyS7GOKKuQ yd4mFeSIlQyuEN25dgdSXuo3XUeVWuz56Gp4IddQlrjAk22uzdLw+eU5WXMy9N+qXP0X rIXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=urjY7VHsv9QYCLvY61L9Oka0E3d3b0NrWrqzwOETjCM=; b=KCH2zoURt8e5fRE6OP+J7cSIOtjqqAI+X2iZ+zBVIrpSL2IaAtgG27DT8vi3fKLIPU UI7OQus22D0wgImEtGU2cbpDZ55UoqkskkyOKNTafdpjs0LdJnart/Yads7a9qXaq88/ kA25Qj1hErqHcaL73wTYUfD1KavFqfemq0Utq5Iv953stKWv7LBQOd4Op0YGjcGntE0O H6Z4BjirMHhn0kUjqKSXKW3HRlPDFZMD8rpmDJSdlcVr3PZ1WQacHGZx4Q516K1TENPD EVtUMPqU0apr60k39L37ZzXRPznZErk7bEJC2vP4u1pTC+agaufRhv7sPK1D1MaG0kRl Pdjw== X-Gm-Message-State: AGi0PuZTp+Z1dSHT8id1yh5N/FyGvW/RsqQJzkG0EknuIe2Xbt8xH81x Q+6l+FwXNyfWe0EGc4IOZROLe7dmH92MH3pPPpw= X-Google-Smtp-Source: APiQypIeZzG9DPanYwSPdyw213Pu7yjQwzMZT/dCebqkyQ/PUaTpQvQG6/2/5JPPD8B7wLLbeLvBKxzMk3wG9WmE6B8= X-Received: by 2002:aca:57d6:: with SMTP id l205mr7304295oib.20.1587743825638; Fri, 24 Apr 2020 08:57:05 -0700 (PDT) MIME-Version: 1.0 References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> In-Reply-To: From: chris - Date: Fri, 24 Apr 2020 11:56:54 -0400 Message-ID: To: Hannes Tschofenig Cc: Achim Kraus , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b8bb5205a40b6a20" Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 15:57:13 -0000 --000000000000b8bb5205a40b6a20 Content-Type: text/plain; charset="UTF-8" Hi all, > 1. Generic question: Should the construction of the additional data be > dependent on what is transmitted over the wire or should it be based > on a "pseudo header"? DTLS 1.2 uses a pseudo header and DTLS 1.3 the > data transmitted over the wire in the additional data calculation. I'd like to point to some related work that could shed light on this question. The decision for TLS 1.3 was to authenticate all data that is written to the wire, as this allows for proving the record layer secure [1] in a strong model for secure channels [2]. However, the formal models of [1,2] assume reliable transport (i.e., TCP): failure to deliver packets in order is deemed an attack. Therefore, the definitions would need to be changed in order to account for the case of DTLS. (I'm not sure if this has been studied.) My hunch is that the same design pattern (i.e., "authenticate everything on the wire") would be called for, but I've not seen formal evidence either way. > 2. Specific question: Should the CID be included in the additional data > calculation, particularly for the case where it is only implicitly > sent? Asked differently, are there attacks possible? Unfortunately I'm unfamiliar with the specific problem at hand, as I've not been following DTLS' development. (I'm in the middle of writing my thesis.) That said, I don't see a problem with having the AAD include *both* the record heard *and* something else, like the CID. And it may very well prevent an attack. Chris P. [1] https://eprint.iacr.org/2018/634.pdf [2] https://eprint.iacr.org/2017/1191.pdf --000000000000b8bb5205a40b6a20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,


>=C2=A0 1. Generic question: Should the construction of the additional d= ata be
>=C2=A0 =C2=A0 =C2=A0dependent on what is transmitted over the wire or s= hould it be based
>=C2=A0 =C2=A0 =C2=A0on a "pseudo header"? DTLS 1.2 uses a pse= udo header and DTLS 1.3 the
>=C2=A0 =C2=A0 =C2=A0data transmitted over the wire in the additional da= ta calculation.

I'd like to point to some rela= ted work that could shed light on this question. The decision for TLS 1.3 w= as to authenticate all data that is written to the wire, as this allows for= proving the record layer secure [1] in a strong model for secure channels = [2]. However, the formal models of [1,2] assume reliable transport (i.e., T= CP): failure to deliver packets in order is deemed an attack. Therefore, th= e definitions would need to be changed in order to account for the case of = DTLS. (I'm not sure if this has been studied.) My hunch is that the sam= e design pattern (i.e., "authenticate everything on the wire") wo= uld be called for, but I've not seen formal evidence either way.


>=C2=A0 2. Specific question: Should the CID be included in the addition= al data
>=C2=A0 =C2=A0 =C2=A0calculation, particularly for the case where it is = only implicitly
>=C2=A0 =C2=A0 =C2=A0sent? Asked differently, are there attacks possible= ?

Unfortunately I'm unfamiliar with the specif= ic problem at hand, as I've not been following DTLS' development. (= I'm in the middle of writing my thesis.) That said, I don't see a p= roblem with having the AAD include *both* the record heard=C2=A0 *and*=C2= =A0 something else, like the CID. And it may very well prevent an attack.


Chris P.

[2] https://e= print.iacr.org/2017/1191.pdf
--000000000000b8bb5205a40b6a20-- From nobody Fri Apr 24 09:20:00 2020 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 083083A0D68 for ; Fri, 24 Apr 2020 09:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, 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=uZO4OtVt; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=uZO4OtVt 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 S0VYwLNxJmBu for ; Fri, 24 Apr 2020 09:19:56 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2070.outbound.protection.outlook.com [40.107.21.70]) (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 542703A0B66 for ; Fri, 24 Apr 2020 09:19:55 -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=Snxf1ekIl0C3FCN3IqJbV3kv7tGPsZMGr48cHPZ7qBc=; b=uZO4OtVtxjr4/W0nXnpOyVTIHHkMw++N2nFhRUUaZTyRQIzmW2+ErNTwARMYvEvOfG7E/Cv4p3ZyB6NND4ouNLi/HO8T0laRfBuuKxvFVqFtQbGaFoRltlWrPA+Gpqz3bAzyStGTFdgTkjPxLqQt3roTklOQi0RLVUab2V/yYD4= Received: from DBBPR09CA0011.eurprd09.prod.outlook.com (2603:10a6:10:c0::23) by DBBPR08MB4235.eurprd08.prod.outlook.com (2603:10a6:10:c2::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Fri, 24 Apr 2020 16:19:53 +0000 Received: from DB5EUR03FT061.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:c0:cafe::33) by DBBPR09CA0011.outlook.office365.com (2603:10a6:10:c0::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Fri, 24 Apr 2020 16:19:53 +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 DB5EUR03FT061.mail.protection.outlook.com (10.152.21.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Fri, 24 Apr 2020 16:19:53 +0000 Received: ("Tessian outbound cbb03e3a1db0:v53"); Fri, 24 Apr 2020 16:19:53 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 070a5bb5797de6ac X-CR-MTA-TID: 64aa7808 Received: from b91e996faadf.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id A88BFC95-1AE9-4968-87DC-7759A8CE6747.1; Fri, 24 Apr 2020 16:19:48 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b91e996faadf.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 24 Apr 2020 16:19:48 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fXjNMvJdasBYe+VHIF/wUXDaCEwDh+Agwh2aL4+wip68/+Q5yw0FdiwJb4Y6FwF+LOz8IikDOUaNQQgrOHVg7IFSvMhcew9SGbmO9JNOBeply8gDP4QKd+o+DrkgW16BUrwRi5fexQUkAnY2uYxJcXkKs56UjjKnU5IXYdUNJIyR0+SBC0A12pmW7KzBYq1cgtLEkOy4cpOyXvAiZyOufGbDqRn3YmO912tsisWliDCzfiqVwibSES0n8ULxzzJNXuzj9NLPp3P099YsSpnccGhdAU1LSQAxoW4iPjyPa8DkqharRaWLC5RLEbRqmmHp6ICjzpIhmPiY+2dBNRANKA== 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=Snxf1ekIl0C3FCN3IqJbV3kv7tGPsZMGr48cHPZ7qBc=; b=hgCWjwfTEWTWTbQUioutoWMLi1upOY/Jn/t55MmU0kXIE6+IPkQLGOA3JhGu4IngKJf5DQ1DY45fAeFsazlEDXSTSoCvW8lGzgoJUy7whlhzA9qzrwWLdCzOicRlxVLL7UNBUXDSVl+m11nysdRDAqCt7iwn3WL9ExQBugLtx4AbHGWqO9qg2L2+KDJoE0EWbmNpc7WIJnOlgpjCu0fmuM0hrUBD8/FiyWDyrYhZpnjr6SHYBAw2N6jKBMImTCsjHsJWLfBLWtF4BvyGo/EjGziNJ6CxB982zGMgoBVfSAVZCaYO/+8bsUlrAiR1dpB2GLID04QEkmzZGpMjP0HR0Q== 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=Snxf1ekIl0C3FCN3IqJbV3kv7tGPsZMGr48cHPZ7qBc=; b=uZO4OtVtxjr4/W0nXnpOyVTIHHkMw++N2nFhRUUaZTyRQIzmW2+ErNTwARMYvEvOfG7E/Cv4p3ZyB6NND4ouNLi/HO8T0laRfBuuKxvFVqFtQbGaFoRltlWrPA+Gpqz3bAzyStGTFdgTkjPxLqQt3roTklOQi0RLVUab2V/yYD4= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6PR08MB3367.eurprd08.prod.outlook.com (2603:10a6:20b:44::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2921.29; Fri, 24 Apr 2020 16:19:46 +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.2937.020; Fri, 24 Apr 2020 16:19:46 +0000 From: Hanno Becker To: chris - , Hannes Tschofenig CC: "tls@ietf.org" Thread-Topic: [TLS] Choice of Additional Data Computation Thread-Index: AdYaKASVCp3JPFQuSaOSMkwtz/VZZwAEUEsAAAN7oaAAAnFQAAAASY9C Date: Fri, 24 Apr 2020 16:19:46 +0000 Message-ID: References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> , In-Reply-To: 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: 4616cf9d-1135-4a21-7065-08d7e86b5222 x-ms-traffictypediagnostic: AM6PR08MB3367:|AM6PR08MB3367:|DBBPR08MB4235: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 03838E948C 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)(346002)(39860400002)(376002)(366004)(136003)(396003)(8676002)(86362001)(110136005)(66556008)(19627405001)(76116006)(26005)(66446008)(6506007)(6636002)(316002)(81156014)(66476007)(5660300002)(33656002)(64756008)(186003)(66946007)(53546011)(9686003)(71200400001)(2906002)(7696005)(52536014)(478600001)(8936002)(4326008)(55016002)(966005); 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: LXR5lbAaVnvXo86s8AdvLy3bUaETnCWHAXPJXqnRekfNCYtJZavuAKaYD0khX81LDoZ27LjIUgEutPvGadi6OjYyGcC09YLXvMaeMd7I8+4obNyRp8WED1Y+faYvB+oXNSWDyH56lu8DJZsmBWoS3RPaOzlatKiHiWb58RaksZ6ZBha4RBpnLNHUwgoOVh+W7JWzIe232KAx/pdmHQN3Yrm0Na/QQEFHxp7jh6QgE+K+92s9sbgP7wed4qdHC2OUal8EIv8PtwdOfCD937zrX9U9KjhpG8umuVaIUZOkdP3S4RGPfkiLCrt+D7CZ+4vVPJt98XjU47ZXExsnEKn9bTuqP6XvcLbZyGa0wA0f4slcKXp48aBvpUw8L2kOcj97e4Ylbs9+yxO1bwbHqjYTOAzD5uYPHWw/XacdL2KPuXIPl59qitNcJgvFAGwXBt1CSj13jpX1gb+A1tvEHxHPyQpkFPP1vFiElCIiLKCkT141qqZdPIzxI2dVIL0ptd+JqAujFS1Mcyj2UYgbknW4cg== x-ms-exchange-antispam-messagedata: vozWACHW9In3EX5pdIWq1uKT5Sq6BooPrPDyYKilYIbQDcvs/JvlCNsJ9895I/xIuNztp2np31wKOzOnw0c+P2HMlgYCXKJEcWai+g+B439DbrDV1Rju9gp5FJxbr1xBQZ8A3FjC6Kza/FIJsiDsvQ== Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3318B6ABD411C8C476C3D10B9BD00AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3367 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT061.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)(376002)(346002)(136003)(39860400002)(396003)(46966005)(6506007)(7696005)(82310400002)(55016002)(9686003)(86362001)(8936002)(33656002)(2906002)(186003)(110136005)(336012)(26005)(5660300002)(316002)(70586007)(6636002)(19627405001)(53546011)(81166007)(356005)(966005)(82740400003)(8676002)(4326008)(70206006)(47076004)(478600001)(81156014)(52536014); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: b00aab6e-22be-4479-ad66-08d7e86b4df4 X-Forefront-PRVS: 03838E948C X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IYgZe5/oClG2xaQ8I8dnBIcr9xf2EG91RstpNwyu2AitJDo0ZzBYDyBX3rzpEJatcALHKZuQWVgaeMU29aqIok61ZI75aWsob2cV3dCnT0cVtcU0IWsvDle0QfLI3c+DEBIkPSn22ME128Ja6kWeAvMURPJXLw8zw68w1PBB1r/IxHGVmy1zxjvn9MX+YCWJkJYowVLgookcyGvCBiUFMPRLxAPaOMRFDZTKWdFnnU0bUsua/7evY2EKMwutIP4U3+bK1tblSBaa0J/p27sF4OKSswWVLW5Vz3SiBLDCXA9Z0wiSfdOs4HKhA9d21Vv9114/ipFQWQayNZqt/PPdMSUExL0zGEvagFo4J9hraNk7yF3CE6h4FKyEhjAj+m3DTu22MGu7iTTRrRmMnAWoOUtFsnRLmql4vQoVsOdEAyL+KbMpbDlDj2WNrOJAyEWHWgklaBIoZbX74nodv/epH9Veuh29p/vInwiIWcpM/eoY9dfAu1QF3vGbkoeRL9gNuUfahnnBxXmXmPlBJMAIlqKvd3ZB7SiKJ533oIJUb1hm1/8uRArOt17XvMVaRdPchdP/jUe+N123jQz0M3YhmA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2020 16:19:53.3278 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4616cf9d-1135-4a21-7065-08d7e86b5222 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: DBBPR08MB4235 Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 16:19:59 -0000 --_000_AM6PR08MB3318B6ABD411C8C476C3D10B9BD00AM6PR08MB3318eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Chris, Just a note on the comparison with TLS 1.3. > I'd like to point to some related work that could shed light on this ques= tion. > The decision for TLS 1.3 was to authenticate all data that is written to = the wire, It doesn't seem straightforward to extrapolate from that case since the 'ps= eudo-header' and on-the-wire header are the same here, as TLS 1.3 doesn't have any heade= r data which is shortened or omitted on the wire. In DTLS 1.3, in contrast, v= arious fields can be dropped or shortened, such as the length, sequence number, CI= D. Best, Hanno ________________________________ From: TLS on behalf of chris - Sent: Friday, April 24, 2020 4:56 PM To: Hannes Tschofenig Cc: tls@ietf.org Subject: Re: [TLS] Choice of Additional Data Computation Hi all, > 1. Generic question: Should the construction of the additional data be > dependent on what is transmitted over the wire or should it be based > on a "pseudo header"? DTLS 1.2 uses a pseudo header and DTLS 1.3 the > data transmitted over the wire in the additional data calculation. I'd like to point to some related work that could shed light on this questi= on. The decision for TLS 1.3 was to authenticate all data that is written t= o the wire, as this allows for proving the record layer secure [1] in a str= ong model for secure channels [2]. However, the formal models of [1,2] assu= me reliable transport (i.e., TCP): failure to deliver packets in order is d= eemed an attack. Therefore, the definitions would need to be changed in ord= er to account for the case of DTLS. (I'm not sure if this has been studied.= ) My hunch is that the same design pattern (i.e., "authenticate everything = on the wire") would be called for, but I've not seen formal evidence either= way. > 2. Specific question: Should the CID be included in the additional data > calculation, particularly for the case where it is only implicitly > sent? Asked differently, are there attacks possible? Unfortunately I'm unfamiliar with the specific problem at hand, as I've not= been following DTLS' development. (I'm in the middle of writing my thesis.= ) That said, I don't see a problem with having the AAD include *both* the r= ecord heard *and* something else, like the CID. And it may very well prev= ent an attack. Chris P. [1] https://eprint.iacr.org/2018/634.pdf [2] https://eprint.iacr.org/2017/1191.pdf 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_AM6PR08MB3318B6ABD411C8C476C3D10B9BD00AM6PR08MB3318eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Chris,

Just a note on the comparison with TLS 1.3.

> I'd like to point to some related work that could shed light on this question.=  
> The decision for TLS 1.3 was to authenticate all data that is written to t= he wire,

It= doesn't seem straightforward to extrapolate from that case since the 'pseu= do-header' 
an= d on-the-wire header ar= e the same here, as TLS 1.3 doesn't have any header
data which is shortened or= omitted on the wire. In DTLS 1.3, in contrast, various
fields can be dropped or s= hortened, such as the length, sequence number, CID.

Best,
Hanno
From: TLS <tls-bounces@i= etf.org> on behalf of chris - <chrispatton@gmail.com>
Sent: Friday, April 24, 2020 4:56 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] Choice of Additional Data Computation
 
Hi all,


>  1. Generic question: Should the construction of the additio= nal data be
>     dependent on what is transmitted over the wire or s= hould it be based
>     on a "pseudo header"? DTLS 1.2 uses a pse= udo header and DTLS 1.3 the
>     data transmitted over the wire in the additional da= ta calculation.

I'd like to point to some related work that could shed light on this q= uestion. The decision for TLS 1.3 was to authenticate all data that is writ= ten to the wire, as this allows for proving the record layer secure [1] in = a strong model for secure channels [2]. However, the formal models of [1,2] assume reliable transport (i.e., = TCP): failure to deliver packets in order is deemed an attack. Therefore, t= he definitions would need to be changed in order to account for the case of= DTLS. (I'm not sure if this has been studied.) My hunch is that the same design pattern (i.e., "authe= nticate everything on the wire") would be called for, but I've not see= n formal evidence either way.


>  2. Specific question: Should the CID be included in the add= itional data
>     calculation, particularly for the case where it is = only implicitly
>     sent? Asked differently, are there attacks possible= ?

Unfortunately I'm unfamiliar with the specific problem at hand, as I'v= e not been following DTLS' development. (I'm in the middle of writing my th= esis.) That said, I don't see a problem with having the AAD include *both* = the record heard  *and*  something else, like the CID. And it may very well prevent an attack.


Chris P.
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_AM6PR08MB3318B6ABD411C8C476C3D10B9BD00AM6PR08MB3318eurp_-- From nobody Fri Apr 24 09:44:53 2020 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 DAD863A0EED for ; Fri, 24 Apr 2020 09:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 Tlul16YvUKGr for ; Fri, 24 Apr 2020 09:44:43 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8034B3A0F60 for ; Fri, 24 Apr 2020 09:44:42 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id y4so10627976ljn.7 for ; Fri, 24 Apr 2020 09:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NVLSC6Syv4v/qvuKkC/2T/cV1cvanei0DVvychIqRxc=; b=0+k09gVeHiCqrxHbvWf4qwhNHcnPNxv2xDB2DM2s+5T5fOTD69zWb3dEoEKPHIqRYe F6yB/ksUTSYN46Vmj6AtHBH3Zcpu7xETxRNIm/NJ7h2l22S+74wBWaGS0x34BotzJwzG dHKQKRNOmgR8UNoT/QN/4/PaljmOPNwo1PMD1CoGgRDEjwoLwvE6+dpVgirA4KLPylJd mjADCTxyzaH/km8BhujbcSxwMGenztB8uXxI829ZbR/zqSvsPrOW5Qd9svOhRYFKeE9F QbJPGatJ6K1WdPcLoshPpdVSTRwVFFZhgyElBi3znVQLgrMVTKNSrUqE1FymIoOLHtP3 avdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NVLSC6Syv4v/qvuKkC/2T/cV1cvanei0DVvychIqRxc=; b=Fr+TA+p/9lpsL1c1/eGdSkj18ONdVuW76cH/xom9nkFxsn31vpNUCjAnc0WPv57sxp tjI/wL6Yl8eL1urJ/uflMbxCshsLwXAaSN1CLzj/e+aSDHf0vtHZ7tYPXzBsi8NQWPDz 1sVP+vHQ6MiWqiUFy60+2lGBvFqkt+0X0pnbsrYcnMvIy+/iKUm6M9SbK+CbVok7A3KQ XniegRSy3XAroI4txSJTUUgcOayAAZiLAiii0lCNHf8rLesjWbbNTb4jwlc2ebLdYC15 Q9nmTmivbPBcgMDVFL7x6P4OjaMuBwTg0nx+YT+C4rstOJT2g8IgBaFZLvgpWQg9a1aK SFqw== X-Gm-Message-State: AGi0PuaSvsPFKfXw1eKsLZRyLIM1rSiL1Asw/WUpE1vfhCpTRYlouAck COBUtRT5Hi09N51jxGziLajm3Cqe4KBYCfvel0+4PA== X-Google-Smtp-Source: APiQypICnWzXMAzFvy3+4rnx3gxW47Dm5K2Jz3NhgI17tMhfZmoSSmQXmfqNKB4OTxm9C34nA7pO2NHn+GCDQAl+F7w= X-Received: by 2002:a2e:b0ee:: with SMTP id h14mr6686876ljl.35.1587746680769; Fri, 24 Apr 2020 09:44:40 -0700 (PDT) MIME-Version: 1.0 References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> In-Reply-To: From: Eric Rescorla Date: Fri, 24 Apr 2020 09:44:04 -0700 Message-ID: To: Hanno Becker Cc: chris - , Hannes Tschofenig , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e6a40c05a40c14cd" Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 16:44:52 -0000 --000000000000e6a40c05a40c14cd Content-Type: text/plain; charset="UTF-8" On Fri, Apr 24, 2020 at 9:20 AM Hanno Becker wrote: > Hi Chris, > > Just a note on the comparison with TLS 1.3. > > > I'd like to point to some related work that could shed light on this > question. > > The decision for TLS 1.3 was to authenticate all data that is written to > the wire, > > It doesn't seem straightforward to extrapolate from that case since the > 'pseudo-header' > and on-the-wire header are the same here, as TLS 1.3 doesn't have any > header > data which is shortened or omitted on the wire. In DTLS 1.3, in contrast, > various > fields can be dropped or shortened, such as the length, sequence number, > CID. > I'm not sure if it's straightforward, but I would note that in TLS 1.3, we did *implicitly* authenticate the length because AEAD provides that, but nevertheless one of Chris's recommendations was to include it in the AAD. -Ekr > Best, > Hanno > ------------------------------ > *From:* TLS on behalf of chris - < > chrispatton@gmail.com> > *Sent:* Friday, April 24, 2020 4:56 PM > *To:* Hannes Tschofenig > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] Choice of Additional Data Computation > > Hi all, > > > > 1. Generic question: Should the construction of the additional data be > > dependent on what is transmitted over the wire or should it be based > > on a "pseudo header"? DTLS 1.2 uses a pseudo header and DTLS 1.3 the > > data transmitted over the wire in the additional data calculation. > > I'd like to point to some related work that could shed light on this > question. The decision for TLS 1.3 was to authenticate all data that is > written to the wire, as this allows for proving the record layer secure [1] > in a strong model for secure channels [2]. However, the formal models of > [1,2] assume reliable transport (i.e., TCP): failure to deliver packets in > order is deemed an attack. Therefore, the definitions would need to be > changed in order to account for the case of DTLS. (I'm not sure if this has > been studied.) My hunch is that the same design pattern (i.e., > "authenticate everything on the wire") would be called for, but I've not > seen formal evidence either way. > > > > 2. Specific question: Should the CID be included in the additional data > > calculation, particularly for the case where it is only implicitly > > sent? Asked differently, are there attacks possible? > > Unfortunately I'm unfamiliar with the specific problem at hand, as I've > not been following DTLS' development. (I'm in the middle of writing my > thesis.) That said, I don't see a problem with having the AAD include > *both* the record heard *and* something else, like the CID. And it may > very well prevent an attack. > > > Chris P. > > [1] https://eprint.iacr.org/2018/634.pdf > [2] https://eprint.iacr.org/2017/1191.pdf > 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 > --000000000000e6a40c05a40c14cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 24, 2020 at 9:20 AM Hanno= Becker <Hanno.Becker@arm.com> wrote:
Hi Chris,

Just a note on the comparison with TLS 1.3.

>=C2=A0I'd like to point to some related work that could shed light on this question.= =C2=A0
> The decision for TLS 1.3 was to authenticate all data that is written to t= he wire,

It doesn't = seem straightforward to extrapolate from that case since the 'pseudo-he= ader'=C2=A0
and on-the-wire= header=C2=A0are the same here= , as TLS 1.3 doesn't have any header
data which is shortened or omitted on t= he wire. In DTLS 1.3, in contrast, various
fields can be dropped or shortened, suc= h as the length, sequence number, CID.



Best,
Hanno
Fro= m: TLS <tl= s-bounces@ietf.org> on behalf of chris - <chrispatton@gmail.com>
Sent: Friday, April 24, 2020 4:56 PM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: tls@ietf.org <tls@ietf.org&g= t;
Subject: Re: [TLS] Choice of Additional Data Computation
=C2=A0
Hi all,


>=C2=A0 1. Generic question: Should the construction of the additio= nal data be
>=C2=A0 =C2=A0 =C2=A0dependent on what is transmitted over the wire or s= hould it be based
>=C2=A0 =C2=A0 =C2=A0on a "pseudo header"? DTLS 1.2 uses a pse= udo header and DTLS 1.3 the
>=C2=A0 =C2=A0 =C2=A0data transmitted over the wire in the additional da= ta calculation.

I'd like to point to some related work that could shed light on th= is question. The decision for TLS 1.3 was to authenticate all data that is = written to the wire, as this allows for proving the record layer secure [1]= in a strong model for secure channels [2]. However, the formal models of [1,2] assume reliable transport (i.e., = TCP): failure to deliver packets in order is deemed an attack. Therefore, t= he definitions would need to be changed in order to account for the case of= DTLS. (I'm not sure if this has been studied.) My hunch is that the same design pattern (i.e., "authe= nticate everything on the wire") would be called for, but I've not= seen formal evidence either way.


>=C2=A0 2. Specific question: Should the CID be included in the add= itional data
>=C2=A0 =C2=A0 =C2=A0calculation, particularly for the case where it is = only implicitly
>=C2=A0 =C2=A0 =C2=A0sent? Asked differently, are there attacks possible= ?

Unfortunately I'm unfamiliar with the specific problem at hand, as= I've not been following DTLS' development. (I'm in the middle = of writing my thesis.) That said, I don't see a problem with having the= AAD include *both* the record heard=C2=A0 *and*=C2=A0 something else, like the CID. And it may very well prevent an attack.


Chris P.
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000e6a40c05a40c14cd-- From nobody Fri Apr 24 10:57:20 2020 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 92D373A10D3 for ; Fri, 24 Apr 2020 10:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 pT4sssiN6UVF for ; Fri, 24 Apr 2020 10:57:15 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9E13A0E61 for ; Fri, 24 Apr 2020 10:57:15 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id j4so13888721otr.11 for ; Fri, 24 Apr 2020 10:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sBHkNTox1wwJ4IZzgbwJaeF+zNd+iWaWMXZPqmHHK1k=; b=ja5oAUFLadGxZWP0oIvMkERFf1ngfIezS9kZBhSzTCFZ6GKQmc6zGVOe7JX0Ke/Gyp P99sIsbolZU3TXp3v9KFAs1l79u6h/bpSAO4bu8FiVoZEhHTsONbN6fZWpZ9zljBRKM2 wrHul0vkZADpYy8skYRd0c200a6OKcGHlvFvJXCkVKLD6aL9+lOl1jBeYwWzwfecrVLp AXkBSQnEIjLsuW0DS+OnOXqePlTt90npjAhNEKVn18xG/w/HUWi9Bb+oI6eqYAlI4M34 BwpHNJMEthpI3fwmKI39w/fNfHEngkamzmSsPkZywVoWZdIJMXqAbd7LOsqX0NMeW13R OjjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sBHkNTox1wwJ4IZzgbwJaeF+zNd+iWaWMXZPqmHHK1k=; b=VivSfCaWGCqISc/eh1cXeOrL8HMHm6Pqxk/BY9xR7J8XI0NvD/BcsDuxAkRt0rhhAd +HBN1VAh9vMU0THM208Dyde9kQeoC+gOLwYUY0SlfzEnWIiZQf0YTry1lroyMtxMHLZL JUvDLjAJv38qLv1I1tXyhJT8vMpZpLVWEv+EyBVRLeLTJMEzGVuplwvP4SK8UEpgpkAe RDI58MuOxqKHrWhqWy9ct4h7LRhq/DCSYQuxyF7pUo5NlLfnHmHam+MEwEOVzu+UzEfH G7iHwls+cbn1XxXvJWPrKfyT+ZcU6afxaBnm/1BKAUMuLMm2LnaQzWsKsAxA2q+LRA/m bZ8Q== X-Gm-Message-State: AGi0Pubr+nZE3VxucbgCqZenmnxiJ/E4zJrKkcqCdoS8HMxClUfD6xt9 SN1skkyxM+sPtUGyjZkxrR22wYmCbICt33QpZXM= X-Google-Smtp-Source: APiQypKU7KixYMl6d2KZfOeii5CojnWxSYnFbI3dBr1QQvhqpXcHdE5hEKW2MyoTec54KQ/yqaxLd5uu59LIkpDq2Tg= X-Received: by 2002:aca:b2d6:: with SMTP id b205mr8136918oif.137.1587751034382; Fri, 24 Apr 2020 10:57:14 -0700 (PDT) MIME-Version: 1.0 References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> In-Reply-To: From: chris - Date: Fri, 24 Apr 2020 13:57:03 -0400 Message-ID: To: Eric Rescorla Cc: Hanno Becker , Hannes Tschofenig , "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000065760d05a40d18b3" Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 17:57:18 -0000 --00000000000065760d05a40d18b3 Content-Type: text/plain; charset="UTF-8" > It doesn't seem straightforward to extrapolate from that case since the > 'pseudo-header' > and on-the-wire header are the same here, as TLS 1.3 doesn't have any > header > data which is shortened or omitted on the wire. In DTLS 1.3, in contrast, > various > fields can be dropped or shortened, such as the length, sequence number, > CID. > It's certainly true that we can't extrapolate the security of DTLS from the existing proof for TLS. In the first place, the threat model is different because in DTLS we need to tolerate dropped/out-of-order packets. Nevertheless, I think the general principle of "authenticate all the bits" is the right way to go here, unless there's a compelling reason not to. In the case of TLS 1.3, authenticating the entire header (including the length, opaque type, and legacy record version) allowed us to effectively ignore most of the header details in the security proof [1]: all we cared about is that the header correctly encodes the length of the next ciphertext to decrypt. We might be able to provide a similar argument for DTLS 1.3. In particular, I'm betting that it doesn't matter what the contents of the header are or how long it is, so long as (a) the entire header is part of the AAD and (b) it correctly encodes the length of the next ciphertext. I might be missing something, however. In any case, new definitions are needed (if they don't already exist) and so too a fresh proof. Chris P. [1] https://eprint.iacr.org/2018/634.pdf --00000000000065760d05a40d18b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It doesn't seem straightforward to extrapolate from th= at case since the 'pseudo-header'=C2=A0
and on-the-wire= header=C2=A0are the same here= , as TLS 1.3 doesn't have any header
data which is shortened or omitted on t= he wire. In DTLS 1.3, in contrast, various
fields can be dropped or shortened, suc= h as the length, sequence number, CID.
=
It's certainly true that we can't extrapolate the se= curity of DTLS from the existing proof for TLS. In the first place, the thr= eat model is different because in DTLS we need to tolerate dropped/out-of-o= rder packets. Nevertheless, I think the general principle of "authenti= cate all the bits" is the right way to go here, unless there's a c= ompelling reason not to.

In the case of TLS 1.3, a= uthenticating the entire header (including the length, opaque type, and leg= acy record version) allowed us to effectively ignore most of the header det= ails in the security proof [1]: all we cared about is that the header corre= ctly encodes the length of the next ciphertext to decrypt. We might be able= to provide a similar argument for DTLS 1.3. In particular, I'm betting= that it doesn't matter what the contents of the header are or how long= it is, so long as (a) the entire header is part of the AAD and (b) it corr= ectly encodes the length of the next ciphertext.

I= might be missing something, however. In any case, new definitions are need= ed (if they don't already exist) and so too a fresh proof.
Chris P.

--00000000000065760d05a40d18b3-- From nobody Fri Apr 24 11:17:51 2020 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 CF0E33A118C for ; Fri, 24 Apr 2020 11:17:47 -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=lyINHHhx; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=lyINHHhx 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 dc6pilyIxSL8 for ; Fri, 24 Apr 2020 11:17:45 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80089.outbound.protection.outlook.com [40.107.8.89]) (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 A47FD3A107F for ; Fri, 24 Apr 2020 11:17:44 -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=mpNkzWggRhyZnv1THxKPetBonhH/pJV14Dv9s71EUlA=; b=lyINHHhxJUFtqYDQyD/Nevp6tSCnVGcUp91Wxd3NecCIQeB/qc+huD4MT0iXMK5tnVDqUXGbUCulY8NQ0dtQwSrKHQTPq0+RLVKhcmRqP28rDOKoh76hkTcfNJA/8WQ0y0gLcItDtAoX4j5mXaU4Yz22wBFvTrQG1FwcehybVMw= Received: from AM0PR06CA0075.eurprd06.prod.outlook.com (2603:10a6:208:fa::16) by AM0PR08MB3842.eurprd08.prod.outlook.com (2603:10a6:208:109::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Fri, 24 Apr 2020 18:17:41 +0000 Received: from AM5EUR03FT032.eop-EUR03.prod.protection.outlook.com (2603:10a6:208:fa:cafe::fc) by AM0PR06CA0075.outlook.office365.com (2603:10a6:208:fa::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Fri, 24 Apr 2020 18:17:41 +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 AM5EUR03FT032.mail.protection.outlook.com (10.152.16.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Fri, 24 Apr 2020 18:17:41 +0000 Received: ("Tessian outbound 11763d234d54:v54"); Fri, 24 Apr 2020 18:17:40 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 5a103f6a15095cb5 X-CR-MTA-TID: 64aa7808 Received: from 1ce6c0f18745.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id C55E4D46-7455-4B53-80FD-067F373E6811.1; Fri, 24 Apr 2020 18:17:35 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 1ce6c0f18745.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 24 Apr 2020 18:17:35 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mEvT1L2CcQjFEQcC+srcUKs0oQAxW42n+aVfa7Nljkt1EXk6eVC457N04ACeqe4te0sM/7kuH1WHM2JTf50e4SY7roWTxJcrkXGdf9ZwcaF45q1cnTUBE+DdBq4/t/P+b9m9y/imzoFmwt4oXWOtwYOJ1NUdbdp0xRzt7RTzJC0PjWnR0qUG5B0Qs3Em7Nt3d7eGmA4gmgc1IHmQKd/j43/uEdzvV1urYlnp+em28KqfrZIAWcA0slbx/hlTx2QrOGCP1PVBxZdC8o2a+yciwHsShDoJqoHbUIY0kTmlRI2GucBFs/LZkybNES2MXWITOAeyXOjIXE4GbGH3M5Xm4A== 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=mpNkzWggRhyZnv1THxKPetBonhH/pJV14Dv9s71EUlA=; b=m4q0INC6z0fjrV2i5/BHyQTQgEtViwGd6k4ABETo5MMZ48du/Hi/7kXgL9DUZzbiPphs6lCRwAXmBBDBbw8gFDnc3sUhmpxxCQwzI+gH2tMz+MDHs/KJ4wk/m+GcTk0+9Y3y3xZtxT2fRqj/0cpZpT089nLyxvRGsq6N6BbjVBX4z3f/MtpfUNAua81qzD3LpWs4cB3rfAixVbOlDSfWP1sF09Cgq09VoCiXuADznMYlLI6+Dee9NPhyMB/dhk2fmN50XBgdW3FKo2o8TZcTEbkpxmZ5Yk8uQnbTdv24hzBUIGDPbmfo1/8G1Yq34zJ08QErvQCGDcoXzFhZS1VA0w== 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=mpNkzWggRhyZnv1THxKPetBonhH/pJV14Dv9s71EUlA=; b=lyINHHhxJUFtqYDQyD/Nevp6tSCnVGcUp91Wxd3NecCIQeB/qc+huD4MT0iXMK5tnVDqUXGbUCulY8NQ0dtQwSrKHQTPq0+RLVKhcmRqP28rDOKoh76hkTcfNJA/8WQ0y0gLcItDtAoX4j5mXaU4Yz22wBFvTrQG1FwcehybVMw= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6PR08MB3957.eurprd08.prod.outlook.com (2603:10a6:20b:a2::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Fri, 24 Apr 2020 18:17:33 +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.2937.020; Fri, 24 Apr 2020 18:17:33 +0000 From: Hanno Becker To: chris - , Eric Rescorla CC: Hannes Tschofenig , "tls@ietf.org" Thread-Topic: [TLS] Choice of Additional Data Computation Thread-Index: AdYaKASVCp3JPFQuSaOSMkwtz/VZZwAEUEsAAAN7oaAAAnFQAAAASY9CAAFcJQAAAoyFgAAAY+d9 Date: Fri, 24 Apr 2020 18:17:33 +0000 Message-ID: References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> , In-Reply-To: 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: 7d65bb5a-cbc7-419a-ac8d-08d7e87bc6d9 x-ms-traffictypediagnostic: AM6PR08MB3957:|AM6PR08MB3957:|AM0PR08MB3842: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 03838E948C 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:(4636009)(39860400002)(376002)(346002)(136003)(396003)(366004)(66476007)(64756008)(66556008)(66446008)(966005)(9686003)(478600001)(71200400001)(66946007)(33656002)(26005)(76116006)(55016002)(2906002)(4326008)(316002)(8936002)(7696005)(54906003)(186003)(86362001)(5660300002)(110136005)(53546011)(6506007)(81156014)(19627405001)(8676002)(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: NuJBULRsT2pJ2QL9l8unVrtKDB/X2KGjoh60NKq28zMV91ojocTlc8Ly07g3HWkLmZi58YdBHCaRwDRv5vVTCKWN6cTZMWhIuJMoPQgetXPveiZzLRBmon2p8baF3u/P2o2HfdmULyXf3EjFEu/qW3ntm8X+tWKUYlKkX2nxzWQEpxDX3m3UP/nf3sNvnA0WQH6tTYN8x/ADms5D28EI8I2dR2SQ79bEKtrLR6YgO6CbnZGs9cXuzjCAmt/4C3D7dORMd/1WOJs6xnwypDkon3zYaLxaozObjkl/HGhEaC7xf2JrpNLJN2QMDAQfzJyQ4n3eqmQsV+UsSHVU0aQarQDSTpH3fCNcOQRB9rgeITw68mv0K92bPaVHseTQ2MJn+L1vcymmob4ym9T+Gfnf9Z1Lh5QqEGBAYwhfqSXgcuFJKDjXeoiGRb9NpawIkMH0RPRA62I7J0wKPnK3CcIihUXej0Ma98GsYdENS7A0Au6IV6P/FoY4oC/IimlSSnvfsmuwNoQFpf3jC7vHa/X8tQ== x-ms-exchange-antispam-messagedata: +OliRY2ej0MrWYKKbV+DjlbARRNac/Dfj6BDYEdjW96RTMaBV2uR3MBlBVZF/9sZjy5lNgGwjXrBGUiV6A8LeZczrcCYhERnNIBR8aZTgN1weFz8TMvxh+8EzYPXPdXx7tPVCugkEQbwz3S1fkbejQ== Content-Type: multipart/alternative; boundary="_000_AM6PR08MB331862B6F143652F4B4C10EE9BD00AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3957 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT032.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:(4636009)(346002)(39860400002)(376002)(136003)(396003)(46966005)(36906005)(54906003)(5660300002)(9686003)(2906002)(26005)(70206006)(110136005)(86362001)(70586007)(19627405001)(52536014)(55016002)(33656002)(82740400003)(8676002)(7696005)(6506007)(81156014)(478600001)(82310400002)(316002)(356005)(81166007)(8936002)(336012)(47076004)(53546011)(966005)(186003)(4326008); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 340c29a0-4e2f-4091-c48e-08d7e87bc250 X-Forefront-PRVS: 03838E948C X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: xONE7/KTp0+st1mMRSy8SqPGLyZZiaOHKMaAq8abebnr+eTtKXieBcDf2IQpIlwv4LtTxw85KaQX2a5Zr2FmJZfxGJYUd7f9scJWjHmEAZMADhLLGoHYwH8A+VgNbsG3a06awZSLBWuJpQ3k8XKnQSigBEBE9JIA988nVbU7TYOf1vhFfyhtfDjKNWGK5GpskXLzQeZFRsJK7rXIGlG/JdiC3IaxdbBSB2V/WTmkK/jNNxJwldg4AJgOurtqu6bhZe4WzQWAC56pHnHqqBpF/5LK478fE9v+leNIf5dzplRIldGcEBZnYw7PmeU/6fNt3jrWiLH83BaCQlXZzgcUOMH1Lsf4BpyudUQWAv36EH8QnkUv8o+vwtKAw8QL68Bwjja2+DkZGvEz+mcdLRyxScG3zy1hAyQUdMvDVj8zzk8yiimLypqzab5fFPreJDmjjTbPXJgBfFVAiyhhXVTCTAzvCudWt0piMugUZzwA7ncEX5reV6F+JpGlDdZpw/MR3IWZ3JdKV31UexAyryBJpAt44oRTElRg+S+6oIsHgqtVC3ysdfZpIZhwSNtLGotDGq8vkcSaYmIPwSM0mPpJnQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2020 18:17:41.0230 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7d65bb5a-cbc7-419a-ac8d-08d7e87bc6d9 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: AM0PR08MB3842 Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 18:17:48 -0000 --_000_AM6PR08MB331862B6F143652F4B4C10EE9BD00AM6PR08MB3318eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Chris and Ekr, > I'm not sure if it's straightforward, but I would note that in TLS 1.3, w= e did *implicitly* authenticate the length because AEAD provides that, but = nevertheless one of Chris's recommendations was to include it in the AAD. I don't know if this recommendation still holds for DTLS (though Chris' las= t reply sounds like it), but DTLS 1.3 currently deviates from it: The length is explicitly= authenticated only for records using header formats which contain the length, while for the mo= st compressed header form omitting the length one relies on implicit length authentication via A= EAD. > In the case of TLS 1.3, authenticating the entire header (including the l= ength, opaque type, and legacy record version) allowed us to effectively ig= nore most of the header details in the security proof [1]: If the security analysis shall be agnostic of header details, then in the c= ase of DTLS 1.3 with its various header formats (https://tools.ietf.org/html/draft= -ietf-tls-dtls13-37#section-4), it sounds to me as if using a pseudo-header containing all header informati= on for AAD would fit better (?). Best, Hanno ________________________________ From: chris - Sent: Friday, April 24, 2020 6:57 PM To: Eric Rescorla Cc: Hanno Becker ; Hannes Tschofenig ; tls@ietf.org Subject: Re: [TLS] Choice of Additional Data Computation It doesn't seem straightforward to extrapolate from that case since the 'ps= eudo-header' and on-the-wire header are the same here, as TLS 1.3 doesn't have any heade= r data which is shortened or omitted on the wire. In DTLS 1.3, in contrast, v= arious fields can be dropped or shortened, such as the length, sequence number, CI= D. It's certainly true that we can't extrapolate the security of DTLS from the= existing proof for TLS. In the first place, the threat model is different = because in DTLS we need to tolerate dropped/out-of-order packets. Neverthel= ess, I think the general principle of "authenticate all the bits" is the ri= ght way to go here, unless there's a compelling reason not to. In the case of TLS 1.3, authenticating the entire header (including the len= gth, opaque type, and legacy record version) allowed us to effectively igno= re most of the header details in the security proof [1]: all we cared about= is that the header correctly encodes the length of the next ciphertext to = decrypt. We might be able to provide a similar argument for DTLS 1.3. In pa= rticular, I'm betting that it doesn't matter what the contents of the heade= r are or how long it is, so long as (a) the entire header is part of the AA= D and (b) it correctly encodes the length of the next ciphertext. I might be missing something, however. In any case, new definitions are nee= ded (if they don't already exist) and so too a fresh proof. Chris P. [1] https://eprint.iacr.org/2018/634.pdf 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_AM6PR08MB331862B6F143652F4B4C10EE9BD00AM6PR08MB3318eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Chris and Ekr,

> I'm not su= re if it's straightforward, but I would note that in TLS 1.3, we did *implicitly* aut= henticate the length because AEAD provides that, but nevertheless one of Ch= ris's recommendations was to include it in the AAD.

I don't know if this recommendation still holds for DTLS (though Chris' last reply sounds
like it), but DTLS 1.3 currently deviates from it: The length is explicitly authenticated only 
for records using header formats which con= tain the length, while for the most compressed header 
form omitting the length one relies on implicit length authentication via AEAD.

>&n= bsp;In the case of TLS 1.3, authenticating the entire header (including the lengt= h, opaque type, and legacy record version) allowed us to effectively ignore= most of the header details in the security proof [1]: 

If the= security analysis shall be agnostic of header details, then in the case of=  
DTLS 1= .3 with its various header formats (https://tools.ietf.o= rg/html/draft-ietf-tls-dtls13-37#section-4),
it sou= nds to me as if using a pseudo-header containing all header information for AAD would fit better (?).=

Best,
Hanno

From: chris - <chrispatt= on@gmail.com>
Sent: Friday, April 24, 2020 6:57 PM
To: Eric Rescorla <ekr@rtfm.com>
Cc: Hanno Becker <Hanno.Becker@arm.com>; Hannes Tschofenig <= ;Hannes.Tschofenig@arm.com>; tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] Choice of Additional Data Computation
 
It doesn't seem= straightforward to extrapolate from that case since the 'pseudo-header'&nb= sp;
and on-the-wire= header are the same here= , as TLS 1.3 doesn't have any header
data which is shortened or omitted on t= he wire. In DTLS 1.3, in contrast, various
fields can be dropped or shortened, suc= h as the length, sequence number, CID.

It's certainly true that we can't extrapolate the security of DTLS fro= m the existing proof for TLS. In the first place, the threat model is diffe= rent because in DTLS we need to tolerate dropped/out-of-order packets. Neve= rtheless, I think the general principle of "authenticate all the bits" is the right way to go here, unle= ss there's a compelling reason not to.

In the case of TLS 1.3, authenticating the entire header (including th= e length, opaque type, and legacy record version) allowed us to effectively= ignore most of the header details in the security proof [1]: all we cared = about is that the header correctly encodes the length of the next ciphertext to decrypt. We might be able to = provide a similar argument for DTLS 1.3. In particular, I'm betting that it= doesn't matter what the contents of the header are or how long it is, so l= ong as (a) the entire header is part of the AAD and (b) it correctly encodes the length of the next cipher= text.

I might be missing something, however. In any case, new definitions ar= e needed (if they don't already exist) and so too a fresh proof.

Chris P.

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_AM6PR08MB331862B6F143652F4B4C10EE9BD00AM6PR08MB3318eurp_-- From nobody Fri Apr 24 11:32:08 2020 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 4A7733A02BD for ; Fri, 24 Apr 2020 11:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 56n6mPtT9b87 for ; Fri, 24 Apr 2020 11:32:05 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8FAF3A0141 for ; Fri, 24 Apr 2020 11:32:05 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id w4so11371932ioc.6 for ; Fri, 24 Apr 2020 11:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aCZRJDMt4NMfD3u9NqeMiwadWCV87SVnW4+/JDUOgNI=; b=WHfZI/KxfHaRRCadVqjjSngyKRkz8oUhaZ3ANXHzQEhNiwH0Wd7Q445NOJrXfC/5fK NYqXL9bR5KvR4685Boz7lvCmN95EmQXSl5q3K8UxWkaRwH4dLaFMEQ9TZCqY2Tp9WGFO SFnTfM2froaz3B1BFd42uaow7CKQc6ZW+t58Tdl09+pJPthiLeYq1DFVvjNcetFvTsMk nRDuV0/WAtOaGcJKBO/lxNvaGjBHtfhakRFKbdJdvi7kX+3BzueowSDBeK7aeDcjbpTH M7X1k6Sex/DvnG0x7yrMM6wdiH5B68joMdRhMmCRNftmwi0JDZIVYVzCFCaq7eMqvBPI ebdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aCZRJDMt4NMfD3u9NqeMiwadWCV87SVnW4+/JDUOgNI=; b=jvANSvVhUsyHrB0wQoQ5b6Ra3cfijoFYbaPRg9mPwp5JtA7/c5zrz5LAtvi5Hm2e4j hGbERSMSO03c/VPG2AIWIxRRIM1cfFlt8/vjMLarFlz2otSiBqkz9yUvE5L8DZv+Ppk6 bTdOxcG2Yt8PllKoqDZ/wlbr7xUhwh55fFjAcm7eZ2OrOo+qreviUDl9EexY4io2dUBi 9K5HSSacC1NTYxPQReibM1/eQW8GoQ++TYvieZZa1b5xUCHtKDgdMTo+ECKtxfuHm4z3 8RRcEBODoenzciuIBj6s2QBbyqirkWPOj1AiFGPtx4u+gtv1EsVnYo/JSECgxSoVrSpv d8Tw== X-Gm-Message-State: AGi0PuZnSlQJmgf9z8cJV9/M3ISAPi99F5S5kTeO84WsOfB6330s7Ib6 4SXpI6X69bU//WpoUnfB4U5XauIzCPYGmLsVEZigd/5b X-Google-Smtp-Source: APiQypJ21vuNHwQiT+ym3RasgsAo05xvZO+xWqPwen3PKoab8mnWMCiDxtQ4eLPLRxEAzQRbWeSCk+LuO4v4O6SHiK8= X-Received: by 2002:a02:cd01:: with SMTP id g1mr9815893jaq.131.1587753124985; Fri, 24 Apr 2020 11:32:04 -0700 (PDT) MIME-Version: 1.0 References: <786abd25-5fc7-46f4-90c4-511a648d0450@www.fastmail.com> In-Reply-To: <786abd25-5fc7-46f4-90c4-511a648d0450@www.fastmail.com> From: Rob Sayre Date: Fri, 24 Apr 2020 11:31:47 -0700 Message-ID: To: Christopher Wood Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="000000000000017ee605a40d9599" Archived-At: Subject: Re: [TLS] ECHO padding review and some open issues 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, 24 Apr 2020 18:32:07 -0000 --000000000000017ee605a40d9599 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 23, 2020 at 4:31 PM Christopher Wood wrote: > > Is this PR ready to go? If not, why not? What would you change, and why? > (Concrete suggestions are highly encouraged!) Note also that this is > currently only a recommended padding algorithm. Implementations are > therefore free to do what they wish. Is this acceptable? Do we need to be > more prescriptive? Food for thought! > It took me a while to notice that many of the padding debates aren't so important if ECHO allows arbitrary structs/extensions in the encrypted ClientHello. The recommendation is fine as a minimum, as long as servers are tolerant of unknown extensions in the ciphertext. thanks, Rob --000000000000017ee605a40d9599 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 23, 2020 at 4:31 PM Christoph= er Wood <caw@heapingbits.net&= gt; wrote:

Is this PR ready to go? If not, why not? What would you change, and why? (C= oncrete suggestions are highly encouraged!) Note also that this is currentl= y only a recommended padding algorithm. Implementations are therefore free = to do what they wish. Is this acceptable? Do we need to be more prescriptiv= e? Food for thought!

It took me a while= to notice that many of the padding debates aren't so important if ECHO= allows arbitrary structs/extensions in the encrypted ClientHello. The reco= mmendation is fine as a minimum, as long as servers are tolerant of unknown= extensions in the ciphertext.

thanks,
R= ob

--000000000000017ee605a40d9599-- From nobody Fri Apr 24 11:33:16 2020 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 AAA1B3A0363 for ; Fri, 24 Apr 2020 11:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 tOyYtOqouqV5 for ; Fri, 24 Apr 2020 11:33:12 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A94C03A0366 for ; Fri, 24 Apr 2020 11:32:54 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id u6so10967337ljl.6 for ; Fri, 24 Apr 2020 11:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nuIlJ8CRYAU5TlckQSl2aKOwwJcY/35FTQ7Xwsz3tfU=; b=U0Ocyf9gPmOEDRgEUv2FAetU/M52gVhVIaDiQ4jDtmed1xb7KM6oVq/6G8A654ohza IcdEl7q2h/NZ1GtJ5uXM/o43LKVQSC6q1une89ZWsiTogtUhrvY5NyZ/FmZk2ScoJDQv xj8m9VOns8Klqc4MlMWhH2XSyY21wQ3B7EYYf11RPhnvCizHewMuAZt4H4dEAR+l5ODU /n4EB50nU/v/j7i0VcRacWpMZ0WGYquPsEpj+J2R38ZXXf+fY3bIq2vp4u/vXSSBE4+1 BhtzwY34RbG2JvFvnVRvRQaadYVYiLVMalmHcVGMRcVnxKjClyE7lXk58ZIhAqAmUks7 mHoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nuIlJ8CRYAU5TlckQSl2aKOwwJcY/35FTQ7Xwsz3tfU=; b=md0tC3SVwou6v8SviuswKhRmryDdZXKEn4zbRXlT0JVkt1QDrdFBHt3rjI24Bzqafi cxkw4Gjv5Jg2UHdoBLOU3PIL0FaYkeeSYz+NCHrX/DghvXWgWS24YGgC+GuOZINRoQaX dtJyyCNb04env9QIM1sCJWMohaoPjN837svteWhg5ksOLYpBxq8kf7ZXVM5E/sjtacT7 ajj/RrgeBHmRKhNLGaOoQS7ywLkAvPPNgqQWaeD2SwZsU37uvP8bb+gtwYbEhpDHlv2U TgRq+oNVeVHvXQE5tq8Pk/Y+u/NFl9SoxDoLHVjzlyheKs/BvF/p2sB1+HCzhULK4h51 nzhw== X-Gm-Message-State: AGi0PuZUPAOkWj88Ith7fHjupv9kOFLysvw+3B+79ALVZBieMwfvjHc6 Vu7eDdyHjNI/wR23AXxeDOkrKEHVU6Qn6im7mX3X1g== X-Google-Smtp-Source: APiQypLs8r7cNeUQByyHM2wYOUVeNoTiWsL9acb9GX9koXW8Tl045XcotTwvI13EMNrbHAAZ1Q3pq3g3V3/4Qg8jOdI= X-Received: by 2002:a2e:9dcd:: with SMTP id x13mr6377735ljj.120.1587753172776; Fri, 24 Apr 2020 11:32:52 -0700 (PDT) MIME-Version: 1.0 References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> In-Reply-To: From: Eric Rescorla Date: Fri, 24 Apr 2020 11:32:16 -0700 Message-ID: To: Hanno Becker Cc: chris - , Hannes Tschofenig , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000dad93405a40d97a3" Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 18:33:15 -0000 --000000000000dad93405a40d97a3 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 24, 2020 at 11:17 AM Hanno Becker wrote: > Hi Chris and Ekr, > > > I'm not sure if it's straightforward, but I would note that in TLS 1.3, > we did *implicitly* authenticate the length because AEAD provides that, but > nevertheless one of Chris's recommendations was to include it in the AAD. > > I don't know if this recommendation still holds for DTLS (though Chris' > last reply sounds > like it), but DTLS 1.3 currently deviates from it: The length is > explicitly authenticated only > for records using header formats which contain the length, while for the > most compressed header > form omitting the length one relies on implicit length authentication via > AEAD. > Yes, that's correct. But you can't swap header formats. > In the case of TLS 1.3, authenticating the entire header (including the > length, opaque type, and legacy record version) allowed us to effectively > ignore most of the header details in the security proof [1]: > > If the security analysis shall be agnostic of header details, then in the > case of > DTLS 1.3 with its various header formats ( > https://tools.ietf.org/html/draft-ietf-tls-dtls13-37#section-4), > it sounds to me as if using a pseudo-header containing all header > information for AAD would fit better (?). > I don't think that's at all obvious. Again, the problem with the pseudo-header is you are authenticating some abstract information, *not* what is actually on the wire, and that allows the attacker to manipulate what's on the wire undetected. We have no analysis for the impact of that. -Ekr > Best, > Hanno > > ------------------------------ > *From:* chris - > *Sent:* Friday, April 24, 2020 6:57 PM > *To:* Eric Rescorla > *Cc:* Hanno Becker ; Hannes Tschofenig < > Hannes.Tschofenig@arm.com>; tls@ietf.org > *Subject:* Re: [TLS] Choice of Additional Data Computation > > > It doesn't seem straightforward to extrapolate from that case since the > 'pseudo-header' > and on-the-wire header are the same here, as TLS 1.3 doesn't have any > header > data which is shortened or omitted on the wire. In DTLS 1.3, in contrast, > various > fields can be dropped or shortened, such as the length, sequence number, > CID. > > > It's certainly true that we can't extrapolate the security of DTLS from > the existing proof for TLS. In the first place, the threat model is > different because in DTLS we need to tolerate dropped/out-of-order packets. > Nevertheless, I think the general principle of "authenticate all the bits" > is the right way to go here, unless there's a compelling reason not to. > > In the case of TLS 1.3, authenticating the entire header (including the > length, opaque type, and legacy record version) allowed us to effectively > ignore most of the header details in the security proof [1]: all we cared > about is that the header correctly encodes the length of the next > ciphertext to decrypt. We might be able to provide a similar argument for > DTLS 1.3. In particular, I'm betting that it doesn't matter what the > contents of the header are or how long it is, so long as (a) the entire > header is part of the AAD and (b) it correctly encodes the length of the > next ciphertext. > > I might be missing something, however. In any case, new definitions are > needed (if they don't already exist) and so too a fresh proof. > > Chris P. > > [1] https://eprint.iacr.org/2018/634.pdf > > 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. > --000000000000dad93405a40d97a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 24, 2020 at 11:17 AM Hann= o Becker <Hanno.Becker@arm.com> wrote:
Hi Chris and Ekr,

>=C2=A0I'm not sure if it's straightforward, but I would note that in TLS 1.3, we did *implicitly* aut= henticate the length because AEAD provides that, but nevertheless one of Ch= ris's recommendations was to include it in the AAD.

I don't know if this recommendation still holds for DTLS (though Chris' last reply sounds
like it), but DTLS 1.3 currently deviates from it:=C2=A0The length is explicitly authenticated only=C2=A0
for records using header formats which conta= in the length, while for the most=C2=A0compressed header=C2=A0
form=C2=A0omittin= g the length one relies on=C2=A0implicit length authentication via AEAD.


>=C2=A0In the case of TLS 1.3, authenticating the entire header (including the lengt= h, opaque type, and legacy record version) allowed us to effectively ignore= most of the header details in the security proof [1]:=C2=A0

If the secur= ity analysis shall be agnostic of header details, then in the case of=C2=A0=
it sounds to= me as if using a pseudo-header=C2=A0containing all header information for AAD would fit better (?).

I don't think that's at a= ll obvious. Again, the problem with the pseudo-header is you are authentica= ting some abstract information, *not* what is actually on the wire, and tha= t allows the attacker to manipulate what's on the wire undetected. We h= ave no analysis for the impact of that.


=
-Ekr


Best,
Hanno

From= : chris - <chrispatton@gmail.com>
Sent: Friday, April 24, 2020 6:57 PM
To: Eric Rescorla <ekr@rtfm.com>
Cc: Hanno Becker <Hanno.Becker@arm.com>; Hannes Tschofenig <Hannes.Tschofenig@arm.c= om>; tls@ietf.org<= /a> <tls@ietf.org&= gt;
Subject: Re: [TLS] Choice of Additional Data Computation
=C2=A0
It doesn't = seem straightforward to extrapolate from that case since the 'pseudo-he= ader'=C2=A0
and on-the-wire= header=C2=A0are the same here= , as TLS 1.3 doesn't have any header
data which is shortened or omitted on t= he wire. In DTLS 1.3, in contrast, various
fields can be dropped or shortened, suc= h as the length, sequence number, CID.

It's certainly true that we can't extrapolate the security of = DTLS from the existing proof for TLS. In the first place, the threat model = is different because in DTLS we need to tolerate dropped/out-of-order packe= ts. Nevertheless, I think the general principle of "authenticate all the bits" is the right way to go here, unle= ss there's a compelling reason not to.

In the case of TLS 1.3, authenticating the entire header (including th= e length, opaque type, and legacy record version) allowed us to effectively= ignore most of the header details in the security proof [1]: all we cared = about is that the header correctly encodes the length of the next ciphertext to decrypt. We might be able to = provide a similar argument for DTLS 1.3. In particular, I'm betting tha= t it doesn't matter what the contents of the header are or how long it = is, so long as (a) the entire header is part of the AAD and (b) it correctly encodes the length of the next cipher= text.

I might be missing something, however. In any case, new definitions ar= e needed (if they don't already exist) and so too a fresh proof.

Chris P.

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.
--000000000000dad93405a40d97a3-- From nobody Fri Apr 24 11:52:03 2020 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 8021B3A081E for ; Fri, 24 Apr 2020 11:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 e7xvcN7RExQ3 for ; Fri, 24 Apr 2020 11:51:45 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 982FA3A082B for ; Fri, 24 Apr 2020 11:51:45 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id e26so14236487otr.2 for ; Fri, 24 Apr 2020 11:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q6QKV0xr5rMObTKfcRhWbg/7OkBubnv3bTdQ2Ap6Cb0=; b=m5OVxiChtlV+GKsasGXgROZODDMx3lDXzwVGSbE0G5Jj6bBd02JhqyIpq+UuXXLwLz qkncCTf+2Jj3P1DeXb0jl2MSyXsfG3xLiXYhaYLA/BGqXvaOdLW0Ql/fGjuJe7bR5UXA UgWp3EiwXnMK44d4I3ZFyPXn4DvstvTWhQjK45Ht9D5iBAhXtkKl0/8uqN8uxtyj+JZ9 Tn08/RhbMiq+S+ttZqWQRqD/uXNUjQm/8Wed/micG/cjd++h98VJrWILBLLpawvHkSfC y0JXU+jtovYUMaQhV8QK4mk3iBbD1/5wa15BhAjIv+UeksIJ1ib643hU7C+QRqZUwS3C GAZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q6QKV0xr5rMObTKfcRhWbg/7OkBubnv3bTdQ2Ap6Cb0=; b=K0vDRg83+kKWTpgoq3Vk33cgrFl1vmzR3jDqf8CSv0g435pbJ9doo6utBbOQOoNfcf 8tHbMT7d1RoKkgtDHe/8d183T4xqLuOouC2Vpjx5C+ZVeRtxmRv+sadwWs4/yOnh9mIm TnqIx5Wt7hHBnne67/Mgi6aZvKS7rqtLvQt9oZ3NlwfERcyFoaGfAfa2u55EkrSGgylX fMF+TDAwzoDW0O1MTKkKnBkUGLx3Jwe81b1Z1gRbPfQ34y7EM5QC425jyEcao8IFYaUN RnsGwrMJl2vekwh+UoBqqNLC0cJas+27YJgAVygncTBWZe+FrXhoAywyeOdJlrTxBvxa gHkA== X-Gm-Message-State: AGi0PuaYB2B8bKET8PenSmtbUly1pcwEmFW0dBk9SZzjXecYqp/EatcG q5dEYJ/L0wYiBLn0YqGH08YCKN+GyszGumJbgLQ= X-Google-Smtp-Source: APiQypLqocjNYZWYttTyDvjDqbxNYK/7c6XJJcfeHtdrTJIDtLJNGSf9n0/HhRcsCMdaLp3Yisv8znDssLVm6nNKwxQ= X-Received: by 2002:a9d:1eaa:: with SMTP id n39mr9307275otn.238.1587754304809; Fri, 24 Apr 2020 11:51:44 -0700 (PDT) MIME-Version: 1.0 References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> In-Reply-To: From: chris - Date: Fri, 24 Apr 2020 14:51:33 -0400 Message-ID: To: Eric Rescorla Cc: Hanno Becker , Hannes Tschofenig , "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000054325205a40ddb43" Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 18:51:57 -0000 --00000000000054325205a40ddb43 Content-Type: text/plain; charset="UTF-8" > I don't think that's at all obvious. Again, the problem with the > pseudo-header is you are authenticating some abstract information, *not* > what is actually on the wire, and that allows the attacker to manipulate > what's on the wire undetected. We have no analysis for the impact of that. > Yes, this is the way I see it. I think you can get by with implicitly authenticating things, but when you start doing this, the details of how to decode the data on the wire begin to really matter for the proof (and potentially for an attacker). This can get complicated if, as you say, the header's content is highly variable. So, I would recommend authenticating what's on the wire. I don't think it would hurt to authenticate more than this, e.g., other fields that the sender and receiver need to agree on. Chris P. --00000000000054325205a40ddb43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I don't think that's at all obvious. Again, t= he problem with the pseudo-header is you are authenticating some abstract i= nformation, *not* what is actually on the wire, and that allows the attacke= r to manipulate what's on the wire undetected. We have no analysis for = the impact of that.
=C2=A0
Yes, thi= s is the way I see it. I think you can get by with implicitly authenticatin= g things, but when you start doing this, the details of how to decode the d= ata on the wire begin to really matter for the proof (and potentially for a= n attacker). This can get complicated if, as you say, the header's cont= ent is highly variable. So, I would recommend authenticating what's on = the wire. I don't think it would hurt to authenticate more than this, e= .g., other fields that the sender and receiver need to agree on.

Chris P.
--00000000000054325205a40ddb43-- From nobody Fri Apr 24 11:56:53 2020 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 2103D3A0799 for ; Fri, 24 Apr 2020 11:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 8phM3qY3M3on for ; Fri, 24 Apr 2020 11:56:49 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5461C3A0798 for ; Fri, 24 Apr 2020 11:56:49 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id l11so8573207lfc.5 for ; Fri, 24 Apr 2020 11:56:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0WwsXrm2G8hfplJrRvZbK2X2FThyTtvKVQ2tsfnhFzM=; b=UHROI4s5JEPsJiwzGr23nBlK1fj7Rv+9/Aa7DsQvwuBTxZLhOTuVC3AI1lhPQX2Ix7 9g1o4VMba+QGCoiTxO6L6bOKP9lcBlErdz80rL3M2NT4y3ZhnDzTPCVduCmcTlD6vWIK 37AilCL/xBby9NZCgL85iXXumI1VYywxlTB41KIgt9oBHIksxZDfr20fqU5ekar91/f8 62jV/hxUk3XsDQ7BzDPWjLRDBAtlc9+I5nZjx+qZHZD2/XKh1bhHqFZp6c7njyIBqE6G efIbTBRynu6YfROkxZOk5Bf3EdXX2Bv0tnPdDHo9yLleKR+mBNNjrznDAqbDgk74Souk 3cGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0WwsXrm2G8hfplJrRvZbK2X2FThyTtvKVQ2tsfnhFzM=; b=uVGEPqXaKQpjJoW9KAt9Tc8zV/IrDLNmDQr9KXS4TACkkPJfS7CwkAehIGs1YfWqWF BHGqTxFqUm2ZRWjaqyoOQJNQfDYG9qx6UJXePYkMFXghToS2JgvzUWJd7xp8aLePn9ck RMg80Oh/e81hNhd4+epzwX0NcwKe7M4LIBesSu1/nIbkq++fZcbbTDiQDEPnn09retFF HcA5zYGFXdXA4+5ykwBKV8b2Zmc8STI2ALet6J/p9NJh5dWy591q3TyDzpbP4Uiw8k0B xNfxzE1t2ckkzHCiog7UljerbD+zZ0Neg1I2vFHLhmQpyC08sKzg6+obScdrAjWQurMb H6yA== X-Gm-Message-State: AGi0Pubv6Q64kmfF53acRa6No6wC8GMOmQkta1PbzTfu+iZkDqQQBmGq QYhKX56VYkfyNboqjAQ1BlEiZgCnPUIkKdJ3GewObrvlQL4= X-Google-Smtp-Source: APiQypLE9dh0lOaclrLsIpee6+/yqMO8n2+qe1TYSq9D6zq7jtI+WAS2EjNGeLUxUx+OTvE3JaY2xAqZiGzVxUdh3pE= X-Received: by 2002:a19:9141:: with SMTP id y1mr7079818lfj.168.1587754607444; Fri, 24 Apr 2020 11:56:47 -0700 (PDT) MIME-Version: 1.0 References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> In-Reply-To: From: Eric Rescorla Date: Fri, 24 Apr 2020 11:56:11 -0700 Message-ID: To: chris - Cc: Hanno Becker , Hannes Tschofenig , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005e1bb805a40dedcc" Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 18:56:51 -0000 --0000000000005e1bb805a40dedcc Content-Type: text/plain; charset="UTF-8" On Fri, Apr 24, 2020 at 11:51 AM chris - wrote: > > I don't think that's at all obvious. Again, the problem with the >> pseudo-header is you are authenticating some abstract information, *not* >> what is actually on the wire, and that allows the attacker to manipulate >> what's on the wire undetected. We have no analysis for the impact of that. >> > > Yes, this is the way I see it. I think you can get by with implicitly > authenticating things, but when you start doing this, the details of how to > decode the data on the wire begin to really matter for the proof (and > potentially for an attacker). This can get complicated if, as you say, the > header's content is highly variable. So, I would recommend authenticating > what's on the wire. I don't think it would hurt to authenticate more than > this, e.g., other fields that the sender and receiver need to agree on. > FWIW, if the consensus of the group were to authenticate both the "pseudoheader information" and the bits on the wire, I could potentially live with that. My rank ordering of options I consider potentially acceptable is: 1. Ban implciit CIDs. 2. Authenticate both the wire format and the abstract information. I am strongly opposed to authenticating only the abstract information. -Ekr P.S. QUIC uses the same implicit length mechanism, so we should form a common theory. > Chris P. > --0000000000005e1bb805a40dedcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Apr 24, 2020 at 11:51 AM chris - = <chrispatton@gmail.com> = wrote:

I don't think that's at all obvious. Again, the problem= with the pseudo-header is you are authenticating some abstract information= , *not* what is actually on the wire, and that allows the attacker to manip= ulate what's on the wire undetected. We have no analysis for the impact= of that.
=C2=A0
Yes, this is the w= ay I see it. I think you can get by with implicitly authenticating things, = but when you start doing this, the details of how to decode the data on the= wire begin to really matter for the proof (and potentially for an attacker= ). This can get complicated if, as you say, the header's content is hig= hly variable. So, I would recommend authenticating what's on the wire. = I don't think it would hurt to authenticate more than this, e.g., other= fields that the sender and receiver need to agree on.

FWIW, if the consensus of the group were to authent= icate both the "pseudoheader information" and the bits on the wir= e, I could potentially live with that.

My rank ord= ering of options I consider potentially acceptable is:

=
1. Ban implciit CIDs.
2. Authenticate both the wire format a= nd the abstract information.

I am strongly opposed= to authenticating only the abstract information.

= -Ekr

P.S. QUIC uses the same implicit length mecha= nism, so we should form a common theory.


Chris P.
--0000000000005e1bb805a40dedcc-- From nobody Fri Apr 24 12:56:23 2020 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 8A9713A099D for ; Fri, 24 Apr 2020 12:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.82, 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=LCgGad4M; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=LCgGad4M 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 jHn_L9O7shLs for ; Fri, 24 Apr 2020 12:56:19 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70078.outbound.protection.outlook.com [40.107.7.78]) (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 3EE2E3A0996 for ; Fri, 24 Apr 2020 12:56:18 -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=VR5cTrXInHZYrjlGgxz9ffuoUB6yw4s64hoR+/vctDA=; b=LCgGad4MzgKpTMaH3eTLof/kSR8DsJkUIiUOB3d8qA97oiQPi0FbPoX8IZEx/EbL6+cZNEssGETrV3LYUSgNhUKQlsHBBzvzsq32vheXJPXjqUV4xl+hHwezbGbfnfB+9JngYSGYjB3anD+oU/Iyx4V+mHC48qfI5UHmpBoFpRE= Received: from AM6P194CA0041.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:84::18) by AM5PR0802MB2531.eurprd08.prod.outlook.com (2603:10a6:203:a0::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Fri, 24 Apr 2020 19:56:16 +0000 Received: from VE1EUR03FT006.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:84:cafe::ec) by AM6P194CA0041.outlook.office365.com (2603:10a6:209:84::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Fri, 24 Apr 2020 19:56:16 +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 VE1EUR03FT006.mail.protection.outlook.com (10.152.18.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Fri, 24 Apr 2020 19:56:15 +0000 Received: ("Tessian outbound b3a67fbfbb1f:v54"); Fri, 24 Apr 2020 19:56:15 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 73f92de9675037e4 X-CR-MTA-TID: 64aa7808 Received: from a063cff59981.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id BD26DEC6-DA80-47E2-BB3A-2916DB749E47.1; Fri, 24 Apr 2020 19:56:09 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a063cff59981.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 24 Apr 2020 19:56:09 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ewEjLibRPXVVtNWQwR1Q72mGhB6gXkxhp5xFQ4y3Q/P8x/XcElk0Q5bplpSgkT4Gz80sMK0LjBezxR1iQstesqU0XaArmm9fpXcXJa85R71fjbPA6rFQFuIYOYlLILkjX7osbOc1rXnLi3AjAuYbE3bfVaVixt57cwv+it51sRLuXs2JCFFa6xVxFe0gI7ClYz6jAd3KEEOg10QYoihIoFU7EE3bq6BV9j6H157sOo9p+KDyOgvHdm4ibCFTwW0V27ou3bKqe1j3tBJ7w2USACOmxeallsuyVExOc2ltfaXsbQNAqRv6DBt1WhMb2s345SdpIVWPK9tKzLwnea/BjQ== 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=VR5cTrXInHZYrjlGgxz9ffuoUB6yw4s64hoR+/vctDA=; b=QIezcxHY2n/Flz0PkTOQMBNFAwSE7GlUCvkbrq4Q5V2Rq/sN/E5/OItNNVXevpVp3B57YirM6eQn+rVDRZBO+9dnNVIgv88trQ7+jK8MI4j07jD9COsnOPUi8xP8mTsQmxLt/ufoud6I6tlbTFmhtYVdc/jm8tfDDJUOAl+Bsp3FvHce3mKwilAkmhw+MaAzXgz7ZOSJxW3ayfcHltILHwvRsL4R9vSj9CayucFPi/o6Mp5FQ1NGg6b9Vx5CjALerT1b6rUY+OEcE3Znz7sXn+rq6gJ65iLyR2wtmjjAqZ14MnAxxcTGa7p2cY47taiBCzbMWV8xqyrL4Ovl7GzVkw== 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=VR5cTrXInHZYrjlGgxz9ffuoUB6yw4s64hoR+/vctDA=; b=LCgGad4MzgKpTMaH3eTLof/kSR8DsJkUIiUOB3d8qA97oiQPi0FbPoX8IZEx/EbL6+cZNEssGETrV3LYUSgNhUKQlsHBBzvzsq32vheXJPXjqUV4xl+hHwezbGbfnfB+9JngYSGYjB3anD+oU/Iyx4V+mHC48qfI5UHmpBoFpRE= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB5062.eurprd08.prod.outlook.com (2603:10a6:20b:e1::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Fri, 24 Apr 2020 19:56:08 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d%6]) with mapi id 15.20.2937.020; Fri, 24 Apr 2020 19:56:08 +0000 From: Thomas Fossati To: chris - , Eric Rescorla CC: "tls@ietf.org" , Thomas Fossati Thread-Topic: [TLS] Choice of Additional Data Computation Thread-Index: AdYaKASVCp3JPFQuSaOSMkwtz/VZZwAEUEsAAAN7oaAAAnFQAAAASY9CAAFcJQAAAoyFgAAAY+d9AADW9gAAAKxogAAEWbaA Date: Fri, 24 Apr 2020 19:56:08 +0000 Message-ID: References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 193a1ddd-3bd8-4e7a-bfb6-08d7e8898c2a x-ms-traffictypediagnostic: AM6PR08MB5062:|AM6PR08MB5062:|AM5PR0802MB2531: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 03838E948C X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(6506007)(36756003)(54906003)(498600001)(110136005)(26005)(91956017)(66446008)(86362001)(66476007)(66946007)(64756008)(2616005)(33656002)(6486002)(66556008)(76116006)(81156014)(53546011)(8676002)(5660300002)(4326008)(71200400001)(2906002)(186003)(8936002)(6512007); 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: Gz74zXDvh62UsOfuYo637U0yEn0itaaZbkVu0AGLewYDaGuJVK2adFAwqBcZpThaRl9bNqTYwkm23l4lu6A7r8EQBbByspMnsAMLKjZCh2QwFlGQk/LrMLoqVh7q7kC0rlw5QkEnNeMUxm8Zg9kvpNLUd2YKjTYkTs/661eMIg3IM8qJBqijKNrUYMBwzO4DruLwsW3GTizb44z9tKukKNMi85JqQtpmOA4CRuQ+oqUsWttAFjvLmZM1dYaasz53DlEXVZptODrGKh1VpbzqdnVoilzcj6uvlNkhuUkn9P6YKH2OjCxQpqgCOiPjCHoFoQhh6jDTS1DRSIXXdKjXTbVi5OK5SJrySRzoBrROVBptRexx0nKZRhyIrm8ZHssoUKJflTAhEDsWb7FfFya3l0K4YNsLpNpEyAsN6w2PMxtJ1VqwdbGbOElc/kfKUexg x-ms-exchange-antispam-messagedata: K7JnGmmOYTdtGkOK6RsyNGZUt3tUP8MuKpQB9P6+ImZa9KEsg2RmfeJUuVeKn46GllSyjcz++mcjV74SxPnScsOM8kCVXRqlfg52r0aYQPomnk6MYgD8A3kSlemfJNkmAaR2McxKVj0NhwIGq+jeGg== Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5062 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT006.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:(4636009)(396003)(376002)(39860400002)(136003)(346002)(46966005)(186003)(2616005)(82740400003)(6486002)(8936002)(54906003)(110136005)(5660300002)(33656002)(53546011)(316002)(36756003)(6506007)(82310400002)(8676002)(356005)(36906005)(6512007)(81156014)(47076004)(86362001)(336012)(70206006)(70586007)(4326008)(81166007)(2906002)(26005)(478600001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 4f399a0c-6748-488d-1d63-08d7e88987ca X-Forefront-PRVS: 03838E948C X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: AVHSL8FOAV04vg1Zfw71oDmv4E4qFuNL2QKR1iyWB8zfWAfo7FEqu1x5WL/vlSYG1F/ghCTYH8tlfa/BMfWEupNK/pTBh9cUR92DXhRdy9cnrvhpg+XRNv3gDq6RDaW7/ofRzLMzVHjRI4GIHEdqXpRsKfCBOb4YrRkot4IvPkgwiKIb0n56OxXLIoXwJhkqL5l3Izwf5ATGq+wa1T2eYLdrx43k0ztT0VsmB4Vat3wvQqa8LAA3IKRMkMCn+lkp9XFxPCEU2+OCYucRIjmDN3PspY2PDy7I62L5ZxiH6MHvO0D1G6nIQFi3kjJuynZD4puYLo8WRz5xA01ggXAvlsemBiDkRgqB6eS6qI2N8oodNsngWwwLCOEm6YSDSt4bODJm7IkhQ7O/hhSKmMGjDULDf3puC99tUaGzW2/e3Mn74561GkVERxPFW5Oxt1NXsueATpiv0uUUWe1BWR+SYl7/HWcN/Js3sd5mUSWGhAhgEgDl0wg7ZH65Q0pAHkY274PZu++K2XcnX+ws31W07A== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2020 19:56:15.4607 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 193a1ddd-3bd8-4e7a-bfb6-08d7e8898c2a 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: AM5PR0802MB2531 Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 19:56:22 -0000 T24gMjQvMDQvMjAyMCwgMTk6NTMsICJjaHJpcyAtIiA8Y2hyaXNwYXR0b25AZ21haWwuY29tPiB3 cm90ZToNCj4gWy4uLl0gdGhlIGRldGFpbHMgb2YgaG93IHRvIGRlY29kZSB0aGUgZGF0YSBvbiB0 aGUgd2lyZSBiZWdpbiB0bw0KPiByZWFsbHkgbWF0dGVyIGZvciB0aGUgcHJvb2YgKGFuZCBwb3Rl bnRpYWxseSBmb3IgYW4gYXR0YWNrZXIpLg0KDQpJIGhhdmUgemVybyBleHBlcmllbmNlIHdpdGgg Zm9ybWFsIHNlY3VyaXR5IHByb29mcywgc28gSSBuZWVkIHRvIHRydXN0DQp5b3VyIGFzc2Vzc21l bnQgaGVyZSwgd2hpY2ggbG9va3MgbGlrZSB0aGUgY3J1eCBvZiB0aGUgYXJndW1lbnQgYWdhaW5z dA0KYXV0aGVudGljYXRpbmcgdGhlIHBzZXVkby1oZWFkZXIgYWxvbmUuDQoNCj4gSSBkb24ndCB0 aGluayBpdCB3b3VsZCBodXJ0IHRvIGF1dGhlbnRpY2F0ZSBtb3JlIHRoYW4gdGhpcywgZS4uZy4s DQo+IG90aGVyIGZpZWxkcyB0aGF0IHRoZSBzZW5kZXIgYW5kIHJlY2VpdmVyIG5lZWQgdG8gYWdy ZWUgb24uDQoNCklJVUMgdGhlIG90aGVyIHNlZW1pbmdseSBjcml0aWNhbCB0aGluZyBmb3IgdGhl IHNlY3VyaXR5IHByb29mIG9mIFRMUywNCndoaWNoIEkgdGhpbmsgaXQncyBjcml0aWNhbGx5IGlt cG9ydGFudCB3ZSB0cnkgaGFyZCBub3QgdG8gZGl2ZXJnZSBmcm9tLCB3YXMNCmF1dGhlbnRpY2F0 aW5nIHRoZSBsZW5ndGggb2YgdGhlIHJlY29yZDoNCg0KPiBbLi4uXSBhbGwgd2UgY2FyZWQgYWJv dXQgaXMgdGhhdCB0aGUgaGVhZGVyIGNvcnJlY3RseSBlbmNvZGVzIHRoZQ0KPiBsZW5ndGggb2Yg dGhlIG5leHQgY2lwaGVydGV4dCB0byBkZWNyeXB0Lg0KDQpUaGUgdGhpbmcgaXMgd2l0aCBVRFAg aXQgaXMgdHJpdmlhbCBmb3IgYW4gYXR0YWNrZXIgdG8gdHJ1bmNhdGUgYQ0KZGF0YWdyYW0gYW5k IHRoZXJlZm9yZSBjaGFuZ2UgdGhlICppbXBsaWNpdCogbGVuZ3RoIG9mIHRoZSBjYXJyaWVkDQpy ZWNvcmQgYW5kIGdvIHVuZGV0ZWN0ZWQgaWYgdGhhdCBpcyBub3QgaW5jbHVkZWQgaW4gdGhlIGF1 dGhlbnRpY2F0ZWQNCmRhdGEuICBTbyBpdCBzZWVtcyB0aGF0IC0gYXQgYSBtaW5pbXVtIC0gd2Ug c2hvdWxkIGFsd2F5cyBhdXRoZW50aWNhdGUNCnRoZSBsZW5ndGggZXZlbiB3aGVuIGl0IGlzIG5v dCBwdXQgb24gdGhlIHdpcmUuDQoNCkFuZCBpZiB3ZSBuZWVkIHRvIGRvIHRoYXQsIGtlZXBpbmcg dGhlIGltcGxpY2l0IENJRCBsb29rcyBsaWtlIGENCm5vLWJyYWluZXIgdG8gbWUuDQoNCg0KSU1Q T1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVy IHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5m b3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Fri Apr 24 13:43:14 2020 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 E86DA3A0AF1 for ; Fri, 24 Apr 2020 13:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 hLLYSYqYeLCG for ; Fri, 24 Apr 2020 13:43:11 -0700 (PDT) Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 249C03A0AF0 for ; Fri, 24 Apr 2020 13:43:11 -0700 (PDT) Received: by mail-lj1-x234.google.com with SMTP id j3so11335146ljg.8 for ; Fri, 24 Apr 2020 13:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xAobyx51xZnd8tkCaha+OWdKLpeQuuGu3Q06iqJ/SKI=; b=euYRtf9vhavqcvg1R9yqk1snYhVeMFv6cLxc8wNXJ3/i3bv84Arvc2unN2dbNgqKWf e/ABa49cC78dghUbZ87y977PjThI0DYfQOUxPXgDobWLB7fx0lfzCV+sVGBTUgZzQRcB MF9hTCHsdYA7o3YrCdC5yMZ8xsMCh2DCWbjKpfger2YLNtdaaTQaf8c+7BNOimPbm+yu n1/Tzvq2jOwHnfFFUbH0GFAH4AStZ3CwqEwShno0YHwEVLFN47zYsxD5ZajieEe0+f9b 1WWR/vLqySR7qjGAHHX8k/O8cjz/L8Ng8ZwB98bT1opbMOe4mLjqhZrSDSbOfGJpKiET qMrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xAobyx51xZnd8tkCaha+OWdKLpeQuuGu3Q06iqJ/SKI=; b=I0QRylOQsi6v1mgMEPPmCi7u2cXWn1dayYxpbwiIoXRTB2iDVDSvio6vbYdpahxuA7 Vg6OnBsNsmszrbya1wYdYnzZDsOGnJZu8YbMVhcF1FibigQwXK5R/j6umQQupiy0pH1p OAEX8U7wQtwkkueeG3o4X9Dp53bIvC4JfARqJsqnEptVEC63SMfXhRaFDBQphWY6kGsh Nju5KfTG11f3s0YBnlT84JezV0wzEUVzAMEWYYTdBVCQim3N0VuxF52doYa4jEtASeht 9rigzojw981SI4RhtzICmKbPkkSRa9gIz0t2Zj3FcCzUAhz+Cdia7881hMxLpFa+4l9i ynsQ== X-Gm-Message-State: AGi0Pub7wH6C9SY9L+Q/4Kb2teJXUTs9+6bDoOhzG5vHJg5EWOByfXxe y7d1srwpoDiXFRvvb0mA6xvZSpv1+JOhb6wZj3rZL+8gkns= X-Google-Smtp-Source: APiQypItx9eYYVJCpRjDhUQd0lzlGUuvcRbDNuQejwrAkeIkkhCj2pppMRTLRJ31PsjzHT/4y1Tn6yk/uyfoM9utbgU= X-Received: by 2002:a2e:2414:: with SMTP id k20mr6906684ljk.162.1587760989237; Fri, 24 Apr 2020 13:43:09 -0700 (PDT) MIME-Version: 1.0 References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> In-Reply-To: From: Eric Rescorla Date: Fri, 24 Apr 2020 13:42:33 -0700 Message-ID: To: Thomas Fossati Cc: chris - , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c0a4c505a40f694f" Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 20:43:13 -0000 --000000000000c0a4c505a40f694f Content-Type: text/plain; charset="UTF-8" On Fri, Apr 24, 2020 at 12:56 PM Thomas Fossati wrote: > On 24/04/2020, 19:53, "chris -" wrote: > > [...] the details of how to decode the data on the wire begin to > > really matter for the proof (and potentially for an attacker). > > I have zero experience with formal security proofs, so I need to trust > your assessment here, which looks like the crux of the argument against > authenticating the pseudo-header alone. > > > I don't think it would hurt to authenticate more than this, e..g., > > other fields that the sender and receiver need to agree on. > > IIUC the other seemingly critical thing for the security proof of TLS, > which I think it's critically important we try hard not to diverge from, > was > authenticating the length of the record: > > > [...] all we cared about is that the header correctly encodes the > > length of the next ciphertext to decrypt. > > The thing is with UDP it is trivial for an attacker to truncate a > datagram and therefore change the *implicit* length of the carried > record and go undetected if that is not included in the authenticated > data. So it seems that - at a minimum - we should always authenticate > the length even when it is not put on the wire. > > And if we need to do that, keeping the implicit CID looks like a > no-brainer to me. > I do want to be clear that AEAD functions implicitly authenticate the length of the input. But I'd like to hear Chris weigh in on whether he thinks we should have them explicitly in the AD (and whether that should be true in QUIC too). -Ekr > > 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. > --000000000000c0a4c505a40f694f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 24, 2020 at 12:56 PM Thom= as Fossati <Thomas.Fossati@arm= .com> wrote:
On 24/04/2020, 19:53, "chris -" <chrispatton@gmail.com> wrote:
> [...] the details of how to decode the data on the wire begin to
> really matter for the proof (and potentially for an attacker).

I have zero experience with formal security proofs, so I need to trust
your assessment here, which looks like the crux of the argument against
authenticating the pseudo-header alone.

> I don't think it would hurt to authenticate more than this, e..g.,=
> other fields that the sender and receiver need to agree on.

IIUC the other seemingly critical thing for the security proof of TLS,
which I think it's critically important we try hard not to diverge from= , was
authenticating the length of the record:

> [...] all we cared about is that the header correctly encodes the
> length of the next ciphertext to decrypt.

The thing is with UDP it is trivial for an attacker to truncate a
datagram and therefore change the *implicit* length of the carried
record and go undetected if that is not included in the authenticated
data.=C2=A0 So it seems that - at a minimum - we should always authenticate=
the length even when it is not put on the wire.

And if we need to do that, keeping the implicit CID looks like a
no-brainer to me.

I do want to be clear= that AEAD functions implicitly authenticate the length of the input. But I= 'd like to hear Chris weigh in on whether he thinks we should have them= explicitly in the AD (and whether that should be true in QUIC too).

-Ekr



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.
--000000000000c0a4c505a40f694f-- From nobody Fri Apr 24 14:29:46 2020 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 9DD933A0C0A for ; Fri, 24 Apr 2020 14:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 RKjCAvh1HDUD for ; Fri, 24 Apr 2020 14:29:42 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB2F3A0BFC for ; Fri, 24 Apr 2020 14:29:42 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id g14so14986802otg.10 for ; Fri, 24 Apr 2020 14:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FbgWI5aJ/5KdL0oN5S3UxMguyTabYjZzkWpUWwwQub8=; b=hFTra4vVG4c8OBw8ikm5VABunoH9GtY+Kh0O9RJkP2wlb6xMUAsyf38vWfrzrdpYTB albmTuRxAbRVbCtELHEAZiKWw83F8J5wnM5CNGHzeOR7vlGAEHPAx+O/CvKIxqZSc2iO j04lEJFnRPf3jaCS1BornYzL8BwNokNHYWrlKqM4vwoq1FwRYuxIrU1YOkx2CvEPZl9o X3GyiTxe7tTYr3SpqOgPoVkUYOBe4Ny16gKCOQMmfdwYJew0EifwVCAYPw2ac4iEF9UX k8Pgys6hlFzrkZdrSEtshBWRLrTBbXC0MHYuBbX5FKpaGbGv2NlHTajARjdPE1Pi6hL7 WLAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FbgWI5aJ/5KdL0oN5S3UxMguyTabYjZzkWpUWwwQub8=; b=eCCJjMSOKwvllLno2UT4uurU5AHuSShegiABol2xZ1bH9G0v/Ia+SY6/VXgvAnCpQ0 5tLw58ntCiT9TTCBu3OjA5sBINoqaSXttd+Z0wGuhOCWc6zQs2lnqqMNufjJEOCBheMU ZzGkQ/1jj2C94YWS9+b6YkR81KsUT7S3EkIVy5GBR1KCFbqGG5OhpvFIufUdMVLEgNlX 4upZHFcEuQ3f1TVeuh3a18H7Ygd+Hm0V3rkUgODCex97JaV5C5MJIlbx2zLD28YVLO+s lvesQ9OY/5bkcj2yILVABYmQrSAECP81X4F/lSKQuZ/5pNZ+XTNr0ETPDr+EkDZFNhJk 9b3Q== X-Gm-Message-State: AGi0PubrXX8meyhtbg4CRceahwkdPwqcEC81a6kqSOy/t+NywUKFn9Fz 4vmcEM49D7Z5oYvwKvIChL8GEpBgbNfHX93N3fU= X-Google-Smtp-Source: APiQypIp4f04YjBFzCfHqa3yy9/20ajjalRIJn+YYVV1ulNNoxSKnQmUxWq7x1CKnTmJdSLO7Y3WPCpHPqCdZgEESjw= X-Received: by 2002:a9d:1eaa:: with SMTP id n39mr9811737otn.238.1587763781218; Fri, 24 Apr 2020 14:29:41 -0700 (PDT) MIME-Version: 1.0 References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> In-Reply-To: From: chris - Date: Fri, 24 Apr 2020 17:29:29 -0400 Message-ID: To: Eric Rescorla Cc: Thomas Fossati , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002ac04305a4101053" Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 21:29:44 -0000 --0000000000002ac04305a4101053 Content-Type: text/plain; charset="UTF-8" > > But I'd like to hear Chris weigh in on whether he thinks we should have > them explicitly in the AD (and whether that should be true in QUIC too). > I would need to study the specs in order to provide an intelligent answer here. Off the hip, it would seem to depend on how the boundaries between record headers and ciphertexts are determined. Taking a quick look at draft-37, Fig. 4: the "full" header includes three values that are excluded from the "minimal" header, the length of the ciphertext being one of the fields. Presumably, when using the "minimal" header, the length is a parameter that the sender and receiver already agree on. If this is case, then I don't see a need to add the length to the AD. If the attacker manages to convince the receiver to use the wrong length parameter (maybe this is negotiated during the handshake?), then as Ekr points out, AEAD decryption would fail, thereby "implicitly authenticating the input length". Chris P. --0000000000002ac04305a4101053 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But I&#= 39;d like to hear Chris weigh in on whether he thinks we should have them e= xplicitly in the AD (and whether that should be true in QUIC too).

I would need to study the spe= cs in order to provide an intelligent answer here. Off the hip, it would se= em to depend on how the boundaries between record headers and ciphertexts a= re determined. Taking a quick look at draft-37, Fig. 4: the "full"= ; header includes three values that are excluded from the "minimal&quo= t; header, the length of the ciphertext being one of the fields. Presumably= , when using the "minimal" header, the length is a parameter that= the sender and receiver already agree on. If this is case, then I don'= t see a need to add the length to the AD. If the attacker manages to convin= ce the receiver to use the wrong length parameter (maybe this is negotiated= during the handshake?), then as Ekr points out, AEAD decryption would fail= , thereby "implicitly authenticating the input length".

Chris P.
--0000000000002ac04305a4101053-- From nobody Fri Apr 24 14:35:20 2020 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 4668C3A0C14 for ; Fri, 24 Apr 2020 14:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 OXvonfe_aMtk for ; Fri, 24 Apr 2020 14:35:16 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040963A0C11 for ; Fri, 24 Apr 2020 14:35:16 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id 198so8951660lfo.7 for ; Fri, 24 Apr 2020 14:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ERGAc3ZNSx/eTFj+M6w2AanT2uv1DHXV2gXbBdZykmg=; b=Vl4eyBWXRb2l2z7q4RYLWSia58fjhYFG8zvrsguLW11zbbNMZEnat5k+CJ56w6+T6e 4nVaVPQa17Mv2LNUpKUnFvgIgwPRqHzEFHcjOCmiq887H/c/hxEkJgURhJtMIOzkZRxA 6t8Zrw/ZbgjoBWxA9L6268XWnU0qDtqAwN5ftRyJa3ougqWuPRlOwTNOzWTIpx464sY2 Rh+69mWRhP8ViJjN4ZVkKNvx31G+Ryd+SMQ6sVCBt1IKwCxn6BK8z6w2jr8vk3R90DYD YTeuSabaXubRx30hSDpTRH9kScI3Pw7UoXviD3Epuyh0YsAf9WbzNVN0taEPzeQazUey 8llA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ERGAc3ZNSx/eTFj+M6w2AanT2uv1DHXV2gXbBdZykmg=; b=tgt6r7G5DVD/PbPgKIwfztWOpGngJxNqvVaIWuDnr8S2N+/LpHs+CteYDMAQHD8Iap vnipeMkzuAe0nc88LWhUdRxEdXoVqyqD9WegC2+GruQayOA6WA9gPIp5Xp4CSz/fllXP WwDU5HnqCHpRT6AmhE+4seHT0WutK0JWEiv3aJ9B7F1Hos96gFbmdCGZW3pq78z8lDzE qXy4sLXOGzvDJ972l8+yozpaXxRvRx8lb/nhcvLRX5L3bh5ld5SSXZzfi+CUhDjol72e 0kjyuXHkl1LfOB6hgdKSkJCA0pTuxl2dLditjhkgSi1icv54z52ja/9WEJYgKjUPUJoV N6Qg== X-Gm-Message-State: AGi0Pub0oB71sXubuibk6ZK5H37jys8mkMOcKJeNuNRT3J98vpwNzEUa K0ISF7xF6ebJrpZQ5TNa0Fg+1mjiTjGf7IBW85Fguw== X-Google-Smtp-Source: APiQypIxidvWlMR8OjzMnAh5xZV+f9vz4+FugHMCV1Mvl+n8+5DqU9uGz7B3H1VMIcjmldL0YPfIsevjizJz6SegTuU= X-Received: by 2002:a19:f806:: with SMTP id a6mr7637741lff.201.1587764114186; Fri, 24 Apr 2020 14:35:14 -0700 (PDT) MIME-Version: 1.0 References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> In-Reply-To: From: Eric Rescorla Date: Fri, 24 Apr 2020 14:34:37 -0700 Message-ID: To: chris - Cc: Thomas Fossati , "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000003751805a4102429" Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 21:35:19 -0000 --00000000000003751805a4102429 Content-Type: text/plain; charset="UTF-8" On Fri, Apr 24, 2020 at 2:29 PM chris - wrote: > But I'd like to hear Chris weigh in on whether he thinks we should have >> them explicitly in the AD (and whether that should be true in QUIC too). >> > > I would need to study the specs in order to provide an intelligent answer > here. Off the hip, it would seem to depend on how the boundaries between > record headers and ciphertexts are determined. Taking a quick look at > draft-37, Fig. 4: the "full" header includes three values that are excluded > from the "minimal" header, the length of the ciphertext being one of the > fields. Presumably, when using the "minimal" header, the length is a > parameter that the sender and receiver already agree on. > Yes. It's "the rest of the UDP datagram". -Ekr > If this is case, then I don't see a need to add the length to the AD. If > the attacker manages to convince the receiver to use the wrong length > parameter (maybe this is negotiated during the handshake?), then as Ekr > points out, AEAD decryption would fail, thereby "implicitly authenticating > the input length". > > Chris P. > --00000000000003751805a4102429 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Apr 24, 2020 at 2:29 PM chris= - <chrispatton@gmail.com&g= t; wrote:
But I'd l= ike to hear Chris weigh in on whether he thinks we should have them explici= tly in the AD (and whether that should be true in QUIC too).

I would need to study the specs in = order to provide an intelligent answer here. Off the hip, it would seem to = depend on how the boundaries between record headers and ciphertexts are det= ermined. Taking a quick look at draft-37, Fig. 4: the "full" head= er includes three values that are excluded from the "minimal" hea= der, the length of the ciphertext being one of the fields. Presumably, when= using the "minimal" header, the length is a parameter that the s= ender and receiver already agree on.
Yes. It's "the rest of the UDP datagram".

-Ekr

=C2=A0
If this is case, then I don't see a need to add the length to= the AD. If the attacker manages to convince the receiver to use the wrong = length parameter (maybe this is negotiated during the handshake?), then as = Ekr points out, AEAD decryption would fail, thereby "implicitly authen= ticating the input length".

Chris P.
--00000000000003751805a4102429-- From nobody Fri Apr 24 15:00:23 2020 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 600743A0D45 for ; Fri, 24 Apr 2020 15:00:21 -0700 (PDT) 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=MGEBbRf6; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=MGEBbRf6 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 a4bIDHuc8n4t for ; Fri, 24 Apr 2020 15:00:15 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60065.outbound.protection.outlook.com [40.107.6.65]) (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 11AD03A0D43 for ; Fri, 24 Apr 2020 15:00:14 -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=YyvxClrbuEKZ+lH13y0SbMsbJFYam0K3rVJYp2RIjLU=; b=MGEBbRf6ENrFycatTItIEBacL0Nt8Xs44QgFaATd+akZ4rbF8FTGiJIsxy28WXhOQebWmieqbX5DgkIYDyq6MjqajnroHXHUWhMuBqSMmeRcNzZIQWVuOH7q5CeoY/rQybnf5GlkezMzkroJu/fUmmDSHFT9dGAzyUKEnr/+87k= Received: from AM7PR03CA0025.eurprd03.prod.outlook.com (2603:10a6:20b:130::35) by DB6PR0801MB1943.eurprd08.prod.outlook.com (2603:10a6:4:74::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Fri, 24 Apr 2020 22:00:11 +0000 Received: from AM5EUR03FT042.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:130:cafe::66) by AM7PR03CA0025.outlook.office365.com (2603:10a6:20b:130::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Fri, 24 Apr 2020 22:00:11 +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 AM5EUR03FT042.mail.protection.outlook.com (10.152.17.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Fri, 24 Apr 2020 22:00:11 +0000 Received: ("Tessian outbound b3a67fbfbb1f:v54"); Fri, 24 Apr 2020 22:00:11 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 3a519c655b029302 X-CR-MTA-TID: 64aa7808 Received: from b3539b79d38e.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 2ADB6AC4-D053-4EA6-90CE-8D76D0A34A7D.1; Fri, 24 Apr 2020 22:00:05 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b3539b79d38e.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 24 Apr 2020 22:00:05 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=i9Z3K5e3uz+t3GuHXmCN9TdpnSnqlnwj8rmZNP4wz14nuYfe41UhGbX5alYhOigt/2k9TtiCkvxZ13TFaBEp2Jz6liqA3j89nIZLPpdDNOOJSY5bZR1hzpiBFB2XCE6w/vrn2Ytm7S1wNNsw53Otd2GFObJCe+zUrZwwv1VQk934eBSoFlX4daHU+ohhSKNiaaDUfSLswdAhdJJAk+V/J24XaYZPxCmBDvg4AiDjSsIv1F4elZpxCqJqcqQ6FSeXGPG52BCZi/dWK3JDbNlr1ASOooeqF6YCUv8vDulqkcQOp7Ctd5S46xPvwM2eqyjEhhpCNaLXDOASyru1jtq27Q== 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=YyvxClrbuEKZ+lH13y0SbMsbJFYam0K3rVJYp2RIjLU=; b=mT7V4JdjHCGPvvuiy0VrEC8fy91cO+SKbsJtqR9BDDGEQM8gJCmRESGgq83DnLURncfwZeEOYRiurVeBDNl+p/puFFTXOFYWZgVmlxGdZcLwUP+onfhinQA6V2DRrg3zz8KDCozclFU9wicUlp01+Kh2oCr22rvr3Xg+gvvm5kSF+g7lAnUD6sYsHaRzZP59PkL9O7bx3g+kRkw9fDPUVp9j0Dc2wW17YVcIVprk8MEI/J85laaohe7rRMWpVOEsfhlPCe9SN/nfbr4ANQlChToVi5yiAjmKVv3wCcvG1VoHg8lgDqatlQqyWqyjmkWcDgksZSjwp89Vxxs10tMmPQ== 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=YyvxClrbuEKZ+lH13y0SbMsbJFYam0K3rVJYp2RIjLU=; b=MGEBbRf6ENrFycatTItIEBacL0Nt8Xs44QgFaATd+akZ4rbF8FTGiJIsxy28WXhOQebWmieqbX5DgkIYDyq6MjqajnroHXHUWhMuBqSMmeRcNzZIQWVuOH7q5CeoY/rQybnf5GlkezMzkroJu/fUmmDSHFT9dGAzyUKEnr/+87k= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6PR08MB4866.eurprd08.prod.outlook.com (2603:10a6:20b:c8::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Fri, 24 Apr 2020 22:00:05 +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.2937.020; Fri, 24 Apr 2020 22:00:05 +0000 From: Hanno Becker To: Eric Rescorla , chris - CC: Hannes Tschofenig , "tls@ietf.org" Thread-Topic: [TLS] Choice of Additional Data Computation Thread-Index: AdYaKASVCp3JPFQuSaOSMkwtz/VZZwAEUEsAAAN7oaAAAnFQAAAASY9CAAFcJQAAAoyFgAAAY+d9AADW9gAAAKxogAAAKW2AAAULeAA= Date: Fri, 24 Apr 2020 22:00:04 +0000 Message-ID: References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> , In-Reply-To: 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: [2a00:23c5:ee06:1300:75ff:a3e1:66f3:b1ab] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 0f186353-9022-4348-1939-08d7e89adc30 x-ms-traffictypediagnostic: AM6PR08MB4866:|AM6PR08MB4866:|DB6PR0801MB1943: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 03838E948C 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:(4636009)(39860400002)(136003)(366004)(376002)(396003)(346002)(8936002)(478600001)(81156014)(55016002)(8676002)(5660300002)(4326008)(9686003)(7696005)(110136005)(6506007)(316002)(54906003)(33656002)(76116006)(71200400001)(86362001)(2906002)(66556008)(186003)(52536014)(64756008)(66946007)(66476007)(66446008); 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: efPxKjw7XK5lQYshr9FyP53tage9r7nU2BQluIZ0+LbNHpTPpp5bf0EM2uaNV4/fl8lxe/lH5TwUKXr+woiG0N/50F1kAqfjsIPAFdSx4A/aPFVhoGREMExM56Ffs1oK1Mh7/OEWSQUuIt4/SsF2BuOppPLH7d7kk3qBD6O4oFAieNe6lD3noVy8jdxI4Gz+GBbVa88UTabXzdQ5k1fqwuqwojB/S/8uw0GqIhogJwbhPi8Jq2FrYJOKoA5Yjsxd5ykqT0oZQR2kwWzCGQpCmGSxCGdFjuoqS/mbDeSW5Pj61XUicClX/pNNv/fuWim1tkpalQzEFpelTUSFswQ1K5suvnxl4Pcet5AT5s3OJAIVDr4VZ38SVJ1fMTbH9oGCah93A7+QpQEgom7qS7k6unY7y3BLdd0d3DDa3Gn499JwLuG3w36cNZYA8YN0H/6s x-ms-exchange-antispam-messagedata: cdqOJT4hgYo2Kqlq3AcIyXfbOSnGbGm+TasuNb4yMle85hH6LJB3H/aosXlmYQuhxlxmF7MOtFo3iKVn4R1DQlRooWItRwbskiLVvslSKAsugU4uqtbMVn4gAGD3jT6eFbCWaJKUAA0Ub89l3oscdTyyFDnSJYsI+Q6SnxwriNZCqayW8O/i3RTlIMlcJiT/NPHP0EpBt1qv6Zt0fcppHw== Content-Type: multipart/alternative; boundary="_000_AM6PR08MB3318AFD0C1FC4011ED2A81919BD00AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4866 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT042.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:(4636009)(136003)(396003)(346002)(376002)(39860400002)(46966005)(26005)(81156014)(4326008)(70206006)(9686003)(55016002)(47076004)(82740400003)(186003)(336012)(33656002)(86362001)(70586007)(81166007)(5660300002)(316002)(478600001)(82310400002)(8936002)(36906005)(8676002)(6506007)(356005)(54906003)(110136005)(7696005)(52536014)(2906002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 5a799a6b-ccc1-4cbd-2b3f-08d7e89ad874 X-Forefront-PRVS: 03838E948C X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 202m3f/qh9/584Eo7c+A9cgPKaqAz0k2Mna5iMPerywa4ZBvkT8WfFI0/4CDzy1Nb/N1vu1FOCpPQknu1ePKYCyyvWbvZgXG/BVH9xb5R5Vv7uuAH5SSCsHSjyL6V7ZEfNA6SmZmbV0e+s0z0Ht4AviHy/pmxz/WogcYVXBHMWPqeXUsK+a6/5HumX5/QWNBwfKoFHF3xSBmyRfzd+dO0Jd8yM14slSCGxbxM/eYrKjSlBa7wH3esexiw5bIUjy3S+A7L0IOBEXIsSBe9no9MoMB+PjCAV94ww6HscBCXbVe3do5DLcPQyqI0A1sLxmKCFIxzuKdeWeodw7tC3vp60SdgNYmPdkDMmkZawVNtasu0UFro5A6ydaAKy0tv58h+xSBHk1Ph0YEtdffbe+bVn/bw6TTn8i5k8N91V3xkWuwgrF+hx/uCBXngXtc0SDpzs+uOjBXMpE5st+XitI2lGRDdfYfumdwnQzUMBs6ciYYs+/bAgMBq98I3iugHSYjshpxPJghNNbQShp9IpTvQA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Apr 2020 22:00:11.2382 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0f186353-9022-4348-1939-08d7e89adc30 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: DB6PR0801MB1943 Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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, 24 Apr 2020 22:00:22 -0000 --_000_AM6PR08MB3318AFD0C1FC4011ED2A81919BD00AM6PR08MB3318eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Thanks for your input Chris, this is very helpful. Yes, this is the way I see it. I think you can get by with implicitly authe= nticating things, but when you start doing this, the details of how to deco= de the data on the wire begin to really matter for the proof (and potential= ly for an attacker). This can get complicated if, as you say, the header's = content is highly variable. So, I would recommend authenticating what's on = the wire. I don't think it would hurt to authenticate more than this, e.g.,= other fields that the sender and receiver need to agree on. So far I fail to understand, on an intuitive level, why it easier to analyz= e the protocol when the AAD can take multiple forms potentially truncating = or omitting the underlying data, but then I don't know the details and you'= re the expert here. If you have time though to explain a bit more where the= flaw in my thinking below is, that would be great, provided it's possible. For example, another thing which I would expect to be more complicated to v= erify in full rigor is epoch authentication: If the epoch is reduced to its= two low order bits in the DTLS 1.3 header and thus (at the moment) also in= the AAD, arguing that decryption can only succeed for the correctly expand= ed epoch involves knowing that all epochs having different keys. That's of = course true but this fact wouldn't be needed if the full numeric epoch was = always explicitly authenticated in the AAD. This isn't a real issue in the = end, but I would expect it to be a nuisance in a formal proof? In terms of what you mentioned regarding decoding details, it seems that ad= ding the underlying logical header to the AAD ensures more directly that de= cryption can only succeed if header decoding (that is, filling in implicit = data or expanding truncated data) was done correctly, whereas it is less cl= ear with the truncated or omitted data in AAD, as in the epoch example abov= e. Is it possible to explain what the flaw is here intuitively? Thanks again, 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_AM6PR08MB3318AFD0C1FC4011ED2A81919BD00AM6PR08MB3318eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,

Thanks for your input Chris, this is very helpful.

Yes, this is the way I see it. I think you can= get by with implicitly authenticating things, but when you start doing thi= s, the details of how to decode the data on the wire begin to really matter= for the proof (and potentially for an attacker). This can get complicated if, as you say, the header's conten= t is highly variable. So, I would recommend authenticating what's on the wi= re. I don't think it would hurt to authenticate more than this, e.g., other= fields that the sender and receiver need to agree on.

So far I fail to understand, on an intuitive level, why it easier to a= nalyze the protocol when the AAD can take multiple forms potentially trunca= ting or omitting the underlying data, but then I don't know the details and= you're the expert here. If you have time though to explain a bit more where the flaw in my thinking below= is, that would be great, provided it's possible.
 
For example, another thing which I would expect to be more complicated= to verify in full rigor is epoch authentication: If the epoch is reduced t= o its two low order bits in the DTLS 1.3 header and thus (at the moment) al= so in the AAD, arguing that decryption can only succeed for the correctly expanded epoch involves knowing that al= l epochs having different keys. That's of course true but this fact wouldn'= t be needed if the full numeric epoch was always explicitly authenticated i= n the AAD. This isn't a real issue in the end, but I would expect it to be a nuisance in a formal proof?
In terms of what you mentioned regarding decoding details, it seems th= at adding the underlying logical header to the AAD ensures more directly th= at decryption can only succeed if header decoding (that is, filling in impl= icit data or expanding truncated data) was done correctly, whereas it is less clear with the truncated or o= mitted data in AAD, as in the epoch example above. Is it possible to explai= n what the flaw is here intuitively?

Thanks again,
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_AM6PR08MB3318AFD0C1FC4011ED2A81919BD00AM6PR08MB3318eurp_-- From nobody Fri Apr 24 15:32:38 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 439833A0E7C; Fri, 24 Apr 2020 15:32:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <158776753919.28865.11749377146222363611@ietfa.amsl.com> Date: Fri, 24 Apr 2020 15:32:19 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-ticketrequests-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 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, 24 Apr 2020 22:32:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : TLS Ticket Requests Authors : Tommy Pauly David Schinazi Christopher A. Wood Filename : draft-ietf-tls-ticketrequests-05.txt Pages : 8 Date : 2020-04-24 Abstract: TLS session tickets enable stateless connection resumption for clients without server-side, per-client state. Servers vend an arbitrary number of session tickets to clients, at their discretion, upon connection establishment. Clients store and use tickets when resuming future connections. This document describes a mechanism by which clients can specify the desired number of tickets needed for future connections. This extension aims to provide a means for servers to determine the number of tickets to generate in order to reduce ticket waste, while simultaneously priming clients for future connection attempts. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-05 https://datatracker.ietf.org/doc/html/draft-ietf-tls-ticketrequests-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ticketrequests-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Apr 24 16:09:42 2020 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 6B1FF3A0F2E for ; Fri, 24 Apr 2020 16:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=TSAfy63o; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uxjkTU6A 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 aRiwv3X82odS for ; Fri, 24 Apr 2020 16:09:38 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4A63A0F30 for ; Fri, 24 Apr 2020 16:09:38 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 565261BAB; Fri, 24 Apr 2020 19:09:37 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Fri, 24 Apr 2020 19:09:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=OdYlPCuI1WPUbWq5j8QthSuqwDE45Bl VPIx5TUtOXg8=; b=TSAfy63o46koQ5wwxlPP3XvVWL8DhGqiURL6BihehSxSRVA fUogW58qiOGJVHNZQU1yF80Ksht5I3BxiM3RrirLIfXpiDOmdf4FBSoIYuZRUN53 X+sqdggXd3nHRY6rE8MGxGdL4Wa0TR9GBx0b23dqEBxE5FgFeRsPnPWpIcz0fc+Y LH/voHt+tflHwzNpHsYFjFsVTMdvMLs5U8QPNDzgB07nClID/HIHGKbe7aDkRs4n cTsHYUjhQm6SkQUZb5DSC1MDvSJcqnjg4UNqRZ9CYKntFs5Vhp/wcn2Gi+xyE/al iuUHS+X+XBAATIn0BAviEEuWszni2XOh9OiD7Jw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=OdYlPC uI1WPUbWq5j8QthSuqwDE45BlVPIx5TUtOXg8=; b=uxjkTU6AdCaezYPNLSkWwd qMw+OlUMPJjgtLhSTcKZwJ7NEPyvBLxE9Gy+m3lxBeSf1sCFyQM69O8Ng7eMDfjp KSnu+3JSk7xP7HQYkskTCVcYUFBj7kSNaQc+ngPANbgKRsHwzY/xRw+ROvF1q+s4 VoAneMo60wxKIrtMybRGsdRytLj9rJYQWWYf5NQaL29IHBrH2UWmhdyCUxkfSeqc lltWakoiGG6zAQuo51DEybdbyOvnY0+fhEnKCDoujEVYioZMXTcO+GzuIchPuDHf ir8VhLGhJ5MetxPdgtrm25BHZ/85i1WtdGKqPP2wWqtEGCk/2jk/tcHLP40XaB1g == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrhedvgddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfvehhrhhi shhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvghtqe enucffohhmrghinheptghishgtohdrtghomhdphhhtthhpshefrgdvfhdvfhhgihhthhhu sgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7EB073C00A1; Fri, 24 Apr 2020 19:09:36 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <8fd481c1-7edb-4d9c-bc6d-f1a3f67e8bcf@www.fastmail.com> In-Reply-To: References: <96ed3f4c-7ad4-4406-95c9-1e96b5a49eed@www.fastmail.com> Date: Fri, 24 Apr 2020 16:09:15 -0700 From: "Christopher Wood" To: "Hollenbeck, Scott" , "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Comments on draft-ietf-tls-external-psk-importer-04 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, 24 Apr 2020 23:09:41 -0000 On Thu, Apr 23, 2020, at 8:10 AM, Hollenbeck, Scott wrote: > > -----Original Message----- > > From: TLS On Behalf Of Christopher Wood > > Sent: Tuesday, April 21, 2020 9:57 PM > > To: TLS@ietf.org > > Subject: [EXTERNAL] Re: [TLS] Comments on draft-ietf-tls-external-psk- > > importer-04 > > > > Thanks for the feedback, Scott! Please see inline below. > > > > On Tue, Apr 21, 2020, at 6:57 AM, Hollenbeck, Scott wrote: > > > 2. Technical comments. > > > > > > a. Distinct identities? Sec. 3 states "Non-imported and imported PSKs > > > are distinct since their identities are different on the wire." We > > > have two concerns about this statement. First, the statement appears > > > to suggest that if two EPSKs have different identities, then they must > > > have different secret values. But couldn't two EPSKs have the same > > > secret value yet employ different identities for convenience? For > > > example, an endpoint might identify the same EPSK with a domain name > > > in some cases and with an IP address in others. > > > > This seems like a reasonable editorial improvement to make. I filed: > > > > https://secure-web.cisco.com/1WQM3tDUuuSkXPZ- > > qwaA2YKrAcqlkOAsqUSqvQThf6zv7T7Gi7ofekeY-6UPrqcF1k5cW- > > i8pc5KYZ8GDkbBhgNSydezOTkChVTOsIlACtvE0hnca9DN7D056URvddDaO54LI > > jMM4o4hOFRlCHReLnVJ4g90Pm0foS9AAaeBQK2w1oTQNJrx9B6EqDlIvn3- > > Sh3oF_cBDlKk0XXLyJYWRZRflbYw3Tg1Ga8HPzfUZf- > > qJqqQquKG5sEsl_vdKIQbyIVGSYJVTTx6x- > > viXGJXTsQ/https%3A%2F%2Fgithub.com%2Ftlswg%2Fdraft-ietf-tls-external- > > psk-importer%2Fissues%2F31 > > Thanks! > > > > Second, and more > > > fundamentally, the statement assumes that a non-imported EPSK, by > > > definition, cannot be misinterpreted as an imported PSK. But isn't > > > the identifier of a non-imported EPSK just an opaque string? A > > > non-imported EPSK identity could therefore have the same "bits on the > > > wire" as an IPSK identity, if the client and server employ an > > > identifier system that whose encoding happens to coincide with the > > > ImportedIdentity structure defined in the draft. ( Moreover, the > > > identifier of a resumption PSK is just an opaque string > > > -- so couldn't this also collide with ImportedIdentity values? > > > Perhaps we are missing something even more fundamental in our > > > reading.) ([draft-dt-tls-external-psk-guidance-01] covers similar > > > issues in its Sec. 6.1.2, "PSK Identity Collisions.") > > > > Yes, certainly it's possible for a non-imported EPSK to have an identity which > > matches the constructed identity of an imported PSK. We can't do anything > > to prevent applications from crafting such identities, so I'm inclined to just > > note this as a possibility, if anything. > > A note would be fine. > > > > b. Attack impact. If it's possible for an opaque identifier for a > > > non-imported EPSK identity to have the same encoding as an > > > ImportedIdentity value, then how does the server recognize > > > unambiguously that the opaque identifier is intended to be an imported > > > identity? The server could take an optimistic approach and assume > > > that an identifier that meets the ImportedIdentity syntax is probably > > > an imported identity, and run the code path for imported identities first. > > > > Yep, that's what I envisioned servers would do. > > > > > If that path fails, however -- either because the server doesn't > > > accept the EPSK or associated parameters, or because the binder value > > > is incorrect -- then the server may need to run the code path for > > > non-imported identities as a fallback, checking next to see if the > > > opaque string is recognized as an ordinary EPSK identity. But this > > > practice just puts more burden on a server against an attacker who > > > replays (or makes up) the PSKIdentity.identity value: two code paths > > > are exercised for the price of one attempted handshake. > > > > I don't think this is a particularly useful attack, though I do agree that it causes > > more work for the server. I'm curious to hear what others think. > > > > > c. Mitigations. One way to reduce the burden is to impose a new > > > requirement that the opaque string can only have the ImportedIdentity > > > syntax if the client (or server in the case of hints) indeed intends > > > to use the import mechanism. An ordinary EPSK could have any other > > > value, just not this kind. But this may not be compatible with the > > > installed base, especially with implementations that allow clients and > > > servers to specify arbitrary EPSK identities. (Consider the case where > > > an application adopts the imported identity syntax for the use > > > intended in this draft, and then decides to reuse the syntax for other > > > purposes, including ordinary EPSK identities.) > > > > > > Another way to ensure distinctness is to add a flag that indicates > > > that the PSK identity is an imported identity. But it's not clear > > > where this flag would go, given that the PskIdentity syntax isn't extensible. > > > Perhaps there could be an overall flag indicating that _all PSK > > > identities are imported identities? Or a new extension for imported > > > PSKs? > > > > Since this draft is meant to fix an annoyance in TLS 1.3, I think anything more > > than a different Identity encoding is overkill. I absolutely agree that the > > rigidity of PskIdentity is something we might want to fix. I'm just not sure > > that should be done here. > > Agreed, this would be a larger discussion. Just wanting to be sure the > concern was noted in the document. > > > > d. Key separation. Note that the foregoing discussion about EPSK > > > identifiers potentially colliding is separate from the question about > > > what happens if an IPSK happens to collide with a non-imported EPSK. > > > The draft handles this effectively with different inputs to the binder > > > derivation ("ext binder" vs. "imp binder"). But this happens after > > > the implementation has already decided whether to interpret the > > > identifier as external or imported. > > > > > > e. Incremental deployment. Section 6 states that " the derived PSK > > > will not be the same [as the underlying EPSK] since the importer > > > differentiates the PSK via the identity, target protocol and target > > > key KDF." However, the next statement does not follow directly: > > > "Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS > > > 1.2, and thereby avoid cross-protocol collisions." Rather, the > > > statement also depends on the requirement in Section 3 that clients > > > (and servers) don't deliberately use EPSKs or IPSKs for other > > > purposes, and the security properties of the KDF that produces the IPSK > > (which ensures > > > that collisions don't occur accidentally). But there also seems to be > > > an implication in Section 6 that the use of the KDF in the TLS 1.3 > > > importer doesn't conflict with the cryptographic functions used for > > > obtaining the TLS 1.2 pre-master secret. If so, this distinction > > > should be spelled out. > > > > Hmm, not quite. The statement intends to say that if you need EPSK k into an > > importer and into TLS 1.2 then the resulting keys used in TLS 1.3 and 1.2 are > > different. I'm not sure further clarification is needed, though I'm happy to > > review suggestions if you have them! > > Agree with that as the goal. Here's our concern in brief. If our > understanding is correct, prior to this draft, the client could use an > EPSK k in two ways: > > * as input to the TLS 1.2 PRF (based on any hash function) > * as input to the TLS 1.3 key schedule via HKDF-extract (based on a > single hash function) > > Following this draft, the client could use k in two ways: > > * as input to the TLS 1.2 PRF (based on any hash function) [same as > before] > * as input to the importer function via HKDF-extract (based on a single > hash function) > > So there is still a potential cryptographic overlap in the use of k > between TLS 1.2 and TLS 1.3. The imported keys don't have this > overlap, because they're separated from one another and from the > underlying EPSK through the use of the importer function. But doesn't > the security proof for k still need to take into account that the input > to HKDF-extract might also be input to the TLS 1.2 PRF (with the same > or a different hash function)? > > In other words, if it was a problem for the security proof that k could > be input to the PRF and to HKDF-extract before the draft, isn't it > still a problem afterwards? The conclusion that there are no > cross-protocol collisions depends on the specifics of the TLS 1.2 PRF > and how it's used, compared to HKDF-extract. > > We're not suggesting there is any attack here, just trying to > understand the design actually addresses the statement in the > introduction that k "could possibly be re-used in two different > contexts with the same hash functions during key derivation". For lack of a better way to describe this (sorry!), we're trying to avoid this input collision during the key derivation process of a TLS connection. As the importer happens before a connection, and can be viewed as part of the provisioning process that produces unique PSKs for each target hash function, we achieve the goal for TLS 1.3 of not re-using a PSK with different hash functions. I'm not sure how to better clarify that right now, so suggestions are very much welcome. Best, Chris From nobody Fri Apr 24 16:50:10 2020 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 2301F3A101C for ; Fri, 24 Apr 2020 16:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=iLucxNek; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=1BpFiiLR 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 cs3EtXLAydba for ; Fri, 24 Apr 2020 16:50:07 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C133A0FE6 for ; Fri, 24 Apr 2020 16:50:06 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 64C8E1516 for ; Fri, 24 Apr 2020 19:50:06 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Fri, 24 Apr 2020 19:50:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=k1+sd1evY4obiDq0MrSDTgO4a8JiHSK lU++ACcV7SMg=; b=iLucxNekYkvzFOwBzUKVV/ulAygfyqV4chGpJOWYF6w4B9y C12zmLvZbGPEuYztPLML3iqpvAYO/6uSgkvIG6elATGhBXDqpZrOvCKXtDeWg994 aloIyE9D4GfypWd7rlI5NPvi1QJTh2z1+XIpAwshYutsQchw18JubV8gKtOw8NhZ uwS3srfH9Qz9JEfUTkAj/C6d+Of+ss78cInj1CSOuswjiC7qFVrB+nwt5WhBdKJx T+sqFswNqD4+uFrCnktwWV8aZUOxXoQQ6Xj3FSVix+tA9A0Fd2/CHMLmeNTm8qDR xCS2A/3wZ2S8H88PS7HIQBDbzwYv/LdKojlLDaw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=k1+sd1 evY4obiDq0MrSDTgO4a8JiHSKlU++ACcV7SMg=; b=1BpFiiLRcNJ8Fj4cz1AHCK k1bk+AB4ZinNBGsJkgR+Cfp4RC/6/nsyVYZpYrv6qXewTkR15CQ7slPRode+ZkNl Kfq0yyg/GHRci15fm48zCpNd7aGxaA8lhSw+dbhw6jx+wiojzjqPQSkkwmnci+Ll lNaZWNlvm2gtcxkTHWA2k5HqAVHObSeKe+XygjvOewTU42xpCTOeBwvvNsEaXbKJ R1I36Op4mDHgnM2t9A+qkEevwxlSu1hTdRUXtjlRntZn/iM1uViUNMrn6xVGbVgS DbXRkRLrV4LQbuwHfNeXIurJCiPwcBcVo3lP6gFvFVZmF7qMOx930cDq74zYwLUw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrhedvgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id BDC053C00A1; Fri, 24 Apr 2020 19:50:05 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <74b2a6ca-0904-4ce6-9334-33d06339f253@www.fastmail.com> In-Reply-To: References: <04c48f22-4475-42fc-bbc9-980523875319@www.fastmail.com> Date: Fri, 24 Apr 2020 16:49:44 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Implicit ACKs in post-handshake 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, 24 Apr 2020 23:50:08 -0000 On Thu, Apr 23, 2020, at 5:23 PM, Eric Rescorla wrote: > > > On Thu, Apr 23, 2020 at 4:58 PM Martin Thomson wrote: > > What makes this case interesting is the non-machine time that might exist between receiving CertificateRequest and sending Certificate. > > > > In most of the exchanges, we expect there to be an answer that is immediately available, so that the implicit ACK works. Here we have to recognize that ACK might need to be sent anyway if the Certificate message is going to take time to source. > > > > If we don't have something already, it might pay to at least mention that if there are significant delays involved in preparing a response, an ACK SHOULD be sent rather than relying on implicit acknowledgment. > > That text is already there, thanks to Hanno. Indeed. Given this recent addition, perhaps it's easiest to do nothing. Best, Chris (no hat) From nobody Fri Apr 24 17:30:39 2020 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 94F553A11EB for ; Fri, 24 Apr 2020 17:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=TJVrTKsm; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dfWAD8zC 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 ehW-6RhVsIR8 for ; Fri, 24 Apr 2020 17:30:36 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FF0A3A11E9 for ; Fri, 24 Apr 2020 17:30:36 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3279C5C0197 for ; Fri, 24 Apr 2020 20:30:35 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Fri, 24 Apr 2020 20:30:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=jsoAm2WTwjZB5Z5N5XYQvs6fRyvYYut MHSYwf9QA60o=; b=TJVrTKsm1GiuYnWdjr7SeVCsEcE6H+ofzkIc91YSOnbqlDQ 1f5kHsQwpT8QUW6ShqF4FEO7O7L9e7g4UZv+BF47U/9aP1+gDZFUdLX86tJqZU3O gXZGNiRk/fLQ8JJ4z6RCBYHXMKsh18BrL7qCj093ZYzj6TMQm81oLxNlNjDUdXiD 4OMU4KK0RyC4WY5XXQY3z+mnYji3pY13W+glddnOTYhhtxoKrwLHSMyFS7rsVz2o iiF0wi9dgVlryjYTFKTOUD/wDKygooNholnLZIGhd+QNf/reMZkExEC0cw+mui1x rPNnhKIXTbHAp7hOiB3kIXT5Q6pueVcUliEJkaA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=jsoAm2 WTwjZB5Z5N5XYQvs6fRyvYYutMHSYwf9QA60o=; b=dfWAD8zCu0oW8BbXh6ZTBD jG9sFbURIQT6VK09OKerhfo8jRlbgMGLFt8tJ930ByE4PznV854mUmvC8Wgi7EXq t0GDu/WX0n9LEli+oCZ2DpPQj4kcncHQETU0A2ISo75LrZl7tkdUABqn/PHeh/PK GswiYNwRsSRCINcbmBeGqKVr6pRSIqvW7Aa3+Bij4S1LWkDrBgaNsHuM96DG+9+q bcydMcaX66BsvCGDjOTL8AI96vvjCEyC7xZgXM6e9hPQmaUgpba1nhcWtH5ALbjl YpbsWL1Ab9SxjDYeMNsbzCjequYAoedSvqWHBYk+nHyWU5k3t4osAAXMBwQcfJ8A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrhedvgdefhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrg hrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CAEE73C00A1; Fri, 24 Apr 2020 20:30:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com> <1e6201d6-a078-4137-898d-d1554c22aa10@www.fastmail.com> Date: Fri, 24 Apr 2020 17:30:14 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Sat, 25 Apr 2020 00:30:38 -0000 On Thu, Apr 23, 2020, at 2:17 PM, Eric Rescorla wrote: > On Thu, Apr 23, 2020 at 12:40 AM Martin Thomson wrote: > > On Thu, Apr 23, 2020, at 11:49, Eric Rescorla wrote: > > > OK but we would expect the peer to process CID-less records if they are > > > coalesced? > > > > I guess so. If we allowed them to drop them, then we're close to saying MUST NOT omit. > > Yeah, I would make three points > > 1. Allowing implicit CIDs is very recent (it was introduced in -34) > 2. The CID specification explicitly prohibits it for DTLS 1.2. > 3. I haven't really heard a very compelling argument for this and I > note that QUIC forbids it [and in fact has much worse problems when you > mix epochs because the long header is so long] > > So, given that the simplest and most consistent thing is to simply > forbid it: can someone make an argument for why this is important to > permit? Thanks to everyone who participated in this thread so far! Given the points above, the chairs would like to hear arguments in favor of implicit CIDs. Absent substantial rationale, we'll assume rough consensus for explicit CIDs. Best, Chris, on behalf of the chairs From nobody Sat Apr 25 03:11:43 2020 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 5356D3A08E6 for ; Sat, 25 Apr 2020 03:11:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.82, 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=nuosombT; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=nuosombT 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 5B81d2GFr4g7 for ; Sat, 25 Apr 2020 03:11:40 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2074.outbound.protection.outlook.com [40.107.21.74]) (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 EF5583A08E4 for ; Sat, 25 Apr 2020 03:11:39 -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=++a+PR15t/ciQzBD6GPwegYejV+o+FMCrnBa0nY2Ihc=; b=nuosombToJDlzWFNyHIOqxoujiY0PTxGSK7Dpa60MrN0IZc/Yoc+WDFpbFX6qjeRQkon9HknvYyYvn/AgIYsHbf56WxWxP5qi+5U2UCpkUHzFqrOpyz4orVqUMc50pptewD+EnpBmYyQ7Nc1vUJacVQBgkgfNUrA+Hpn8yCkpuc= Received: from AM6P192CA0088.EURP192.PROD.OUTLOOK.COM (2603:10a6:209:8d::29) by DB6PR0802MB2134.eurprd08.prod.outlook.com (2603:10a6:4:83::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Sat, 25 Apr 2020 10:11:37 +0000 Received: from AM5EUR03FT056.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8d:cafe::ca) by AM6P192CA0088.outlook.office365.com (2603:10a6:209:8d::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Sat, 25 Apr 2020 10:11:37 +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 AM5EUR03FT056.mail.protection.outlook.com (10.152.17.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Sat, 25 Apr 2020 10:11:36 +0000 Received: ("Tessian outbound e88319d7ccd0:v54"); Sat, 25 Apr 2020 10:11:36 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: c0c570dec3e9609b X-CR-MTA-TID: 64aa7808 Received: from 970cf4210ab5.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 975287D5-FE8C-45A3-9AF7-0EFB7A49A35A.1; Sat, 25 Apr 2020 10:11:31 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 970cf4210ab5.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Sat, 25 Apr 2020 10:11:31 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KzmLysYbUR1G2UyfNRSjy9vCKzsZKjxNo3J2+VY8wQ8W5o1yTbmvIwoEj5JpLeLyMUfH+VgOjoUuc1JL28Cw5PGF6xvzyW5/OvkRf+YiIWIm0RQ1OUgUbcaBfnWMHbzNwGwsrMI1lRe+M+t41UCos/9tVsi0jl32awO6LxWxGUmi6HGU5GWw3YKMLrzVYIqcGNETQIdv/W0opaV5eFzFcZ5KoBSJHeLViOZ4GUMYwC/rmN+n3SMuTzHm7KjETOT3I6hWxJq7YwR2mPivQuzIlbuwtVnbT0RMxBWGGML0uRLypFfUgMrg/8jpvZ97vMimRq4pW+nD9OF0S3IRA80dYQ== 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=++a+PR15t/ciQzBD6GPwegYejV+o+FMCrnBa0nY2Ihc=; b=I2OhE65WV+fECNCE2XLOOEkoO4/5enPVbCINCRIEeMCd9a+bxw/s4FmA4lOe1ERUAbnAkYfhriXAOtuRGIzge2w/WLfCI4N1QzpM/G8eysbVWaavq8g2KvlTSZAk0WDRMviqG6mwsXunKucwtV2JmzRcugvNhhnew99n1vRBGfLGJ9fChtW97iR0CtAYcwdHlBFO3/sb8hljyvZMJgQxe3tp+FF70BBp2e25n52RMTTeU+i6tOlutSjRLgxVANGE/Rshd5AqvRluWEPjCk+pU5LQND31nby5DZnxGx09OEjS6bg0UD+zPwuNJJPPvUnxrgJ9at2rC8xJPkqig3RXYQ== 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=++a+PR15t/ciQzBD6GPwegYejV+o+FMCrnBa0nY2Ihc=; b=nuosombToJDlzWFNyHIOqxoujiY0PTxGSK7Dpa60MrN0IZc/Yoc+WDFpbFX6qjeRQkon9HknvYyYvn/AgIYsHbf56WxWxP5qi+5U2UCpkUHzFqrOpyz4orVqUMc50pptewD+EnpBmYyQ7Nc1vUJacVQBgkgfNUrA+Hpn8yCkpuc= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB3400.eurprd08.prod.outlook.com (2603:10a6:20b:42::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Sat, 25 Apr 2020 10:11:30 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d%6]) with mapi id 15.20.2937.020; Sat, 25 Apr 2020 10:11:29 +0000 From: Thomas Fossati To: Christopher Wood , "tls@ietf.org" Thread-Topic: [TLS] DTLS 1.3 AEAD additional data Thread-Index: AQHWF+iN1gKILcDltkmRr5OfopCaAaiD3VMAgAB8FQCAAE7VmIAAawyAgAAHdS6AAB8+AIAACQCRgACPx4CAABkpAIAABDCAgAAC0ICAAEL8/IAAHxqAgADkdgCAAcgWAIAAsyqA Date: Sat, 25 Apr 2020 10:11:29 +0000 Message-ID: References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com> <1e6201d6-a078-4137-898d-d1554c22aa10@www.fastmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 1bb43b70-d788-4be7-de2f-08d7e9010a04 x-ms-traffictypediagnostic: AM6PR08MB3400:|AM6PR08MB3400:|DB6PR0802MB2134: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0384275935 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(376002)(346002)(396003)(366004)(136003)(6506007)(66476007)(53546011)(8676002)(6512007)(64756008)(66446008)(66556008)(186003)(76116006)(5660300002)(2616005)(91956017)(478600001)(33656002)(2906002)(8936002)(71200400001)(6486002)(4326008)(66946007)(81156014)(86362001)(36756003)(316002)(110136005)(26005); 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: PXmiv+P5XB53yE5MquEXQS/ap1JpJNWshiEu+6yYRNKsaRkfougp9mHf653n+UXsQAclfVlhEN1TBBlSMglgASxdAjzoniSIi0w/1KSZLkOjBww5bhipzPWK9UhMAFgU+XThrj5GzkLN0CQ6cUXFwCEURyKlXgMrmSjJZomc2hW6XNh1C8WSWsf5Hmsih6QMewKgnAQUfLfIIzTOzN7V+m1fLw8yUFw/fYbY4Iu3+nPqdKzLPD3vFdrxVg8gov6RyfF5QNAAOrTj7uFGl0exFNvOJc3I3BegIR2wmo1f74vAzuik8f44CNqLUxhBqQ0RZrgEQbIQh32rs82kOfvG1uwcdle2O7UWC/kwZ8p8Bz49aX5rXeNZqUhYtnjClEwP4FTTrNF7y1Y/mwnRjmkPhjMRDO8DICjueOuS3rl8EBH89LpnYZYMxoVQDV+0Cznh x-ms-exchange-antispam-messagedata: 7hNAhnAs3Ndota/PqZaRwg2J3k2edcS3lIIXM5DzF2aqOpFL5YF+QWR8GBAtyZ1rOi8QdzF8h7CIrBegs7vWdFjwl2hpNKnRLPHY6xUlCw+KBbzuGpJRfREZhhjCu1DnNtSzZ1kBCtyulbaOFbv6SZCUiEyT60sa40DcBCP25TwUtUfBT0n5VFP/+NZK3DkrpaIIoa5Ijq61PSlQ49yJKr22DzAOExKopqaHSO/N7MMRX7LgzuhSrPmoKrdGGqhZXCIDF8WuYy5elahUeiMyGkbzwhX1hNqfTOo1oM7s+B4adyNf4caAIEXsCuyOJ5zYMZn5zeg9W/YgUlOIZX/w/LpGwB55Gc9YJ0l1bZN0pSfjsK4s8USBfhVdEr5fwH4l68FyUJ4OosmJfZ4+uaDP1MKizOI749bMMRYdtnTJM6mhRZbhyyvbDP4RkVx7ECa9XJgH8rq5rw51Mg8Ft+4SOR0iWBwu4QY6I24wCEmsnx/sVrlnhPjy/nvwdUAoJxB9PLUf9Z86Y5kjFvRAFc2W1seH3bKgsONJ68RdOE1OTDIq3GgPFYEBmukoNXvfV0x+VWzEgP4ap57pzXHy5Soygk6xoU4S4EK/jFxxJmVygHKCuVZtq8MridO4jVNmuI/ieF1s+2QqUxXs96Y6hv9HOAjAi980iEoIiDY7FpTmLYHlltvuovDujBNy5hrRHB9YcxJhFU1ef4L5yYzpK4M0Q1C9qceV4vVsE8Vtg2U7XF4NGj7h2WRtoV/IRNRziwPolo/8SCo+xyfGz1LSCj7UP34CsLLCiwx3hdc6RWF22xo= Content-Type: text/plain; charset="utf-8" Content-ID: <9AD2AFF919A2254CBCCAF71840F78B47@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3400 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT056.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:(4636009)(346002)(136003)(376002)(39860400002)(396003)(46966005)(110136005)(6486002)(186003)(86362001)(53546011)(5660300002)(36756003)(316002)(2616005)(6506007)(36906005)(336012)(81156014)(8936002)(8676002)(82740400003)(47076004)(82310400002)(81166007)(6512007)(478600001)(2906002)(356005)(70206006)(4326008)(70586007)(26005)(33656002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 1373bbcb-805b-4589-c2da-08d7e90105e2 X-Forefront-PRVS: 0384275935 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rBAlqFunvgRIUTmDOVyb7phgqShFLsNy8r7l4Y9tLDD0ssab5Kdj5C4HyLUST2+r3DSVNaPAQGNndeLhoJIIN1iBHBLNatWJOR45ZrLWtNqZHMeIEe32smGtWepRkKlwGWCPQNORqPH/4qNWa99I90566Vn8WTOdeSM65CjEIyChzxEyyxPgzRay7owQ0xKzRiNlD+7oEocG5t+BGCJxlMMmj5ilJbQRzUxBdC5h+mJJqSmArlzTH7GhpsVRo91lG9fp44fjxeC/3onddp53l6Y+yxQ/ux+NaCUudqMm68drAfYWdpZV2ew0wpsIdnzl54fBnc34I+j63Ax9gDbvQZzMnxxYmI15yqp2ilNlxtnI9AwueHa7FY9J2b7Eo/Jy46ssU3MzDnEMP8DJSX23v5VtagttjOBDiY/xZG/BDXyLI3BKn0cVVc8VRVMJIu5vu8FYvI5Y6crG5hOzfHwWn5bUUq2WYtsUq2lIit3i6tkzl45IUgW91forABL4T0YUbsQ1iZLszkhXPuq8qFNSWw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2020 10:11:36.7895 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1bb43b70-d788-4be7-de2f-08d7e9010a04 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: DB6PR0802MB2134 Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Sat, 25 Apr 2020 10:11:42 -0000 T24gMjUvMDQvMjAyMCwgMDE6MzAsICJDaHJpc3RvcGhlciBXb29kIiA8Y2F3QGhlYXBpbmdiaXRz Lm5ldD4gd3JvdGU6DQo+IE9uIFRodSwgQXByIDIzLCAyMDIwLCBhdCAyOjE3IFBNLCBFcmljIFJl c2NvcmxhIHdyb3RlOg0KPiA+IDEuIEFsbG93aW5nIGltcGxpY2l0IENJRHMgaXMgdmVyeSByZWNl bnQgKGl0IHdhcyBpbnRyb2R1Y2VkIGluIC0zNCkNCj4gPiAyLiBUaGUgQ0lEIHNwZWNpZmljYXRp b24gZXhwbGljaXRseSBwcm9oaWJpdHMgaXQgZm9yIERUTFMgMS4yLiAgMy4gSQ0KPiA+IGhhdmVu J3QgcmVhbGx5IGhlYXJkIGEgdmVyeSBjb21wZWxsaW5nIGFyZ3VtZW50IGZvciB0aGlzIGFuZCBJ IG5vdGUNCj4gPiB0aGF0IFFVSUMgZm9yYmlkcyBpdCBbYW5kIGluIGZhY3QgaGFzIG11Y2ggd29y c2UgcHJvYmxlbXMgd2hlbiB5b3UNCj4gPiBtaXggZXBvY2hzIGJlY2F1c2UgdGhlIGxvbmcgaGVh ZGVyIGlzIHNvIGxvbmddDQo+ID4NCj4gPiBTbywgZ2l2ZW4gdGhhdCB0aGUgc2ltcGxlc3QgYW5k IG1vc3QgY29uc2lzdGVudCB0aGluZyBpcyB0byBzaW1wbHkNCj4gPiBmb3JiaWQgaXQ6IGNhbiBz b21lb25lIG1ha2UgYW4gYXJndW1lbnQgZm9yIHdoeSB0aGlzIGlzIGltcG9ydGFudCB0bw0KPiA+ IHBlcm1pdD8NCj4NCj4gVGhhbmtzIHRvIGV2ZXJ5b25lIHdobyBwYXJ0aWNpcGF0ZWQgaW4gdGhp cyB0aHJlYWQgc28gZmFyISBHaXZlbiB0aGUNCj4gcG9pbnRzIGFib3ZlLCB0aGUgY2hhaXJzIHdv dWxkIGxpa2UgdG8gaGVhciBhcmd1bWVudHMgaW4gZmF2b3Igb2YNCj4gaW1wbGljaXQgQ0lEcy4g QWJzZW50IHN1YnN0YW50aWFsIHJhdGlvbmFsZSwgd2UnbGwgYXNzdW1lIHJvdWdoDQo+IGNvbnNl bnN1cyBmb3IgZXhwbGljaXQgQ0lEcy4NCg0KSGkgQ2hyaXMsIEkgdGhpbmsgaW1wbGljaXQgQ0lE IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQgaW4gdGhlIHdpZGVyIHNjb3BlDQpvZiB1bmlmaWVkX2hk ciBjb21wcmVzc2lvbiwgdG9nZXRoZXIgd2l0aCBpbXBsaWNpdCBsZW5ndGggYW5kIHNob3J0ZW5l ZA0KZXBvY2guICBJbiBwYXJ0aWN1bGFyLCBmcm9tIENocmlzIFAncyBlbWFpbHMgSSB1bmRlcnN0 YW5kIHRoYXQgYmVpbmcNCmFibGUgdG8gYXV0aGVudGljYXRlIHJlY29yZHMnIGxlbmd0aCBpcyBh IGNvcmUgYXNzdW1wdGlvbiBpbiB0aGUNCnNlY3VyaXR5IHByb29mIG9mIFRMUy4gIFRoZXJlZm9y ZSBsZWF2aW5nIGl0IG91dCBmcm9tIERUTFMgQUFEIHdoZW4gaXQncw0Kbm90IGluIHRoZSBoZWFk ZXIgbG9va3MgbGlrZSBhIHByZXR0eSBiYWQgaWRlYS4gIElmIHRoaXMgaXMgdGhlIGNhc2UNCihp LmUuIHRoZSBmYWN0IHRoYXQgdGhlIHdpcmUgaW1hZ2UgYnkgaXRzZWxmIGlzIG5vdCBzdWZmaWNp ZW50IGlucHV0IHRvDQp0aGUgQUFEKSwgdGhlbiBhdXRoZW50aWNhdGluZyBpbXBsaWNpdCBDSURz IHNob3VsZCBqdXN0IGNvbWUgaW4gdGhlIHNhbWUNCmJ1bmRsZS4NCg0KSU1QT1JUQU5UIE5PVElD RTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29u ZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkg YW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNl IGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4g YW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Sat Apr 25 03:41:18 2020 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 DCF823A0A01 for ; Sat, 25 Apr 2020 03:41:15 -0700 (PDT) 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, 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=y/0AP4b0; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=y/0AP4b0 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 NBmfIQqOz2Y2 for ; Sat, 25 Apr 2020 03:41:14 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150053.outbound.protection.outlook.com [40.107.15.53]) (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 C21183A09F1 for ; Sat, 25 Apr 2020 03:41:13 -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=FhnETYQw/Y5tm3E0WDf70VrLPRJkeFUOjVlzs+7y3Rk=; b=y/0AP4b0KB+jr64DVQB86DntMC8dwDmmtjU/OMDz6YdRatP1pT5v0uVBY1dMRHACdgh0aQphs65Whd0dgsz8w53r5OylPzUiQTS/yoYGWQ0kj4J405yU6TJXKZSle+2I0JInK7F1MHcABLLyeuhWWqpWVwboUM/h+VZnZgrRUjY= Received: from AM6PR10CA0098.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:209:8c::39) by AM0PR08MB3139.eurprd08.prod.outlook.com (2603:10a6:208:5d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Sat, 25 Apr 2020 10:41:11 +0000 Received: from VE1EUR03FT054.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8c:cafe::7b) by AM6PR10CA0098.outlook.office365.com (2603:10a6:209:8c::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Sat, 25 Apr 2020 10:41:11 +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 VE1EUR03FT054.mail.protection.outlook.com (10.152.19.64) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Sat, 25 Apr 2020 10:41:08 +0000 Received: ("Tessian outbound 4cdf5642225a:v54"); Sat, 25 Apr 2020 10:41:08 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 40eadf2ace2dd633 X-CR-MTA-TID: 64aa7808 Received: from 1a7b04ba0168.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id F35D2151-01AB-4600-9247-81E091BEB0ED.1; Sat, 25 Apr 2020 10:41:02 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 1a7b04ba0168.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Sat, 25 Apr 2020 10:41:02 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BP2AEEVNf5WFFQ4zd3f3r7/FwmqnbTGbG6vB6FFiEUB5dmPGaphmx+p+bdu+bq3L6fzWkx/xg2eEwnVyr9PokvGIkSbc47FWEvB2kKwx60JnzHgYHyR44N8PF94TPcvi2wHMgJSDISz834leGvS6A1ETQcI2XSenWJe3eVvxTMC6LvLJ5mJtH4Fb5iO+i558oMUYnTB0zoe7fltMXi7trc9CamRFQ0hit/eFxDLCSEkVXAtixWBips/kjOD8H5PNcld1MSKYsHx9LD7dBObOlFHJwphs17bnzQ4vrZDxhnS3z1+/L57aesJhhdSZG4iu9dN4y7/ddiJBhXRsoPdvbA== 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=FhnETYQw/Y5tm3E0WDf70VrLPRJkeFUOjVlzs+7y3Rk=; b=ELiVLHDNo2GhbjKgP4ZPyXKVJ9DujAKLD0ccBLiq6Rv+H8iqKz/q8UuAS9FmFUDVBtdCG5hNcp2MbAxDjuDT+fj8n5nObHdyJxjsIxGntFq5fdXeEvqy3q3El+wOeu8CEuVCVYZ/lDXhvUqktYwRodzGTC++HNNyYpXetvwkTpNYpzv0NrqP7rzeRfxbixNcn5mrh9LMs1gKnVhGfAR0zm4pLecrKO4c1ZUX560Guw3uUDsQrnxehplCqDPXG/fXro5q7EAWjJZ+DMysBB4W/bnLau7hgTs5UPibd/ODTD7wfgZbFeIDFGzsKsaJ7Ov8zlJ9ysqapZ0S03PwJEu2Ig== 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=FhnETYQw/Y5tm3E0WDf70VrLPRJkeFUOjVlzs+7y3Rk=; b=y/0AP4b0KB+jr64DVQB86DntMC8dwDmmtjU/OMDz6YdRatP1pT5v0uVBY1dMRHACdgh0aQphs65Whd0dgsz8w53r5OylPzUiQTS/yoYGWQ0kj4J405yU6TJXKZSle+2I0JInK7F1MHcABLLyeuhWWqpWVwboUM/h+VZnZgrRUjY= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB3397.eurprd08.prod.outlook.com (2603:10a6:20b:43::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Sat, 25 Apr 2020 10:41:01 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d%6]) with mapi id 15.20.2937.020; Sat, 25 Apr 2020 10:41:01 +0000 From: Thomas Fossati To: Eric Rescorla , chris - CC: "tls@ietf.org" , Thomas Fossati Thread-Topic: [TLS] Choice of Additional Data Computation Thread-Index: AdYaKASVCp3JPFQuSaOSMkwtz/VZZwAEUEsAAAN7oaAAAnFQAAAASY9CAAFcJQAAAoyFgAAAY+d9AADW9gAAAKxogAAEWbaA///8NYCAAA0dgIAAAW+AgADsegA= Date: Sat, 25 Apr 2020 10:41:00 +0000 Message-ID: <9B719965-F763-4DDD-9961-56930017EBEC@arm.com> References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 75ad719b-fb0a-47be-adf1-08d7e9052a37 x-ms-traffictypediagnostic: AM6PR08MB3397:|AM6PR08MB3397:|AM0PR08MB3139: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:10000; x-forefront-prvs: 0384275935 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(366004)(376002)(396003)(136003)(91956017)(76116006)(186003)(66946007)(53546011)(26005)(64756008)(2906002)(71200400001)(36756003)(66476007)(4326008)(66446008)(2616005)(66556008)(8676002)(86362001)(54906003)(8936002)(110136005)(6512007)(5660300002)(81156014)(6486002)(478600001)(316002)(6506007)(33656002); 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: NmEaSBuYwrCEA7IFWmL+qTxAUQfvksabcXfPluNx95dju0Nm0MXangA+0UOTYMtLZXTff+9yNyKhsooe0VO0cv2A0z8edVJSeb4L9M6jIhsBK5qwshACauhsKN/FSMfT3fYXR9lB/tXp2xVd6xDljfpeXFLi380r8cb2+Tm2QBLPHks360XEpQh7CkwlvDHLJPSiGIwnA/cCbOe57IYtnqs+9Bs6JqWXKb3oiP4s+VL6j++FIVXf9wbRIHwQt7XbPFyGi62M2tX63WqgIWqQaO8kfBfAExr6HPNOltVsC5wweNm8qNG0KYNR7T7P7fzj+lQMr4iX7gbaxGdUbcR/zQYh6cx9kQpnc8fzDBbQ3lfFdhoVWYlczsuWw5mlZDhVSxDoOFyIb7WrI6jL9RyEYdf8UiDLuRdaVS35t6+4bjb3aKs83lI9Dwy0cIdlri7c x-ms-exchange-antispam-messagedata: 9FhWgA6bK0SxvIdjlJGMsIdwu35fkwsWgo0fkYbDLnG7NLsTh7JOfuRdyY00J0PNR/T3MWo2cP1ehYVtzx3ns28ra5jsS7DmOA2SN5fKrbr19n6R84tz5RNDUJbXmS2z/L68oG4oXiOGAxgZxHvkDxGhw/L6apuSCbhtv3MA0YiNTCWs/QRl5kmn07GylQKIJjLORjlftLfL6MG2DCcdvYQl//SVpX1ib29UZr3ZXtRRKY0TEjFDV8bLOKtly98pxykXffL3a8qocbYDJVhgwTO5e/aWkE0HtFqluaKcgn0LS7VxSb6dBoPp5raZLz7qj4vXgrFmIL+mVvVdhrGZigEwAQ1/5zsjaHaemaeobeMZGzyZebr4szstev1WOQyQbOIFQrLdtFZ2oJwLzUQN88+TK/+7CU+HmlBpOs0tJqbBeuv1oNuyb58sc3a8Fvfwtrgcn72eFLAJVCkg8/m+MvHuTeUE+lod7abIbLqiuMHAdKySYxIyyub813S76Uk8wWmyq10gu6CoO+pYGc2fxj+QRq56vXkvp0iC8Qx1+WsU2GbEhV/Nos5DelvZrWvY8IsEi3dpgRCPYgWMX3WqZOkOVjwhUiCQpOikt92V0AFOSR8ICKABJE7IoTqHhtvn5x1Ef2XssS5f58nwxJyATsfQsIyHJ5A09H9z3qdNTNcjJXAq2IyfFAhdgbuDopN24N5GtbqX2LKnln9LgRa+C5pBNO5TiHY7+8O0gZOb/vsJw1/WGhVcELRUzb1EOzjoLUsqnsS633Vf0LV9+2Gev/x0Q/GAWev9K/rIdC6fYlA= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3397 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT054.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:(4636009)(376002)(396003)(346002)(136003)(39860400002)(46966005)(356005)(86362001)(316002)(478600001)(6486002)(81166007)(36906005)(82740400003)(110136005)(8676002)(47076004)(6512007)(2906002)(70586007)(8936002)(26005)(2616005)(54906003)(70206006)(82310400002)(6506007)(81156014)(53546011)(5660300002)(33656002)(186003)(336012)(4326008)(36756003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 2617b05c-3e16-4737-de1e-08d7e905258f X-Forefront-PRVS: 0384275935 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MQ9amETHWF3lk5IEyzEisMzmnZ///DBxlVAk2Q8gXtumq8niyKfDdRoBM9RLJ07pGJS/wTYerIKb/0eay6gEqVVSjOtbOaze9bR9XTxfFYUgUr8KH1oQNvGWHaRuureuRLTveeeZdgnnzZjsQSmtJx0bBvHnZsJ5lS8RHdTDey8ooxZ35Po18zmy9rd2SbBAaNxTkeHpEPIiEz+cS40CG0juoqyp/8eCoKHI6tu4B/ED0THmuY/enTWyF1mXHlYq01SgVPOHPBbOz88Q9FmaLxKGGi68I5jrBCkl9MFzC5LS/VkcnPxrsyCO199k1u+N8/luP9WU2qqkynRDWMjrWckG2gmq0i1VPmD7y3x/WLAokUbaMwEtfBBLsXupwrIKENUG5i9lUxghAYbm7ewQ+yuXz/jjBUHncrTZiWYABiAo8i3A2yEOrvQEQCkVmzuOHPfacLgi/1ksrBFv5f8nNQK+TTMxSlWSqEfCkwMGkiYyNFC8Vo1fE93BcW6EXfc+7iqpDEABQPSH5GnYYhoKag== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2020 10:41:08.7205 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 75ad719b-fb0a-47be-adf1-08d7e9052a37 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: AM0PR08MB3139 Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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: Sat, 25 Apr 2020 10:41:16 -0000 T24gMjQvMDQvMjAyMCwgMjI6MzUsICJFcmljIFJlc2NvcmxhIiA8ZWtyQHJ0Zm0uY29tPiB3cm90 ZToNCj4gT24gRnJpLCBBcHIgMjQsIDIwMjAgYXQgMjoyOSBQTSBjaHJpcyAtIDxjaHJpc3BhdHRv bkBnbWFpbC5jb20+IHdyb3RlOg0KPiA+IEkgd291bGQgbmVlZCB0byBzdHVkeSB0aGUgc3BlY3Mg aW4gb3JkZXIgdG8gcHJvdmlkZSBhbiBpbnRlbGxpZ2VudA0KPiA+IGFuc3dlciBoZXJlLiBPZmYg dGhlIGhpcCwgaXQgd291bGQgc2VlbSB0byBkZXBlbmQgb24gaG93IHRoZQ0KPiA+IGJvdW5kYXJp ZXMgYmV0d2VlbiByZWNvcmQgaGVhZGVycyBhbmQgY2lwaGVydGV4dHMgYXJlIGRldGVybWluZWQu DQo+ID4gVGFraW5nIGEgcXVpY2sgbG9vayBhdCBkcmFmdC0zNywgRmlnLiA0OiB0aGUgImZ1bGwi IGhlYWRlciBpbmNsdWRlcw0KPiA+IHRocmVlIHZhbHVlcyB0aGF0IGFyZSBleGNsdWRlZCBmcm9t IHRoZSAibWluaW1hbCIgaGVhZGVyLCB0aGUgbGVuZ3RoDQo+ID4gb2YgdGhlIGNpcGhlcnRleHQg YmVpbmcgb25lIG9mIHRoZSBmaWVsZHMuIFByZXN1bWFibHksIHdoZW4gdXNpbmcNCj4gPiB0aGUg Im1pbmltYWwiIGhlYWRlciwgdGhlIGxlbmd0aCBpcyBhIHBhcmFtZXRlciB0aGF0IHRoZSBzZW5k ZXIgYW5kDQo+ID4gcmVjZWl2ZXIgYWxyZWFkeSBhZ3JlZSBvbi4NCj4NCj4gWWVzLiBJdCdzICJ0 aGUgcmVzdCBvZiB0aGUgVURQIGRhdGFncmFtIi4NCg0KSSBtaWdodCBiZSBtaXNzaW5nIHNvbWV0 aGluZyBidXQgdGhpcyBkb2Vzbid0IGxvb2sgdG8gbWUgbGlrZSB0aGUNCmRlZmluaXRpb24gb2Yg ImFncmVlZCB1cG9uIiBieSB0aGUgVExTIHByaW5jaXBhbHM6IGFuIGF0dGFja2VyIGNhbg0KbW9k aWZ5IHdoYXQgInRoZSByZXN0IG9mIHRoZSBkYXRhZ3JhbSIgaXMgYXQgd2lsbCwgbm8/DQoNCg0K DQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0 dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElm IHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkg b3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRo ZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Sat Apr 25 03:43:45 2020 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 20CEC3A0A31 for ; Sat, 25 Apr 2020 03:43:43 -0700 (PDT) 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, 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=0CLLIVfc; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=0CLLIVfc 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 bgvDwuulrttr for ; Sat, 25 Apr 2020 03:43:41 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130081.outbound.protection.outlook.com [40.107.13.81]) (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 0518B3A0A28 for ; Sat, 25 Apr 2020 03:43:40 -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=sOjkosUZXZtTScerb4D/Hok2leqfoL3KP1Lo2DFR63I=; b=0CLLIVfcrsMF+kjxFMj9FXwTR92M97xOVql8S9AtoFAEkqY+9/OCi3ijE6a4d/+DMHv1VhXvhWufMRf8DgBNwzavPMMN08q5Y0nCOfEnIhKoyHNbGpGfjSZCz+StNLG1leZYyhtV+pII2RstZ/yfWFSouYViLUZsXyb6ugzhpXs= Received: from DB8PR04CA0025.eurprd04.prod.outlook.com (2603:10a6:10:110::35) by HE1PR0802MB2235.eurprd08.prod.outlook.com (2603:10a6:3:c3::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Sat, 25 Apr 2020 10:43:38 +0000 Received: from DB5EUR03FT055.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:110:cafe::9) by DB8PR04CA0025.outlook.office365.com (2603:10a6:10:110::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Sat, 25 Apr 2020 10:43:37 +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 DB5EUR03FT055.mail.protection.outlook.com (10.152.21.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Sat, 25 Apr 2020 10:43:37 +0000 Received: ("Tessian outbound ff098c684b24:v54"); Sat, 25 Apr 2020 10:43:37 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 055fb1c150337261 X-CR-MTA-TID: 64aa7808 Received: from cb6f2a36c75f.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 21B473CB-B98E-4BA8-ADA2-2216D0FA82E4.1; Sat, 25 Apr 2020 10:43:32 +0000 Received: from EUR04-VI1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id cb6f2a36c75f.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Sat, 25 Apr 2020 10:43:32 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KrmzPixatVEQXKpWQ8g0OfRm51ZssxgsPsxRjYCVjdVQm6nC1oyJzIsjHxcHpho3inPLWlRVJ7KSCn9x49Lm75VT0TBQcQaiFTL+/zyImI7GN3N3LFpX0PjnAxIveeifygjYxRmGHEZkzptnpXcx0GeBfiN4VSoyd3KSjKEC9TG9XtbWOHLz8KAaVaa5XZDNybsPyHrcZS+K5pGwzJj4uqSmAAheDtuHDqvxhrG3smTjvJbOeOfhNdwP69zKqVpo+jeTUxO0pDHjMuzX6OXBY0iOycz/bplufkD6MnvUJQLFyCVUJtBJfj7xXz/As9qe0LyjZhl5Onjde61ZY1evAw== 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=sOjkosUZXZtTScerb4D/Hok2leqfoL3KP1Lo2DFR63I=; b=IRy3COFr14ipb+tX77UnWIJx99GCWAS13CTuuaMS+6xC1PsqvWvi/xn7Gm7qXA4EpiOmSKIF4pgVvkZa5hOZPwgY7ezri26GLlKlsYmG9c/vHHoxvoicCSIIMA0yAB3XTBP4jRaLPmNn80pw/TpE6QbM2adUSY+VTbG4jnSMbJW9XhA6rRv1dALGGdlil0jIWNReFfHtn47jGrQaVVldReNmPdoYtPyWob/6JZRq6Em3ZnjAa8I/VxxI3JnyWQ1dW/Mz5BgeZzU8LwnG5lLbX32FGmCKTqaG9FdwxB8FW1RmSR5ptiNZBOhVvBXiREyC9beIa/PVKDLhgnCpxWnrAg== 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=sOjkosUZXZtTScerb4D/Hok2leqfoL3KP1Lo2DFR63I=; b=0CLLIVfcrsMF+kjxFMj9FXwTR92M97xOVql8S9AtoFAEkqY+9/OCi3ijE6a4d/+DMHv1VhXvhWufMRf8DgBNwzavPMMN08q5Y0nCOfEnIhKoyHNbGpGfjSZCz+StNLG1leZYyhtV+pII2RstZ/yfWFSouYViLUZsXyb6ugzhpXs= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB3397.eurprd08.prod.outlook.com (2603:10a6:20b:43::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Sat, 25 Apr 2020 10:43:26 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d%6]) with mapi id 15.20.2937.020; Sat, 25 Apr 2020 10:43:26 +0000 From: Thomas Fossati To: Christopher Wood , "tls@ietf.org" Thread-Topic: [TLS] DTLS 1.3 AEAD additional data Thread-Index: AQHWF+iN1gKILcDltkmRr5OfopCaAaiD3VMAgAB8FQCAAE7VmIAAawyAgAAHdS6AAB8+AIAACQCRgACPx4CAABkpAIAABDCAgAAC0ICAAEL8/IAAHxqAgADkdgCAAcgWAIAAsyqAgAAI7IA= Date: Sat, 25 Apr 2020 10:43:26 +0000 Message-ID: <1CBF6B88-8830-44A4-8F9B-143F884FF6ED@arm.com> References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com> <1e6201d6-a078-4137-898d-d1554c22aa10@www.fastmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 5458a1ff-5850-4d51-c8f4-08d7e90582f5 x-ms-traffictypediagnostic: AM6PR08MB3397:|AM6PR08MB3397:|HE1PR0802MB2235: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0384275935 X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(376002)(39860400002)(366004)(346002)(110136005)(6512007)(81156014)(6486002)(5660300002)(86362001)(8676002)(8936002)(6506007)(316002)(33656002)(478600001)(53546011)(66946007)(26005)(2906002)(64756008)(76116006)(186003)(91956017)(2616005)(66556008)(36756003)(66446008)(71200400001)(66476007)(4326008); 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: Uz4Azy34HT2LJONHfvHJECuE0VYRhQL6gpkEvEv6gTKDNOjb/rm7WCy1zeWnueI+UaWG/Je9xqqLSW/iosoRYUDrNw9F34PPn+DwrBCoHxJEFVDU9xoza0r34lI39OzCEPl3FdqzvFTnTF8sQ10V+4z6g0E0hXm7ziBJVnR4kJBJT26iybHCesj5Np1LZD90u5D5jcUzAOUMhG1a3qlYPyccbiTCPmuETb9vPx2wAxiC4t3GeDEduCLgZWnqr23welDJB8FFPKPe2TjHeeeR9g9i8YFBBnTJrgHNZ4nRC/2b+HxIavB1TAYVdWg0Nxa1+dZYpsiuQPqgyDUGjLQke5wUHbzibNfYDD4unNXVjLcsBHlagx7ViRgItCiIoYT1veXPi4qEPJJUw9IuQNcdziSNigjhPKSfOGEzDFkUg2uo5Hifqpz43woJ26EZnrM8 x-ms-exchange-antispam-messagedata: vo70uidEq6dY0uvXAqKrg3K5slPQGIgINwoWjRJjeSWo5riXMouTVsldmdeAylePmSpu+6A6CIhwRdVGxkm+YWV0nOp6x8TwndR8cXRLCcoZgilhlIPmAJvWex0Xa36RZAyEyPxiefSWGlOg5u82FFl13WcOs0ehWp+3yRuU26BVIfubTXLAUJI1nUI96KQZvdvLfAgEhikMPPEIgL7gGZX4LQ9a2C+bVK6qIc+R9lYn+0z50V57ppiT3dyP3aZqQgJ4o8+keapwu7ptZY3t2WijKMRUBgtFD08U6URRu+6jK4Kn1dPK2IFFVlzMvldOmxmwsYbHVTFczS/fCg19SraWLOsomuqeKCYfKMJaxAGQcIDedqRVSiIlDDFm99gMYTXzdbaPA5h/AG3E3NQPPqHZKB9+Zz8QxNdvCw4CEfu7LxYbKnYGfslKEQrL+QtnRmJ1pVjR4NMMNonzBIvNsMCHeUuR6aQoEATP02HUVuAHt4lwxulkk1IDKFfnWDipu0J+REFXAulhI8yDLgkDBDkYnt+Mst6oF3QdJNNDfp/Nn3iEfAIOtwt6t4uCjTq0xbHQyQ2AJjGIQ4vj7k4NA4qSYMLIrFNY0GKZCSxnlWFZ0hsYUCfG8+JsR2gAbAkhLhT3mwsCVDKKndzV23k9tjqO/x5lgfcDiV612Zby2kYZV7qPE5wNruoIj8IxRW1pzeLYy7WeWPSvRtscSkR7wH1ShhqOtcZTUnNzGhw9eYxuW88CxaK1rarJGFFW+rvP0PXh/o32XzzUH2+ColwnYAlsfWrhFJNMvjZsKcV5zF8= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3397 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT055.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:(4636009)(396003)(39860400002)(346002)(136003)(376002)(46966005)(86362001)(316002)(110136005)(81166007)(4326008)(6512007)(82740400003)(6486002)(36756003)(33656002)(5660300002)(81156014)(186003)(8676002)(70586007)(8936002)(47076004)(478600001)(2616005)(356005)(336012)(2906002)(82310400002)(53546011)(26005)(6506007)(70206006); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 214a50be-bb2f-4dfb-d667-08d7e9057c34 X-Forefront-PRVS: 0384275935 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lx+iEdkBqklt46ICTSmdrUQRBRqp6YS3Xr2YYcLbwathyH+Ja+k4vFP0FolQlDmsA3xGHBowkeQrbaxneErjW480SjazbHNA6k9LyiKQDPse1Z83JAkYN7T3XXd0pqjvMVi2r3KoavBQQrzqFSfGk55hp2bims1hP4y+MXCkeUpe4wCDyYcd12Azc0++ExYXId/3FdD/n5Pxvk5pGpqbLu8aH45v5aVB82zRTteK69sVNf7SO9EbnAk5gfbNrM4psChdoqWzV3AJ7AjH68/NE529y+/bSSMCfUgGX88VVsmuzedlvDi3bqYH89lK4vdWkw0QoewPLwwexToicwK2SMzsyFrABUdGY1EtcxgYuVwBO8H2Sky/t2Ro93aTicgTjuhYZrQXz8GZIJ7TGARgTMMkiOVos2mOdt4FDcmqiRA1+wOjS75Zd5KkNn09qmVrAnhQaXmURkJ7phWlXQ7M+iZlQFOjJUgleu8g5ff9OmDxR6Vg3qQwd1mQKAMlt0AW/uCZ6QsNZf1JG0A7UjqBdA== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Apr 2020 10:43:37.7398 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5458a1ff-5850-4d51-c8f4-08d7e90582f5 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: HE1PR0802MB2235 Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Sat, 25 Apr 2020 10:43:43 -0000 T24gMjUvMDQvMjAyMCwgMTE6MTEsICJUaG9tYXMgRm9zc2F0aSIgPFRob21hcy5Gb3NzYXRpQGFy bS5jb20+IHdyb3RlOg0KPiBPbiAyNS8wNC8yMDIwLCAwMTozMCwgIkNocmlzdG9waGVyIFdvb2Qi IDxjYXdAaGVhcGluZ2JpdHMubmV0PiB3cm90ZToNCj4gPiBPbiBUaHUsIEFwciAyMywgMjAyMCwg YXQgMjoxNyBQTSwgRXJpYyBSZXNjb3JsYSB3cm90ZToNCj4gPiA+IDEuIEFsbG93aW5nIGltcGxp Y2l0IENJRHMgaXMgdmVyeSByZWNlbnQgKGl0IHdhcyBpbnRyb2R1Y2VkIGluDQo+ID4gPiAtMzQp DQo+ID4gPiAyLiBUaGUgQ0lEIHNwZWNpZmljYXRpb24gZXhwbGljaXRseSBwcm9oaWJpdHMgaXQg Zm9yIERUTFMgMS4yLiAgMy4NCj4gPiA+IEkgaGF2ZW4ndCByZWFsbHkgaGVhcmQgYSB2ZXJ5IGNv bXBlbGxpbmcgYXJndW1lbnQgZm9yIHRoaXMgYW5kIEkNCj4gPiA+IG5vdGUgdGhhdCBRVUlDIGZv cmJpZHMgaXQgW2FuZCBpbiBmYWN0IGhhcyBtdWNoIHdvcnNlIHByb2JsZW1zDQo+ID4gPiB3aGVu IHlvdSBtaXggZXBvY2hzIGJlY2F1c2UgdGhlIGxvbmcgaGVhZGVyIGlzIHNvIGxvbmddDQo+ID4g Pg0KPiA+ID4gU28sIGdpdmVuIHRoYXQgdGhlIHNpbXBsZXN0IGFuZCBtb3N0IGNvbnNpc3RlbnQg dGhpbmcgaXMgdG8gc2ltcGx5DQo+ID4gPiBmb3JiaWQgaXQ6IGNhbiBzb21lb25lIG1ha2UgYW4g YXJndW1lbnQgZm9yIHdoeSB0aGlzIGlzIGltcG9ydGFudA0KPiA+ID4gdG8gcGVybWl0Pw0KPiA+ DQo+ID4gVGhhbmtzIHRvIGV2ZXJ5b25lIHdobyBwYXJ0aWNpcGF0ZWQgaW4gdGhpcyB0aHJlYWQg c28gZmFyISBHaXZlbiB0aGUNCj4gPiBwb2ludHMgYWJvdmUsIHRoZSBjaGFpcnMgd291bGQgbGlr ZSB0byBoZWFyIGFyZ3VtZW50cyBpbiBmYXZvciBvZg0KPiA+IGltcGxpY2l0IENJRHMuIEFic2Vu dCBzdWJzdGFudGlhbCByYXRpb25hbGUsIHdlJ2xsIGFzc3VtZSByb3VnaA0KPiA+IGNvbnNlbnN1 cyBmb3IgZXhwbGljaXQgQ0lEcy4NCj4NCj4gSGkgQ2hyaXMsIEkgdGhpbmsgaW1wbGljaXQgQ0lE IG5lZWRzIHRvIGJlIGNvbnNpZGVyZWQgaW4gdGhlIHdpZGVyDQo+IHNjb3BlIG9mIHVuaWZpZWRf aGRyIGNvbXByZXNzaW9uLCB0b2dldGhlciB3aXRoIGltcGxpY2l0IGxlbmd0aCBhbmQNCj4gc2hv cnRlbmVkIGVwb2NoLiAgSW4gcGFydGljdWxhciwgZnJvbSBDaHJpcyBQJ3MgZW1haWxzIEkgdW5k ZXJzdGFuZA0KPiB0aGF0IGJlaW5nIGFibGUgdG8gYXV0aGVudGljYXRlIHJlY29yZHMnIGxlbmd0 aCBpcyBhIGNvcmUgYXNzdW1wdGlvbg0KPiBpbiB0aGUgc2VjdXJpdHkgcHJvb2Ygb2YgVExTLiAg VGhlcmVmb3JlIGxlYXZpbmcgaXQgb3V0IGZyb20gRFRMUyBBQUQNCj4gd2hlbiBpdCdzIG5vdCBp biB0aGUgaGVhZGVyIGxvb2tzIGxpa2UgYSBwcmV0dHkgYmFkIGlkZWEuICBJZiB0aGlzIGlzDQo+ IHRoZSBjYXNlIChpLmUuIHRoZSBmYWN0IHRoYXQgdGhlIHdpcmUgaW1hZ2UgYnkgaXRzZWxmIGlz IG5vdA0KPiBzdWZmaWNpZW50IGlucHV0IHRvIHRoZSBBQUQpLCB0aGVuIGF1dGhlbnRpY2F0aW5n IGltcGxpY2l0IENJRHMgc2hvdWxkDQo+IGp1c3QgY29tZSBpbiB0aGUgc2FtZSBidW5kbGUuDQoN ClNvcnJ5LCBzY3JhdGNoIHRoYXQgZm9yIHRoZSBtb21lbnQgLSBJIGhhZCBtaXNzZWQgdGhlIG1v c3QgcmVjZW50IGVtYWlscw0Kb24gdGhpcyB0aHJlYWQgOi0oDQoNCklNUE9SVEFOVCBOT1RJQ0U6 IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZp ZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGlu dGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFu ZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBp dCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFu eSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== From nobody Sat Apr 25 10:58:46 2020 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 9B0983A0FCB for ; Sat, 25 Apr 2020 10:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 foLJ26cUQp-b for ; Sat, 25 Apr 2020 10:58:42 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F013A0FCA for ; Sat, 25 Apr 2020 10:58:42 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id m18so18524697otq.9 for ; Sat, 25 Apr 2020 10:58:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p/kWuVRf3zldESSResazLHIR05HopKEgp2z8hY/N3sg=; b=qpjXucK3IAc36IFmaBp5dfnR7Fox2SDVnFrTbeywNzokcu4Z5ugwQL3ayr8l/KjQR3 U1RbFyR3aT6Pi3LQXXvBy6uG4S8UYM6Q29FRu0+r9Ky/Tynd14hbZLSvah2xyH3hqfmc u9cgqbTiOJYJGRqH02BYnrdkizko35cHnJv3dkPtJHhwt2aGqK2vq3ouKsBEURsadaFi +9adRCfh5AvBoZ2ml8K06La+upK4QI6mE77+XMPGLt3/kaVo2xlFulWOksceiezdYlv8 RS4P6fiK7moolJmrsos50hiZ7PmIJBwz2XKw2DxW2pffD4UUYkG3VLq+bJdhQtIoLtIZ afeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=p/kWuVRf3zldESSResazLHIR05HopKEgp2z8hY/N3sg=; b=KcrSYBXFJ+Z9xMrgOl3l37Bz5ym+avJkN8Y1k1ScDTtQj4oFrzhhmjFxjjK8ngvFUl mQC82DFUNGQHlYXpPbKE6Z62mOnJyhj4PA4gF2Q0T6BZ5aEZGqItUjPMmBEW7Qcc0K6S kbZujEFnO1C37h7ONYFwmVAKmyfpyIfgsvkKdsnVx+FqJft2UJT7u7zuWQNzLsiph7oU clB5+OMPG/2IC7znHJ7QIsFk+VjMsGScwzhF7t9A7P3cRZ9jKhI0UfDpJThv3IF1SRJB 6e2fzWLq/vQGOnKpfSegJLfZm7fuUZLSCNKh6KPgBzDWokPE7I4QWhZENQTTIok7RtmZ pu5g== X-Gm-Message-State: AGi0Pubo5BS6jjBjdqycfB1/YvDs9aHhUKwEbCvqBznL1Uc6q2BVmy+W jY6F08nfSfInoXYp7IXh3l5L6dqwLoD9AUCHyUs= X-Google-Smtp-Source: APiQypIxUHOHZP//TB8C8cmaMzdQOI7B1AFReaeVAkyCRnA2NVI2cpjL9dcTDovWguRG3Ck47vH19LkLUDkEWzSlMvE= X-Received: by 2002:aca:57d6:: with SMTP id l205mr10617617oib.20.1587837521123; Sat, 25 Apr 2020 10:58:41 -0700 (PDT) MIME-Version: 1.0 References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> In-Reply-To: From: chris - Date: Sat, 25 Apr 2020 13:58:29 -0400 Message-ID: To: Hanno Becker Cc: Eric Rescorla , Hannes Tschofenig , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000685e7e05a4213b0b" Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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: Sat, 25 Apr 2020 17:58:45 -0000 --000000000000685e7e05a4213b0b Content-Type: text/plain; charset="UTF-8" > So far I fail to understand, on an intuitive level, why it easier to > analyze the protocol when the AAD can take multiple forms potentially > truncating or omitting the underlying data, but then I don't know the > details and you're the expert here. If you have time though to explain a > bit more where the flaw in my thinking below is, that would be great, > provided it's possible. > I don't know that there's a flaw in your thinking. At the moment, all that I can speak to is how authenticating the header (or not) might impact security of DTLS. We can't directly extrapolate from what we know about TLS, because the security goal is not to the same. That said what I know about TLS is the following: the contents of the record header doesn't matter for security goal considered in [1], as long as (1) the header is authenticated; and (2) it correctly encodes the length of the next ciphertext. But since the security goal of DTLS is not the same, the details of the spec that are (ir)relevant to security are likely to differ. > For example, another thing which I would expect to be more complicated to > verify in full rigor is epoch authentication: If the epoch is reduced to > its two low order bits in the DTLS 1.3 header and thus (at the moment) also > in the AAD, arguing that decryption can only succeed for the correctly > expanded epoch involves knowing that all epochs having different keys. > That's of course true but this fact wouldn't be needed if the full numeric > epoch was always explicitly authenticated in the AAD. This isn't a real > issue in the end, but I would expect it to be a nuisance in a formal proof? > In terms of what you mentioned regarding decoding details, it seems that > adding the underlying logical header to the AAD ensures more directly that > decryption can only succeed if header decoding (that is, filling in > implicit data or expanding truncated data) was done correctly, whereas it > is less clear with the truncated or omitted data in AAD, as in the epoch > example above. Is it possible to explain what the flaw is here intuitively? > I'm afraid I would need to absorb spec and think about its intended security properties in order to answer these specific questions. I'm sorry if this answer is unhelpful; Ekr asked that I chime due to my prior work on TLS. But I don't think there's a simple answer here, and unfortunately I don't have the time to think it through at the moment. For now, I'll just leave you with this. I'm a fan of the following design principle: whenever there is a branch in your code that depends on a bit read from the wire, that bit should be authenticated if possible. To your example, if a decision you're about to make depends on you agreeing with the peer on the current epoch, the principle says that the epoch had better be authenticated. Whether it's necessary or appropriate to do so here (via AEAD decryption) depends very much on the context, i.e., the protocol details and the security goal. Chris P. --000000000000685e7e05a4213b0b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
=C2=A0
So far I fail to understand, on an intuitive level, why it easier to a= nalyze the protocol when the AAD can take multiple forms potentially trunca= ting or omitting the underlying data, but then I don't know the details= and you're the expert here. If you have time though to explain a bit more where the flaw in my thinking below= is, that would be great, provided it's possible.

I don't know that there&= #39;s a flaw in your thinking. At the moment, all that I can speak to is ho= w authenticating the header (or not) might impact security of DTLS. We can&= #39;t directly extrapolate from what we know about TLS, because the securit= y goal is not to the same. That said what I know about TLS is the following= : the contents of the record header doesn't matter for security goal co= nsidered in [1], as long as (1) the header is authenticated; and (2) it cor= rectly encodes the length of the next ciphertext. But since the security go= al of DTLS is not the same, the details of the spec that are (ir)relevant t= o security are likely to differ.

=C2=A0
For example, another thing which I would expect to be more = complicated to verify in full rigor is epoch authentication: If the epoch i= s reduced to its two low order bits in the DTLS 1.3 header and thus (at the= moment) also in the AAD, arguing that decryption can only succeed for the correctly expanded epoch involves knowing that al= l epochs having different keys. That's of course true but this fact wou= ldn't be needed if the full numeric epoch was always explicitly authent= icated in the AAD. This isn't a real issue in the end, but I would expect it to be a nuisance in a formal proof?
=
In terms of what you mentioned regarding decoding details, it seems th= at adding the underlying logical header to the AAD ensures more directly th= at decryption can only succeed if header decoding (that is, filling in impl= icit data or expanding truncated data) was done correctly, whereas it is less clear with the truncated or o= mitted data in AAD, as in the epoch example above. Is it possible to explai= n what the flaw is here intuitively?

I'm afraid I would need to absorb spec an= d think about its intended security properties in order to answer these spe= cific questions. I'm sorry if this answer is unhelpful; Ekr asked that = I chime due to my prior work on TLS. But I don't think there's a si= mple answer here, and unfortunately I don't have the time to think it t= hrough at the moment.

For now, I'll just leave= you with this. I'm a fan of the following design principle: whenever t= here is a branch in your code that depends on a bit read from the wire, tha= t bit should be authenticated if possible. To your example, if a decision y= ou're about to make depends on you agreeing with the peer on the curren= t epoch, the principle says that the epoch had better be authenticated. Whe= ther it's necessary or appropriate to do so here (via AEAD decryption) = depends very much on the context, i.e., the protocol details and the securi= ty goal.


Chris P.


--000000000000685e7e05a4213b0b-- From nobody Sat Apr 25 11:38:31 2020 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 465973A12E6 for ; Sat, 25 Apr 2020 11:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 iqPJeXhngtKb for ; Sat, 25 Apr 2020 11:38:27 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B1E73A12E5 for ; Sat, 25 Apr 2020 11:38:27 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id t14so15547016wrw.12 for ; Sat, 25 Apr 2020 11:38:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VsgKz21Azac5gDGD+SpVbwcg6I65QVKnR5jdIM1BmI4=; b=Odpj+iHOrwGJu6111c/6X31bSmG+LYx1SHFPMwdV5hPlp04yqWPzpeYzOkoanYC5za WulFOxVwixQjvbHP7pU8LHCQ/NA0CsKN2qzV2X/QCz4fVnKPR56fhmXGGdAUWjF6Po8g iJNahJ7c6IKowWdKPm8ZaAb9/iIqGNcpbHbw9avySyhL7935b0iE/PFQTPhOMAV/UDcU aYXA9gZ+aJ6EAbOXWR+g4d3oqxb4JoP19IOfBLHy3ngmy7INTNfetGT7IMSg00q4NRGn kIhT3IUyOHTdV4LKFrsG0LYEuEeYszrRwCpYrDtJInzsciZUXzf5VAV/HEFXtDr1NYTP MlMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VsgKz21Azac5gDGD+SpVbwcg6I65QVKnR5jdIM1BmI4=; b=P4yAz7RbpP1SiGzr0lgt4pT0w8Vu+d1mBWJJpHQSm2S5A7bTN9cR2u3KMH2+FhMSIQ HwUdYRl2TEnfSDP/Szvb66nH8/xFuspCMeoB+x1a6Lh1mO0QyP2+uqikWW/ZvCMhnANO rOwKh1s+iDQpd+c6q/K5DxXo8gzixtLTOdq80IpuqG5qPwSxNQpR3T6aHr8Wv5uHupWj 3yPhM3oAXR2sig3jX7wUBPVyYuFHUIt5uPRhQfiQxP7tfHxo5wLOIvMMnsVt8kO/FKNE DBLKKl3ORZ9oPTRdXPav5sMo8SOwqFhz4uC3lYMFx9cclX2QqK/tlnkqTIcN+VSbTnl9 EWOg== X-Gm-Message-State: AGi0Pua8925fDYU5PULq+eWAzuoCDviIsEgd/O3/KGG6kmd7lDI26vIH gKeLaPPhhBPDAqaTP1ioyF2cgCkJ X-Google-Smtp-Source: APiQypIalN+3hgHM4tZU2zQ4nZrTNGAJFIct9FOwhbJKfaCVBoKqOKhd2xx9Vy/5wW9ZDqqgC1p92w== X-Received: by 2002:a5d:4dcd:: with SMTP id f13mr17787137wru.417.1587839905551; Sat, 25 Apr 2020 11:38:25 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id n9sm13644683wrx.61.2020.04.25.11.38.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 25 Apr 2020 11:38:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Yoav Nir In-Reply-To: Date: Sat, 25 Apr 2020 21:38:23 +0300 Cc: tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <730DE2CB-BD16-47B9-9729-B8D49615AB7B@gmail.com> References: <3aab08b9-d979-4952-85f6-62e993f6fb4b@www.fastmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [TLS] WGLC for "A Flags Extension for TLS 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: Sat, 25 Apr 2020 18:38:29 -0000 See below. I think the next thing to do is to get a signal from the working group = about whether we do or don=E2=80=99t want to allow unsolicited server = flags, because prohibiting it will require a significant change in the = draft. I=E2=80=99m happy to make such a change, because I still can=E2=80=99t = come up with such a flag. > On 23 Apr 2020, at 3:07, Martin Thomson wrote: >=20 > On Wed, Apr 22, 2020, at 05:31, Yoav Nir wrote: >>> Third, more substantially, and invalidating the above, I don't think = that we should make flags introduce a new style of negotiation just = because it can. I would strongly prefer that this function as close as = possible to "empty ClientHello extension; empty EncryptedExtensions = extension". Aside from that, the utility of an advertisement from the = server that a client cannot respond to is pretty marginal. >>=20 >> If this is what the group prefers, I=E2=80=99m fine with it, but then = there=E2=80=99s=20 >> never any point in sending an empty extension, either from the client=20= >> of form the server. The absence of an individual flag is always = implied=20 >> from the absence of the extension. >=20 > When you say "empty extension" here, do you mean "empty flags = extension" or are you speaking more generally? >=20 > If the server can't add flags, then I agree that having the client = send an empty flags extension has little value. Same for the server = sending an empty flags extension in that case. I mean the flags extension. An empty extension conveys just that the = sender supports the extension. An empty CH flags extension just says the = client supports the flags extension. Unless the server is allowed to = send unsolicited flags, an empty flags extension in CH does not convey = any useful information. >=20 >>> Are we confident that sending the same extension in both places is = safe? I know that clients have to implement this and so should be able = to test that this works, but it seems awkward. And it might not be = necessary. It's also not sufficient, as we currently allow responses to = ClientHello extensions to appear in Certificate (and for = CertificateRequest to carry "requests" in the other direction). >>=20 >> I don=E2=80=99t think the two extensions ever carry the same flags. = Each server=20 >> side flag should be one of three: serverHello, encrpytedExtensions, = or=20 >> neither (if we are not expecting a response) >=20 > So the intersection of flags in different responses must be zero? = i.e. flags[ServerHello] & flags[EncryptedExtensions] =3D=3D 0 (and the = same for any combination that we allow, including Certificate and = NewSessionTicket, I guess). I can=E2=80=99t think of any flag that will have a different meaning = when sent in SH or EE so that you might want to send both. Just in case, = the flag registry should have a field similar to the extension registry = which says where the field is valid. >=20 >> As for Certificate, I don=E2=80=99t see why we=E2=80=99d need to add = bit responses to=20 >> Certificate. They can safely be sent in either serverHello or=20 >> encryptedExtensions. >=20 > The obvious thing here is when the extension applies on a = per-certificate basis as opposed to the entire chain. But I don't have = an example you can use; see below. >=20 >> I=E2=80=99m trying to come up with key exchange bits that might be = useful. =20 >> Perhaps a new, improved alternative to HKDF? Support for Quantum Key=20= >> Exchange? >=20 > This might require an understanding of the overall strategy. If the = goal is to provide an analogue of a generic "empty extension", then = sure, put it in ServerHello. But put it in Certificate and = NewSessionTicket too. But if you make this more narrowly applicable and = say that you have a different flags extension for each type of exchange = (ClientHello -> ServerHello, ClientHello -> EncryptedExtensions, = ClientHello -> NewSessionTicket, ClientHello/CertificateRequest -> = Certificate), then you might avoid answering this question for now. >=20 > Right now, it seems like the obvious use here is for = EncryptedExtensions, so we could decide to defer that architectural = question by saying that it is limited to EncryptedExtensions for now. = Then we can either expand the one flags extensions to allow it in = NewSessionTicket when we need to, or define a new one. From nobody Sun Apr 26 00:33:07 2020 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 C87623A0FAE for ; Sun, 26 Apr 2020 00:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=U0Cy+rP7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=3TOibYb8 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 Pt0P6CzdPCGE for ; Sun, 26 Apr 2020 00:32:51 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1100E3A0F95 for ; Sun, 26 Apr 2020 00:32:50 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3D9665C0310 for ; Sun, 26 Apr 2020 03:32:50 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 26 Apr 2020 03:32:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm2; bh=Ss2S53qduN20pQQRh+Jqb13JIGktFYY0QKkc5HBxG3Q=; b=U0Cy+rP7 nobed2nQVqrBaT7RRqqhHCLIWdx6jO2jWW8KeQ4C6WAMdTybqPC3Ado60sYQAvxk S3To7vIN8btTWQDS354lp+Hn1yNJXuB5njT89h46VTZtArGAR1HJAm4RdBSe5B3D Gl39KCd5gTHg39VDC4K5NEAlyWF4IHyrqFJmL4IbsJLmX/NWXX2S2gVaF7VUSeAh YdjxCgz6ky0lYSDIyHkJL46aM0f90FWwKab9baS+dj3x2yiE0deOHE0IZSDN4kZt hSu2y3+nj9W995fcEIeHUdDtj8KdYzYZJ20nykVQBgQox5sdFhsJlCf2+Cwm/YgZ b0AtvbV6NS9fRg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=Ss2S53qduN20pQQRh+Jqb13JIGktF YY0QKkc5HBxG3Q=; b=3TOibYb89XG1iECvTdtf8eXSHtE96lVVQSGt5K9yo14xK 2cg7gYdgST4Th13wqvCY2eqWgL9S+DffoXS7QqhHKvn1AhY6WDfozAkLnWG17RiI GZgr6rshq+OeYAHXJmD1ZYVeLJoIEzjV2uF24OCg7z8yeTzVlEDQE4BrI73I1apE +4r9UCZO6Ahj5z8CRgu81uR7aSVTpRWDMZ5YkC1zk666eqLGReusv7zjVXgMu6fx PZpwaCCXhCSDbAsGrbsCeZ7rL4WQW+SKsiw3Coq/ci5j6jF4b5zQsCz9eVOi50h7 uFX0StVQG/Oh2vnaSS+Gz1OLtX98aTL1cY/zYtCPQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrheeigddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecukfhppedufedrledtrddvvdeirddvtddvnecuvehluhhsthgv rhfuihiivgepudenucfrrghrrghmpehmrghilhhfrhhomhepughopghnohhtpghrvghplh ihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az86.internal.cloudapp.net (unknown [13.90.226.202]) by mail.messagingengine.com (Postfix) with ESMTPA id E99BE3065E10 for ; Sun, 26 Apr 2020 03:32:49 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============5869089515059996555==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: tls@ietf.org Message-Id: <20200426073249.E99BE3065E10@mailuser.nyi.internal> Date: Sun, 26 Apr 2020 03:32:49 -0400 (EDT) Archived-At: Subject: [TLS] Weekly github digest (TLS Working Group Drafts) 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: Sun, 26 Apr 2020 07:33:00 -0000 --===============5869089515059996555== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/draft-ietf-tls-esni (+1/-0/=F0=9F=92=AC8) 1 issues created: - Restrict ECHO inner/outer variance for interop purposes (by sftcd) https://github.com/tlswg/draft-ietf-tls-esni/issues/223=20 5 issues received 8 new comments: - #223 Restrict ECHO inner/outer variance for interop purposes (1 by ekr) https://github.com/tlswg/draft-ietf-tls-esni/issues/223=20 - #218 HPKE code points vs. TLS ciphersuites (3 by bifurcation, chris-woo= d, ekr) https://github.com/tlswg/draft-ietf-tls-esni/issues/218=20 - #217 ECHOConfigContents.extensions is not needed (1 by ekr) https://github.com/tlswg/draft-ietf-tls-esni/issues/217=20 - #214 Clarify whether ClientHelloInner can support TLS 1.2. (2 by ekr, g= rittygrease) https://github.com/tlswg/draft-ietf-tls-esni/issues/214=20 - #177 GREASE ESNI extensions are easily distinguished from real ones (1 = by ekr) https://github.com/tlswg/draft-ietf-tls-esni/issues/177=20 * tlswg/draft-ietf-tls-external-psk-importer (+4/-4/=F0=9F=92=AC0) 4 issues created: - Remove RFC1035 and RFC6234 references (by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/33= =20 - Link to Selfie upon first reference (by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/32= =20 - Clarify that EPSKs with the same identity will yield the same imported = PSK (by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/31= =20 - Replace use of "clients" with "endpoints" (by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/30= =20 4 issues closed: - Replace use of "clients" with "endpoints" https://github.com/tlswg/draf= t-ietf-tls-external-psk-importer/issues/30=20 - Clarify that EPSKs with the same identity will yield the same imported = PSK https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/31= =20 - Link to Selfie upon first reference https://github.com/tlswg/draft-ietf= -tls-external-psk-importer/issues/32=20 - Remove RFC1035 and RFC6234 references https://github.com/tlswg/draft-ie= tf-tls-external-psk-importer/issues/33=20 * tlswg/dtls13-spec (+1/-1/=F0=9F=92=AC1) 1 issues created: - Should we require CIDs on all packets (by ekr) https://github.com/tlswg/dtls13-spec/issues/144=20 1 issues received 1 new comments: - #144 Should we require CIDs on all packets (1 by ekr) https://github.com/tlswg/dtls13-spec/issues/144=20 1 issues closed: - Improve ACK advice https://github.com/tlswg/dtls13-spec/issues/128=20 * tlswg/tls-subcerts (+0/-2/=F0=9F=92=AC2) 1 issues received 2 new comments: - #57 Editor drafts are out-of-date (2 by chris-wood, grittygrease) https://github.com/tlswg/tls-subcerts/issues/57=20 2 issues closed: - Editor drafts are out-of-date https://github.com/tlswg/tls-subcerts/iss= ues/57=20 - Add RSA signing oracle concerns to security considerations https://gith= ub.com/tlswg/tls-subcerts/issues/59=20 Pull requests ------------- * tlswg/draft-ietf-tls-md5-sha1-deprecate (+2/-0/=F0=9F=92=AC0) 2 pull requests submitted: - Add reference to transcript collision paper (by ghedo) https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/6=20 - Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms exte= nsion (by ghedo) https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/5=20 * tlswg/draft-ietf-tls-esni (+2/-2/=F0=9F=92=AC5) 2 pull requests submitted: - Fix outdated references to ESNIConfig (by d1vyank) https://github.com/tlswg/draft-ietf-tls-esni/pull/222=20 - Rearrange sentences for better readability (by d1vyank) https://github.com/tlswg/draft-ietf-tls-esni/pull/221=20 1 pull requests received 5 new comments: - #209 padding scheme text (5 by chris-wood, ekr, sftcd) https://github.com/tlswg/draft-ietf-tls-esni/pull/209=20 2 pull requests merged: - Rearrange sentences for better readability https://github.com/tlswg/draft-ietf-tls-esni/pull/221=20 - Fix outdated references to ESNIConfig https://github.com/tlswg/draft-ietf-tls-esni/pull/222=20 * tlswg/draft-ietf-tls-external-psk-importer (+2/-2/=F0=9F=92=AC1) 2 pull requests submitted: - Couple of other notes (by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/35=20 - Apply edits from Verisign review. (by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/34=20 1 pull requests received 1 new comments: - #29 Tighten up IANA considerations (1 by chris-wood) https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/29=20 2 pull requests merged: - Tighten up IANA considerations https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/29=20 - Apply edits from Verisign review. https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/34=20 * tlswg/draft-ietf-tls-ticketrequest (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Declining new tickets requires both counters =3D=3D 0 (by vdukhovni) https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/20=20 * tlswg/dtls13-spec (+3/-8/=F0=9F=92=AC6) 3 pull requests submitted: - Explicitly provide integrity for the CID (by ekr) https://github.com/tlswg/dtls13-spec/pull/143=20 - Ack epochs2 (by ekr) https://github.com/tlswg/dtls13-spec/pull/142=20 - Ack epochs (by ekr) https://github.com/tlswg/dtls13-spec/pull/141=20 5 pull requests received 6 new comments: - #142 Ack epochs2 (2 by chris-wood, ekr) https://github.com/tlswg/dtls13-spec/pull/142=20 - #137 Describe duplication of state machines for post-handshake messages= (1 by ekr) https://github.com/tlswg/dtls13-spec/pull/137=20 - #134 Draft -37 changes not uploaded to repo (?) (1 by ekr) https://github.com/tlswg/dtls13-spec/pull/134=20 - #130 Update to Figure 1 (1 by ekr) https://github.com/tlswg/dtls13-spec/pull/130=20 - #129 Removed term "deprotection" (1 by ekr) https://github.com/tlswg/dtls13-spec/pull/129=20 8 pull requests merged: - Clarify when to ACK and what to ACK https://github.com/tlswg/dtls13-spec/pull/139=20 - Nits and wording improvements. https://github.com/tlswg/dtls13-spec/pull/131=20 - Providing an informational design rational for the ACK message https://github.com/tlswg/dtls13-spec/pull/140=20 - Allow ACKing non-terminal complete flights if response takes time https://github.com/tlswg/dtls13-spec/pull/138=20 - Remove SENDING->FINISHED transition in state machine https://github.com/tlswg/dtls13-spec/pull/136=20 - KeyUpdate Clarification https://github.com/tlswg/dtls13-spec/pull/135=20 - Indicate to remove Working Group Info Section https://github.com/tlswg/dtls13-spec/pull/133=20 - Adding Acknowledgements Section https://github.com/tlswg/dtls13-spec/pull/132=20 * tlswg/tls-subcerts (+1/-2/=F0=9F=92=AC1) 1 pull requests submitted: - Nick/08 (by grittygrease) https://github.com/tlswg/tls-subcerts/pull/61=20 1 pull requests received 1 new comments: - #61 Nick/08 (1 by chris-wood) https://github.com/tlswg/tls-subcerts/pull/61=20 2 pull requests merged: - Nick/08 https://github.com/tlswg/tls-subcerts/pull/61=20 - The impact of signature forgery attacks https://github.com/tlswg/tls-subcerts/pull/60=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/tlswg/draft-ietf-tls-semistatic-dh * https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate * https://github.com/tlswg/draft-ietf-tls-esni * https://github.com/tlswg/certificate-compression * https://github.com/tlswg/draft-ietf-tls-external-psk-importer * https://github.com/tlswg/draft-ietf-tls-ticketrequest * https://github.com/tlswg/tls-flags * https://github.com/tlswg/dtls13-spec * https://github.com/tlswg/dtls-conn-id * https://github.com/tlswg/tls-subcerts * https://github.com/tlswg/oldversions-deprecate * https://github.com/tlswg/sniencryption * https://github.com/tlswg/tls-exported-authenticator * https://github.com/tlswg/draft-ietf-tls-grease --===============5869089515059996555== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday April 26, 2020

Issues

tlswg/draft-ietf-tls-esni (+1/-0/=F0=9F=92=AC8)

1 issues created:

5 issues received 8 new comments:

tlswg/draft-ietf-tls-external-psk-importer (+4/-4/=F0=9F=92=AC0)

4 issues created:

4 issues closed:

tlswg/dtls13-spec (+1/-1/=F0=9F=92=AC1)

1 issues created:

1 issues received 1 new comments:

1 issues closed:

tlswg/tls-subcerts (+0/-2/=F0=9F=92=AC2)

1 issues received 2 new comments:

2 issues closed:

Pull requests

tlswg/draft-ietf-tls-md5-sha1-deprecate (+2/-0/=F0=9F=92=AC0)

2 pull requests submitted:

tlswg/draft-ietf-tls-esni (+2/-2/=F0=9F=92=AC5)

2 pull requests submitted:

1 pull requests received 5 new comments:

2 pull requests merged:

tlswg/draft-ietf-tls-external-psk-importer (+2/-2/=F0=9F=92=AC1)

2 pull requests submitted:

1 pull requests received 1 new comments:

2 pull requests merged:

tlswg/draft-ietf-tls-ticketrequest (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

tlswg/dtls13-spec (+3/-8/=F0=9F=92=AC6)

3 pull requests submitted:

5 pull requests received 6 new comments:

8 pull requests merged:

tlswg/tls-subcerts (+1/-2/=F0=9F=92=AC1)

1 pull requests submitted:

1 pull requests received 1 new comments:

2 pull requests merged:

Repositories tracked by this digest:

--===============5869089515059996555==-- From nobody Sun Apr 26 02:37:55 2020 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 ECAD13A119C for ; Sun, 26 Apr 2020 02:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.82, 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=Ofn8ybY6; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=Ofn8ybY6 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 8qO6hh_s2xg9 for ; Sun, 26 Apr 2020 02:37:50 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80052.outbound.protection.outlook.com [40.107.8.52]) (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 C9F583A119B for ; Sun, 26 Apr 2020 02:37:49 -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=ik53waGTvDhaaCuuIHvwLnTtGiy5J4U5dWP4KXh56vg=; b=Ofn8ybY6jFlEsPJKDpaU5kajd4CYdj88xUPIL1zxQ1/fYzkUnHGXjdSfkCBIRqFXa9xB4MOa7azLasmWB4THhl2q0uB7Q3qOdwpihtM9edUl6SjBrPiqfRrzuyg2zMdeJbp4OUkDFitq9lRazs6ToUYYLEVpXBcBoal7bs+zPBg= Received: from AM6P192CA0089.EURP192.PROD.OUTLOOK.COM (2603:10a6:209:8d::30) by DBBPR08MB4348.eurprd08.prod.outlook.com (2603:10a6:10:cc::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Sun, 26 Apr 2020 09:37:46 +0000 Received: from VE1EUR03FT050.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8d:cafe::bb) by AM6P192CA0089.outlook.office365.com (2603:10a6:209:8d::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Sun, 26 Apr 2020 09:37:46 +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 VE1EUR03FT050.mail.protection.outlook.com (10.152.19.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Sun, 26 Apr 2020 09:37:45 +0000 Received: ("Tessian outbound fb9de21a7e90:v54"); Sun, 26 Apr 2020 09:37:45 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 10cbee33d0ad7fb2 X-CR-MTA-TID: 64aa7808 Received: from 530a54f5b349.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 277E0265-65F9-44CE-96F7-F8ED2BD24B14.1; Sun, 26 Apr 2020 09:37:40 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 530a54f5b349.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Sun, 26 Apr 2020 09:37:40 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OiRM/EbKjLDno/o2sDU1JQZRw4mc8wZ3yygGb20cMmzGgdYvGzdlSkf27sEiBPWx/Z43+/hsinnCR+f5R5ORuOAIk6g4YY5+BNwPwMjCZWZz+HoyCH2RLWToINhhPOPhZpkUgKjs1b2nAmGllyUGcsfB3IllbNt2QUcZBELd/RkAnswpAOUnabmsgEvoXjXN/Dp8q71b4+zB0WL1pL6UV9shXNzZcyf268fpiyl9Hcd5llYFDJKWcedGbXBoHusIDgwxTug0P0qxmq3RSerbKv4Zxy+N/8fr5f3tW2JpUmij9RCkk03tNcI8DH4SyMZMF58ykiSIqjtqgfLq2umnIw== 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=ik53waGTvDhaaCuuIHvwLnTtGiy5J4U5dWP4KXh56vg=; b=etMQZXEMl60yDuKUta/hc7VKYicOZ8N8iV2cinXHtIfU6HizvJFK7/6Es46rLAc19wEK2UlpRn8nZ/vjUcwX/gdQjIqaq+BFQYcfYYC6qvUbzmNDnJinZ1JV3epiZepx0/MDkJmP6uH0BBUB+QfjSUUIqHoA1/dw8Y+hCMnnpcxcfCc0yKVG70uHGw9VEUnUJfTQaD18ypcdcVFsk/xd8Rkiw5FiOatRQz8iE5SldZaHDv/gdifpZKXsARAAgogAIPxCXhs3Crt0c58X0TfY50P4KtzYfncg6XVGcFZWdUS1nN/FZ/HSPNfnFRNPbnUbxCQEV/VwQgxOUzKb40t3eA== 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=ik53waGTvDhaaCuuIHvwLnTtGiy5J4U5dWP4KXh56vg=; b=Ofn8ybY6jFlEsPJKDpaU5kajd4CYdj88xUPIL1zxQ1/fYzkUnHGXjdSfkCBIRqFXa9xB4MOa7azLasmWB4THhl2q0uB7Q3qOdwpihtM9edUl6SjBrPiqfRrzuyg2zMdeJbp4OUkDFitq9lRazs6ToUYYLEVpXBcBoal7bs+zPBg= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB3845.eurprd08.prod.outlook.com (2603:10a6:20b:85::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Sun, 26 Apr 2020 09:37:39 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d%6]) with mapi id 15.20.2937.020; Sun, 26 Apr 2020 09:37:39 +0000 From: Thomas Fossati To: Christopher Wood , "tls@ietf.org" Thread-Topic: [TLS] DTLS 1.3 AEAD additional data Thread-Index: AQHWF+iN1gKILcDltkmRr5OfopCaAaiD3VMAgAB8FQCAAE7VmIAAawyAgAAHdS6AAB8+AIAACQCRgACPx4CAABkpAIAABDCAgAAC0ICAAEL8/IAAHxqAgADkdgCAAcgWAIAAsyqAgAAI7ICAAX/zAA== Date: Sun, 26 Apr 2020 09:37:39 +0000 Message-ID: <009D63D5-6353-4429-A62C-EB7617E4B9EC@arm.com> References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com> <1e6201d6-a078-4137-898d-d1554c22aa10@www.fastmail.com> <1CBF6B88-8830-44A4-8F9B-143F884FF6ED@arm.com> In-Reply-To: <1CBF6B88-8830-44A4-8F9B-143F884FF6ED@arm.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 4360a4f9-b9bc-4c20-229a-08d7e9c579f9 x-ms-traffictypediagnostic: AM6PR08MB3845:|AM6PR08MB3845:|DBBPR08MB4348: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 03853D523D X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(396003)(136003)(376002)(346002)(478600001)(33656002)(8676002)(91956017)(4326008)(76116006)(66946007)(36756003)(6506007)(8936002)(2616005)(110136005)(53546011)(316002)(186003)(71200400001)(5660300002)(86362001)(66556008)(6486002)(6512007)(66446008)(2906002)(66476007)(26005)(64756008)(81156014); 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: Z7LZURx9HJl+95O1ATgFo4RvjFrxAISELr/7L1Hp+QVGT0vTg1FhP/TIKtmUeuEnbQDfd12gtBOi5z0A2j1C4nx8PQalOospcuKKFslyv6rNrY1+/gAJvvaW0fztuRRYh2XkvUZi+jr8pcIv9A59CpFwCeIvXIEWg+uLpYKqZtlv6WWgC+lZGrm9I14fuyruohBwR73qL3DtI8xBUPq6Y7DJ85wjl97+Qou5gwEJSNnPJLC59cyzTHp9i3ZdmGmzadvsI+bQchjruxDU07UJh3nrvqO6ePYDaaY+6lqoaphe7laFv+1SXoKiyyaVU83zSq4qunFLq9gXb+QVimPI90U5trvn6mnLPhL2Kq5/sy/UcpIlYH5vVzFDLDEJPp5APXAWPi2Z0BUHIO2aRuIBt/PHHsiEI9+lIhruBh7JP7I8/2bNhMMDaxUG6mGl1D4z x-ms-exchange-antispam-messagedata: df6ZfzhU02NgsN7EtEE+tobcrzFbpahIELJAwtQXKNGBB5p55M/5jhJm5/w6Dov0qgH4xxWq8ZX1X8Baqct+ADNv5o9JE2irSfatBb1CW9WGr4s/GOcmwbPygnSW2ikx3vSh2ly3QkawrspkbtJrKYvoHBqkPQUHgieDnzjVcmpJJbK6o1ii22vvgx0VhkfM/NfAU9WvP8LYE0rPr1PYqaNWvDg7P6Ld6BPUPCD4aQPTSuStB8CZRyW7/c/ymERrtIch9UBvxq75GqD0l5cCAzvGWOL8DYLwtUUFH/pWtlC/suzFtHmjQPE4a26BJIrnWr56/a9HixvZMs0gf1A7W03m8EZ6uzvOCPqLy9ngjNr8VsNUuR8QhZHX/4SpmO5qswVcgkw8kza0AAhazvtQbUNm88Z6O2b0QQCBjdeeXiwLPN2gZDvZmtr4saoMMmRjl9teEYCBf+BixSaaIgy4zzmVVuUvC1kUfGrtt+q20p83TI2Kf1lPfDDSMJ90CmPQsEiGlFyU/N7EnS12MNCkcVcMTzGEddaMLk6sT1r4oORsyKhyZNk1Rt8GUXZDbVhAdQVqul+8yXxjizotYyeKSsM7BC+qlt5zUChNj9HsuEUpnlYJfuzBQFWYC1qFTZ5289u1/lLLK5d4c1bhUx4NvZkvtYqiGdI7O6PTFM5G88ul5922oAkpmhm7p3VJFmJPIPmc1UqkPhAmoPFjKDg1OWRpPVoBomKrzI6Dw9LH8SBQpXv0FTTASIodkuL9POlrmoam4DYqJc2ABEu8N/ELM+4Pe0NZKf7IowTTDoWdTjk= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3845 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT050.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:(4636009)(136003)(376002)(346002)(39860400002)(396003)(46966005)(53546011)(86362001)(6506007)(81156014)(47076004)(82740400003)(8676002)(70206006)(2906002)(356005)(82310400002)(70586007)(6512007)(8936002)(36906005)(33656002)(2616005)(5660300002)(26005)(6486002)(336012)(4326008)(478600001)(316002)(36756003)(110136005)(186003)(81166007); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 7ebafd65-03d0-4750-5bbc-08d7e9c575e4 X-Forefront-PRVS: 03853D523D X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: an5azUWxbRnPWZYoCySIly4cwHf6otwcAMQvdmwM0Z6BNnwyezHLkWDqw4k2mJ1kK1oedPzCkgElnPBIA6Kn+vb52+G98pCZPEDnYJSV76N3IGbr49zDCjS9cdmHyYcmYiqQTSizdcCvkUbp/m4E3x1ZNgkCGV35rm6cLb8EwqiwKJ97DVdWlZ5aVo26++h1a93X8CZXXzWXUFnEx99+cU1+ANkPYPyLha/ejnzzuzJPDZocKuyQJqWl9pQZ7q8SYP7wfI2vcdXz+zLHoaLH6eE6tIqoskAXF88vPgI/ib2ahEzedMAeHrONEaV+vcpFFma73TR3CvcyUpFKe0XPcjNs7DmYB+ddy3yGUCzFxt318MhnkoBmTlESVP7/SLHw2mxG9if2Cg6pFPm06mawJNXmoPgtypRf5/2CVgScdh3kIUQHmLEA+F6AfgqDPwQbi0KKY4gfaJsB5lNbTEsCD5fkPfck3GQ0YRW+NKsFegpG1slYj0dsLOmQ04oPA9yQwEGtwT/4bP3lb0lbNVwHxQ== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2020 09:37:45.9414 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4360a4f9-b9bc-4c20-229a-08d7e9c579f9 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: DBBPR08MB4348 Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Sun, 26 Apr 2020 09:37:53 -0000 T24gMjUvMDQvMjAyMCwgMTE6NDMsICJUaG9tYXMgRm9zc2F0aSIgPFRob21hcy5Gb3NzYXRpQGFy bS5jb20+IHdyb3RlOg0KPiBPbiAyNS8wNC8yMDIwLCAxMToxMSwgIlRob21hcyBGb3NzYXRpIiA8 VGhvbWFzLkZvc3NhdGlAYXJtLmNvbT4gd3JvdGU6DQo+ID4gT24gMjUvMDQvMjAyMCwgMDE6MzAs ICJDaHJpc3RvcGhlciBXb29kIiA8Y2F3QGhlYXBpbmdiaXRzLm5ldD4NCj4gPiB3cm90ZToNCj4g PiA+IE9uIFRodSwgQXByIDIzLCAyMDIwLCBhdCAyOjE3IFBNLCBFcmljIFJlc2NvcmxhIHdyb3Rl Og0KPiA+ID4gPiAxLiBBbGxvd2luZyBpbXBsaWNpdCBDSURzIGlzIHZlcnkgcmVjZW50IChpdCB3 YXMgaW50cm9kdWNlZCBpbg0KPiA+ID4gPiAtMzQpDQo+ID4gPiA+IDIuIFRoZSBDSUQgc3BlY2lm aWNhdGlvbiBleHBsaWNpdGx5IHByb2hpYml0cyBpdCBmb3IgRFRMUyAxLjIuDQo+ID4gPiA+IDMu IEkgaGF2ZW4ndCByZWFsbHkgaGVhcmQgYSB2ZXJ5IGNvbXBlbGxpbmcgYXJndW1lbnQgZm9yIHRo aXMNCj4gPiA+ID4gICAgYW5kIEkgbm90ZSB0aGF0IFFVSUMgZm9yYmlkcyBpdCBbYW5kIGluIGZh Y3QgaGFzIG11Y2ggd29yc2UNCj4gPiA+ID4gICAgcHJvYmxlbXMgd2hlbiB5b3UgbWl4IGVwb2No cyBiZWNhdXNlIHRoZSBsb25nIGhlYWRlciBpcyBzbw0KPiA+ID4gPiAgICBsb25nXQ0KPiA+ID4g Pg0KPiA+ID4gPiBTbywgZ2l2ZW4gdGhhdCB0aGUgc2ltcGxlc3QgYW5kIG1vc3QgY29uc2lzdGVu dCB0aGluZyBpcyB0bw0KPiA+ID4gPiBzaW1wbHkgZm9yYmlkIGl0OiBjYW4gc29tZW9uZSBtYWtl IGFuIGFyZ3VtZW50IGZvciB3aHkgdGhpcyBpcw0KPiA+ID4gPiBpbXBvcnRhbnQgdG8gcGVybWl0 Pw0KPiA+ID4NCj4gPiA+IFRoYW5rcyB0byBldmVyeW9uZSB3aG8gcGFydGljaXBhdGVkIGluIHRo aXMgdGhyZWFkIHNvIGZhciEgR2l2ZW4NCj4gPiA+IHRoZSBwb2ludHMgYWJvdmUsIHRoZSBjaGFp cnMgd291bGQgbGlrZSB0byBoZWFyIGFyZ3VtZW50cyBpbiBmYXZvcg0KPiA+ID4gb2YgaW1wbGlj aXQgQ0lEcy4gQWJzZW50IHN1YnN0YW50aWFsIHJhdGlvbmFsZSwgd2UnbGwgYXNzdW1lIHJvdWdo DQo+ID4gPiBjb25zZW5zdXMgZm9yIGV4cGxpY2l0IENJRHMuDQo+ID4NCj4gPiBIaSBDaHJpcywg SSB0aGluayBpbXBsaWNpdCBDSUQgbmVlZHMgdG8gYmUgY29uc2lkZXJlZCBpbiB0aGUgd2lkZXIN Cj4gPiBzY29wZSBvZiB1bmlmaWVkX2hkciBjb21wcmVzc2lvbiwgdG9nZXRoZXIgd2l0aCBpbXBs aWNpdCBsZW5ndGggYW5kDQo+ID4gc2hvcnRlbmVkIGVwb2NoLiAgSW4gcGFydGljdWxhciwgZnJv bSBDaHJpcyBQJ3MgZW1haWxzIEkgdW5kZXJzdGFuZA0KPiA+IHRoYXQgYmVpbmcgYWJsZSB0byBh dXRoZW50aWNhdGUgcmVjb3JkcycgbGVuZ3RoIGlzIGEgY29yZSBhc3N1bXB0aW9uDQo+ID4gaW4g dGhlIHNlY3VyaXR5IHByb29mIG9mIFRMUy4gIFRoZXJlZm9yZSBsZWF2aW5nIGl0IG91dCBmcm9t IERUTFMNCj4gPiBBQUQgd2hlbiBpdCdzIG5vdCBpbiB0aGUgaGVhZGVyIGxvb2tzIGxpa2UgYSBw cmV0dHkgYmFkIGlkZWEuICBJZg0KPiA+IHRoaXMgaXMgdGhlIGNhc2UgKGkuZS4gdGhlIGZhY3Qg dGhhdCB0aGUgd2lyZSBpbWFnZSBieSBpdHNlbGYgaXMgbm90DQo+ID4gc3VmZmljaWVudCBpbnB1 dCB0byB0aGUgQUFEKSwgdGhlbiBhdXRoZW50aWNhdGluZyBpbXBsaWNpdCBDSURzDQo+ID4gc2hv dWxkIGp1c3QgY29tZSBpbiB0aGUgc2FtZSBidW5kbGUuDQo+DQo+IFNvcnJ5LCBzY3JhdGNoIHRo YXQgZm9yIHRoZSBtb21lbnQgLSBJIGhhZCBtaXNzZWQgdGhlIG1vc3QgcmVjZW50DQo+IGVtYWls cyBvbiB0aGlzIHRocmVhZCA6LSgNCg0KQmFjayB0byB0aGlzIGFmdGVyIGhhdmluZyByZWFkIGFu ZCBkaWdlc3RlZCB0aGUgcGFyYWxsZWwgdGhyZWFkLg0KDQpBcyBpdCBzdGFuZHMgSSBkb24ndCB0 aGluayB3ZSBoYXZlIGVub3VnaCBkYXRhIHRvIHRha2UgYW4gb3B0aW1hbA0KZGVjaXNpb24gd2l0 aCByZXNwZWN0IHRvIHdoYXQgbmVlZHMgdG8gYmUgaW5wdXQgdG8gdGhlIEFBRC4NCg0KSSBzdWdn ZXN0IHdlIGVyciBvbiB0aGUgc2lkZSBvZiBjYXV0aW9uIGFuZCB1c2UgYSBwc2V1ZG8taGVhZGVy IGFwcHJvYWNoDQp3aGVyZSB0aGUgcHNldWRvLWhlYWRlciBlcXVhdGVzIHRoZSB3aXJlLWhlYWRl ciAoZXhjZXB0IHRoZSBlcG9jaCBpcyBpbg0KZnVsbCkgd2hlbiBubyBjb21wcmVzc2lvbiBpcyBp bnZvbHZlZCBhbmQgb3RoZXJ3aXNlIGluY2x1ZGVzIGFsbCB0aGUNCmVsaWRlZCBmaWVsZHMuDQoN CkkgYWxzbyBub3RlIHRoYXQgaXQnZCBiZSBncmVhdCBpZiB0aGUgZm9ybWFsIHZlcmlmaWNhdGlv biBjb21tdW5pdHkNCmNvdWxkIGNhcnZlIHNvbWUgdGltZSB0byBsb29rIGludG8gdGhlIHNlY3Vy aXR5IG9mIERUTFMgMS4zLiAgVGhlcmUgaXMNCmNlcnRhaW5seSBhIGxvdCBvZiBvdmVybGFwIHdp dGggVExTIGFuZCBJIGd1ZXNzIHN1YnN0YW50aWFsIHBhcnRzIG9mIHRoZQ0KbW9kZWxsaW5nIGNh biBiZSByZXVzZWQsIGJ1dCB0aGVyZSBhcmUgaW50ZXJlc3RpbmcgZGlmZmVyZW5jZXMgKGluDQpw YXJ0aWN1bGFyLCBhcm91bmQgdGhlIHRpZ2h0IGtuaXQgYmV0d2VlbiByZWxpYWJpbGl0eSBhbmQg c2VjdXJpdHkNCmxheWVycyBkdXJpbmcgaGFuZHNoYWtlKSB0aGF0IGFyZSB1bmlxdWUgdG8gRFRM UyBhbmQgbGlrZWx5IGRlc2VydmUgYQ0KbW9yZSBjYXJlZnVsIGxvb2suDQoNCmNoZWVycyENCg0K SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUg aW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Sun Apr 26 02:43:38 2020 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 BD9EF3A0E98 for ; Sun, 26 Apr 2020 02:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, 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=gBLfvph+; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=gBLfvph+ 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 IZQvogDa0uXh for ; Sun, 26 Apr 2020 02:43:33 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80051.outbound.protection.outlook.com [40.107.8.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 083FD3A0E94 for ; Sun, 26 Apr 2020 02:43:32 -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=Sp/L52Bsbh2Ev4VYicGTvJIsp16cl/gDBcLMFo1XWq8=; b=gBLfvph+g3qPqlhKRTTYfCmLEJCZEuJxRKsY+dBy3ibVz+9Wc8biUHJ9nrKrfvDAKrxeqHJvBCXKZa+2m8W1BMITntAuET2jpcMq1ErvGpd9kSr9tu0O6545UWuXGgD+J4zfRMWJD9ezj2HDMoE9lnsZVyoIBxpMrR+XS+I2VpY= Received: from DB6PR0202CA0025.eurprd02.prod.outlook.com (2603:10a6:4:a5::11) by VI1PR08MB3518.eurprd08.prod.outlook.com (2603:10a6:803:7a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Sun, 26 Apr 2020 09:43:29 +0000 Received: from DB5EUR03FT050.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:a5:cafe::16) by DB6PR0202CA0025.outlook.office365.com (2603:10a6:4:a5::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Sun, 26 Apr 2020 09:43: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 DB5EUR03FT050.mail.protection.outlook.com (10.152.21.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Sun, 26 Apr 2020 09:43:29 +0000 Received: ("Tessian outbound ff098c684b24:v54"); Sun, 26 Apr 2020 09:43:29 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: d79acfa38b1d1ce3 X-CR-MTA-TID: 64aa7808 Received: from b398d8389341.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 88B55679-B5ED-4436-8AC4-1F6783DC1DD0.1; Sun, 26 Apr 2020 09:43:23 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b398d8389341.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Sun, 26 Apr 2020 09:43:23 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=md536OK6wuUKF/y37abqiJgtPaduRld1muUVSdABOLREIoDEY+Lxz8u2iXmu96PPMNh/G10G3liKwLlwElRwVwmJXuvlXjbW5RdvgVyk/W28wphYJE5hxBGC4lEgwSF2Un9qqUbW4syJiXiOYa54UKngu3gUzRhaQjDnPFUjTMPWH8SGQSdYbBYAzbxnR/c+eWkO47m7EELltzNg56bDg+crmrDU/SdgwUjHn0YPtLk0Vy8qUCYdhL3k5Ck7o2b005omQoDocTNYS+ByjZ+PKeT7aqEnc3rxgXpEwYPiuSWI26qWpcOWAfySuKmOGJx2DU7ElomfU3UdTI9wOCxsiw== 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=Sp/L52Bsbh2Ev4VYicGTvJIsp16cl/gDBcLMFo1XWq8=; b=lSdEmY2A4Z5SxDtB619pxv6I5WrKcXJij2w74KVtBENV4j0sEYJyoJOygpg4NBOLCV51yeIU9hELlxdNxbt2eHnl6modELyf3lGOnoEWRpnpsxKKfjkEMti0Sw59tCxgCc0x2K7/RGOGnZai9kPypmTuy9xG9xuhO2TvOysgDLMuOfR89NCSdO8QYbt/QIIQvD9qCJXsvubOayuopgbnFdadKaSS46WbAJfs/brhTWRommAJoncZpTmVQkuaadQ+7B3J/7wkWnCKHFuOk6zeR4qzPIVBJ9sGFbPx2wuY5Gxhy5HZSDygqWH+dexlo2FiV5Xxweo/CUM0m7mpSUhNrA== 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=Sp/L52Bsbh2Ev4VYicGTvJIsp16cl/gDBcLMFo1XWq8=; b=gBLfvph+g3qPqlhKRTTYfCmLEJCZEuJxRKsY+dBy3ibVz+9Wc8biUHJ9nrKrfvDAKrxeqHJvBCXKZa+2m8W1BMITntAuET2jpcMq1ErvGpd9kSr9tu0O6545UWuXGgD+J4zfRMWJD9ezj2HDMoE9lnsZVyoIBxpMrR+XS+I2VpY= Received: from AM6PR08MB3318.eurprd08.prod.outlook.com (2603:10a6:209:45::15) by AM6PR08MB3702.eurprd08.prod.outlook.com (2603:10a6:20b:8e::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Sun, 26 Apr 2020 09:43:21 +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.2937.023; Sun, 26 Apr 2020 09:43:21 +0000 From: Hanno Becker To: chris - CC: Eric Rescorla , Hannes Tschofenig , "tls@ietf.org" Thread-Topic: [TLS] Choice of Additional Data Computation Thread-Index: AdYaKASVCp3JPFQuSaOSMkwtz/VZZwAEUEsAAAN7oaAAAnFQAAAASY9CAAFcJQAAAoyFgAAAY+d9AADW9gAAAKxogAAAKW2AAAULeAAAKztBgAAIVeEa Date: Sun, 26 Apr 2020 09:43:21 +0000 Message-ID: References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> , In-Reply-To: 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.169.222.218] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: b7f2b1f5-b235-4363-c3af-08d7e9c64678 x-ms-traffictypediagnostic: AM6PR08MB3702:|AM6PR08MB3702:|VI1PR08MB3518: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 03853D523D 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:(4636009)(366004)(376002)(39860400002)(136003)(396003)(346002)(186003)(66946007)(86362001)(26005)(76116006)(66446008)(66556008)(6916009)(4326008)(64756008)(5660300002)(66476007)(71200400001)(33656002)(19627405001)(9686003)(53546011)(8936002)(55016002)(316002)(7696005)(2906002)(8676002)(478600001)(52536014)(54906003)(6506007)(81156014); 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: 6ox/xb07jiSoPZ7Bxa8GEVvXRz5I0KQ9lmySPxNVCukryS061wkIg9XN2JoWygYAG3vujt40EIzoRtLJSW1rGCPbvom6pgax64ItdQseIzjqnjldzYJknyI+IaCPV05N1s0uZEZeO6Ol/S3xnWopxrP0ktOiGiiuG4x5Q41t0mEW9LMVT77XFMpyP+2rbGhZZbr9monVaP/UfaCv3USTH25RLnA43SftZagsSiQtwgLoKxydi0YdD+8QLGCF2gWinskYW8tudwk5QwplLnfHBObU9okLxOTac+vsv2WmO2sH6uHlq/7EBoJlM7hP8pTaUtvxXB0oDpTHNTET36+rDSHkgSLhdOafSqO+0rFn8b5DvWl6lKBMDejUZwXORTY5vcLeyAfNP4QzJvmXhadSESqYw8gPENrQtfMqgZxQngu7Za4ERbHqhE2YZsE2C8fs x-ms-exchange-antispam-messagedata: xpGvoipQ88Hy8S8KlgSeRWAeA6CWQyWbpA9Ulwwz7Vt/rrVYKbGIuvW8UyI/l31wtqGqHEI0aDCkZpHJLaZ1tsIJhcM+wxy21r3tc1GLqe5Si50cnvkVxODmrr0F/URoKdmzgsCZJmUGed2ZVoto128mS63G+t0PWWdRrqP68XB7qzCHTPjMpH7/ou2/Gm1V49Yl+LuCDiGa1D8tIpsGVQpF10JqqlhlQjxGnb3dEBK37oui7DmAY5qYVEdfmAysipi5p15zf2yOKtAfH3Ujh6AvYmZRAPmyLXGLhM3+l+brXXKro+RipnSkxITVdRBNgXsiv8yG5hn92AtzLPJBil8G2QIFBMjhyEzIgIqPvOSoLtwr/DS9zsnJYZbpkktxRPRxLUiBuIxdRVff9oG1/XjpWKObJK0Mk7ul2kG2xHY+ko2TpCYUMyq0upx3mB7W48TQzF+gzOrmc/Td1Tg7RQI6xtQlKITr7J2k8ASTElpzmkpCurhk80Bz0sIHdV1VxJqjbne0i0sxlspseq1N6IlILCmF9DNZIcgDoZVNWhsijv2+Mc7mFIaiF49FWMtP9jL4g4+kZ38Hd5SZbvV/JHygvokGfzo8QJDBw7JI3zz2Os62qquZbuUc4JhAUYEKfB0XszbrxLlRYZEem7X6fU5LklcgUZ4gFX3Vr3Dg8vNFjhZbaHErmhslXgPlJRcqtJ9YtqjJuYiBYXTUtAwuYKt8pFnnMhspS07XjuesP1UJRZ5b+4dS0VE/N1lhCHecvW/QAYoV3Jr3DMkyP72WMInZRaNPm3p6ujt/ksah68M= Content-Type: multipart/alternative; boundary="_000_AM6PR08MB33185190928734FAFCEDFFCE9BD10AM6PR08MB3318eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3702 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hanno.Becker@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT050.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:(4636009)(136003)(346002)(396003)(39860400002)(376002)(46966005)(8676002)(52536014)(81156014)(55016002)(8936002)(54906003)(7696005)(6862004)(4326008)(70586007)(70206006)(47076004)(336012)(82740400003)(186003)(9686003)(5660300002)(86362001)(356005)(33656002)(81166007)(82310400002)(19627405001)(2906002)(26005)(53546011)(6506007)(478600001)(316002); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: ca6267c6-ce00-4852-b1e2-08d7e9c641f5 X-Forefront-PRVS: 03853D523D X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ydb+9adxt+FNop3gLGg3ZKJ4d12JMpYmRBI/KkiHj3Q+duTsjqjue03DS2Y1D/CpJRDFRLn+SNd4f/tS4AMWfvgnNFSGGiu+uH1fOmy506hoyoIQfwVAq1pTV/MpEMctjY1wh6iTc138oxC+jVH004KEhbS8hd4vTqkAI71Jyhmx+NdES2RCtz6x6+3PGbubrGk0VTvRrZgmqWPEEj/uZfXOYLSFX6HGDFVO6xwyjZa6hQzb2toxfbHtc6WWRxpvho3HkF3nM47Z5ns7x8AfMufm8/jMMYCB56bJ5wqGuciTHBmxnEuL4oTOtmix/ekcAfSMzEgI30Q/H4rGIfxY0kIRQFHQnCU6QqWgStNLo5dlQnWG+f2EJwGYY0IcsEJhhuYGkVwTamGjCytZWX8QkT0Lnmu7iIQ8YvUsbk9R/9zTb5oT7Smb0KhlyzZxQnVvnwEMJbn3TYWO8Ka1MOQwJw7NOLVVXr5iayvA6gcDDFYtMt653JU6098CqA1lIv/H9XAu1+zw14X7kYO83UGTgw== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Apr 2020 09:43:29.1255 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b7f2b1f5-b235-4363-c3af-08d7e9c64678 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: VI1PR08MB3518 Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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: Sun, 26 Apr 2020 09:43:36 -0000 --_000_AM6PR08MB33185190928734FAFCEDFFCE9BD10AM6PR08MB3318eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Thanks Chris for your thoughts. Yes, it seems that specific formal analysis is needed, since we're dealing = with the new situation that - in contrast to TLS 1.3 - shortened or omitted fields in th= e DTLS 1.3 headers (e.g. epoch, length, CID) introduce a notion of implicit context to a recor= d which wasn't present before. This requires analysis of the desired properties of this im= plicit context and their implications on the protocol design. For example, such a property might informally be that a party able to decry= pt a record must have correctly reconstructed the full implicit context of the record, = such as the full epoch when it was shortened in the header, the CID when it was omitted, or = the length when it was omitted. This seems most directly achieved by cryptographically= binding this context to the record through AAD, while protecting only the explicit conte= xt makes reasoning that the party has the correct context either less straightforward (see the= epoch example) or impossible (current CID issue allowing to decrypt a record in a context wit= h different CID). To me it therefore still appears preferable to use a pseudo-header as the A= AD. Hopefully some more people from the protocol verification community will join in here and give their thoughts. Best, Hanno ________________________________ From: chris - Sent: Saturday, April 25, 2020 6:58 PM To: Hanno Becker Cc: Eric Rescorla ; Hannes Tschofenig ; tls@ietf.org Subject: Re: [TLS] Choice of Additional Data Computation So far I fail to understand, on an intuitive level, why it easier to analyz= e the protocol when the AAD can take multiple forms potentially truncating = or omitting the underlying data, but then I don't know the details and you'= re the expert here. If you have time though to explain a bit more where the= flaw in my thinking below is, that would be great, provided it's possible. I don't know that there's a flaw in your thinking. At the moment, all that = I can speak to is how authenticating the header (or not) might impact secur= ity of DTLS. We can't directly extrapolate from what we know about TLS, bec= ause the security goal is not to the same. That said what I know about TLS = is the following: the contents of the record header doesn't matter for secu= rity goal considered in [1], as long as (1) the header is authenticated; an= d (2) it correctly encodes the length of the next ciphertext. But since the= security goal of DTLS is not the same, the details of the spec that are (i= r)relevant to security are likely to differ. For example, another thing which I would expect to be more complicated to v= erify in full rigor is epoch authentication: If the epoch is reduced to its= two low order bits in the DTLS 1.3 header and thus (at the moment) also in= the AAD, arguing that decryption can only succeed for the correctly expand= ed epoch involves knowing that all epochs having different keys. That's of = course true but this fact wouldn't be needed if the full numeric epoch was = always explicitly authenticated in the AAD. This isn't a real issue in the = end, but I would expect it to be a nuisance in a formal proof? In terms of what you mentioned regarding decoding details, it seems that ad= ding the underlying logical header to the AAD ensures more directly that de= cryption can only succeed if header decoding (that is, filling in implicit = data or expanding truncated data) was done correctly, whereas it is less cl= ear with the truncated or omitted data in AAD, as in the epoch example abov= e. Is it possible to explain what the flaw is here intuitively? I'm afraid I would need to absorb spec and think about its intended securit= y properties in order to answer these specific questions. I'm sorry if this= answer is unhelpful; Ekr asked that I chime due to my prior work on TLS. B= ut I don't think there's a simple answer here, and unfortunately I don't ha= ve the time to think it through at the moment. For now, I'll just leave you with this. I'm a fan of the following design p= rinciple: whenever there is a branch in your code that depends on a bit rea= d from the wire, that bit should be authenticated if possible. To your exam= ple, if a decision you're about to make depends on you agreeing with the pe= er on the current epoch, the principle says that the epoch had better be au= thenticated. Whether it's necessary or appropriate to do so here (via AEAD = decryption) depends very much on the context, i.e., the protocol details an= d the security goal. Chris P. 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_AM6PR08MB33185190928734FAFCEDFFCE9BD10AM6PR08MB3318eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,

Thanks Chris for your thoughts. 

Yes, it seems that specific formal analysis is needed= , since we're dealing with the new
situation that - in contrast to TLS 1.3 -&nb= sp;shortened or omitted fields in the <= /span>DTLS 1.3 headers 
(e.g. epoch, length, CID) introduce a notion of implicit context to a record which wasn't 
present before. This requires analysis of the desired properties of this implicit context 
and their implications on the protocol design.

For example, such a = ;property might informally be that a party able to decrypt a record 
must have correctly reconstructed the full implicit context of the record, such as the fu= ll 
epoch when it was shortened in the header, the CID when it was = omitted, or the length 
when it was omitted. This seems most directly achieved by cryptographically binding th= is 
context to the record through AAD, while protecting only the explicit context makes reasoning 
that the party has the correct context either less straightforward (see the&n= bsp;epoch example) or
impossible (current CID issue allowing to decrypt a&nbs= p;record in a context with different CID= ).
To me it therefore still appears = preferable to use a pseudo-header as the A= AD.

Hopefully some more people from the protocol verification community 
will join in here and give their thoughts.

Best,
Hanno
From: chris - <chrispatt= on@gmail.com>
Sent: Saturday, April 25, 2020 6:58 PM
To: Hanno Becker <Hanno.Becker@arm.com>
Cc: Eric Rescorla <ekr@rtfm.com>; Hannes Tschofenig <Hannes= .Tschofenig@arm.com>; tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] Choice of Additional Data Computation
 
 
So far I fail to understand, on an intuitive level, why it easier to a= nalyze the protocol when the AAD can take multiple forms potentially trunca= ting or omitting the underlying data, but then I don't know the details and= you're the expert here. If you have time though to explain a bit more where the flaw in my thinking below= is, that would be great, provided it's possible.

I don't know that there's a flaw in your thinking. At the moment, all = that I can speak to is how authenticating the header (or not) might impact = security of DTLS. We can't directly extrapolate from what we know about TLS= , because the security goal is not to the same. That said what I know about TLS is the following: the content= s of the record header doesn't matter for security goal considered in [1], = as long as (1) the header is authenticated; and (2) it correctly encodes th= e length of the next ciphertext. But since the security goal of DTLS is not the same, the details of the sp= ec that are (ir)relevant to security are likely to differ.

 
For example, another thing which I would expect to be more complicated= to verify in full rigor is epoch authentication: If the epoch is reduced t= o its two low order bits in the DTLS 1.3 header and thus (at the moment) al= so in the AAD, arguing that decryption can only succeed for the correctly expanded epoch involves knowing that al= l epochs having different keys. That's of course true but this fact wouldn'= t be needed if the full numeric epoch was always explicitly authenticated i= n the AAD. This isn't a real issue in the end, but I would expect it to be a nuisance in a formal proof?
In terms of what you mentioned regarding decoding details, it seems th= at adding the underlying logical header to the AAD ensures more directly th= at decryption can only succeed if header decoding (that is, filling in impl= icit data or expanding truncated data) was done correctly, whereas it is less clear with the truncated or o= mitted data in AAD, as in the epoch example above. Is it possible to explai= n what the flaw is here intuitively?

I'm afraid I would need to absorb spec and think about its intended se= curity properties in order to answer these specific questions. I'm sorry if= this answer is unhelpful; Ekr asked that I chime due to my prior work on T= LS. But I don't think there's a simple answer here, and unfortunately I don't have the time to think it th= rough at the moment.

For now, I'll just leave you with this. I'm a fan of the following des= ign principle: whenever there is a branch in your code that depends on a bi= t read from the wire, that bit should be authenticated if possible. To your= example, if a decision you're about to make depends on you agreeing with the peer on the current epoch, the pr= inciple says that the epoch had better be authenticated. Whether it's neces= sary or appropriate to do so here (via AEAD decryption) depends very much o= n the context, i.e., the protocol details and the security goal.


Chris P.


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_AM6PR08MB33185190928734FAFCEDFFCE9BD10AM6PR08MB3318eurp_-- From nobody Sun Apr 26 07:49:31 2020 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 1235A3A0793 for ; Sun, 26 Apr 2020 07:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=dbVuI783; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dNmMCXMM 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 zsPmjcLx6S06 for ; Sun, 26 Apr 2020 07:49:27 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DBCC3A0791 for ; Sun, 26 Apr 2020 07:49:27 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BFFD75C0108; Sun, 26 Apr 2020 10:49:26 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Sun, 26 Apr 2020 10:49:26 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=gpP6ou7WwShqq28KpasFdAZTcf0ecWt S/4DbFIHdSso=; b=dbVuI783k4xciKYDV2NskypxV7SoesZN7zGlGmPriqUqTLD DqAlR7NAFTbno+18IOxttzxcnTTLWSjv4i9MoThIUwCABOMD7OMTgm3BfbjXlNGj jrDI1F+ebSTsntMVWyZIsHpyR+61KUnBatA0qtYY+8GkE474bAO5LzFuYPsQCfTE KxbNDC40GphZ7WtBwH9SmLwssFWc26Cu6KfN0HqSoz4QMJ2wWWnyy6W55ZwAI/Iq 9alD7ug2AxidbNQoM8nOkPD7wOKmaNBMNbLXHZOZg2k58Q/cysTpda7ZlTwTZMCr Df3NVof3Ktw3I9i4KUYhWITX64EnGCT7UCiM3uA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=gpP6ou 7WwShqq28KpasFdAZTcf0ecWtS/4DbFIHdSso=; b=dNmMCXMMw0KqIHpmfpP/h3 TxFJ35augGtYPEngNIQvrRLcv9MPLliXi26rGrKQOxfWKspMDxWLDuzvu7gXbX3b MPvo4Qrlgwc982QH0XG+3HP0fjYHVWqkMSlfFxNiUvaiNq8uYEcsPVO1yqciWfly PUrto2xgpzv7KcgewtOba87TiDdoUQ9ua8ufXWxdI2BGnCCkzR8+dJBOfqunhq2V MI7Uw96UtMdjn7Jwfi8ZZQnn/jyOItEJioGXOtS7IXpBm79wXZNx/PguDttbh9BY X6lemLkiEVDtsrxusanrujEmX7SLTJKaWV3bvgwBtbo8kMFIbliUifT85I4/4bdA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrheejgdekfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfvehhrhhi shhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvghtqe enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgif sehhvggrphhinhhgsghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2073F3C00A1; Sun, 26 Apr 2020 10:49:26 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <18d9978c-1dd1-4365-827c-94c121099949@www.fastmail.com> In-Reply-To: <009D63D5-6353-4429-A62C-EB7617E4B9EC@arm.com> References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com> <1e6201d6-a078-4137-898d-d1554c22aa10@www.fastmail.com> <1CBF6B88-8830-44A4-8F9B-143F884FF6ED@arm.com> <009D63D5-6353-4429-A62C-EB7617E4B9EC@arm.com> Date: Sun, 26 Apr 2020 07:49:05 -0700 From: "Christopher Wood" To: "Thomas Fossati" , "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Sun, 26 Apr 2020 14:49:29 -0000 On Sun, Apr 26, 2020, at 2:37 AM, Thomas Fossati wrote: > On 25/04/2020, 11:43, "Thomas Fossati" wrote: > > On 25/04/2020, 11:11, "Thomas Fossati" wrote: > > > On 25/04/2020, 01:30, "Christopher Wood" > > > wrote: > > > > On Thu, Apr 23, 2020, at 2:17 PM, Eric Rescorla wrote: > > > > > 1. Allowing implicit CIDs is very recent (it was introduced in > > > > > -34) > > > > > 2. The CID specification explicitly prohibits it for DTLS 1.2. > > > > > 3. I haven't really heard a very compelling argument for this > > > > > and I note that QUIC forbids it [and in fact has much worse > > > > > problems when you mix epochs because the long header is so > > > > > long] > > > > > > > > > > So, given that the simplest and most consistent thing is to > > > > > simply forbid it: can someone make an argument for why this is > > > > > important to permit? > > > > > > > > Thanks to everyone who participated in this thread so far! Given > > > > the points above, the chairs would like to hear arguments in favor > > > > of implicit CIDs. Absent substantial rationale, we'll assume rough > > > > consensus for explicit CIDs. > > > > > > Hi Chris, I think implicit CID needs to be considered in the wider > > > scope of unified_hdr compression, together with implicit length and > > > shortened epoch. In particular, from Chris P's emails I understand > > > that being able to authenticate records' length is a core assumption > > > in the security proof of TLS. Therefore leaving it out from DTLS > > > AAD when it's not in the header looks like a pretty bad idea. If > > > this is the case (i.e. the fact that the wire image by itself is not > > > sufficient input to the AAD), then authenticating implicit CIDs > > > should just come in the same bundle. > > > > Sorry, scratch that for the moment - I had missed the most recent > > emails on this thread :-( > > Back to this after having read and digested the parallel thread. > > As it stands I don't think we have enough data to take an optimal > decision with respect to what needs to be input to the AAD. > > I suggest we err on the side of caution and use a pseudo-header approach > where the pseudo-header equates the wire-header (except the epoch is in > full) when no compression is involved and otherwise includes all the > elided fields. > > I also note that it'd be great if the formal verification community > could carve some time to look into the security of DTLS 1.3. There is > certainly a lot of overlap with TLS and I guess substantial parts of the > modelling can be reused, but there are interesting differences (in > particular, around the tight knit between reliability and security > layers during handshake) that are unique to DTLS and likely deserve a > more careful look. Thanks, Thomas. To clarify (as the request was about prohibiting implicit CIDs and not more generally about what's included in the AAD), you'd prefer we allow implicit CIDs, correct? I agree that backing analysis would be generally useful here. Best, Chris From nobody Sun Apr 26 14:09:55 2020 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 1A0753A124B for ; Sun, 26 Apr 2020 14:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 RfCLF61dk3_S for ; Sun, 26 Apr 2020 14:09:52 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC5593A124A for ; Sun, 26 Apr 2020 14:09:51 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id f18so15461958lja.13 for ; Sun, 26 Apr 2020 14:09:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sWQklTZnNTzryLE9rOuxfwAtCXs1ALD5kqlT2Ft2nFY=; b=TLcuYt8F/ucVQ94fRA+6KRrI5YvTjJwe0npG4qkCigozcllBNWRP6/Uuacg12J5/K9 DFks6ILEo7S22S6mHrM8+kQvxn3/MLRojWZv5tKxZR+RrIvgz8gSUR5svBOAF+NlNYEk JoGu+DSmg9kFOTwFzPQ4F7M6f1zkN9pxytnQO9PxH9yS1IeJItG2hmuWMBRO2FllNfN5 DsHdQm3ZQSl29grKySmSza9jQuhCkK9ARmO7ESCEv7QmuGlBfkqY/8GH+gqKKyVdEsVY E/A9lr/xsWoGUDyiOqxk7NfvY8g0O0erGZEYnelpyE0NPx/jhKE87V2SUj/NRuqPSRla T2ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sWQklTZnNTzryLE9rOuxfwAtCXs1ALD5kqlT2Ft2nFY=; b=oIglYJSZgA3ogGKziT5H12p+Ko/tmTgIFCP0Su43laaYO+3NnuOdWI0dIXSq6ajpIP OH7nU/hnPefsJDDlc9aek9iSA9CFgrnlV6TgBWIrbduW0hjtaVwajyEZFwfYw+Vgr4Vr TRv4Pr0+nGd3VoMZ0vVcXiROhu5MdnxsML0cB7gxy4YSvhDPiTdDp/sfu4r5J1aKf6uy 3d+wzSp56K8dZ+BDphtGh/tRBe4gZ801uUGjHi8B/ibXRr3yRqraIeb7oBPL8BiUiHSE 4ss20kkUYly1aU1/JUpipWg1A+4iCDVeNCouMArhz0xeB8EItUWAFQduvIi+S2856TxQ N/tQ== X-Gm-Message-State: AGi0Puaf6vRVDJ3Xc3nf0Onh2+7rQ+6F65z8TKcftUDt2oOI63SkzhOw NDdDkUz5NuMzOJWFyHAZ8RNWJli6HzcakgtykKOhzw== X-Google-Smtp-Source: APiQypL9y3HqplA0RyMVV7fBsIMP57n8ADcIc2mRAfv65GRjEUuXQPbuskwENmx0RnAEMS4bltTkFQpzSKRuiVgUipY= X-Received: by 2002:a2e:99ca:: with SMTP id l10mr12311831ljj.274.1587935389823; Sun, 26 Apr 2020 14:09:49 -0700 (PDT) MIME-Version: 1.0 References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> In-Reply-To: From: Eric Rescorla Date: Sun, 26 Apr 2020 14:09:13 -0700 Message-ID: To: Hanno Becker Cc: chris - , Hannes Tschofenig , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d647f905a438040d" Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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: Sun, 26 Apr 2020 21:09:54 -0000 --000000000000d647f905a438040d Content-Type: text/plain; charset="UTF-8" On Sun, Apr 26, 2020 at 2:43 AM Hanno Becker wrote: > Hi, > > Thanks Chris for your thoughts. > > Yes, it seems that specific formal analysis is needed, since we're > dealing with the new > situation that - in contrast to TLS 1.3 - shortened or omitted fields in > the DTLS 1.3 headers > (e.g. epoch, length, CID) introduce a notion of implicit context to a > record which wasn't > present before. This requires analysis of the desired properties of this > implicit context > and their implications on the protocol design. > > For example, such a property might informally be that a party able to > decrypt a record > must have correctly reconstructed the full implicit context of the > record, such as the full > epoch when it was shortened in the header, the CID when it was omitted, or > the length > when it was omitted. > The epoch, the sequence number, and the length are all bound to the AEAD computation: - The epoch determines the key - The sequence number determines the nonce [note that this is actually implicit in TLS 1.3] - The length determines the input to the AAD. And I am proposing removing implicit CIDs. -Ekr This seems most directly achieved by cryptographically binding this > context to the record through AAD, while protecting only the explicit > context makes reasoning > that the party has the correct context either less straightforward (see > the epoch example) or > impossible (current CID issue allowing to decrypt a record in a context > with different CID). > To me it therefore still appears preferable to use a pseudo-header as the > AAD. > > Hopefully some more people from the protocol verification community > will join in here and give their thoughts. > > Best, > Hanno > ------------------------------ > *From:* chris - > *Sent:* Saturday, April 25, 2020 6:58 PM > *To:* Hanno Becker > *Cc:* Eric Rescorla ; Hannes Tschofenig < > Hannes.Tschofenig@arm.com>; tls@ietf.org > *Subject:* Re: [TLS] Choice of Additional Data Computation > > > > So far I fail to understand, on an intuitive level, why it easier to > analyze the protocol when the AAD can take multiple forms potentially > truncating or omitting the underlying data, but then I don't know the > details and you're the expert here. If you have time though to explain a > bit more where the flaw in my thinking below is, that would be great, > provided it's possible. > > > I don't know that there's a flaw in your thinking. At the moment, all that > I can speak to is how authenticating the header (or not) might impact > security of DTLS. We can't directly extrapolate from what we know about > TLS, because the security goal is not to the same. That said what I know > about TLS is the following: the contents of the record header doesn't > matter for security goal considered in [1], as long as (1) the header is > authenticated; and (2) it correctly encodes the length of the next > ciphertext. But since the security goal of DTLS is not the same, the > details of the spec that are (ir)relevant to security are likely to differ. > > > > For example, another thing which I would expect to be more complicated to > verify in full rigor is epoch authentication: If the epoch is reduced to > its two low order bits in the DTLS 1.3 header and thus (at the moment) also > in the AAD, arguing that decryption can only succeed for the correctly > expanded epoch involves knowing that all epochs having different keys. > That's of course true but this fact wouldn't be needed if the full numeric > epoch was always explicitly authenticated in the AAD. This isn't a real > issue in the end, but I would expect it to be a nuisance in a formal proof? > > In terms of what you mentioned regarding decoding details, it seems that > adding the underlying logical header to the AAD ensures more directly that > decryption can only succeed if header decoding (that is, filling in > implicit data or expanding truncated data) was done correctly, whereas it > is less clear with the truncated or omitted data in AAD, as in the epoch > example above. Is it possible to explain what the flaw is here intuitively? > > > I'm afraid I would need to absorb spec and think about its intended > security properties in order to answer these specific questions. I'm sorry > if this answer is unhelpful; Ekr asked that I chime due to my prior work on > TLS. But I don't think there's a simple answer here, and unfortunately I > don't have the time to think it through at the moment. > > For now, I'll just leave you with this. I'm a fan of the following design > principle: whenever there is a branch in your code that depends on a bit > read from the wire, that bit should be authenticated if possible. To your > example, if a decision you're about to make depends on you agreeing with > the peer on the current epoch, the principle says that the epoch had better > be authenticated. Whether it's necessary or appropriate to do so here (via > AEAD decryption) depends very much on the context, i.e., the protocol > details and the security goal. > > > Chris P. > > > 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. > --000000000000d647f905a438040d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Apr 26, 2020 at 2:43 AM Hanno= Becker <Hanno.Becker@arm.com> wrote:
Hi,

Thanks Chris for your thoughts.=C2=A0

Yes, it seems that specific formal analysis is needed, = since=C2=A0we're dealing=C2=A0with=C2=A0the new
situation that - in contrast to TLS 1.3 -=C2=A0<= span style=3D"color:rgb(0,0,0);font-family:Calibri,Arial,Helvetica,sans-ser= if;font-size:12pt">shortened or omitted=C2=A0fields in the=C2=A0DTLS 1.3 headers=C2=A0
(e.g. epoch, length, CID)=C2=A0introduce a notion=C2=A0of=C2=A0implicit=C2=A0context to a record which wasn't=C2=A0
present=C2=A0before. This re= quires analysis of=C2=A0the desired properties of this implicit context=C2=A0
and their implications on the=C2=A0protocol design.

For example, such a=C2=A0property might informally be=C2=A0that a party=C2=A0able to decrypt a record=C2=A0
must have correctly reconstructed=C2=A0the full implicit context of=C2=A0the record, such=C2=A0as the=C2=A0full=C2=A0
epoch when=C2=A0it was short= ened in the header, the=C2=A0CID=C2=A0wh= en it was=C2=A0omitted,=C2=A0or the length=C2=A0
when it was omitted.





= =C2=A0This seems most direct= ly=C2=A0achieved by cryptographically=C2=A0binding this=C2=A0
context to the record through=C2=A0AAD, while protecting=C2=A0only the=C2=A0explicit context=C2=A0makes reasoning=C2=A0
that the=C2=A0party has the = correct context=C2=A0either less straightforward=C2=A0(see the=C2=A0= epoch example)=C2=A0or
impossible=C2=A0(current=C2= =A0CID issue allowing to decrypt=C2=A0a=C2=A0record in a context with=C2=A0different CID).
To me it=C2=A0therefore stil= l appears=C2=A0preferable to use a pseudo-header=C2=A0as the AAD.<= /div>

Hopefully some more people from the protocol verification community=C2=A0
will join in here=C2=A0and give their thoughts.<= /div>

Best,
Hanno
From= : chris - <chrispatton@gmail.com>
Sent: Saturday, April 25, 2020 6:58 PM
To: Hanno Becker <Hanno.Becker@arm.com>
Cc: Eric Rescorla <ekr@rtfm.com>; Hannes Tschofenig <Hannes.Tschofenig@arm.com>; tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] Choice of Additional Data Computation
=C2=A0
=C2=A0
So far I fail to understand, on an intuitive level, why it easier to a= nalyze the protocol when the AAD can take multiple forms potentially trunca= ting or omitting the underlying data, but then I don't know the details= and you're the expert here. If you have time though to explain a bit more where the flaw in my thinking below= is, that would be great, provided it's possible.

I don't know that there's a flaw in your thinking. At the mome= nt, all that I can speak to is how authenticating the header (or not) might= impact security of DTLS. We can't directly extrapolate from what we kn= ow about TLS, because the security goal is not to the same. That said what I know about TLS is the following: the content= s of the record header doesn't matter for security goal considered in [= 1], as long as (1) the header is authenticated; and (2) it correctly encode= s the length of the next ciphertext. But since the security goal of DTLS is not the same, the details of the sp= ec that are (ir)relevant to security are likely to differ.

=C2=A0
For example, another thing which I would expect to be more complicated= to verify in full rigor is epoch authentication: If the epoch is reduced t= o its two low order bits in the DTLS 1.3 header and thus (at the moment) al= so in the AAD, arguing that decryption can only succeed for the correctly expanded epoch involves knowing that al= l epochs having different keys. That's of course true but this fact wou= ldn't be needed if the full numeric epoch was always explicitly authent= icated in the AAD. This isn't a real issue in the end, but I would expect it to be a nuisance in a formal proof?
In terms of what you mentioned regarding decoding details, it seems th= at adding the underlying logical header to the AAD ensures more directly th= at decryption can only succeed if header decoding (that is, filling in impl= icit data or expanding truncated data) was done correctly, whereas it is less clear with the truncated or o= mitted data in AAD, as in the epoch example above. Is it possible to explai= n what the flaw is here intuitively?

I'm afraid I would need to absorb spec and think about its intende= d security properties in order to answer these specific questions. I'm = sorry if this answer is unhelpful; Ekr asked that I chime due to my prior w= ork on TLS. But I don't think there's a simple answer here, and unfortunately I don't have the time to think i= t through at the moment.

For now, I'll just leave you with this. I'm a fan of the follo= wing design principle: whenever there is a branch in your code that depends= on a bit read from the wire, that bit should be authenticated if possible.= To your example, if a decision you're about to make depends on you agreeing with the peer on the current epoch, the pr= inciple says that the epoch had better be authenticated. Whether it's n= ecessary or appropriate to do so here (via AEAD decryption) depends very mu= ch on the context, i.e., the protocol details and the security goal.


Chris P.


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.
--000000000000d647f905a438040d-- From nobody Sun Apr 26 14:10:10 2020 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD3E3A1285; Sun, 26 Apr 2020 14:10:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.127.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <158793540276.8190.8571632584417892419@ietfa.amsl.com> Date: Sun, 26 Apr 2020 14:10:02 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-ctls-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.29 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: Sun, 26 Apr 2020 21:10:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Compact TLS 1.3 Authors : Eric Rescorla Richard Barnes Hannes Tschofenig Filename : draft-ietf-tls-ctls-00.txt Pages : 17 Date : 2020-04-26 Abstract: This document specifies a "compact" version of TLS 1.3. It is isomorphic to TLS 1.3 but saves space by trimming obsolete material, tighter encoding, and a template-based specialization technique. cTLS is not directly interoperable with TLS 1.3, but it should eventually be possible for a cTLS/TLS 1.3 server to exist and successfully interoperate. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-ctls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-ctls-00 https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctls-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Apr 26 17:14:00 2020 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 31AFF3A044A for ; Sun, 26 Apr 2020 17:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Ko+x80UJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lkNiz6z1 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 QpXC4G7OuTx2 for ; Sun, 26 Apr 2020 17:13:56 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19B83A0437 for ; Sun, 26 Apr 2020 17:13:55 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 1B49B5C0056 for ; Sun, 26 Apr 2020 20:13:55 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Sun, 26 Apr 2020 20:13:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=HpHCggnbTmGWlop19l//ZC7uOQXPsCL bp6GqpnXPGt8=; b=Ko+x80UJsJyE4t8JIf7TaX1hj5UH/qK72+sUSHUlHk5dDz5 xqJGnbu1ok+RUuADpcFCsQbrJ8hxhL3+YsWjwqHcLLPFshY74r7ofUi+B9XPF+ke 09fnWzknHErwoL8LZXWfv/d8njAPgZ6pz4oRfZwfVufct5yElzgHXRZ+iLR94YxX iPgurXcA2DRo68AqgnBreN+BSZ6zuYtiZilq8oUcsWcgZGLyzeWngkKrT/LWd7g+ vTSnSoRzgO6+6m/FX7cId8wl1IX89pYX3NwbsDFKFNjk2/l3jmNnBEkdmsz3smk2 Y8TzCvY71j87QxiCDLuamOqzfPE4RtRmp4N3Olg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=HpHCgg nbTmGWlop19l//ZC7uOQXPsCLbp6GqpnXPGt8=; b=lkNiz6z1WWQBEdN/rk79RT MC9vu5+uep/nvF9vuTzI4Blg3Pz8w8ZvT1BjaxTHERSVL6xn5QmxRHHfR39AnI1s VFfoztYAAWlIMwTvwEnJOK1HEfjz771qIObrfICDt0lLZ1Nr/moH+e5XIbh9LmRm i7j5EH4F8V6qeUxTLZ2x+yWSqBZcS/MYPC6aegn95D98mK0mOZ8LrlpsRdrBwSnr t0Sb+aSTLOflXx2dJhQzC6pFf7xiVotdjmG64o21UpQgcxNNG0RL42xUEtBg+5gc oBYvaOmOMTVx1/DMgxnTrixhdaAzr0jiUagxFkGVukYGZ1WvpP8thtIO+rY8PYKw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrheekgdefvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehirggtrhdrohhrghenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhht rhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D3364E00C7; Sun, 26 Apr 2020 20:13:54 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> Date: Mon, 27 Apr 2020 10:13:31 +1000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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: Mon, 27 Apr 2020 00:13:59 -0000 On Sat, Apr 25, 2020, at 01:56, chris - wrote: > However, the formal > models of [1,2] assume reliable transport (i.e., TCP): failure to > deliver packets in order is deemed an attack. Therefore, the > definitions would need to be changed in order to account for the case > of DTLS. (I'm not sure if this has been studied.) My hunch is that the > same design pattern (i.e., "authenticate everything on the wire") would > be called for, but I've not seen formal evidence either way. A few of the submissions to QUIPS addressed this question for QUIC (which has a similar construction to DTLS) and concluded that this was broadly OK. What changes is the degree to which we rely on the strength of the AEAD for prevention of spoofing. (I'm sorry, but I can't find the paper that was most directly applicable, perhaps Felix can help out. https://eprint.iacr.org/2020/114.pdf does a pretty good job, though it is a broader treatment.) From nobody Mon Apr 27 00:07:13 2020 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 313D33A0F04 for ; Mon, 27 Apr 2020 00:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.82, 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=l4QM89b0; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=l4QM89b0 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 FaLlmkPj_3dV for ; Mon, 27 Apr 2020 00:07:09 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2077.outbound.protection.outlook.com [40.107.21.77]) (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 DFC783A0EF2 for ; Mon, 27 Apr 2020 00:07:08 -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=50zLd3j5K/dgLodKpGf3my/WqmR8x7xmOw4rVIIwQlc=; b=l4QM89b0QBg3qRQJGKP1SdYABDrXyVGUpDyo9LUvedI+rxT5rkPA7tHoGNke4p5Vb/omI59BrTJcyUqXO0BFilJ/GfH+UurG/mKFLUuO052y7K2/JwCEbIUfX75tze8H5vJu6jAd/euSFe9XtgAYjMHND4qZ3o3f2G6yhQizrjo= Received: from DB6PR0501CA0003.eurprd05.prod.outlook.com (2603:10a6:4:8f::13) by DBBPR08MB4918.eurprd08.prod.outlook.com (2603:10a6:10:dc::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Mon, 27 Apr 2020 07:07:05 +0000 Received: from DB5EUR03FT059.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:8f:cafe::ad) by DB6PR0501CA0003.outlook.office365.com (2603:10a6:4:8f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Mon, 27 Apr 2020 07:07:05 +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 DB5EUR03FT059.mail.protection.outlook.com (10.152.21.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Mon, 27 Apr 2020 07:07:05 +0000 Received: ("Tessian outbound b3a67fbfbb1f:v54"); Mon, 27 Apr 2020 07:07:05 +0000 X-CR-MTA-TID: 64aa7808 Received: from fa2da2274922.2 by 64aa7808-outbound-1.mta.getcheckrecipient.com id AA0BD59D-7CD0-4D14-AC0E-8A6EDE9A4397.1; Mon, 27 Apr 2020 07:07:00 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id fa2da2274922.2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 27 Apr 2020 07:07:00 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QCJU1vfzx0Fsk5uOzT5nCN/bArMP2VbMZrMPPIht1RJVGPuzUZr7eq7wn4+bJ73KIpp2mpmor3UgKoAMK7HNjWGC+9r/iOZBpY0UTDkWD2dlWXH9SU5jofR8Nk7R1b7fF70bSpYC9evoYB1sS5aQbjpD0hSfSH1UjIkfmG9+L+qd41PPFczJUvRhAXhTdSWB4VS/6lbHJGj3GNc9Jp0t+Fjjw2rnnUp8m+3wsGpzgQ485QZiYrPewqjaoE3v80VVJjdWbvWI+7JlApEHPjcrVmpgMk5GwSN3VysVgFs3VzQFZtPiz3KhDdJyp1iJ8AvtsjNADzD0WbEq+palzj9oFg== 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=50zLd3j5K/dgLodKpGf3my/WqmR8x7xmOw4rVIIwQlc=; b=Fgr7FkYJ8sIBJif3IEC4aL9LWiEtSMLzb0GUvE9848YtiilSby31o3OmaJO7hW3i4qesRWaZZ4wljAvRB5IbyLriS3Wg5CpnYWcBwuzQpli8Uq8A0fzH8FnGTUNqPYNXikMVia5RI53joysX3Kv/nhdw8YKmG5r9QlUh3Nz7uJPgB0i6oVdVnqywGi9MubOyBL0VznkuLSFHaOa8YuG3ghCqMHsSR+NwGSkYm+3pC4wEPnQcYZcAcsQXrU/VSJKXfw/PZz3B5UpqF1vqj0/Awz7PdOpwpnPym5OtjdFm1uh1zqjtupUryy6e/73j90ZrIjsuBbtjA+/TepvJRhjgbA== 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=50zLd3j5K/dgLodKpGf3my/WqmR8x7xmOw4rVIIwQlc=; b=l4QM89b0QBg3qRQJGKP1SdYABDrXyVGUpDyo9LUvedI+rxT5rkPA7tHoGNke4p5Vb/omI59BrTJcyUqXO0BFilJ/GfH+UurG/mKFLUuO052y7K2/JwCEbIUfX75tze8H5vJu6jAd/euSFe9XtgAYjMHND4qZ3o3f2G6yhQizrjo= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB5124.eurprd08.prod.outlook.com (2603:10a6:208:161::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Mon, 27 Apr 2020 07:06:59 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::f501:c93e:1c20:8bee]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::f501:c93e:1c20:8bee%6]) with mapi id 15.20.2937.023; Mon, 27 Apr 2020 07:06:59 +0000 From: Hannes Tschofenig To: Eric Rescorla , Hanno Becker CC: chris - , "tls@ietf.org" Thread-Topic: [TLS] Choice of Additional Data Computation Thread-Index: AdYaKASVCp3JPFQuSaOSMkwtz/VZZwAEUEsAAAN7oaAAAnFQAAAASY9CAAFcJQAAAoyFgAAAY+d9AADW9gAAAKxogAAAKW2AAAULeAAAKztBgAAIVeEaADCeBIAAFLmdIA== Date: Mon, 27 Apr 2020 07:06:59 +0000 Message-ID: References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 67c042ce-3ae7-4613-91fd-7bd88aba58f9.1 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [80.92.118.138] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 88def612-3b00-4843-2c95-08d7ea7997e3 x-ms-traffictypediagnostic: AM0PR08MB5124:|AM0PR08MB5124:|DBBPR08MB4918: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:7691;OLM:10000; x-forefront-prvs: 0386B406AA X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR08MB3716.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(136003)(366004)(376002)(346002)(52536014)(6636002)(86362001)(186003)(4326008)(478600001)(9686003)(55016002)(5660300002)(33656002)(4744005)(26005)(9326002)(6506007)(66446008)(8676002)(66476007)(66946007)(2906002)(316002)(110136005)(64756008)(7696005)(66556008)(71200400001)(54906003)(81156014)(76116006)(8936002); 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: KNW+Udwm39o3vv5JOtYGsMFMONFVQqKRMNMcyospxAS7slDTqZoU7u38f8epVjCS1zhwUhFoavB3WohHdoBaY/L9WHwKcM+xxAInRbUMGlSbh+DuLwCLoTQrLXlUH2+XGKF9Junp11vPrmFH7FWFeQa31EbvRfWggZcEWy8xyQ0UBq2871mW/MzcnJR4c5Uiavz0GwgchRu2na7/YDI35OEDisI4jA28QsKr0uqadE7hAE0LYpsa+1MsR0eREokGTeIeaxvfEyYU48JiThwvWub3dA7VZdcWI+NeR5xZHiGUb2yn/ixjGTJRzJOkd7MzdNc4J6X0E7NzEt6XAiedd7x4S8QsOj69VbfjBD97oY9y5N7UUQZEwiZu2WK9G0AhQQeE6fxk2kVfba57Au13qHg7DsCs2FNJg4IZupqZHXDx6WTOEH+rT183xREDdHlx x-ms-exchange-antispam-messagedata: xVaqhA5Nv/iXFTRUMlsIyepaYt1bb5M2Q8NjDnixKpcqZu6BSYRPCNDOPZgBTftfaDwA2uz4Xbv3QudFawa8dJNKc5a794DT0mD1Vdqc9+EvTvCjkAgFr6vYqqjSCf/do/fh5mVkCF0Ao6Y9djYDcQxMbJ2zK+RpG22L3r+HiDI3gWo0pHrzSqyUhy5FBgXtYHHcvbXVGyq+KGB+ir/MetPxXt+Te1l8C0ShBsP4DS/dJ5QzlvoWQfRxegHA25yqFf8gfqkj2CBVKNiYS9WEv5wRBCVnTF9eoetCxqckoyBijdsC6jl2IQfh/9ErKCR2kjuE6qQcHSl6TxtD+YpkUgrQ1wUQsMO5+jR07gqD7+gBDpqC1sUVr8fhpSY10evPDuc4uaooLGlVWGTkhf6g14niqFNtLiu8nbHYJJxTeNmBbqCZLv1BUXpWGfzV9uZyCsELfNo/OBAHvGUuwymGTTmxly6bKncYdsIIERN1Vgm70NQr+o/Y+ctj9EH2GyiteOdVlWPBUkQAsCpUEWjsF3eCVLF5xygmNOR17TFTjoDfyXDyadwtfj6ZusGLpsAXs+VT8f31RG8MnoaxbV0Elm8t2Drm1vAPR04OM0abetOLEsW6hQZ8mkkdCJue7nrZps1dKwgzdxz9gDbavELZnEtdMvLH/jjPyMtPPQsEb/M/gMLFVOPK8upnKV8d0b9dSfws4zurZzz4pbVPUREiUIg/0T00RIb+hquwQDPnNNWjSwIQ2qINaDvZEUTQREKSo17R3JvGzstqxcg1YzK1TY7cuQHuOU6sZgoKmVV/Y5I= Content-Type: multipart/alternative; boundary="_000_AM0PR08MB37163F09F66FB8FEE2E3D010FAAF0AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5124 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT059.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:(4636009)(376002)(346002)(136003)(39860400002)(396003)(46966005)(8676002)(26005)(81156014)(33964004)(8936002)(7696005)(82310400002)(4326008)(33656002)(9686003)(47076004)(9326002)(356005)(55016002)(2906002)(6636002)(336012)(70206006)(70586007)(478600001)(81166007)(86362001)(82740400003)(316002)(6506007)(52536014)(186003)(110136005)(5660300002)(54906003); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 07238083-9c0f-4e8b-0b50-08d7ea799429 X-Forefront-PRVS: 0386B406AA X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: kQ5fFzVTAXRo57OK8QhWy4Q+eP3rL0vdFOf0rgukLK0nlKM3/8+hb8+JXIeSyWH4HwhAYSr6GLkRNN0Euw2NTKcKDU9v8e73JmVEfCQI516mdSa54i5NfvX6QrZ3Uzc716jW3YWqzWfo+C0mRBCRzFU8Yd7n8vxqt7FYUM/Q2zw0EYCw4k6DOHa5/uQ8JvNud2iYypVkLN9bDVO1Q9W0UVnSILQGsCw9m/vtdCPwVUE0SIL6g6GEa1Q4xnpU0dyNmN5+nwo4geIONTbKg9cB3NOATRvBRTMKHlB74n5pSyUiMbD13JDcBhTs4VR+IQUH4udLA4bMAtSr9cmLdg/p8tAqpYdP5MHMDMDof7T7QTFH8D/B3luytREN2Flh2hWEDwNSdUY56qaGkXPfg/QZhv4ojoLgscAMwg85V6XQ1YSGKCbZ/EDmhK+tqpV+AEdJ2lBfYrUytJzMQte/RHZRDQniqM9qunlLr9gtDXnpIGTyXpqC6yQOe9TW5mnCG+3zDs0eObkmGv2DylCZIFDxRg== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2020 07:07:05.6304 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 88def612-3b00-4843-2c95-08d7ea7997e3 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: DBBPR08MB4918 Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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: Mon, 27 Apr 2020 07:07:11 -0000 --_000_AM0PR08MB37163F09F66FB8FEE2E3D010FAAF0AM0PR08MB3716eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRWtyLA0KDQoNCiAgKiAgIEFuZCBJIGFtIHByb3Bvc2luZyByZW1vdmluZyBpbXBsaWNpdCBD SURzDQoNClRoYXQgd291bGQgYmUgYSBiaXQgdW5mb3J0dW5hdGUuIFdoZW4gd2UgcHV0IG11bHRp cGxlIERUTFMgcmVjb3JkcyBpbiBhIHNpbmdsZSBVRFAgZGF0YWdyYW0gdGhlbiB0aGUgQ0lEIGlu IGFsbCBidXQgdGhlIGZpcnN0IGRhdGFncmFtIGlzIHJlZHVuZGFudCouDQoNCkNpYW8NCkhhbm5l cw0KDQooKik6IEV2ZW4gaWYgd2Ugb3B0aW1pemUgdGhlIENJRCBhd2F5IHdpdGggY1RMUyB0aGUg cXVlc3Rpb24gYWJvdXQgdGhlIHNlY3VyaXR5IGltcGxpY2F0aW9ucyB3aWxsIHN1cmZhY2UgYWdh aW4uDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBh bnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJpdmlsZWdl ZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRv IGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNv cHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg== --_000_AM0PR08MB37163F09F66FB8FEE2E3D010FAAF0AM0PR08MB3716eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21w b3NlO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjUyOTY5MDExMjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6OTQ4MjE0MjU4IC00ODkyNDA1MTYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoxMDsNCgltc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkRlbmdYaWFuOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczsNCgltc28tYmlkaS1mb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo4OTM2NjE3OTM7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi00MTQyOTgyMDg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGkgRWtyLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzMiPkFuZCBJIGFtIHByb3Bvc2luZyByZW1vdmluZyBpbXBsaWNpdCBDSURz PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgd291bGQgYmUgYSBiaXQgdW5mb3J0 dW5hdGUuIFdoZW4gd2UgcHV0IG11bHRpcGxlIERUTFMgcmVjb3JkcyBpbiBhIHNpbmdsZSBVRFAg ZGF0YWdyYW0gdGhlbiB0aGUgQ0lEIGluIGFsbCBidXQgdGhlIGZpcnN0IGRhdGFncmFtIGlzIHJl ZHVuZGFudCouDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2lhbzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFubmVzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPigqKTog RXZlbiBpZiB3ZSBvcHRpbWl6ZSB0aGUgQ0lEIGF3YXkgd2l0aCBjVExTIHRoZSBxdWVzdGlvbiBh Ym91dCB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zIHdpbGwgc3VyZmFjZSBhZ2Fpbi4NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250 ZW50cyBvZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBh bmQgbWF5IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJl Y2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3Qg ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55 IHB1cnBvc2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1 bS4gVGhhbmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM0PR08MB37163F09F66FB8FEE2E3D010FAAF0AM0PR08MB3716eurp_-- From nobody Mon Apr 27 04:32:48 2020 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 DFCAA3A093A for ; Mon, 27 Apr 2020 04:32:46 -0700 (PDT) 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, 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=nbqLNxV/; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=nbqLNxV/ 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 F7blKslqSLQL for ; Mon, 27 Apr 2020 04:32:45 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40056.outbound.protection.outlook.com [40.107.4.56]) (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 608003A09D8 for ; Mon, 27 Apr 2020 04:32:35 -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=HSex+m6xbulu5lQiu3OZ/XOolL1Wkx5WcoZVmDuUID0=; b=nbqLNxV/ZhFOW2vCykr8ohN5xqfPMr6fqD0aMUxFxXELE6ObM4IEjamLf7AsjN0yurfspEjfmVEaN7o7lrOI5706iy3nrA4nDMvwHMBGrdYykHu6GfxnzUEZbHalHP23XEV7+CEtX5bXNISVh7nrGAo8nN6LwilWhNFqxE85tKE= Received: from AM6P194CA0088.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:8f::29) by HE1PR0801MB1737.eurprd08.prod.outlook.com (2603:10a6:3:81::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.22; Mon, 27 Apr 2020 11:32:33 +0000 Received: from AM5EUR03FT062.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:8f:cafe::29) by AM6P194CA0088.outlook.office365.com (2603:10a6:209:8f::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Mon, 27 Apr 2020 11:32:33 +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 AM5EUR03FT062.mail.protection.outlook.com (10.152.17.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.19 via Frontend Transport; Mon, 27 Apr 2020 11:32:33 +0000 Received: ("Tessian outbound fb9de21a7e90:v54"); Mon, 27 Apr 2020 11:32:32 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 2093ca19852ad4eb X-CR-MTA-TID: 64aa7808 Received: from b2d25b1d334a.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 09F94A25-148F-44ED-87AD-84513AB4666C.1; Mon, 27 Apr 2020 11:32:27 +0000 Received: from EUR05-DB8-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b2d25b1d334a.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 27 Apr 2020 11:32:27 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=V7UCHUmVIAqmXBjaq4ApwxDWlX2+qjXEd3dEpDw/DLiN/SJC+C4W7VXr/+cnrXETj6HOzpazeisPAEgi6B/4/qxE5ehUATVFiwij25z2Ae5GaizeGowve4dBOZQP+Tr3xIi7LrsCZybI8+8I4Ndw/wBB54NHPH94gQUKzFomXRzOjnasqwrwVJzqjvdPj+I01ajtT3ooMUJ8OY7ZesionVymWXfzWDA48Z1reb3ernwG/fVNX1MgbxZKCfabzJNhCD0HapVcsXaB71JEu0icLLUM9/Rq+vzOsUZr2ISFPGKyuumcJA824o07tqfp4ZLovgRvhKkPMEk13nkmaukIBw== 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=HSex+m6xbulu5lQiu3OZ/XOolL1Wkx5WcoZVmDuUID0=; b=lAyadFrhkLm2n4zRNH4awJtuy2OBRvui8GDt703zmnNJqeWu9m9q22RkyNjFh4fFnQd970Hi4Sfd6ttAL4teTVRI5aQv0S//3SvEnkAq9qkkkHQYL7nB6sKfr/5yJ8JxWeoNtZMuZBoSs4Hem/Ntw2al0vcoNQXeSUT2tAKKR+nScI7G+R4Dt9KMsY+3zdjevuZCCEgQtAvguxAkuSx9+3bgoQLf1TiZD4gkPZq4ntJw9V9s0EGtOB6Xi+YPJb6/WLURG6Eyixb8aACdEmoFYYtZrN9CvExuSIbUSS3w1+tgiMfgj+NYrZ2LErRyDqUyPLCgg+Z4p+xiEzaDpaEGAg== 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=HSex+m6xbulu5lQiu3OZ/XOolL1Wkx5WcoZVmDuUID0=; b=nbqLNxV/ZhFOW2vCykr8ohN5xqfPMr6fqD0aMUxFxXELE6ObM4IEjamLf7AsjN0yurfspEjfmVEaN7o7lrOI5706iy3nrA4nDMvwHMBGrdYykHu6GfxnzUEZbHalHP23XEV7+CEtX5bXNISVh7nrGAo8nN6LwilWhNFqxE85tKE= Received: from AM6PR08MB4231.eurprd08.prod.outlook.com (2603:10a6:20b:73::23) by AM6PR08MB4818.eurprd08.prod.outlook.com (2603:10a6:20b:cb::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13; Mon, 27 Apr 2020 11:32:26 +0000 Received: from AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d]) by AM6PR08MB4231.eurprd08.prod.outlook.com ([fe80::5e0:a53a:d4d6:2e8d%6]) with mapi id 15.20.2937.023; Mon, 27 Apr 2020 11:32:26 +0000 From: Thomas Fossati To: Christopher Wood , "TLS@ietf.org" Thread-Topic: [TLS] DTLS 1.3 AEAD additional data Thread-Index: AQHWF+iN1gKILcDltkmRr5OfopCaAaiD3VMAgAB8FQCAAE7VmIAAawyAgAAHdS6AAB8+AIAACQCRgACPx4CAABkpAIAABDCAgAAC0ICAAEL8/IAAHxqAgADkdgCAAcgWAIAAsyqAgAAI7ICAAX/zAIAARkGAgAFsJoA= Date: Mon, 27 Apr 2020 11:32:26 +0000 Message-ID: <58E5E6E8-2ED2-4C0C-B600-19CC1F347CDE@arm.com> References: <8371994b-799c-4196-a3cd-4b0f71e24b5e@www.fastmail.com> <5b74a840-a1cd-4b5b-a0c5-65320b851325@www.fastmail.com> <1e6201d6-a078-4137-898d-d1554c22aa10@www.fastmail.com> <1CBF6B88-8830-44A4-8F9B-143F884FF6ED@arm.com> <009D63D5-6353-4429-A62C-EB7617E4B9EC@arm.com> <18d9978c-1dd1-4365-827c-94c121099949@www.fastmail.com> In-Reply-To: <18d9978c-1dd1-4365-827c-94c121099949@www.fastmail.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; x-originating-ip: [82.11.185.80] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: a88e21ad-5663-4731-4dd9-08d7ea9ead77 x-ms-traffictypediagnostic: AM6PR08MB4818:|AM6PR08MB4818:|HE1PR0801MB1737: x-ms-exchange-transport-forked: True X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:6790;OLM:10000; x-forefront-prvs: 0386B406AA X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4231.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(366004)(376002)(136003)(346002)(4326008)(81156014)(6486002)(8936002)(8676002)(6512007)(86362001)(33656002)(36756003)(316002)(478600001)(71200400001)(6506007)(26005)(2616005)(66556008)(76116006)(91956017)(66476007)(66446008)(5660300002)(64756008)(4744005)(53546011)(2906002)(110136005)(186003)(66946007); 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: L4icuP4ejnFeDUJKHSVgfoNCAf+hKr2VJCqDDo4flFp29U7BOA81Ndi7X63URtCVIpRmuYBqF6mZQsZ6u3uO2vt5m2fllc+ubW1o40Xc5jCm9oN5VXUwaQBsBwh1PHXEOfJqFghw4sikS+qCeT1UStVgwHLK4TSPCf/qDH4y/qSm7LBvjlafiKBiBCx5+5+AFyV/lI95ZBs9LTqxfOqO4BujKMvGrReF5VV+Uxc6d8L7ezmTnfXp54Cf5fmreO4HIrkMAmeHiStV2TCE/bNJLQJ2Mzz3edaHHJJNCPAOsuW7rzSlOyVT4+8cPZpx4cl1uBnCdVeQjmIzV83O1yJXRyzNwDlvxWfxAJRXBeStVUbLQd+ySC2s9Rfmxqn1B+YqRLxXkTYOZPP2Lpg/UOTlDEy9zfcT4K+XvB+bykXPRDvmXWz1jHeKhl5I0cxUMxBL x-ms-exchange-antispam-messagedata: bP/qFOACBNaFIyXBHO+Qx6hdXbKxTfEjNhiLBFqaIZL/5Z3oMhI0Db7buE+j6QLjAdNNA+yBgqpd2ztvOx3fN/Fl65340YR6QJId+yficg7kwsIooeF2i5Z7GoK+5md3HFIG9Rq2/RgMcLurXl1w3o+i3CNq/a7PHsyEFBivPDF9SAFXbppCQ9FNqvOwZx3dxSrGri9/YDcRJEuNMMqnIzklcUafC1zmZqFC15M5pBQic/81RicFYuh95qlk0ZgptIuUzBQNVUb6lSZ8/QcuzjadOyGEiQUSKMa98EOFxRlFPsFruJUf+qeJgr+Pci3gr50rZ+4zjXWmaBC9b1YUKooTMbXvKCQNYl2sYIbCGUd6h+OQW0QD0i4yMpunuQlkFzVHCJIS69xQkoXvy9MgfC1SSyNmj7SzSvi4V4oYTB4CuX+zS/lmA1HfObo582ozPHr9DQtYagw3Fj3XNBkcHXurBJ+MDz9AOL1VITLv6ZZi38hWtjMlLihBz9HMm7bh4ZNF54lYqssl+vaBe3oIc1x7TmMnjEk0Rq1hthezdOHHxNbJn9DIW7k6BRHxCbKfiqvePHy3pZdQc7lBAPkv6QcC2cni02MYCGior/yoYOHJ0gRf797Zk9o/e9OEDfKwYwBBmRIguntEbbVtrH0Z1HMMh29miJ9f2dxZBh3AsHiRZrbcC/8DT5SPH2U66j2gptSPaBGEoJQ86e80HxLBW1D8kgNBtgcBmdJ8fpNCiU/dyxARDs/G8elcNsQtYEuddvUid3L5ad+521RpLnHmdPabQlzWygx5yvWjUtSFgv4= Content-Type: text/plain; charset="utf-8" Content-ID: <0B456F6C78B97D4A8B187C25F6D0A2B7@eurprd08.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4818 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Thomas.Fossati@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT062.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:(4636009)(396003)(39860400002)(376002)(136003)(346002)(46966005)(5660300002)(26005)(36756003)(6506007)(53546011)(81166007)(36906005)(2906002)(2616005)(356005)(4744005)(316002)(110136005)(336012)(33656002)(82310400002)(4326008)(6486002)(186003)(81156014)(8676002)(8936002)(47076004)(82740400003)(86362001)(478600001)(70206006)(70586007)(6512007); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 64d1bbd2-2b5e-47b8-c82c-08d7ea9ea95d X-Forefront-PRVS: 0386B406AA X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: dcGwgBs/x/w8RSgEj5CvWi4mOfjQglZtsDE0iGU6j0jXUw3sem4ZaIvaAx4KQVyq+04DvxdBLJUgCceI7+JMj2Ni/FlWJO8rcsUSxg/5vtGvm2ZozNdK4Qmu6S7JHT/YxeVMqozFsCIs1z8s3F9AjKMUxfBb47Od4uBscwlCXA9tMgXI5HXPb9fAOJ2BtZv4RAd4IbZ/JlOWj0N9CgoDZh+Nhhm8ak1q6zUQ5doQQFMU06aX8FfzbvSqsDdWccuyyMcz5KXHUR/paL4Mg4R0T1Bxb4KAW84bW/snp08KiNiRdFHsFvBdEf3Y60/9++QWV6eRo8dvtW7kdU9oQkUffT1udrNdIBG9xGVsmWqrvs33xsQpZYXowFd6kyfhQAr6NeT6+isyfBqdEb92HBOUVpD/0vs+kcwfiWq/btKqspM44QQDgrJz1Mkyxmy4Pp56rJcqmNsQJhrCLlGuaz6QqLVn6lPJlmVuq9cyt+gaq67CvMLYzKdSNpgaJraZV1Or9fZ+tf0C3NgQ+9AF65u76g== X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2020 11:32:33.1624 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: a88e21ad-5663-4731-4dd9-08d7ea9ead77 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: HE1PR0801MB1737 Archived-At: Subject: Re: [TLS] DTLS 1.3 AEAD additional data 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: Mon, 27 Apr 2020 11:32:47 -0000 T24gMjYvMDQvMjAyMCwgMTU6NDksICJDaHJpc3RvcGhlciBXb29kIiA8Y2F3QGhlYXBpbmdiaXRz Lm5ldD4gd3JvdGU6DQo+IFRvIGNsYXJpZnkgKGFzIHRoZSByZXF1ZXN0IHdhcyBhYm91dCBwcm9o aWJpdGluZyBpbXBsaWNpdCBDSURzIGFuZCBub3QNCj4gbW9yZSBnZW5lcmFsbHkgYWJvdXQgd2hh dCdzIGluY2x1ZGVkIGluIHRoZSBBQUQpLCB5b3UnZCBwcmVmZXIgd2UNCj4gYWxsb3cgaW1wbGlj aXQgQ0lEcywgY29ycmVjdD8NCg0KSGkgQ2hyaXMsIGNvcnJlY3QuDQoNCg0KSU1QT1JUQU5UIE5P VElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUg Y29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwg dXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24g aW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Mon Apr 27 05:47:57 2020 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 5DA333A08CC for ; Mon, 27 Apr 2020 05:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1EkabWgvkVUY for ; Mon, 27 Apr 2020 05:47:52 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6A03A08CB for ; Mon, 27 Apr 2020 05:47:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 6BBAC140B6 for ; Mon, 27 Apr 2020 15:47:49 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id IiIfsdTuIMBt for ; Mon, 27 Apr 2020 15:47:48 +0300 (EEST) Received: from LK-Perkele-VII (87-100-246-37.bb.dnainternet.fi [87.100.246.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id DF7BF27B for ; Mon, 27 Apr 2020 15:47:46 +0300 (EEST) Date: Mon, 27 Apr 2020 15:47:46 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20200427124746.GA3839288@LK-Perkele-VII> References: <158793540276.8190.8571632584417892419@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <158793540276.8190.8571632584417892419@ietfa.amsl.com> Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ctls-00.txt 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: Mon, 27 Apr 2020 12:47:55 -0000 On Sun, Apr 26, 2020 at 02:10:02PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Compact TLS 1.3 > Authors : Eric Rescorla > Richard Barnes > Hannes Tschofenig > Filename : draft-ietf-tls-ctls-00.txt > Pages : 17 > Date : 2020-04-26 > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-ctls/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-ctls-00 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctls-00 First impressions: - I think this protocol should use different label in key derivations from the "tls13" label used by TLS 1.3. I do not see any fundamential reason why transcripts could not collide with TLS 1.3 ones. - It seems not be possible for server to support multiple profiles at once. This could be useful for things like updating clients to use better algorithms. - It probably makes sense to support the case where client profile has incomplete list of certificates. E.g., some IoT client only knows its own and server certificates, whereas the server knows all certificates. - If one wanted dual TLS 1.3/cTLS server, one would presumably have to define TCP mapping. Simplest one that might work: Connection starts with fixed byte (which should not be 20-126 to be able to tell the thing apart from both TLS 1.x and HTTP), followed by sequence of records, where each record is prefixed with varint length. Application data records transport application data. However, cTLS is not quite "TLS 2.0", as that would presumably move some important extensions into top-level messages. Especially stuff like supported_groups, key_share and pre_shared_key. - There is one special case where epoch is not clear: alert mesages in response to server handshake. These can be unprotected despite being in position where protected record is possible. It is possible to tell apart unprotected alerts from everything else by size. Unprotected alerts are 2 bytes (if the useless severity field is stripped out), and no protected record can be that small. - Just blindly switching all integers to varints does not work, as there are integer fields that can legimately have integer values >=2^22. TLS 1.3 spec itself has two of those: PskIdentity.obfuscated_ticket_age and NewSessionTicket.ticket_age_add. And with those two, it is not even possible to just take modulo 2^22, as the time unit is milliseconds, so that would limit the ticket age to just ~70 minutes. Some extensions have more integer fields that can be >=2^22, but none that I can find where limiting to 2^22-1 would be a significant issue. - Strict ascending extension sort probably does not work, as extension 41 is magic due to having to be last in client hello. If there is strict extension sort, most straightforward fix would be to make the order 0,1,2,3,4,..,39,40,42,43,,..,65534,65535,41. - Some ways to eke a few more bytes out of profiling: * If group is specified, move key share out of extensions. * If group is specified to something with fixed length, omit the group length. * If using uncompressed P-x keys, strip the 04 prefix (does not work with X25519 nor X448, as there is no prefix). * If using compressed P-521 keys, stuff the sign bit into unused bit of the x coordinate field (does not work with P-256 nor P-384 as there are no unused bits in x coordinate field, nor with X25519 nor X448 as there is no sign bit). * If signature algorith is specified, omit the signature algorithm. * If EncryptedExtensions is empty, omit it (can tell if it is there from type sequence). * Re-encode ECDSA signatures to raw form (can also be done without profiling; does not work with Ed25519 nor Ed448 as the signatures are already in raw form). * If signature algorithm has fixed signature length, omit it in signatures (e.g., Ed25519 and raw form ECDSA/P-256 are always 64 bytes; can also be done without profiling). - The example in A.1 looks suspect: * Why is client_shares.length encoded as 2 bytes? it is vector length <128, so should be 1 byte? * Why is KeyShareEntry.group encoded as 2 bytes? It is enumeration value <128, so should be 1 byte? (Both in Client Hello and Server Hello). * Why is length of KeyShareEntry.key_exchange encoded as 2 bytes? It is vector length <128, so should be 1 byte? (Both in Client Hello and Server Hello). * Why does the signature start with 4047? The signature should be 71 bytes, so should be 47? (Both in server and client flights). - And example in A.2 has this: * Server hello has 18 bytes = RANDOM(16) + 2 ... Those 2 are presumably overhead? * Client Flight: 1 byte = Overhead(3) ... Should presumably be 1 byte of overhead. -Ilari From nobody Mon Apr 27 07:08:09 2020 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 F168A3A0B32 for ; Mon, 27 Apr 2020 07:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com 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 MQce1oYMYSUn for ; Mon, 27 Apr 2020 07:08:05 -0700 (PDT) Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 35CCC3A0B30 for ; Mon, 27 Apr 2020 07:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=3327; q=dns/txt; s=VRSN; t=1587996485; h=from:to:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version:subject; bh=CUBsYOEeq1djXy7iVIAh05WKoPeJbBkC8ucdosl93To=; b=FLn/wMHJqtUIP//96aXuGNSMzDRqs/1+GnRmiUWrvGj71g8p4jOcPHW7 72MrifiMWL1CVVCbg3GDXI32iemHISdNwdFh2GrtJDauA3ViE/PQtM5K/ 4tCzfz+ApNUDpCBdApp18+7HG1cjyftJsGARwA1HUvW8pyllsp9e9G5N/ joLuVqD6MDcTi9YbM9rFtE71YVAu856RkRRYAn5NvhDj/0bagf5mblCeK cMqon3ZepIBUoJgu5YkoUqHzn+dvV0uNWWRLO7A5dRxzAHGg5hGn5Z8hv YYnbDAgCjXdXQS3dGlBOar4D2xfp0xJBETxA1AAXwwSCDO1qjK5y2TVnM A==; IronPort-SDR: Q6yVPYWROp9q615sGq1HtHbyleWrRcXzIZ3JAEV7B8SWcHi1pTwXeCklzSrHPdyB8FRhpsfc1j kslOkC5Ve45Q6TAG3mFsKQAuTBoFxTjuYEl4ErEnKS0FcvNjZkWoLaWqgf+ERKNt/e3VYYfRBC UFsOiM7v4y7uGzEgCFcZLxgfXvL8CFShBJbMhkVplYWYIn6D5NTUxBNpsXFn+20trYO8gqXSO2 67am3ZRy9hM7hzOBUQmiGDQFQl9qc0CLcXvaQ27ZEKmRRrPGbSNccHs8kY8F2JlZz+SsrN5GTS gIs= X-IronPort-AV: E=Sophos;i="5.73,324,1583193600"; d="scan'208";a="761493" IronPort-PHdr: =?us-ascii?q?9a23=3A9LAUOxekufWaVU1/XyYbYifFlGMj4u6mDksu8p?= =?us-ascii?q?Mizoh2WeGdxcW6Zh7h7PlgxGXEQZ/co6odzbaP7ua9CCdfud6oizMrSNR0TR?= =?us-ascii?q?gLiMEbzUQLIfWuLgnFFsPsdDEwB89YVVVorDmROElRH9viNRWJ+iXhpTEdFQ?= =?us-ascii?q?/iOgVrO+/7BpDdj9it1+C15pbffxhEiCCybL9vLBi6twXcu80ZjYZgNqo61w?= =?us-ascii?q?fErGZPd+lK321jOEidnwz75se+/Z5j9zpftvc8/MNeUqv0Yro1Q6VAADspL2?= =?us-ascii?q?466svrtQLeTQSU/XsTTn8WkhtTDAfb6hzxQ4r8vTH7tup53ymaINH2QLUpUj?= =?us-ascii?q?ms86tnVBnlgzoBOjUk8m/Yl9Zwgbpbrhy/uhJ/34DaboKbNPV8f6PSYdwUSm?= =?us-ascii?q?VaU8ZNTixBAJ+wY5cTA+YfO+tTsonzp0EJrRu7HQSgCuHhyjhMhn/yw6I61f?= =?us-ascii?q?8uHh/a0wwjB94FrWnao8nyNKcOTeC5wrTDwDLYb/NW3jf97IzIfQ4nof6XQ7?= =?us-ascii?q?1/bcnRxFIxFwzblFWQqJflPzKa1uQLqWSU8+1gVee2hmMhtgp/oSCvy98xho?= =?us-ascii?q?XVnI4Z11LJ+CtjzIooJdC1RlR3bNGnHZdIqi2WK5F6Tt4gTm10oio217ILtJ?= =?us-ascii?q?2hcCQXy5kqwQPUZeadfIiS+B3jUf6cITJ/hH14Zr2ynw2y8U28yu3kUcm0zU?= =?us-ascii?q?pKojJFktbSsnAN0ATe59WbRPVl40uu2S6B2Q/S5e1YPEw4j7TbJIImwr4qjp?= =?us-ascii?q?ofq17METLslEXolq+WbUMk9vK05OTgZ7Xqvp6cN4lqhQHiKqkih9CzDf4lPg?= =?us-ascii?q?UMUWWX4/mw2b3t8EHjT7hHjeU6kqzDv5DbIcQbqLS5AwhQ0os78Ba/DzCm0N?= =?us-ascii?q?AcnXYZKlJKYwyIgJTqO1zVPvD3E+2/g1W3kDdqyPDGOKftDYnKLnjGiLvhZ6?= =?us-ascii?q?py61ZAyAovytBS/45bBasPIf/oWk/+qsbXDgc4MwyyzOboE9R91p8FWW6VBK?= =?us-ascii?q?+WLr/Su0eS5u0zO+mMeJMVuDHlJvY74fDgkGQ0mV4Dcqm105sbcne4Hu5pIx?= =?us-ascii?q?bRXX25yNwIDk8KswMmTerlglyeSnhVamr4F/Y37y4TCI+vFYbFSYqsnKfH2i?= =?us-ascii?q?qnSNkeLFxiMXiNHGvmMYKeVL1EPB62GedgnyAKE7+7RNly+wupsVqw671jKu?= =?us-ascii?q?fS8CATttar79Ny+/GZ3UUp9TtwC8mb2WyGTElqk3kJXD452uZ0pkkrmQTL6r?= =?us-ascii?q?Rxn/ENTY8b3PhOSApvbZM=3D?= X-IPAS-Result: =?us-ascii?q?A2HOAgDU5qZe/zCZrQpmHAEBAQEBBwEBEQEEBAEBPIFHg?= =?us-ascii?q?XiCTwqVL4EBmHCBZwsBAQEBAQEBAQEHAS8EAQGERAKCTTgTAgMBAQsBAQEFA?= =?us-ascii?q?QEBAQEFAwEBAQKGS4I7IoNpAQEBAQIBOhoxBAIBCBEEAQEWCRAyHQgCBAESC?= =?us-ascii?q?IV7sXp0gTSFT4UYgTiJcYJmgUI+gRGCWzU+hAeBBoUyBI4QpBIDB4JFl3gln?= =?us-ascii?q?HuPep0GAgQCBAUCFYFpgXlwgzlQGA2RPxiOJXQ1AgYIAQEDCY4MgRABAQ?= Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 27 Apr 2020 10:08:03 -0400 Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1913.005; Mon, 27 Apr 2020 10:08:03 -0400 From: "Hollenbeck, Scott" To: "caw@heapingbits.net" , "TLS@ietf.org" Thread-Topic: [EXTERNAL] Re: [TLS] Comments on draft-ietf-tls-external-psk-importer-04 Thread-Index: AQHWGo1uQ1Ky+wbzAEuWZzH8R3hjiaiNBD1Q Date: Mon, 27 Apr 2020 14:08:03 +0000 Message-ID: References: <96ed3f4c-7ad4-4406-95c9-1e96b5a49eed@www.fastmail.com> <8fd481c1-7edb-4d9c-bc6d-f1a3f67e8bcf@www.fastmail.com> In-Reply-To: <8fd481c1-7edb-4d9c-bc6d-f1a3f67e8bcf@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.148.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Comments on draft-ietf-tls-external-psk-importer-04 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: Mon, 27 Apr 2020 14:08:08 -0000 > -----Original Message----- > From: Christopher Wood > Sent: Friday, April 24, 2020 7:09 PM > To: Hollenbeck, Scott ; TLS@ietf.org > Subject: [EXTERNAL] Re: [TLS] Comments on draft-ietf-tls-external-psk- > importer-04 [snip] > > > Hmm, not quite. The statement intends to say that if you need EPSK k > > > into an importer and into TLS 1.2 then the resulting keys used in > > > TLS 1.3 and 1.2 are different. I'm not sure further clarification is > > > needed, though I'm happy to review suggestions if you have them! > > > > Agree with that as the goal. Here's our concern in brief. If our > > understanding is correct, prior to this draft, the client could use an > > EPSK k in two ways: > > > > * as input to the TLS 1.2 PRF (based on any hash function) > > * as input to the TLS 1.3 key schedule via HKDF-extract (based on a > > single hash function) > > > > Following this draft, the client could use k in two ways: > > > > * as input to the TLS 1.2 PRF (based on any hash function) [same as > > before] > > * as input to the importer function via HKDF-extract (based on a > > single hash function) > > > > So there is still a potential cryptographic overlap in the use of k > > between TLS 1.2 and TLS 1.3. The imported keys don't have this > > overlap, because they're separated from one another and from the > > underlying EPSK through the use of the importer function. But doesn't > > the security proof for k still need to take into account that the > > input to HKDF-extract might also be input to the TLS 1.2 PRF (with the > > same or a different hash function)? > > > > In other words, if it was a problem for the security proof that k > > could be input to the PRF and to HKDF-extract before the draft, isn't > > it still a problem afterwards? The conclusion that there are no > > cross-protocol collisions depends on the specifics of the TLS 1.2 PRF > > and how it's used, compared to HKDF-extract. > > > > We're not suggesting there is any attack here, just trying to > > understand the design actually addresses the statement in the > > introduction that k "could possibly be re-used in two different > > contexts with the same hash functions during key derivation". >=20 > For lack of a better way to describe this (sorry!), we're trying to avoid= this > input collision during the key derivation process of a TLS connection. As= the > importer happens before a connection, and can be viewed as part of the > provisioning process that produces unique PSKs for each target hash > function, we achieve the goal for TLS 1.3 of not re-using a PSK with diff= erent > hash functions. >=20 > I'm not sure how to better clarify that right now, so suggestions are ver= y > much welcome. We're okay with the arguments in the draft that the design preserves securi= ty proofs when the same EPSK is used to produce internal PSKs associated wi= th different hash functions within TLS 1.3 only. However, it isn't clear en= ough to us how the design preserves security proofs when the same EPSK is u= sed with both TLS 1.2 and TLS 1.3. I don't yet have any text to suggest, b= ecause we're not sure we understand the rationale. What is the rationale fo= r the design in that situation? Scott From nobody Mon Apr 27 14:45:14 2020 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 09C243A0B94 for ; Mon, 27 Apr 2020 14:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=XRocwzm8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XQVnBu0N 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 8HXhbuh5AVGM for ; Mon, 27 Apr 2020 14:45:10 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01963A0B95 for ; Mon, 27 Apr 2020 14:45:09 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id D01AA572 for ; Mon, 27 Apr 2020 17:45:08 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Mon, 27 Apr 2020 17:45:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type; s= fm1; bh=Nh31LmdWF33DzXc1j7AueHhoTg34nF905AFDc/t6gXA=; b=XRocwzm8 4cQwBy14FL8KkC9M6YxooE93s/rb9fJgLJRVNKPVWXAsaId5UMNY4cb0vryJ4HPa pggTa8s174MHS6YoE6pidcRkd04HykloImaM2G5nKE6W23FwdbLPwXfuQyRg17yl nIJvGi56pJj1ppswGni8aGqqGmW/NaNdcFtu6WvOWsyz7aFF/nF+dmt49A3TyJml z7Gwh+Y1fXzxpax5sStp/z6JW6PxBVrZelxMQkQTnYL5SQlaHMvyQUaJj4MnKMEp XDCzjvvwN1v3pnGSwMFPtFnLlYQKjVW0MclmzJlPh1dj2BywDlB+JcD9QhNv72id L1YRGPiIz/MtQw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=Nh31LmdWF33DzXc1j7AueHhoTg34n F905AFDc/t6gXA=; b=XQVnBu0NVZNsJYhJgGxeaSQoizhy54KL5WLq9K2nC9118 sONTFUOJVV5fMrFqaJ6/sEcyoctHMcpfVGUHgsebRENp/KyysW9r9ZVmlGgy5EQ6 ClW2V+aZ+wy5cp18PFWqJr5gUACtuU4h12059mIiFr/wh715JFI74iZZ+jS2Gyyo VLEEEIa5E+T8VP5LuOS7bn+K+3COoO505c2kGrBHCNzx2IycWgLxtEm+8G/sZmsW e9/4GP+zWGm0kJ6y84Pt/OmyaENSM2ZLeAOEbc6hgtJh5BQLLKFeFWpgtf+e3d3y xdV6EALsozd8JNTF5a/U8t/gOTIt2mUwEBTM6IHfA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedriedtucetufdoteggodetrfdotffvucfrrh hofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgenuceurghi lhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertderredtne cuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhi nhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghp ihhnghgsihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E5E3C3C00A1; Mon, 27 Apr 2020 17:45:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: Date: Mon, 27 Apr 2020 14:44:47 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Content-Type: text/plain Archived-At: Subject: [TLS] Draft of virtual interim meeting minutes 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: Mon, 27 Apr 2020 21:45:11 -0000 Draft minutes from today's virtual interim are now available [1]. Please send any edits or corrections to the list (or as PRs to the repository) as needed. Thanks to Rich and Peter for taking notes! Best, Chris, on behalf of the chairs [1] https://github.com/tlswg/wg-materials/blob/master/interim-20-04/minutes.md From nobody Mon Apr 27 15:26:16 2020 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 946713A0CDF for ; Mon, 27 Apr 2020 15:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=U3e9AUPr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jDBtjbD9 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 cXzIfWg8tWkT for ; Mon, 27 Apr 2020 15:26:05 -0700 (PDT) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B49973A0D88 for ; Mon, 27 Apr 2020 15:25:56 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 259DE652 for ; Mon, 27 Apr 2020 18:25:56 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 27 Apr 2020 18:25:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=VdyC08D7axv+8FkUm3zNHXKciMEfWBa c7tis4OyoISQ=; b=U3e9AUPrtrLXYDdOjOs19CRHPlhta29Ii+VmlxCblW/MSGi ik/DaGhGK7/btlbFBbdcDu4/oQXlCqtOQthO4OkhpAPaJSjXJvY4/k9fYMtk155i qEzBiT3jKsFuXCpyXXcPQT/Js17WPh9XAmQljfS6fBy0YqdIK3R49ZgAiiv6dBOA 3iLPSkifsrb3gwju7v1zXcsBsOlfUSRZbjtR1AKgfCLtl94Jh0fftwzn91nfiJE2 e5ciao15GyygO7xVnN7A3zkXnNWYri0hFJk4efmeL4tJy6RKS/u+2z5qV+/+4czd y84JMPtueGwoHeFFlPYwO55KeQXaZopKq8bhTWw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=VdyC08 D7axv+8FkUm3zNHXKciMEfWBac7tis4OyoISQ=; b=jDBtjbD97JC8IHIT9ux8kW rfE9412actme5dgmHJVp69zBuKMLGRmcTsntqzTX73bFf0fTwegIF6r7mAErVKXq au/aXIJ7Qt0sP98/Lv/saTZ+CFI8BFC7jZoqJuPppzqV+xduPn8uzEdix/AipMJz JAULbx1hfkEvJAPiiW0Axcze3Q1tEVH7ec1dW2Mg7bqSBpkYW2rfmhECLaOAntpn BHaVp6gW+Mw6XObVvdGu2UdDIOlu5GfKoR6zieVnDF20nf9OScENSXzf3L36eemF d67BF74+BUBBoTec/ErDYU2QK91Yh3oLfUm0jtTu4LVZ+7eF1TfS+OOq33EWuZGg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedriedtgddtjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9A912E00AD; Mon, 27 Apr 2020 18:25:55 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <530cd39e-64c9-4a3a-91cb-2a13e3106037@www.fastmail.com> In-Reply-To: References: <93042b37-37e1-5b6a-3578-a750054d0507@gmx.net> Date: Tue, 28 Apr 2020 08:25:37 +1000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] Choice of Additional Data Computation 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: Mon, 27 Apr 2020 22:26:13 -0000 On Mon, Apr 27, 2020, at 17:06, Hannes Tschofenig wrote: > (*): Even if we optimize the CID away with cTLS the question about the > security implications will surface again. I think that cTLS is the answer to the size issue. But there, the rule tends to be that removing from the wire doesn't also remove from the canonical value that is processed by the stack, so we might be able to send without a CID, but re-insert the value before processing. As the canonical form, DTLS always including the value seems fine to me. From nobody Tue Apr 28 06:44:54 2020 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 885EA3A1560 for ; Tue, 28 Apr 2020 06:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 O_iCcwGf7zk1 for ; Tue, 28 Apr 2020 06:44:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01703A157D for ; Tue, 28 Apr 2020 06:44:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DE313F40749; Tue, 28 Apr 2020 06:44:29 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200428134429.DE313F40749@rfc-editor.org> Date: Tue, 28 Apr 2020 06:44:29 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6135) 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: Tue, 28 Apr 2020 13:44:52 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6135 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: Global Original Text ------------- list, series, set, and vector are seemingly used as synonyms. Corrected Text -------------- Using list, series, set, xor vector would help at least one reader. Notes ----- Additionally, consistent usage is desirable, e.g., page 31 uses "A list of extensions" whereas "A set of extensions" is used on page 60. Elsewhere inconsistently usage causes confusion, e.g., Page 48: client_shares: A list of offered KeyShareEntry values in descending order of client preference. This vector MAY be empty if the client is requesting a (Replace "vector" with "list", or vice versa.) Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Apr 28 08:43:17 2020 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 342103A0CF5 for ; Tue, 28 Apr 2020 08:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 SO2c6Vw5eI5W for ; Tue, 28 Apr 2020 08:43:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AFA03A0CBC for ; Tue, 28 Apr 2020 08:43:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 599AEF40749; Tue, 28 Apr 2020 08:42:59 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200428154259.599AEF40749@rfc-editor.org> Date: Tue, 28 Apr 2020 08:42:59 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC8446 (6136) 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: Tue, 28 Apr 2020 15:43:16 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6136 -------------------------------------- Type: Technical Reported by: Ben Smyth Section: 4.1.4 Original Text ------------- Upon receipt of a HelloRetryRequest, the client MUST check the legacy_version, legacy_session_id_echo, cipher_suite, and legacy_compression_method as specified in Section 4.1.3 Corrected Text -------------- Notes ----- Section 4.1.3 defines no checks for legacy_version nor legacy_compression_method Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Apr 28 08:52:22 2020 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 B92B43A0143 for ; Tue, 28 Apr 2020 08:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 cdyhnk3G_EGE for ; Tue, 28 Apr 2020 08:52:19 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2D9B3A0138 for ; Tue, 28 Apr 2020 08:52:19 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B6028F40745; Tue, 28 Apr 2020 08:52:05 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200428155205.B6028F40745@rfc-editor.org> Date: Tue, 28 Apr 2020 08:52:05 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6137) 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: Tue, 28 Apr 2020 15:52:21 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6137 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: 4.2.10 Original Text ------------- symmetric cipher suite Corrected Text -------------- cipher suite Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Apr 28 08:57:32 2020 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 EC7993A03F3 for ; Tue, 28 Apr 2020 08:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 yoanIAEVVm2S for ; Tue, 28 Apr 2020 08:57:29 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A5F3A03F2 for ; Tue, 28 Apr 2020 08:57:29 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 72B85F40749; Tue, 28 Apr 2020 08:57:15 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200428155715.72B85F40749@rfc-editor.org> Date: Tue, 28 Apr 2020 08:57:15 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6138) 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: Tue, 28 Apr 2020 15:57:31 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6138 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: 4.2.10 Original Text ------------- For externally provisioned PSKs, the associated values are those provisioned along with the key. For PSKs established via a NewSessionTicket message, the associated values are those which were negotiated in the connection which established the PSK. ... For externally established PSKs, the associated values are those provisioned along with the key. For PSKs established via a NewSessionTicket message, the associated values are those negotiated in the connection during which the ticket was established. Corrected Text -------------- For externally provisioned PSKs, the associated values are those provisioned along with the key. For PSKs established via a NewSessionTicket message, the associated values are those which were negotiated in the connection which established the PSK. Notes ----- Drop largely verbatim duplicated text Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Apr 28 10:24:42 2020 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 1DDAC3A09E4 for ; Tue, 28 Apr 2020 10:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 At1JV4gIi9rR for ; Tue, 28 Apr 2020 10:24:39 -0700 (PDT) Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22BFB3A09DF for ; Tue, 28 Apr 2020 10:24:39 -0700 (PDT) Received: by mail-il1-x131.google.com with SMTP id i16so21279659ils.12 for ; Tue, 28 Apr 2020 10:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=weXo6xxDJ1Zjxeiu1GUzNJbbZ/9y3QygyTG27gFrYmU=; b=sZY4S7T6FHBbadupRHa6ktJvS/kqiJ25ttCg93eWJJi58Q+FyqNodCnq1XcBL/G7dD ClReaItleCjBm6g5o3Y/vSV60BWONzAFTWNQYobSq1vY6DdkyYduhGnbVklukgY99C6u SstTyupSoTxzeLSJt0citFz21C7/lX6ANhnQhWzXh5bDazW7IB672NQNaG7BXIQDSGLf HrS2Qu4n/DIjoGGQ7cDBMKhf1NM0W0ZUZlLJ2uv/j26MBrL3vi3f71xeBOR856iIQWmy s5ucLHSXFDP0XBOWFiCrQRlxrECxukOvpgeNNl1vqayZfvntyv/J+QE1WhC97lumXv9b vnwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=weXo6xxDJ1Zjxeiu1GUzNJbbZ/9y3QygyTG27gFrYmU=; b=F8xDp0pbo5EEj2E/D1q100Xh2w9LPaCRycdpDkNvVa8XYSZzoKFbfEEazPfgsO4WBX zkCdTE0aL2F1DgG+Fp4pp64LILowXlVdX5mXjY0FSF40Qo1RweuaBPTDBGONKrocodX8 lspFhC5UTXIVeQzSeQMVGpnezZK+Kv7i9flRMfy715DeuFPPQAmpHKhXyIKMJQjiQCfM 839B1zx7ZhvyUvWnWpeBk36CpmetldLLUHLY+JKiV51sP90fV25D7GJ4kkHia5if+PY6 UMROw2L0rt0c/jVZNaYh3v1mRah7gaWg1WbN5QL6XrVB1Cvr/shPdgSMaBynK57Xqsv5 u3zg== X-Gm-Message-State: AGi0PuYquPGTeD1rEv6Kjw/MH6x7Ij0nlVFbrzofHHeMhcHfVAnnzVnV egTL19Dqr8sEXJsP6chPAvmSivu6sKS2LDefQgsFsIfnTJM= X-Google-Smtp-Source: APiQypJzBsxapmfisIaGmeXQjbjcO6PSA4EPfY53yzN9IY0lUwcYAWX90LNRKRnowoFyUiEC3c68/Fo63E4MWHb4M10= X-Received: by 2002:a92:c144:: with SMTP id b4mr27131679ilh.89.1588094678168; Tue, 28 Apr 2020 10:24:38 -0700 (PDT) MIME-Version: 1.0 References: <158793540276.8190.8571632584417892419@ietfa.amsl.com> In-Reply-To: <158793540276.8190.8571632584417892419@ietfa.amsl.com> From: Raja Ashok Date: Tue, 28 Apr 2020 22:54:27 +0530 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000002978a005a45d1b77" Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-ctls-00.txt 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: Tue, 28 Apr 2020 17:24:41 -0000 --0000000000002978a005a45d1b77 Content-Type: text/plain; charset="UTF-8" Some suggestion from my side for cTLS 1. Currently supported ciphersuites in cTLS are only 5. In that case I feel changing 2 byte "CipherSuite" also to "varint" will help to reduce few more bytes on wire. Similarly for "NamedGroup" and "SignatureScheme". 2. In section 5.1, last sentence in the explanation of "version" should contain "SeverHello.extensions" version (integer): indicates that both sides agree to the single TLS version specified by the given integer value (772 == 0x0304 for TLS 1.3). The supported_versions extension is omitted from ClientHello.extensions and reconstructed in the transcript as a single-valued list with the specified value. The supported_versions extension is omitted from ClientHello.extensions and reconstructed in the transcript with the specified value. Thanks & Regards Raja Ashok On Mon, Apr 27, 2020 at 2:41 AM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Transport Layer Security WG of the IETF. > > Title : Compact TLS 1.3 > Authors : Eric Rescorla > Richard Barnes > Hannes Tschofenig > Filename : draft-ietf-tls-ctls-00.txt > Pages : 17 > Date : 2020-04-26 > > Abstract: > This document specifies a "compact" version of TLS 1.3. It is > isomorphic to TLS 1.3 but saves space by trimming obsolete material, > tighter encoding, and a template-based specialization technique. cTLS > is not directly interoperable with TLS 1.3, but it should eventually > be possible for a cTLS/TLS 1.3 server to exist and successfully > interoperate. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-ctls/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tls-ctls-00 > https://datatracker.ietf.org/doc/html/draft-ietf-tls-ctls-00 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000002978a005a45d1b77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Some suggestion from my side for cTLS

<= /div>1. Currently supported ciphersuites in cTLS are only 5. In that case I= feel changing 2 byte "CipherSuite" also to "varint" wi= ll help to reduce few more bytes on wire. Similarly for "NamedGroup&qu= ot; and "SignatureScheme".

2. In section 5.1, last sentenc= e in the explanation of "version" should contain "SeverHello= .extensions"

=C2=A0 =C2=A0version (integer): =C2=A0indicates th= at both sides agree to the single TLS
=C2=A0 =C2=A0 =C2=A0 version speci= fied by the given integer value (772 =3D=3D 0x0304 for
=C2=A0 =C2=A0 =C2= =A0 TLS 1.3).=C2=A0 The supported_versions extension is omitted from
=C2= =A0 =C2=A0 =C2=A0 ClientHello.extensions and reconstructed in the transcrip= t as a
=C2=A0 =C2=A0 =C2=A0 single-valued list with the specified value.= =C2=A0 The
=C2=A0 =C2=A0 =C2=A0 supported_versions extension is omitted = from
=C2=A0 =C2=A0 =C2=A0 ClientHello.extensions and reconstructed in th= e transcript with
=C2=A0 =C2=A0 =C2=A0 the specified value.

=
Thanks & Regards
Raja Ashok

On Mon, Apr 27, 2= 020 at 2:41 AM <internet-dra= fts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Transport Layer Security WG of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Compact TLS 1.3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Eric= Rescorla
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Richard Barnes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Hannes Tschofenig
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-tls-ctls-00.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 17
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-04-26

Abstract:
=C2=A0 =C2=A0This document specifies a "compact" version of TLS 1= .3.=C2=A0 It is
=C2=A0 =C2=A0isomorphic to TLS 1.3 but saves space by trimming obsolete mat= erial,
=C2=A0 =C2=A0tighter encoding, and a template-based specialization techniqu= e. cTLS
=C2=A0 =C2=A0is not directly interoperable with TLS 1.3, but it should even= tually
=C2=A0 =C2=A0be possible for a cTLS/TLS 1.3 server to exist and successfull= y
=C2=A0 =C2=A0interoperate.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls= -ctls/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tls-ctls-00=
https://datatracker.ietf.org/doc/html/dr= aft-ietf-tls-ctls-00


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000002978a005a45d1b77-- From nobody Wed Apr 29 01:14:41 2020 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 E2CAC3A047D for ; Wed, 29 Apr 2020 01:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 syjkk-eqdhOh for ; Wed, 29 Apr 2020 01:14:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995393A044D for ; Wed, 29 Apr 2020 01:14:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A0285F406F2; Wed, 29 Apr 2020 01:14:21 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200429081421.A0285F406F2@rfc-editor.org> Date: Wed, 29 Apr 2020 01:14:21 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6139) 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: Wed, 29 Apr 2020 08:14:39 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6139 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: 4.4.2.2. Original Text ------------- As servers MAY require the presence of the "server_name" extension, clients SHOULD send this extension, when applicable. Corrected Text -------------- As servers MAY require the presence of the "server_name" extension, client SHOULD send this extension. Notes ----- Since it is unclear when it is applicable for a server to send the extension, dropping "when applicable" seems appropriate. Alternatively, giving some extra guidance would be useful. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Apr 29 01:18:56 2020 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 B71E43A058F for ; Wed, 29 Apr 2020 01:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 LhiV1Tll8vgL for ; Wed, 29 Apr 2020 01:18:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA643A053E for ; Wed, 29 Apr 2020 01:18:52 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id B9382F40756; Wed, 29 Apr 2020 01:18:37 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200429081837.B9382F40756@rfc-editor.org> Date: Wed, 29 Apr 2020 01:18:37 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6140) 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: Wed, 29 Apr 2020 08:18:55 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6140 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: 4.4.2.2. Original Text ------------- This fallback chain SHOULD NOT use the deprecated SHA-1 hash algorithm in general, but MAY do so if the client's advertisement permits it, and MUST NOT do so otherwise. Corrected Text -------------- This fullback chain MUST NOT use the deprecated SHA-1 hash, except if advertised by the client, in which case it MAY. Notes ----- The original text is difficult to read, eliminating the unnecessary "SHOULD NOT" seems to make it easier. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Apr 29 01:24:25 2020 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 A43CB3A0779 for ; Wed, 29 Apr 2020 01:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 LWFu7eGc17i8 for ; Wed, 29 Apr 2020 01:24:22 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAAD3A0774 for ; Wed, 29 Apr 2020 01:24:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 48603F40756; Wed, 29 Apr 2020 01:24:07 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200429082407.48603F40756@rfc-editor.org> Date: Wed, 29 Apr 2020 01:24:07 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6141) 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: Wed, 29 Apr 2020 08:24:24 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6141 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: 4.4.3 Original Text ------------- - The context string Corrected Text -------------- - The context string (defined below) Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Apr 29 01:31:46 2020 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 A1E6D3A07AD for ; Wed, 29 Apr 2020 01:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GNO6_dEvPbC3 for ; Wed, 29 Apr 2020 01:31:42 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3461C3A07AA for ; Wed, 29 Apr 2020 01:31:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 51CD3F40756; Wed, 29 Apr 2020 01:31:27 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200429083127.51CD3F40756@rfc-editor.org> Date: Wed, 29 Apr 2020 01:31:27 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC8446 (6142) 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: Wed, 29 Apr 2020 08:31:44 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6142 -------------------------------------- Type: Technical Reported by: Ben Smyth Section: 4.6.1. Original Text ------------- Clients MUST NOT cache tickets for longer than 7 days Corrected Text -------------- Clients MUST NOT use tickets for longer than 7 days Notes ----- "MUST NOT cache" is surely overly zealous and may unnecessarily result in non-compliant implementations Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Apr 29 02:19:44 2020 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 E015E3A0A30 for ; Wed, 29 Apr 2020 02:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 4QolyCeYpD9c for ; Wed, 29 Apr 2020 02:19:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CFF03A0A2F for ; Wed, 29 Apr 2020 02:19:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8F5FFF40756; Wed, 29 Apr 2020 02:19:25 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200429091925.8F5FFF40756@rfc-editor.org> Date: Wed, 29 Apr 2020 02:19:25 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC8446 (6143) 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: Wed, 29 Apr 2020 09:19:42 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6143 -------------------------------------- Type: Technical Reported by: Ben Smyth Section: 4.2.7 Original Text ------------- As of TLS 1.3, servers are permitted to send the "supported_groups" extension to the client. Corrected Text -------------- Notes ----- It is unclear whether servers are permitted to send the "supported_groups" extension to the client without solicitation, i.e., when the client does not first send the extension to the server. Clarification would be useful. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Apr 29 02:36:50 2020 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 A581D3A0A9C for ; Wed, 29 Apr 2020 02:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wAgPs7nCEJ1q for ; Wed, 29 Apr 2020 02:36:47 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4973A0A9A for ; Wed, 29 Apr 2020 02:36:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8E153F40756; Wed, 29 Apr 2020 02:36:32 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200429093632.8E153F40756@rfc-editor.org> Date: Wed, 29 Apr 2020 02:36:32 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6144) 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: Wed, 29 Apr 2020 09:36:49 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6144 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: 4.2.8. Original Text ------------- Upon receipt of this extension in a HelloRetryRequest, the client MUST verify that...the selected_group field does not correspond to a group which was provided in the "key_share" extension in the original ClientHello. Corrected Text -------------- Upon receipt of this extension in a HelloRetryRequest, the client MUST verify that...a key share was not offered (in the "key_share" extension in the original ClientHello) for the group in the selected_group field. Notes ----- The original text requires knowledge of the "key_share" extension and is rather hard to read, the proposed text should be easier to understand. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Apr 29 02:47:46 2020 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 6C96F3A0AC1 for ; Wed, 29 Apr 2020 02:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 JMkzHrkMoXG5 for ; Wed, 29 Apr 2020 02:47:38 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00583A0ACB for ; Wed, 29 Apr 2020 02:47:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A87CBF40756; Wed, 29 Apr 2020 02:47:23 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200429094723.A87CBF40756@rfc-editor.org> Date: Wed, 29 Apr 2020 02:47:23 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC8446 (6145) 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: Wed, 29 Apr 2020 09:47:41 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6145 -------------------------------------- Type: Technical Reported by: Ben Smyth Section: 4.2.10. Original Text ------------- When a PSK is used and early data is allowed for that PSK Corrected Text -------------- Notes ----- I couldn't find restrictions that forbid early data for a PSK. Explaining where such restrictions could exist would be useful. E.g., PSKs might be associated with data that forbids early data. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Apr 29 02:50:38 2020 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 2A3B03A0AD8 for ; Wed, 29 Apr 2020 02:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 nLgtlpal6uYg for ; Wed, 29 Apr 2020 02:50:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 643CD3A0AD6 for ; Wed, 29 Apr 2020 02:50:34 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5D9F5F40756; Wed, 29 Apr 2020 02:50:19 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200429095019.5D9F5F40756@rfc-editor.org> Date: Wed, 29 Apr 2020 02:50:19 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC8446 (6146) 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: Wed, 29 Apr 2020 09:50:36 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6146 -------------------------------------- Type: Technical Reported by: Ben Smyth Section: 4.2.10. Original Text ------------- The TLS version number Corrected Text -------------- The selected TLS version number Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Apr 29 02:54:33 2020 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 2DE243A0AF5 for ; Wed, 29 Apr 2020 02:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 mkLI10JhYqBk for ; Wed, 29 Apr 2020 02:54:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C487E3A0AF4 for ; Wed, 29 Apr 2020 02:54:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E25A0F40756; Wed, 29 Apr 2020 02:54:15 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200429095415.E25A0F40756@rfc-editor.org> Date: Wed, 29 Apr 2020 02:54:15 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6147) 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: Wed, 29 Apr 2020 09:54:32 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6147 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: 4.2.10. Original Text ------------- In order to accept early data, the server MUST have accepted a PSK cipher suite....In addition, it MUST verify that the following values are the same as those associated with the selected PSK: ... - The selected cipher suite Corrected Text -------------- Notes ----- Accepting the "PSK cipher suite" surely implies the PSK is associated with the cipher suite, hence, "The selected cipher suite" can be dropped. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Apr 29 02:55:29 2020 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 28E623A0ACE for ; Wed, 29 Apr 2020 02:55:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 vE_XJH3XRhE5 for ; Wed, 29 Apr 2020 02:55:25 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3415D3A0AF4 for ; Wed, 29 Apr 2020 02:55:25 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 5336CF40756; Wed, 29 Apr 2020 02:55:10 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200429095510.5336CF40756@rfc-editor.org> Date: Wed, 29 Apr 2020 02:55:10 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6148) 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: Wed, 29 Apr 2020 09:55:29 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6148 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: 4.2.10 Original Text ------------- The selected ALPN [RFC7301] protocol, if any Corrected Text -------------- The selected ALPN [RFC7301] protocol, if extension application_layer_protocol_negotiation is present Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Apr 29 05:36:55 2020 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 A3DA23A0E44 for ; Wed, 29 Apr 2020 05:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 gBIO2-tJ9CMC for ; Wed, 29 Apr 2020 05:36:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840873A0E3F for ; Wed, 29 Apr 2020 05:36:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 79CC2F4073D; Wed, 29 Apr 2020 05:36:36 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200429123636.79CC2F4073D@rfc-editor.org> Date: Wed, 29 Apr 2020 05:36:36 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC8446 (6150) 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: Wed, 29 Apr 2020 12:36:54 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6150 -------------------------------------- Type: Editorial Reported by: Ben Smyth Section: GLOBAL Original Text ------------- Note that certificate-based client authentication is not available in PSK handshake flows (including 0-RTT). Corrected Text -------------- Note that certificate-based client authentication is not available in PSK handshake flows (including 0-RTT), post-handshake certificate-based client authentication is possible. Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From research@bensmyth.com Wed Apr 29 05:21:56 2020 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 731233A0E0E for ; Wed, 29 Apr 2020 05:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=bensmyth.com 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 kE1S07DA0By2 for ; Wed, 29 Apr 2020 05:21:53 -0700 (PDT) Received: from 1.smtp.34sp.com (1.smtp.34sp.com [46.183.9.64]) (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 8A8D73A0E0B for ; Wed, 29 Apr 2020 05:21:52 -0700 (PDT) Received: from smtpauth2.mailarray.34sp.com (lvs5.34sp.com [46.183.13.73]) by 1.smtp.34sp.com (Postfix) with ESMTPS id 1D6CB1480075 for ; Wed, 29 Apr 2020 13:21:18 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bensmyth.com; s=dkim; t=1588162878; bh=r/tsO2yI8tfZ5lNokqnLYbxxn9jBvpKqMHylhU6qxq0=; h=Reply-To:From:Date:Subject:To; b=iEHSdxraXiYJR/n4AL13MqXSPo8aO33QI4TX/aSXyIvrM1HyvfByCj/tOBBaOhANp bzavV/CX8qaf+on9RQyY4MZcGRIwkaI0p0J9nJOHnP2hNu9eCY683waXjhe0d85MWY 19/ebshEWgVraGJM/JFMi49M922YQ4CiMYiNHR40= Received: from mail-ed1-f54.google.com ([209.85.208.54]:39501) by smtpauth2.mailarray.34sp.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1jTliH-0006WY-Vg for tls@ietf.org; Wed, 29 Apr 2020 13:21:18 +0100 Received: by mail-ed1-f54.google.com with SMTP id k22so1334895eds.6 for ; Wed, 29 Apr 2020 05:21:17 -0700 (PDT) X-Gm-Message-State: AGi0Puaa0mbFfRXKTBqH9t4DepjPIeDFAk2bvvGmU/uUJvkZGJPKEhts +ekPKVh+HKX5yTyDhcwS2MhjwBrGdu9KBPjHupE= X-Google-Smtp-Source: APiQypIJcwXCS+jnqtkM4O4UZtJN9U35mQRZfKQ/IQJ/+RJwXMEjUgC1c8A97f72+5ZheqKiB6OpgWfTh09iWWy/bUs= X-Received: by 2002:a50:ee0e:: with SMTP id g14mr2231518eds.34.1588162877169; Wed, 29 Apr 2020 05:21:17 -0700 (PDT) MIME-Version: 1.0 Reply-To: research@bensmyth.com From: Ben Smyth Date: Wed, 29 Apr 2020 14:20:50 +0200 X-Gmail-Original-Message-ID: Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="00000000000023a92305a46cfc36" X-Authenticated-As: research@bensmyth.com X-OriginalSMTPIP: 209.85.208.54 X-34spcom-MailScanner-Information: Please contact the ISP for more information X-34spcom-MailScanner-ID: 1D6CB1480075.A70A5 X-34spcom-MailScanner: Found to be clean X-34spcom-MailScanner-SpamCheck: not spam, SpamAssassin (score=-20.1, required 6.5, autolearn=disabled, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00, SPF_PASS -0.00, X34SP_ALLOW_GMAIL_EVEN_IF_BLACKLISTED -10.00, X34SP_OVERRIDE -10.00) X-34spcom-MailScanner-From: research@bensmyth.com Archived-At: Subject: [TLS] RFC 8446 Early data, server response: deprotect vs. type checking 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: Wed, 29 Apr 2020 12:42:39 -0000 --00000000000023a92305a46cfc36 Content-Type: text/plain; charset="UTF-8" Section 4.2.10 requires a server receiving early data to behave in ways including (p53): * Ignore the extension and return a regular 1-RTT response. The server then skips past early data by attempting to deprotect received records using the handshake traffic key, discarding records which fail deprotection... * Request that the client send another ClientHello by responding with a HelloRetryRequest... The server then ignores early data by skipping all records with an external content type of "application_data"... What are the use cases for each behaviour? And why does the former rely on deprotecting, when checking record content types is surely more efficient? (I'm extending my TLS 1.3 tutorial -- https://bensmyth.com/publications/2019-TLS-tutorial/ -- to include discussion of early data and I'm struggling to understand the rationale behind these two behaviours.) Best regards, Ben --00000000000023a92305a46cfc36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Section 4.2.10 requires a server receiving early data= to behave in ways including (p53):

* Ignore the extension and retur= n a regular 1-RTT response.=C2=A0 The server then skips past early data by = attempting to deprotect received records using the handshake traffic key, d= iscarding records which fail deprotection...

* Req= uest that the client send another ClientHello by responding with a HelloRet= ryRequest... The server then ignores early data by skipping all records wit= h an external content type of "application_data"...
What are the use cases for each behaviour? And why does the for= mer rely on deprotecting, when checking record content types is surely more= efficient?

(I'm extending my TLS 1.3 tut= orial -- h= ttps://bensmyth.com/publications/2019-TLS-tutorial/ -- to include discu= ssion of early data and I'm struggling to understand the rationale behi= nd these two behaviours.)


Best= regards,

Ben
--00000000000023a92305a46cfc36-- From nobody Wed Apr 29 06:43:44 2020 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 4DDEE3A0FD2 for ; Wed, 29 Apr 2020 06:43:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 5AyI8Wdt9zpJ for ; Wed, 29 Apr 2020 06:43:40 -0700 (PDT) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAA6D3A0FED for ; Wed, 29 Apr 2020 06:43:39 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id 188so1682040lfa.10 for ; Wed, 29 Apr 2020 06:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C04JPfb1AAdlMDBFxi/JU51KlwQGcZT0WqR5fjwtYU0=; b=0VWyYqO0XzVG9weajiJ5mOqHs8WFSyts14Efp+j6t7XQz1DvJNX0+X5Z1Vl89veK2d xknbpeVRGZZew3lvyk2eohmWOeKfr7DJDRUjIKB7WC0vJrCC1nskwFZ2ht8ahRohlHj7 W4geeecB/hGQ9gPXWOimWR0Ukvesr5/qFMUxxc9GH6l8bfEURYcUAExmUaq0kMC+3qlT tMdOEf9rNaWoVweMSrb+mgiExPPJEqusess0+E2S0RyrSGJCjzjS4124bmTr5dglVahm oVmqgMI6majeVmWvtLxcihYw97zF1GooGn+T/9NZPbwM6n7TNAOZr1wt52BtBzeCDye3 HqNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C04JPfb1AAdlMDBFxi/JU51KlwQGcZT0WqR5fjwtYU0=; b=A77ov3OW5MjJBi14WlUD/QozfPBkZvCu8qSgvoMik+k1nJr9756d4Qk+O9cbZCaCpr 4t/FPoopQlDorqfC8Ky9nGKD4AOQj5QTm+6q6NgAgq4TUdv8auqOiHDr/b+WwVsKbIbE 6F8hqKlugQJfwPlNe833son7e2xPGXL+KCFNYvgvPFVov6K1HdvIV6UV7iRl6BC5vFl/ tJuaA2FNbsnAltBr5bo+qQa5/RtDxLLY9YSlFaNDtI2cWh62Xz3DkU4zhk/Bchy+hL+7 ZcwJ0N0LLUMJKIxxhVGhW341cbKbVDoE8RN8yNl0xgA3ikuR0nbwMFfbTFjjMCQfnyk9 H7Og== X-Gm-Message-State: AGi0PuYrBzK0FRYuSpdOSSbMHuCIvYa9Il3GOSCkcIbl/JOir4W4VbJe UN6zJ3URKwVXkQV6i8TnLxrwiUpGjRHuDDgdClir1Lgk3m8= X-Google-Smtp-Source: APiQypL5wChU2ra4g8bgPkKEls7CtbI3xCNhU2sVT+ctwnYh9x3NLzUJObAOu22A0bazvr0uKLlfLKI7dCOEHH5/OFs= X-Received: by 2002:ac2:5b92:: with SMTP id o18mr19002902lfn.140.1588167818005; Wed, 29 Apr 2020 06:43:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Wed, 29 Apr 2020 06:43:01 -0700 Message-ID: To: research@bensmyth.com Cc: "" Content-Type: multipart/alternative; boundary="000000000000a2e41305a46e220a" Archived-At: Subject: Re: [TLS] RFC 8446 Early data, server response: deprotect vs. type checking 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: Wed, 29 Apr 2020 13:43:43 -0000 --000000000000a2e41305a46e220a Content-Type: text/plain; charset="UTF-8" Hi Ben, Thanks for your note and for your efforts on the tutorial! On Wed, Apr 29, 2020 at 5:43 AM Ben Smyth wrote: > Section 4.2.10 requires a server receiving early data to behave in ways > including (p53): > > * Ignore the extension and return a regular 1-RTT response. The server > then skips past early data by attempting to deprotect received records > using the handshake traffic key, discarding records which fail > deprotection... > > * Request that the client send another ClientHello by responding with a > HelloRetryRequest... The server then ignores early data by skipping all > records with an external content type of "application_data"... > > What are the use cases for each behaviour? > I expect that the first response will be the ordinary one. However, in some cases you will be forced to employ the second one because it is not possible to send a SH. For instance, consider the case where the server has been reconfigured and no longer accepts the DH group that the client employs in the CH. In that case, it will have to send HRR. > And why does the former rely on deprotecting, when checking record content > types is surely more efficient? > Unfortunately, the record types are encrypted, and this will not work. Best, -Ekr > (I'm extending my TLS 1.3 tutorial -- > https://bensmyth.com/publications/2019-TLS-tutorial/ -- to include > discussion of early data and I'm struggling to understand the rationale > behind these two behaviours.) > > > Best regards, > > Ben > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000a2e41305a46e220a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

Thanks for your note= and for your efforts on the tutorial!

On Wed, Apr 29, 2= 020 at 5:43 AM Ben Smyth <research@bensmyth.com> wrote:
Section 4.2.10 requ= ires a server receiving early data to behave in ways including (p53):
* Ignore the extension and return a regular 1-RTT response.=C2=A0 The ser= ver then skips past early data by attempting to deprotect received records = using the handshake traffic key, discarding records which fail deprotection= ...

* Request that the client send another ClientH= ello by responding with a HelloRetryRequest... The server then ignores earl= y data by skipping all records with an external content type of "appli= cation_data"...

What are the use cases for ea= ch behaviour?

I expect that th= e first response will be the ordinary one. However, in some cases you will = be forced to employ the second one because it is not possible to send a SH.= For instance, consider the case where the server has been reconfigured and= no longer accepts the DH group that the client employs in the CH. In that = case, it will have to send HRR.

=C2=A0
And why d= oes the former rely on deprotecting, when checking record content types is = surely more efficient?

Unf= ortunately, the record types are encrypted, and this will not work.

Best,
-Ekr

=C2=A0
(I= 'm extending my TLS 1.3 tutorial -- https://bensmyth.com/public= ations/2019-TLS-tutorial/ -- to include discussion of early data and I&= #39;m struggling to understand the rationale behind these two behaviours.) =


Best regards,

Ben
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000a2e41305a46e220a-- From nobody Thu Apr 30 01:02:15 2020 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 B698A3A0AEF for ; Thu, 30 Apr 2020 01:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=bensmyth.com 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 rZ5fYnBfjtzi for ; Thu, 30 Apr 2020 01:02:10 -0700 (PDT) Received: from 2.smtp.34sp.com (2.array2.smtp.34sp.com [IPv6:2a00:1ee0:2:5::2eb7:902]) (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 909103A0AE7 for ; Thu, 30 Apr 2020 01:02:09 -0700 (PDT) Received: from smtpauth2.mailarray.34sp.com (lvs5.34sp.com [46.183.13.73]) by 2.smtp.34sp.com (Postfix) with ESMTPS id 9ECB65816D8 for ; Thu, 30 Apr 2020 09:01:49 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bensmyth.com; s=dkim; t=1588233709; bh=Hm7eV1bnHpChnEKuwMqbIQa8HLwf0r8V0EVOtIXuZ+k=; h=References:In-Reply-To:Reply-To:From:Date:Subject:To:Cc; b=Mji9DY0phJHBRNY3o/1b8dgrnGqpjGq0VqIP4zafQ34i+CoEjaz39SwWdVRiRRk3T tE0G/eA01KOifQozcImoqgBq40x4cmDHD3IdiztFsIqZiETryoVXFaKCdb+3h4cnXj qRdoRdvXnhsq09LaFVzYt6H4WSPFkVBUb5dqxn8g= Received: from mail-ej1-f54.google.com ([209.85.218.54]:33244) by smtpauth2.mailarray.34sp.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1jU48j-0001fi-93 for tls@ietf.org; Thu, 30 Apr 2020 09:01:49 +0100 Received: by mail-ej1-f54.google.com with SMTP id s9so3934239eju.1 for ; Thu, 30 Apr 2020 01:01:49 -0700 (PDT) X-Gm-Message-State: AGi0PuahULaP7hsk0TgijPdblInBSEvGGzt4KWn5mKapIFTBmNukzcd1 nhLrxLEflcBd0vm0+SPkH8PUy/9qh2Me/nlhraA= X-Google-Smtp-Source: APiQypIF0yOaehqgxZp4PtTlyQBp+L5GASKCwqBlzWdYJipLDRCBhlMwqCtt39RPv8RanI5r1g8EuPzFzezK28p30KQ= X-Received: by 2002:a17:906:2410:: with SMTP id z16mr1587953eja.1.1588233708912; Thu, 30 Apr 2020 01:01:48 -0700 (PDT) MIME-Version: 1.0 References: <20200429094723.A87CBF40756@rfc-editor.org> In-Reply-To: <20200429094723.A87CBF40756@rfc-editor.org> Reply-To: research@bensmyth.com From: Ben Smyth Date: Thu, 30 Apr 2020 10:01:21 +0200 X-Gmail-Original-Message-ID: Message-ID: To: RFC Errata System Cc: ekr@rtfm.com, rdd@cert.org, Benjamin Kaduk , caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com, tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000000a47ac05a47d7a50" X-Authenticated-As: research@bensmyth.com X-OriginalSMTPIP: 209.85.218.54 X-34spcom-MailScanner-Information: Please contact the ISP for more information X-34spcom-MailScanner-ID: 9ECB65816D8.A6BE9 X-34spcom-MailScanner: Found to be clean X-34spcom-MailScanner-SpamCheck: not spam, SpamAssassin (score=-20.1, required 6.5, autolearn=disabled, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00, SPF_PASS -0.00, X34SP_ALLOW_GMAIL_EVEN_IF_BLACKLISTED -10.00, X34SP_OVERRIDE -10.00) X-34spcom-MailScanner-From: research@bensmyth.com Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC8446 (6145) 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: Thu, 30 Apr 2020 08:02:14 -0000 --0000000000000a47ac05a47d7a50 Content-Type: text/plain; charset="UTF-8" > Original Text > ------------- > When a PSK is used and early data is allowed for that PSK > > Notes > ----- > I couldn't find restrictions that forbid early data for a PSK. Explaining > where such restrictions > could exist would be useful. E.g., PSKs might be associated with data that > forbids early data. > That's an oversight on my part: The sole extension currently defined for NewSessionTicket is "early_data", indicating that the ticket may be used to send 0-RTT data The client may only send early data when permitted: When a PSK is used and early data is allowed for that PSK, the client can send Application Data in its first flight of messages. Servers don't appear to be forbidden from consuming early data when keys don't permit them to. Perhaps I've missed that too. Or perhaps it doesn't matter: If a client does something they aren't supposed to, then they're only compromising their own security. --0000000000000a47ac05a47d7a50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Original Text
-------------
When a PSK is used and early data is allowed for that PSK

Notes
-----
I couldn't find restrictions that forbid early data for a PSK. Explaini= ng where such restrictions
could exist would be useful. E.g., PSKs might be associated with data that = forbids early data.

That's an overs= ight on my part:

=C2=A0=C2=A0 The sole extension c= urrently defined for NewSessionTicket is
=C2=A0 =C2=A0"early_data&q= uot;, indicating that the ticket may be used to send 0-RTT
=C2=A0 =C2=A0= data

The client may only send early data when perm= itted:

=C2=A0=C2=A0 When a PSK is used and early d= ata is allowed for that PSK, the client
=C2=A0 =C2=A0can send Applicatio= n Data in its first flight of messages. =C2=A0

Servers don't appear to be forbidden from consuming early data when ke= ys don't permit them to. Perhaps I've missed that too. Or perhaps i= t doesn't matter: If a client does something they aren't supposed t= o, then they're only compromising their own security.
--0000000000000a47ac05a47d7a50-- From nobody Thu Apr 30 02:40:08 2020 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 1490B3A00AD for ; Thu, 30 Apr 2020 02:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=bensmyth.com 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 kOj6k_GeASMr for ; Thu, 30 Apr 2020 02:40:04 -0700 (PDT) Received: from 5.smtp.34sp.com (5.smtp.34sp.com [IPv6:2a00:1ee0:2:5::2eb7:8e4]) (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 DD6B03A00C4 for ; Thu, 30 Apr 2020 02:39:55 -0700 (PDT) Received: from smtpauth5.mailarray.34sp.com (lvs5.34sp.com [46.183.13.73]) by 5.smtp.34sp.com (Postfix) with ESMTPS id 348882C180C for ; Thu, 30 Apr 2020 10:39:29 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bensmyth.com; s=dkim; t=1588239569; bh=A7AMCi3R/HSK5NX10oepryBo5tTdVB/2r2notFaf5RA=; h=Reply-To:From:Date:Subject:To; b=BBiCNIDHmCuyt7XWQ39WbcNPuDBMo91rsOcjIRAIEZTyBOkFoOcYKh9t2pc35HIBH 9RjIgd2UONl4wthYhy1B7oO4QrLpGbBpUV9JhnzsZGzeyMNo2/xUi+mqZ2ykAkMxdY siRcCZEY/r1VlF+ndDS6RByQu2Te3b3LrxJjv3+0= Received: from mail-ej1-f49.google.com ([209.85.218.49]:43200) by smtpauth5.mailarray.34sp.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1jU5fF-0004WQ-2A for tls@ietf.org; Thu, 30 Apr 2020 10:39:29 +0100 Received: by mail-ej1-f49.google.com with SMTP id s9so4151432eju.1 for ; Thu, 30 Apr 2020 02:39:29 -0700 (PDT) X-Gm-Message-State: AGi0PuaCCITVT9nfO9bCR0ojqTa6Gn0izRAMXtnjOAbICRGqeSByVYHs TOEvBv2sCxrfyNhEomTPJ5dvfpNQrG0u5YQSVPw= X-Google-Smtp-Source: APiQypLM+HN0+raft3Kw03OsvsVzkiergDLyr+NSbVLM2NO/GdL04T9B9Ol5OW7nSKn+IJZqWRIWNaVemBd9NdyYOdM= X-Received: by 2002:a17:906:1387:: with SMTP id f7mr1772564ejc.333.1588239568712; Thu, 30 Apr 2020 02:39:28 -0700 (PDT) MIME-Version: 1.0 Reply-To: research@bensmyth.com From: Ben Smyth Date: Thu, 30 Apr 2020 11:39:02 +0200 X-Gmail-Original-Message-ID: Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000004fb91c05a47ed736" X-Authenticated-As: research@bensmyth.com X-OriginalSMTPIP: 209.85.218.49 X-34spcom-MailScanner-Information: Please contact the ISP for more information X-34spcom-MailScanner-ID: 348882C180C.A7496 X-34spcom-MailScanner: Found to be clean X-34spcom-MailScanner-SpamCheck: not spam, SpamAssassin (score=-20.1, required 6.5, autolearn=disabled, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00, SPF_PASS -0.00, X34SP_ALLOW_GMAIL_EVEN_IF_BLACKLISTED -10.00, X34SP_OVERRIDE -10.00) X-34spcom-MailScanner-From: research@bensmyth.com Archived-At: Subject: [TLS] RFC 8446: Correlating connections with ticket ages 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: Thu, 30 Apr 2020 09:40:07 -0000 --0000000000004fb91c05a47ed736 Content-Type: text/plain; charset="UTF-8" Section 4.2.11.1 explains that: ...PskIdentity contains an obfuscated version of the ticket age formed by taking the age in milliseconds and adding the "ticket_age_add"... This addition prevents passive observers from correlating connections unless tickets are reused. So: Correlations are possible when tickets are reused. But, what connection correlations are prevented when tickets aren't reused? Best regards, Ben -- TLS 1.3 tutorial: https://bensmyth.com/publications/2019-TLS-tutorial/ --0000000000004fb91c05a47ed736 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Section 4.2.11.1 explains that:

...PskIde= ntity contains an obfuscated version of the ticket age formed by taking the= age in milliseconds and adding the "ticket_age_add"... This addi= tion prevents passive observers from correlating connections unless tickets= are reused.

So: Correlations are possible when tickets= are reused. But, what connection correlations are prevented when tickets a= ren't reused?


Best regards,

<= div>Ben

--0000000000004fb91c05a47ed736-- From nobody Thu Apr 30 02:47:20 2020 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 DD35D3A02BC for ; Thu, 30 Apr 2020 02:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=bensmyth.com 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 ZJRzzghpuCNH for ; Thu, 30 Apr 2020 02:47:15 -0700 (PDT) Received: from 1.smtp.34sp.com (1.smtp.34sp.com [46.183.9.64]) (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 287D63A0101 for ; Thu, 30 Apr 2020 02:47:14 -0700 (PDT) Received: from smtpauth3.mailarray.34sp.com (lvs5.34sp.com [46.183.13.73]) by 1.smtp.34sp.com (Postfix) with ESMTPS id E0BBF148009D for ; Thu, 30 Apr 2020 10:46:20 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bensmyth.com; s=dkim; t=1588239980; bh=HHVdpEcr8mbJG/Ge8MwFx7PVa9Z94Nmalq7k0D/Kzsc=; h=References:In-Reply-To:Reply-To:From:Date:Subject:To:Cc; b=Ham4GSnapR0lMDglZ28/23qk9PKqxD9GOKyUvgXFTdiset8Nv/hRpP8ziRKzgOHqC 0Bw8GLpCc5nZc5zJxmXCBbRkQG/hc9EY5/w89oxKI3L2xsd56zyKmugQYtZzEpenEp HLsZNyfL31R0Hbti/5OLwRWoCNr4gR7QnBQlyGFw= Received: from mail-ed1-f51.google.com ([209.85.208.51]:42846) by smtpauth3.mailarray.34sp.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1jU5ls-00035B-Tc for tls@ietf.org; Thu, 30 Apr 2020 10:46:20 +0100 Received: by mail-ed1-f51.google.com with SMTP id l3so3948200edq.13 for ; Thu, 30 Apr 2020 02:46:20 -0700 (PDT) X-Gm-Message-State: AGi0PuYowofm2XTebI6WIaUS9lqhrRqMpPkq4OpIPeQrEy5LU+4O/9c0 ydBB8dfra7S6xOjJXi85fgwYzRvyLWUDUM7Z5/Q= X-Google-Smtp-Source: APiQypKsB/gEpkZRAgWDcyEp0DJA3mfvvCTzFPxuHEEf7anMzTe/8/fXmjFuNfJPAfODV7TCvknyLYJF6OhgM2xe150= X-Received: by 2002:aa7:c306:: with SMTP id l6mr1808404edq.356.1588239980516; Thu, 30 Apr 2020 02:46:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: research@bensmyth.com From: Ben Smyth Date: Thu, 30 Apr 2020 11:45:54 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Eric Rescorla Cc: "" Content-Type: multipart/alternative; boundary="000000000000db5ae405a47eef32" X-Authenticated-As: research@bensmyth.com X-OriginalSMTPIP: 209.85.208.51 X-34spcom-MailScanner-Information: Please contact the ISP for more information X-34spcom-MailScanner-ID: E0BBF148009D.A6C93 X-34spcom-MailScanner: Found to be clean X-34spcom-MailScanner-SpamCheck: not spam, SpamAssassin (score=-20.1, required 6.5, autolearn=disabled, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00, SPF_PASS -0.00, X34SP_ALLOW_GMAIL_EVEN_IF_BLACKLISTED -10.00, X34SP_OVERRIDE -10.00) X-34spcom-MailScanner-From: research@bensmyth.com Archived-At: Subject: Re: [TLS] RFC 8446 Early data, server response: deprotect vs. type checking 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: Thu, 30 Apr 2020 09:47:19 -0000 --000000000000db5ae405a47eef32 Content-Type: text/plain; charset="UTF-8" > > Section 4.2.10 requires a server receiving early data to behave in ways >> including (p53): >> >> * Ignore the extension and return a regular 1-RTT response. The server >> then skips past early data by attempting to deprotect received records >> using the handshake traffic key, discarding records which fail >> deprotection... >> >> * Request that the client send another ClientHello by responding with a >> HelloRetryRequest... The server then ignores early data by skipping all >> records with an external content type of "application_data"... >> >> What are the use cases for each behaviour? >> > I expect that the first response will be the ordinary one. However, in some > cases you will be forced to employ the second one because it is not > possible to send a SH. For instance, consider the case where the server has > been reconfigured and no longer accepts the DH group that the client > employs in the CH. In that case, it will have to send HRR. > SH and HRR are simply used in their usual ways: Thanks for the clarification. > And why does the former rely on deprotecting, when checking record content >> types is surely more efficient? >> > > Unfortunately, the record types are encrypted, and this will not work. > (I meant the external content type. But, that doesn't work anyhow.) I have now understood: When not consuming early data, respond with SH or HRR. For the former, given that all messages will be encrypted, the server must decrypt messages with the handshake traffic key, discard messages when decryption fails, and treat the first successfully decrypted message as the client's next handshake message, thereafter proceeding as if no early data were sent. For the latter, the second CH message will be unencrypted and the server can discard all encrypted messages (identified by record type 0x23, rather than 0x22), before proceeding as if no early data were sent when the second CH is identified. Thanks for your support, Ben --000000000000db5ae405a47eef32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Section 4.= 2.10 requires a server receiving early data to behave in ways including (p5= 3):

* Ignore the extension and return a regular 1-RTT response.=C2= =A0 The server then skips past early data by attempting to deprotect receiv= ed records using the handshake traffic key, discarding records which fail d= eprotection...

* Request that the client send anot= her ClientHello by responding with a HelloRetryRequest... The server then i= gnores early data by skipping all records with an external content type of = "application_data"...

What are the use c= ases for each behaviour?

I expect that the first r= esponse will be the ordinary one. However, in some cases you will be forced= to employ the second one because it is not possible to send a SH. For inst= ance, consider the case where the server has been reconfigured and no longe= r accepts the DH group that the client employs in the CH. In that case, it = will have to send HRR.

<= div>SH and HRR are simply used in their usual ways: Thanks for the clarific= ation.
=C2=A0
And why does the for= mer rely on deprotecting, when checking record content types is surely more= efficient?

Unfortunately,= the record types are encrypted, and this will not work.
<= /div>

(I meant the ex= ternal content type. But, that doesn't work anyhow.)

I have now understo= od:

When not consuming early data, = respond with SH or HRR. For the former, given that all messages will be enc= rypted, the server must decrypt messages with the handshake traffic key, di= scard messages when decryption fails, and treat the first successfully decr= ypted message as the client's next handshake message, thereafter procee= ding as if no early data were sent. For the latter, the second CH message w= ill be unencrypted and the server can discard all encrypted messages (ident= ified by record type 0x23, rather than 0x22), before proceeding as if no ea= rly data were sent when the second CH is identified.


Thanks for your sup= port,

Ben
--000000000000db5ae405a47eef32-- From nobody Thu Apr 30 03:21:00 2020 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 5DE783A07F9 for ; Thu, 30 Apr 2020 03:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 fbXDSoFVqaGe for ; Thu, 30 Apr 2020 03:20:55 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 322E13A080E for ; Thu, 30 Apr 2020 03:20:55 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C74D1F4073A; Thu, 30 Apr 2020 03:20:38 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200430102038.C74D1F4073A@rfc-editor.org> Date: Thu, 30 Apr 2020 03:20:38 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC8446 (6151) 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: Thu, 30 Apr 2020 10:20:58 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6151 -------------------------------------- Type: Technical Reported by: Ben Smyth Section: 4.4 Original Text ------------- | Post- | ClientHello ... client | client_application_traffic_ | | Handshake | Finished + | secret_N | | | CertificateRequest | | Corrected Text -------------- | Post- | ClientHello ... client | [sender]_application_traffic| | Handshake | Finished + | _secret_N | | | CertificateRequest | | Notes ----- Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Thu Apr 30 06:04:17 2020 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 65FE33A0909 for ; Thu, 30 Apr 2020 06:04:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 rRv5OF5wEbxH for ; Thu, 30 Apr 2020 06:04:13 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8863A0908 for ; Thu, 30 Apr 2020 06:04:13 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id u10so1135002lfo.8 for ; Thu, 30 Apr 2020 06:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eYpaDyxkUZSCWZnoRloD3TUa+/M76on7xMrym2Tsnr4=; b=xleC95TozfJYI+gaCnaSnV9HEU5TtG/Ig3MXfUljWbA+ywe3Ldjsp4sa3EDeqFQAUe qd0g3go6Kb42h5OPvOFUm9XaWG+A+Q+CYL9ELUAyeo0z8vFQdk2KVL439Twa5Xf/ap5i FHBHgxANctUG2A+1/89PF0EGn6ztQi3jsYA0Pm0EULMJtzoNXaEX033KN9WM6/ZC2lw8 8dEs31P10rHxyzq4LK6N5Abyp8sXF77r4/LPZRiP1tJNE1Ke3iIaPflt6AcEY/AKbP8n 5/GEHen12sPGOrKDJN2ASa9ZNR4PJ9APFXzUo773Ct8PsYUv9qtfQdzue406BHG65776 GRGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eYpaDyxkUZSCWZnoRloD3TUa+/M76on7xMrym2Tsnr4=; b=a/HfLm7zue9+/nYy6FfslwjJ4JkBY36x8UlhZSdfRTwOqibwiK5545ghlB/tjfZzh8 87EC/p5VVJ+OenwLvRsCmtr/IBbz2CpIyJ0HB3zKkWue9mbwQ+EAkpqYJ6joJqMIwjT4 PxkS4jEjKZqDivmkhRFwCXsKjJGInXLhEAQKihh7ZVwJXa7fSUkgMNwNUWG4v8mhOf3V mmkmjJMh3vHwktyPhAF7P66gprwckAc9rsmZyIktgn5l6owd0FPd+t/KAAvfw4pFRoWB QsjF1LpOIYdEDcLqd45OTOp1vzLiKoSb+PL8KLbDgJWlcsxNzNZ4pPoakN+9U46IPyZ5 aogw== X-Gm-Message-State: AGi0PuYESlF8AQk/aH15BKaoqGk1JIsjX2+zdiy4zquiisAuz3TjzH1o EeQDgkcCNP/b8stk+YHt5arU2sU6bhLwaJdlEwcjug== X-Google-Smtp-Source: APiQypK0KUuPP4n2O97C2JpUtINnZ3o82+HZTeqyLKnfpJ/hTXmRb5ZUV6AEfABunwx7jlywcLRwDHwgtLU+BkK8eZk= X-Received: by 2002:a19:3850:: with SMTP id d16mr2076020lfj.161.1588251851526; Thu, 30 Apr 2020 06:04:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Thu, 30 Apr 2020 06:03:35 -0700 Message-ID: To: research@bensmyth.com Cc: "" Content-Type: multipart/alternative; boundary="0000000000006cd71e05a481b360" Archived-At: Subject: Re: [TLS] RFC 8446: Correlating connections with ticket ages 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: Thu, 30 Apr 2020 13:04:16 -0000 --0000000000006cd71e05a481b360 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 30, 2020 at 2:40 AM Ben Smyth wrote: > Section 4.2.11.1 explains that: > > ...PskIdentity contains an obfuscated version of the ticket age formed by > taking the age in milliseconds and adding the "ticket_age_add"... This > addition prevents passive observers from correlating connections unless > tickets are reused. > > So: Correlations are possible when tickets are reused. But, what > connection correlations are prevented when tickets aren't reused? > If ticket X is issued at time T and then reused at time T+delta, it prevents the attacker from learning delta and hence from learning T. -Ekr > > Best regards, > > Ben > -- > TLS 1.3 tutorial: https://bensmyth.com/publications/2019-TLS-tutorial/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000006cd71e05a481b360 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 30, 2020 at 2:40 AM Ben S= myth <research@bensmyth.com= > wrote:
Section 4.2.11.1 explains that:

...PskIdentit= y contains an obfuscated version of the ticket age formed by taking the age= in milliseconds and adding the "ticket_age_add"... This addition= prevents passive observers from correlating connections unless tickets are= reused.

So: Correlations are possible when tickets are= reused. But, what connection correlations are prevented when tickets aren&= #39;t reused?

If ticket X is iss= ued at time T and then reused at time T+delta, it prevents the attacker fro= m learning delta and hence from learning T.

-Ekr



Best regards,

Ben=

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000006cd71e05a481b360-- From nobody Thu Apr 30 06:05:29 2020 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 AF22C3A091D for ; Thu, 30 Apr 2020 06:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com 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 D1cmi-p0JCO4 for ; Thu, 30 Apr 2020 06:05:24 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756703A0936 for ; Thu, 30 Apr 2020 06:05:24 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id f11so6431130ljp.1 for ; Thu, 30 Apr 2020 06:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xqgh8cuYjZ+z5gqcAKSa9icp5BgjMhiR4ORAs6cR66o=; b=11ed5jskiNxCmCeqeaTva4KhVsdggWXMLc1RMWkMXtAPgYxetnuYFG0GkevMdTABbV 6BLHQE+ivYby10mMxlo8fn4241nbW4Pcro5ZINSpsnrGoYrEUjLwmVFqiSY3aJCVJgO6 1RcoLNiExy6e3uFeh/U4fN6oBK0ZMT2wPCjSUAEnQEcXXoe4/XiGwIycqMs1frDMM6yP +gYWrjcO6GdKDv6DXOzOjXuTcWGnzpwo6X4foH7hnUhGllDL6FZ+OzY4b2d3vSvCE3cM Ztu3jUxRIz3fJmxoXjWEoeugGUnbAt75NKMNOaaHk1eZ/rgHu80qhjqO2MQcBwYjwBxz x9ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xqgh8cuYjZ+z5gqcAKSa9icp5BgjMhiR4ORAs6cR66o=; b=jBoQ2DPi3YCevoNEqLp+qgocO3MEpmzVq2sOLWFA60lIxp9o9dtGnec68lbbyDRYre WCowOJsDXC/Z4xwFIDruBEUXeRIoHBNbhTBwI/ee0CyCRXqjENMZievmkog23nvtgjjO 11QExxhlFHdMHmx7GBSeavdUHB0j5R2e0GX6CImkQcY6B6FGoUUkU1IdSizZq5fXV1Lr VOPloOqchhRPfFp1aR7aWUrvXn/Ggej9VdC+09i4cJvveFsYOdc0xG2nwN2qITCjvifW qun0HRLlodthfeLseG+JzkpT1yJtOPGZWWZxxMeuQnoewtofa0ny0mEJreYqZypeTc12 Q9vQ== X-Gm-Message-State: AGi0Pua5Qf1STFXbimPAvG/1iIq8uL4bqlgDk39ZtXm5wKmNP+avmRkG ioSy3tmphsTjEUsyye6wWhRq+zxQLtWE6MVFoBjg3PWow28= X-Google-Smtp-Source: APiQypIyyDWR5YyxhqF6Hxbirn+xsAQuzXhLtWZJP29iiTvhJllDqrRgDQWt8il9VmKPYHnDJbVBODtR4tpsI2EDzI0= X-Received: by 2002:a2e:2414:: with SMTP id k20mr2145541ljk.162.1588251922520; Thu, 30 Apr 2020 06:05:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Thu, 30 Apr 2020 06:04:45 -0700 Message-ID: To: research@bensmyth.com Cc: "" Content-Type: multipart/alternative; boundary="000000000000a7e81805a481b72e" Archived-At: Subject: Re: [TLS] RFC 8446 Early data, server response: deprotect vs. type checking 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: Thu, 30 Apr 2020 13:05:27 -0000 --000000000000a7e81805a481b72e Content-Type: text/plain; charset="UTF-8" On Thu, Apr 30, 2020 at 2:46 AM Ben Smyth wrote: > Section 4.2.10 requires a server receiving early data to behave in ways >>> including (p53): >>> >>> * Ignore the extension and return a regular 1-RTT response. The server >>> then skips past early data by attempting to deprotect received records >>> using the handshake traffic key, discarding records which fail >>> deprotection... >>> >>> * Request that the client send another ClientHello by responding with a >>> HelloRetryRequest... The server then ignores early data by skipping all >>> records with an external content type of "application_data"... >>> >>> What are the use cases for each behaviour? >>> >> > I expect that the first response will be the ordinary one. However, in >> some cases you will be forced to employ the second one because it is not >> possible to send a SH. For instance, consider the case where the server has >> been reconfigured and no longer accepts the DH group that the client >> employs in the CH. In that case, it will have to send HRR. >> > > SH and HRR are simply used in their usual ways: Thanks for the > clarification. > > >> And why does the former rely on deprotecting, when checking record >>> content types is surely more efficient? >>> >> >> Unfortunately, the record types are encrypted, and this will not work. >> > > (I meant the external content type. But, that doesn't work anyhow.) > > I have now understood: > > When not consuming early data, respond with SH or HRR. For the former, > given that all messages will be encrypted, the server must decrypt messages > with the handshake traffic key, discard messages when decryption fails, and > treat the first successfully decrypted message as the client's next > handshake message, thereafter proceeding as if no early data were sent. For > the latter, the second CH message will be unencrypted and the server can > discard all encrypted messages (identified by record type 0x23, rather than > 0x22), before proceeding as if no early data were sent when the second CH > is identified. > Yes. -Ekr > Thanks for your support, > > Ben > --000000000000a7e81805a481b72e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Apr 30, 2020 at 2:46 AM Ben S= myth <research@bensmyth.com= > wrote:
Section 4.2.10= requires a server receiving early data to behave in ways including (p53):<= br>
* Ignore the extension and return a regular 1-RTT response.=C2=A0 Th= e server then skips past early data by attempting to deprotect received rec= ords using the handshake traffic key, discarding records which fail deprote= ction...

* Request that the client send another Cl= ientHello by responding with a HelloRetryRequest... The server then ignores= early data by skipping all records with an external content type of "= application_data"...

What are the use cases f= or each behaviour?
=

I expect that the first respo= nse will be the ordinary one. However, in some cases you will be forced to = employ the second one because it is not possible to send a SH. For instance= , consider the case where the server has been reconfigured and no longer ac= cepts the DH group that the client employs in the CH. In that case, it will= have to send HRR.

= SH and HRR are simply used in their usual ways: Thanks for the clarificatio= n.
=C2=A0
And why does the former r= ely on deprotecting, when checking record content types is surely more effi= cient?

Unfortunately, the = record types are encrypted, and this will not work.
=

(I meant the externa= l content type. But, that doesn't work anyhow.)

I have now understood:
When not consuming early data, respo= nd with SH or HRR. For the former, given that all messages will be encrypte= d, the server must decrypt messages with the handshake traffic key, discard= messages when decryption fails, and treat the first successfully decrypted= message as the client's next handshake message, thereafter proceeding = as if no early data were sent. For the latter, the second CH message will b= e unencrypted and the server can discard all encrypted messages (identified= by record type 0x23, rather than 0x22), before proceeding as if no early d= ata were sent when the second CH is identified.

Yes.

-Ekr


Thanks for your s= upport,

Ben
--000000000000a7e81805a481b72e-- From nobody Thu Apr 30 21:51:37 2020 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 7B4553A003D for ; Thu, 30 Apr 2020 21:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=TXjnTbTu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uzCSp4Ug 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 SaEPtrbwg18I for ; Thu, 30 Apr 2020 21:51:32 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1506B3A003C for ; Thu, 30 Apr 2020 21:51:32 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 00D5B5C02DE for ; Fri, 1 May 2020 00:51:31 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Fri, 01 May 2020 00:51:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:date:from:to:subject:content-type :content-transfer-encoding; s=fm2; bh=1WO/NRhm1cdH0Quj/D7PtTtsog VNaJi2As9JAgD/giI=; b=TXjnTbTu+giBT+wmbqD77Wj56OYnj0SMGHUU/AeI1f jV1JuXJG0G/6FjiQ8gtOOTd3Jf2H7onYaaW7fLakmVFTE7js6MTEgZJMh2DC65VO ZeEq+/siTbw+RZEyUnaUl3qeHTzLY0yC/0hs4dJO+LluvwGVhvGhCdAIOokEe+3h /Kc5q1g4sz2DdOeJ21n7raTTs4t30MAAjqMxMjZyaufcIOzEvZdoQkRC8rUGchO2 vpcvc2YPjkeBUESTddHQqhYQVlQYnGH4wgKuxH+hG+irDwALujMbA2myHesTfrct q6+wQRT3Bc874Q/Xtt0L7ZPMXEsG+YQwboiFKEY429Qg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=1WO/NR hm1cdH0Quj/D7PtTtsogVNaJi2As9JAgD/giI=; b=uzCSp4UgQAZIIdP/lfNl1S B4dakcNqESOWT95fKajcRxjOK6+ujCpyjTVA3ohdrl4t5XlbA6F4/z+PEIXBsLsO MzeCeHxvWKffRZ/zKIlZg9Gphse9zvLxff57GKf8DsT8UY2SwrEX7rINkt4WfhPF aTk+LcLerzkP9UAo+pCCvOI2nahrfNOErizdu51Vs4GEZnaFGv4Ir5iA7YtmlG4N DhTsUK4RJmqXlvtsxoXsLBLym6PzJ3iB7/gG7vOof7qrciTGrrJ6MI8fp4mUBnh0 OPaC7OJm7YXvruXbUTw2haj2lvpoYBlkLQrIkn1yi1NnCMOdpep8vFNmGwofmS8Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrieeigdekhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgfgsehtqhertd erreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigv nhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefggfetfefgvedvhefhhfehhe ehfeekveehgeduveehjeevteeggfevheelhffgjeenucffohhmrghinhepghhithhhuhgs rdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 878B8E00A9; Fri, 1 May 2020 00:51:30 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: <0a9e740f-c20a-4def-9a61-d256cbcbf07c@www.fastmail.com> Date: Fri, 01 May 2020 14:51:11 +1000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] Integrity bounds in DTLS 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, 01 May 2020 04:51:35 -0000 Thanks to some good work from Felix G=C3=BCnther, Marc Fischlin, Christi= an Janson, and Kenny Paterson we now have a new result to share about th= e integrity limits in QUIC. There is a long write-up in https://github.com/quicwg/base-drafts/issues= /3619, the conclusion of which is that endpoints need to count the numbe= r of failed decryptions and stop using keys once a certain limit is reac= hed. Key updates can be used to avoid this. The same concern applies to DTLS. I believe that the same solution - or= at least a similar solution - is therefore necessary for DTLS. I know that we're past WGLC, but this is an important result regarding a= key distinction between TLS and DTLS. From nobody Thu Apr 30 22:33:41 2020 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 879AB3A080B for ; Thu, 30 Apr 2020 22:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1LFGy0gWpf6a for ; Thu, 30 Apr 2020 22:33:36 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F643A07F9 for ; Thu, 30 Apr 2020 22:33:36 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 91992F40750; Thu, 30 Apr 2020 22:33:18 -0700 (PDT) To: ekr@rtfm.com, rdd@cert.org, kaduk@mit.edu, caw@heapingbits.net, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: research@bensmyth.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200501053318.91992F40750@rfc-editor.org> Date: Thu, 30 Apr 2020 22:33:18 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC8446 (6152) 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, 01 May 2020 05:33:38 -0000 The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6152 -------------------------------------- Type: Technical Reported by: Ben Smyth Section: 4 Original Text ------------- Clients MUST check for ["supported_versions"] prior to processing the rest of the ServerHello (although they will have to parse the ServerHello in order to read the extension). -- Section 4.2.1. Upon receipt of a HelloRetryRequest, the client MUST check the legacy_version, legacy_session_id_echo, cipher_suite, and legacy_compression_method as specified in Section 4.1.3 and then process the extensions, starting with determining the version using "supported_versions". -- Section 4.1.4 Upon receiving a message with type server_hello, implementations MUST first examine the Random value... -- Section 4.1.3. Corrected Text -------------- Notes ----- These requirements are seemingly conflicting. I suspect checking for "supported_versions" must come first, since that may influence subsequent steps, e.g., checking legacy_compression_method and the Random value. It doesn't seem to matter whether legacy_version, legacy_session_id_echo, cipher_suite, and legacy_compression_method are checked before the Random value, so it doesn't seem to matter which check is second and which is third. (Noting, as per one of my earlier reports, dated 28 Apr, Section 4.1.3 defines no checks for legacy_version nor legacy_compression_method. Perhaps the latter should be checked to be zero, aborting with alert illegal_parameter if it isn't, as per Section 4.1.2.) Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8446 (draft-ietf-tls-tls13-28) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.3 Publication Date : August 2018 Author(s) : E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG