From nobody Wed Jul 1 08:09: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 C33353A0F21 for ; Wed, 1 Jul 2020 08:09: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, 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=dEVXRPd3; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=dEVXRPd3 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 1c5FL9b5LDe1 for ; Wed, 1 Jul 2020 08:09:36 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60061.outbound.protection.outlook.com [40.107.6.61]) (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 920B03A0F20 for ; Wed, 1 Jul 2020 08:09: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=zKXXx7GmEASEPeQeLu480jzls/75qi0p9j8wvdcImsE=; b=dEVXRPd3BS+Pb/+I1xqXXhpct47TUKkFXwl8rYhPpR5EUiqsuDfON/kr3hIHtjq4DVfO76g9pzPdQeC8FZvFBsjgTDzflvVZvqmZt4x2zkXBSprngX/XrZHPKfH9DtzEoDqwsWlwv2eEfDbLh3gerqdKSk7O8Rjq722MlFmSctQ= Received: from MR2P264CA0036.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500::24) by DB6PR0801MB1847.eurprd08.prod.outlook.com (2603:10a6:4:3c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.23; Wed, 1 Jul 2020 15:09:33 +0000 Received: from VE1EUR03FT043.eop-EUR03.prod.protection.outlook.com (2603:10a6:500:0:cafe::67) by MR2P264CA0036.outlook.office365.com (2603:10a6:500::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.22 via Frontend Transport; Wed, 1 Jul 2020 15:09:32 +0000 X-MS-Exchange-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 VE1EUR03FT043.mail.protection.outlook.com (10.152.19.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Wed, 1 Jul 2020 15:09:32 +0000 Received: ("Tessian outbound e44de778b77e:v62"); Wed, 01 Jul 2020 15:09:32 +0000 X-CR-MTA-TID: 64aa7808 Received: from dbd5a4c138ff.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 61021E9B-A7EA-452B-B092-21A4D0FAF49F.1; Wed, 01 Jul 2020 15:09:27 +0000 Received: from EUR03-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id dbd5a4c138ff.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 01 Jul 2020 15:09:27 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f3bBxwj/jfIgg7xf/PdACAA7lqNh53rMOI4EFhw7KS0eib0f1zcoP+6+1LBspp5twXw+q1FbpCdXXRmdF3cVrVsZoffTBPGavDC69wczilsApl9OstdC6K1tDWHJWtVzgKUmfCp3Dss36gfhP/iPTrzBm/B9T3iEYYzthzyHL0BxjnI/aqQezC3w7M2ww3dpa87YwyuYBwMXtyRyGp3eQ5Lr/yfTBACHdSpJPnvQbNhfwvydGCOWpscfHHETJtc9yg2GZHj/L1oeRuo0EHnU3fhJv1FOkJL3VTz8P1pxSH422GSi0sxh3emWWdwsLywpqFh7f7QWqKVvcsqLpY6QRw== 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=zKXXx7GmEASEPeQeLu480jzls/75qi0p9j8wvdcImsE=; b=jrCgGpNmXqifJuEfpwnec/d4nZHg5na+8E1ZbRkfKjkV4lXYoVgwxyM6VcYyN+U1OvdqYiE9ewc/jfYwK40T4SWdhXTOq4DM+OpdG5v8gFaAkH8y7HHUSSuZGb0HceVJXw+9PFnIH33Ucdlfd5LdttZwNfajqDZMVpd9y86+Q46RRV9e437WUuJnDSK/kkF+ElwYBXO4R0elAyGFatfo/y1KLpCH6yBP87jx/ceKMCGePe3VEdMt2N5b5ntGu07K4oPERSp4wMJthpYSWKzU16K1RXN14QrFZvE7znEtk80B4HIieMyBORCT8cXxvmhPawW/1MUlKenOvagZHv6b8A== 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=zKXXx7GmEASEPeQeLu480jzls/75qi0p9j8wvdcImsE=; b=dEVXRPd3BS+Pb/+I1xqXXhpct47TUKkFXwl8rYhPpR5EUiqsuDfON/kr3hIHtjq4DVfO76g9pzPdQeC8FZvFBsjgTDzflvVZvqmZt4x2zkXBSprngX/XrZHPKfH9DtzEoDqwsWlwv2eEfDbLh3gerqdKSk7O8Rjq722MlFmSctQ= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB5524.eurprd08.prod.outlook.com (2603:10a6:208:181::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.22; Wed, 1 Jul 2020 15:09:25 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3131.030; Wed, 1 Jul 2020 15:09:25 +0000 From: Hannes Tschofenig To: Joseph Salowey , "" Thread-Topic: [TLS] 2nd WGLC for Delegated Credentials for TLS Thread-Index: AQHWTi5icKe0L+OVmUmqcb3z5zqCaajy1BWw Date: Wed, 1 Jul 2020 15:09:25 +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: 121e881d-9fd7-4087-8a4a-7a594f0b8858.1 x-checkrecipientchecked: true Authentication-Results-Original: salowey.net; dkim=none (message not signed) header.d=none;salowey.net; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.121.249] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 034a417e-642e-4e5a-fa7e-08d81dd0c271 x-ms-traffictypediagnostic: AM0PR08MB5524:|DB6PR0801MB1847: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 04519BA941 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: v7Ob7ftJtl6k5JtZQhgx2g4dCeGusgeqRr3ULR7oJQCAyKy61E244yOWvDsshRjd/y54KKOkmJR4QxasBWoJWzboOqTsH/tZVe+mc4tkm/QQCAxZyuGJJCPUVH4xK5K8R/BxWalzb1t5S16fz836wOl16so4s2z8TFmrVoDLwbBK5G3hk9cLzKJq60WX6zV06pAOFL39W2I8bSEKFifrvA5NX4f0dR/aRDh/Yh2bu0QLsKo2RfSuRG8iScz0cdNQxglyeGU6yu7+NrhJR6UDGPYRJjKhJiw6knEPAr91mfvFfqBUN0W+biJh6jE/yKK4w1Wn2nskuqLANG43r+GBjyBGndBHRq7JSHnH0Gi5VbatFJAsJyo9Bvgypaxhw8bX3+NtpxwWmKd/CSqMGRGrBywk0oRv2A6oLt1OWoJjCCYxEKDjMvyKH8GK8rwMFoEc 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)(366004)(346002)(39860400002)(376002)(136003)(396003)(8676002)(26005)(53546011)(86362001)(33656002)(5660300002)(2906002)(71200400001)(166002)(83380400001)(186003)(8936002)(64756008)(66556008)(66476007)(52536014)(9686003)(55016002)(316002)(110136005)(478600001)(6506007)(966005)(66446008)(66946007)(76116006)(7696005)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: y9hRR/fJ85vjXpAw1r8S2tSRrQ7ehd6gUqXBOuOB7V+e3+q/HuF+VuAZKsj+WOpNxW3f5kjmRkQWl4jltvoa5+JAwOy912FcL3z39EQWb4FgIAiTJSjsqQ3nBjEWmC2IO4Yy0QWs843tWOvU/qDlo6tuQ9ulYbJgyPT3elKcDsvxM7xQNkeZmquCQmBHCU77PW4LCgv+f1A3yefobeBH1aqyZ+MoFSwN9C7l29UZ+6b0Yfdee5VGdLb1rCxm/GFRxx3c5Du1dkPZ+AHBrNgWq5v7HOlyg783n1QYfWRPBahltLSlLOAryex9YBxPZoaKjuLnbpx6glMKnK26+gmiVRwKnwlIX9fzEpTcYHQgX4zgRUj4k8Qx5iOQoZtaf8VY83YufJUcESD/1AaUB2oKYmW3M5sssGf+O8cjAkjtP347SOypkX4CmjK/OOLMnbAaZdu7ILl5SPIBbYMsq7MPByyQQXhKz/MDH1zoODgXt5Qxh9xYAUEQ8ZY5n4ccXjWj x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB37162AD05CC8FFA2325218D1FA6C0AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB5524 Original-Authentication-Results: salowey.net; dkim=none (message not signed) header.d=none;salowey.net; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT043.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)(39860400002)(136003)(376002)(396003)(346002)(46966005)(70586007)(52536014)(110136005)(5660300002)(966005)(8936002)(6506007)(53546011)(336012)(33964004)(55016002)(26005)(8676002)(2906002)(33656002)(70206006)(186003)(478600001)(9686003)(7696005)(47076004)(86362001)(81166007)(83380400001)(356005)(82310400002)(36906005)(82740400003)(166002)(316002)(491001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: caf2e0c4-e886-4475-bec2-08d81dd0be82 X-Forefront-PRVS: 04519BA941 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YxYQqnyS46TqcwhXF23INY9UuFkzF5fhYaFjSGZRG9rmP4aEmQHRFSp3+wBOFjYPJE7dTaYa/sPoVxnrudOgGhWuu9OdICbEVGJUkrbcJO7XDwaZRiI7ah7hSGUMBDKFWoumBMviXIALEXygVVRLgjaY1jYMd95odTlqpaZ3wMgiyG4PCkYOuPfMBrb+GDfLnmOkPaLsL5YF2jlg0r3Bcn1jgzL66xotiScrLXcKg92kQlx6cHtrZojSGzqXjejeZz8aj8rQDcz19biDvUmrsS8fMhDZMcy4T9Y2nZTssvBZTXPXvAExblpK6USX+fQYL77Q/MkrNrSTLHyE/tSr735447k6WsLHmoXHBUHHmn1joQSW0NjfLfijU41EAu37ziOXHFlI6QwVRB7ofzGqRvBaC7fQRI/meqGUcDOHgAa8j8Xk9Y+Boky+Gt+cbb3jZvDlZQK+2aTRmb+KOqHqBD+ENd3CG19R1hlyhXKKTpgIyuc2xHaXgTWEGIydO3A1 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2020 15:09:32.4128 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 034a417e-642e-4e5a-fa7e-08d81dd0c271 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-AuthSource: VE1EUR03FT043.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0801MB1847 Archived-At: Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS 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, 01 Jul 2020 15:09:39 -0000 --_000_AM0PR08MB37162AD05CC8FFA2325218D1FA6C0AM0PR08MB3716eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9lLCBIaSBkcmFmdCBhdXRob3JzLA0KDQpJIHJldmlld2VkIGRyYWZ0LWlldGYtdGxzLXN1 YmNlcnRzLTA5IGFuZCB0aGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuIGFuZCBlYXN5IHRvIHVu ZGVyc3RhbmQuDQoNCkkgaGF2ZSBvbmx5IGEgbWlub3IgcmVtYXJrIHJlZ2FyZGluZyB0aGUgdmFs aWRpdHkgdGltZSBvZiB0aGUgZGVsZWdhdGVkIGNyZWRlbnRpYWwuDQoNCkluIFNlY3Rpb24gMyB5 b3Ugc2F5DQoiDQogICBJbg0KICAgdGhlIGFic2VuY2Ugb2YgYW4gYXBwbGljYXRpb24gcHJvZmls ZSBzdGFuZGFyZCBzcGVjaWZ5aW5nIG90aGVyd2lzZSwNCiAgIHRoZSBtYXhpbXVtIHZhbGlkaXR5 IHBlcmlvZCBpcyBzZXQgdG8gNyBkYXlzLiAgUGVlcnMgTVVTVCBOT1QgaXNzdWUNCiAgIGNyZWRl bnRpYWxzIHdpdGggYSB2YWxpZGl0eSBwZXJpb2QgbG9uZ2VyIHRoYW4gdGhlIG1heGltdW0gdmFs aWRpdHkNCiAgIHBlcmlvZC4NCiINCg0KSW4gU2VjdGlvbiA0IHlvdSBzYXkgdGhlIGZvbGxvd2lu ZyBhYm91dCB0aGUgdmFsaWRpdHkgdGltZS4gIlRoaXMgTVVTVCBOT1QgZXhjZWVkIDcgZGF5cy4i DQoNCkkgd29uZGVyIHdoZXRoZXIgaXQgbWFrZXMgc2Vuc2UgdG8ganVzdCBjb3B5IHRoZSB0ZXh0 IGZyb20gU2VjdGlvbiAzIHRvIFNlY3Rpb24gNCBoYXZlIGl0IHJlYWQgdGhlIHNhbWUgd2F5Lg0K SGF2aW5nIHRoZSBmbGV4aWJpbGl0eSB0byBleHRlbmQgdGhpcyBtYXhpbXVtIHZhbGlkaXR5IHRp bWUgdmlhIHByb2ZpbGVzIG1heSB0dXJuIG91dCB0byBiZSB1c2VmdWwsIGFzIFNlY3Rpb24gMyBh bHJlYWR5IHN0YXRlcy4NCg0KVGhlIHVzZSBvZiBhIG5ldyBYLjUwOSBleHRlbnNpb24gaXMgdW5m b3J0dW5hdGUgYmVjYXVzZSB0b29scyB1c2VkIGZvciBjcmVhdGluZyBjZXJ0aWZpY2F0ZXMgYXJl IHNvbWV3aGF0IGJlaGluZCBzdXBwb3J0aW5nIHZhcmlvdXMgZXh0ZW5zaW9ucy4NCldlIHJhbiBp bnRvIHRoaXMgaXNzdWUgZm9yIHVzZSB3aXRoIGRldmljZSBjZXJ0aWZpY2F0ZXMgaW4gSW9UIGRl cGxveW1lbnRzLg0KDQpJIGd1ZXNzIHRoZXJlIGlzIG5vdGhpbmcgdG8gZG8gYWJvdXQgdGhpcyBv dGhlciB0aGFuIHRyeWluZyB0byBhZGQgc3VwcG9ydCBvZiB0aGlzIGV4dGVuc2lvbiBpbiBwb3B1 bGFyIHRvb2xzLg0KQW55IHBsYW5zIHRvIGFkZCBzdXBwb3J0IGZvciB0aGlzIGV4dGVuc2lvbiB0 byB0aGUgT3BlblNTTCBjb21tYW5kIGxpbmUgdG9vbCB0byBjcmVhdGUgY2VydGlmaWNhdGVzPw0K DQpDaWFvDQpIYW5uZXMNCg0KRnJvbTogVExTIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIEpvc2VwaCBTYWxvd2V5DQpTZW50OiBNb25kYXksIEp1bmUgMjksIDIwMjAgNTo1OSBQ TQ0KVG86IDx0bHNAaWV0Zi5vcmc+IDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbVExTXSAybmQg V0dMQyBmb3IgRGVsZWdhdGVkIENyZWRlbnRpYWxzIGZvciBUTFMNCg0KVGhpcyBpcyB0aGUgc2Vj b25kIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciBEZWxlZ2F0ZWQgQ3JlZGVudGlhbHMgZm9y IFRMUy4gIFRoZSBsYXRlc3QgZHJhZnQgY2FuIGJlIGZvdW5kIGhlcmU6IGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRscy1zdWJjZXJ0cy0wOS4gIFRoZXJlIGhhdmUgYmVl biAyIHJldmlzaW9ucyBzaW5jZSB0aGUgbGFzdCByZXZpZXcuICBEcmFmdCA4IGNvbnRhaW5zIGNo YW5nZXMgdGhhdCB3ZXJlIG5vdCBjb21taXR0ZWQgaW4gdGltZSBmb3IgZHJhZnQgNyBhbmQgZHJh ZnQgOSBjb250YWlucyByZXZpc2lvbnMgZnJvbSB0aGUgcHJldmlvdXMgV0dMQy4gIExpbmtzIHRv IHRoZSBEaWZmcyBiZXR3ZWVuIHRoZSBkcmFmdCA5IGFuZCBkcmFmdCA3IGNhbiBiZSBmb3VuZCBh dCB0aGUgZW5kIG9mIHRoaXMgbWVzc2FnZS4gICBQbGVhc2UgZm9jdXMgeW91ciByZXZpZXcgb24g dGhlIGNoYW5nZXMgYmV0d2VlbiBkcmFmdCA3IGFuZCBkcmFmdCA5LiAgUGxlYXNlIHNlbmQgeW91 ciBjb21tZW50cyB0byB0aGUgbGlzdCBieSBKdWx5IDEzLCAyMDIwLg0KDQpUaGFua3MsDQoNClNl YW4gYW5kIEpvZQ0KDQpbSW5saW5lIERpZmZdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlm Zj9kaWZmdHlwZT0tLWh3ZGlmZiZ1cmwyPWRyYWZ0LWlldGYtdGxzLXN1YmNlcnRzLTA5LnR4dCZ1 cmwxPWRyYWZ0LWlldGYtdGxzLXN1YmNlcnRzLTA3LnR4dA0KW1NpZGUtYnktc2lkZSBEaWZmXSBo dHRwczovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXRscy1zdWJjZXJ0 cy0wOS50eHQmdXJsMT1kcmFmdC1pZXRmLXRscy1zdWJjZXJ0cy0wNy50eHQNCg0KSU1QT1JUQU5U IE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBh cmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRp YXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNv biwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRp b24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K --_000_AM0PR08MB37162AD05CC8FFA2325218D1FA6C0AM0PR08MB3716eurp_ 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+SGkgSm9lLCBIaSBkcmFmdCBhdXRob3JzLCA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSByZXZpZXdlZCBkcmFmdC1pZXRmLXRscy1zdWJjZXJ0cy0wOSBhbmQg dGhlIGRvY3VtZW50IGlzIHdlbGwgd3JpdHRlbiBhbmQgZWFzeSB0byB1bmRlcnN0YW5kLg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBvbmx5IGEgbWlub3IgcmVtYXJrIHJlZ2FyZGlu ZyB0aGUgdmFsaWRpdHkgdGltZSBvZiB0aGUgZGVsZWdhdGVkIGNyZWRlbnRpYWwuDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SW4gU2VjdGlvbiAzIHlvdSBzYXkgPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyZuYnNwOyBJbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7Jm5ic3A7IHRoZSBhYnNlbmNlIG9mIGFuIGFwcGxpY2F0aW9uIHByb2ZpbGUgc3Rh bmRhcmQgc3BlY2lmeWluZyBvdGhlcndpc2UsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDsgdGhlIG1heGltdW0gdmFsaWRpdHkgcGVyaW9kIGlzIHNldCB0 byA3IGRheXMuJm5ic3A7IFBlZXJzIE1VU1QgTk9UIGlzc3VlPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgY3JlZGVudGlhbHMgd2l0aCBhIHZhbGlkaXR5 IHBlcmlvZCBsb25nZXIgdGhhbiB0aGUgbWF4aW11bSB2YWxpZGl0eTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IHBlcmlvZC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBT ZWN0aW9uIDQgeW91IHNheSB0aGUgZm9sbG93aW5nIGFib3V0IHRoZSB2YWxpZGl0eSB0aW1lLiAm cXVvdDtUaGlzIE1VU1QgTk9UIGV4Y2VlZCA3IGRheXMuJnF1b3Q7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgd29uZGVyIHdoZXRoZXIgaXQgbWFrZXMgc2Vuc2UgdG8ganVzdCBjb3B5IHRoZSB0 ZXh0IGZyb20gU2VjdGlvbiAzIHRvIFNlY3Rpb24gNCBoYXZlIGl0IHJlYWQgdGhlIHNhbWUgd2F5 Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYXZpbmcgdGhlIGZsZXhp YmlsaXR5IHRvIGV4dGVuZCB0aGlzIG1heGltdW0gdmFsaWRpdHkgdGltZSB2aWEgcHJvZmlsZXMg bWF5IHR1cm4gb3V0IHRvIGJlIHVzZWZ1bCwgYXMgU2VjdGlvbiAzIGFscmVhZHkgc3RhdGVzLg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB1c2Ugb2YgYSBuZXcgWC41MDkgZXh0ZW5zaW9u IGlzIHVuZm9ydHVuYXRlIGJlY2F1c2UgdG9vbHMgdXNlZCBmb3IgY3JlYXRpbmcgY2VydGlmaWNh dGVzIGFyZSBzb21ld2hhdCBiZWhpbmQgc3VwcG9ydGluZyB2YXJpb3VzIGV4dGVuc2lvbnMuDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHJhbiBpbnRvIHRoaXMgaXNz dWUgZm9yIHVzZSB3aXRoIGRldmljZSBjZXJ0aWZpY2F0ZXMgaW4gSW9UIGRlcGxveW1lbnRzLg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZ3Vlc3MgdGhlcmUgaXMgbm90aGluZyB0byBkbyBh Ym91dCB0aGlzIG90aGVyIHRoYW4gdHJ5aW5nIHRvIGFkZCBzdXBwb3J0IG9mIHRoaXMgZXh0ZW5z aW9uIGluIHBvcHVsYXIgdG9vbHMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFueSBwbGFucyB0byBhZGQgc3VwcG9ydCBmb3IgdGhpcyBleHRlbnNpb24gdG8gdGhlIE9w ZW5TU0wgY29tbWFuZCBsaW5lIHRvb2wgdG8gY3JlYXRlIGNlcnRpZmljYXRlcz8NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5DaWFvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IYW5uZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IFRMUyAmbHQ7dGxzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJl aGFsZiBPZiA8L2I+DQpKb3NlcGggU2Fsb3dleTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1 bmUgMjksIDIwMjAgNTo1OSBQTTxicj4NCjxiPlRvOjwvYj4gJmx0O3Rsc0BpZXRmLm9yZyZndDsg Jmx0O3Rsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1RMU10gMm5kIFdHTEMg Zm9yIERlbGVnYXRlZCBDcmVkZW50aWFscyBmb3IgVExTPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIHRoZSBzZWNvbmQgd29ya2luZyBncm91cCBs YXN0IGNhbGwgZm9yJm5ic3A7RGVsZWdhdGVkIENyZWRlbnRpYWxzIGZvciBUTFMuJm5ic3A7IFRo ZSBsYXRlc3QgZHJhZnQgY2FuIGJlIGZvdW5kIGhlcmU6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGxzLXN1YmNlcnRzLTA5IiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGxzLXN1YmNlcnRz LTA5PC9hPi4mbmJzcDsNCiBUaGVyZSBoYXZlIGJlZW4gMiByZXZpc2lvbnMgc2luY2UgdGhlIGxh c3QgcmV2aWV3LiZuYnNwOyBEcmFmdCA4IGNvbnRhaW5zIGNoYW5nZXMgdGhhdCB3ZXJlIG5vdCBj b21taXR0ZWQmbmJzcDtpbiB0aW1lIGZvciBkcmFmdCA3IGFuZCBkcmFmdCA5IGNvbnRhaW5zIHJl dmlzaW9ucyBmcm9tIHRoZSBwcmV2aW91cyBXR0xDLiZuYnNwOyBMaW5rcyB0byB0aGUgRGlmZnMg YmV0d2VlbiB0aGUgZHJhZnQgOSBhbmQgZHJhZnQgNyBjYW4gYmUgZm91bmQgYXQgdGhlIGVuZCBv ZiB0aGlzDQogbWVzc2FnZS4mbmJzcDsgJm5ic3A7UGxlYXNlIGZvY3VzIHlvdXIgcmV2aWV3IG9u IHRoZSBjaGFuZ2VzIGJldHdlZW4gZHJhZnQgNyBhbmQgZHJhZnQgOS4mbmJzcDsgUGxlYXNlIHNl bmQgeW91ciBjb21tZW50cyB0byB0aGUgbGlzdCBieSBKdWx5IDEzLCAyMDIwLiZuYnNwOyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNlYW4gYW5kIEpvZTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+W0lubGluZSBEaWZmXSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv cmZjZGlmZj9kaWZmdHlwZT0tLWh3ZGlmZiZhbXA7dXJsMj1kcmFmdC1pZXRmLXRscy1zdWJjZXJ0 cy0wOS50eHQmYW1wO3VybDE9ZHJhZnQtaWV0Zi10bHMtc3ViY2VydHMtMDcudHh0IiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP2RpZmZ0eXBlPS0taHdkaWZm JmFtcDt1cmwyPWRyYWZ0LWlldGYtdGxzLXN1YmNlcnRzLTA5LnR4dCZhbXA7dXJsMT1kcmFmdC1p ZXRmLXRscy1zdWJjZXJ0cy0wNy50eHQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bU2lkZS1ieS1zaWRlIERpZmZdJm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi10bHMtc3ViY2Vy dHMtMDkudHh0JmFtcDt1cmwxPWRyYWZ0LWlldGYtdGxzLXN1YmNlcnRzLTA3LnR4dCIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt dGxzLXN1YmNlcnRzLTA5LnR4dCZhbXA7dXJsMT1kcmFmdC1pZXRmLXRscy1zdWJjZXJ0cy0wNy50 eHQ8L2E+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRo ZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_AM0PR08MB37162AD05CC8FFA2325218D1FA6C0AM0PR08MB3716eurp_-- From nobody Wed Jul 1 08:52: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 D34013A10E1 for ; Wed, 1 Jul 2020 08:52:53 -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, HTML_MESSAGE=0.001, 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 lffRgTSD10nS for ; Wed, 1 Jul 2020 08:52:52 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2ED13A0F85 for ; Wed, 1 Jul 2020 08:52:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 4E009300B71 for ; Wed, 1 Jul 2020 11:52:48 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NDWm-2tboLsF for ; Wed, 1 Jul 2020 11:52:46 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id A21C330009A; Wed, 1 Jul 2020 11:52:46 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_E315E334-B774-4637-8298-6B7489F2FE93" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Wed, 1 Jul 2020 11:52:47 -0400 References: To: Joe Salowey , IETF TLS In-Reply-To: Message-Id: <1C7C439A-D360-47B0-9C51-D884238CBB67@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS 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, 01 Jul 2020 15:52:54 -0000 --Apple-Mail=_E315E334-B774-4637-8298-6B7489F2FE93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This update resolves the comments that I posted on the previous version. = Thanks. Russ =20 From: TLS > On Behalf = Of Joseph Salowey Sent: Monday, June 29, 2020 5:59 PM To: > > Subject: [TLS] 2nd WGLC for Delegated Credentials for TLS =20 This is the second working group last call for Delegated Credentials for = TLS. The latest draft can be found here: = https://tools.ietf.org/html/draft-ietf-tls-subcerts-09 = . There have = been 2 revisions since the last review. Draft 8 contains changes that = were not committed in time for draft 7 and draft 9 contains revisions = from the previous WGLC. Links to the Diffs between the draft 9 and = draft 7 can be found at the end of this message. Please focus your = review on the changes between draft 7 and draft 9. Please send your = comments to the list by July 13, 2020. =20 =20 Thanks, =20 Sean and Joe =20 [Inline Diff] = https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-tls-s= ubcerts-09.txt&url1=3Ddraft-ietf-tls-subcerts-07.txt = [Side-by-side Diff] = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-subcerts-09.txt&url1=3D= draft-ietf-tls-subcerts-07.txt = --Apple-Mail=_E315E334-B774-4637-8298-6B7489F2FE93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

This update resolves the comments = that I posted on the previous version.  Thanks.


Russ

 

From: TLS <tls-bounces@ietf.org> On Behalf = Of Joseph = Salowey
Sent: Monday, June 29, 2020 5:59 = PM
To: <tls@ietf.org> <tls@ietf.org>
Subject: [TLS] 2nd WGLC for = Delegated Credentials for TLS

 

This = is the second working group last call for Delegated Credentials for = TLS.  The latest draft can be found here: https://tools.ietf.org/html/draft-ietf-tls-subcerts-09.&nbs= p; There have been 2 revisions since the last review.  Draft 8 = contains changes that were not committed in time for draft 7 and = draft 9 contains revisions from the previous WGLC.  Links to the = Diffs between the draft 9 and draft 7 can be found at the end of this = message.   Please focus your review on the changes between = draft 7 and draft 9.  Please send your comments to the list by July = 13, 2020.  

 

Thanks,

 

Sean and Joe

 

[Inline Diff] https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Dd= raft-ietf-tls-subcerts-09.txt&url1=3Ddraft-ietf-tls-subcerts-07.txt

[Side-by-side Diff] https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-subcerts-0= 9.txt&url1=3Ddraft-ietf-tls-subcerts-07.txt


= --Apple-Mail=_E315E334-B774-4637-8298-6B7489F2FE93-- From nobody Wed Jul 1 08:55: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 18A013A111D for ; Wed, 1 Jul 2020 08:55:05 -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=IBAOlnYW; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=IBAOlnYW 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 A-hIs4jlH6lR for ; Wed, 1 Jul 2020 08:55:00 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30060.outbound.protection.outlook.com [40.107.3.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 476B63A11E0 for ; Wed, 1 Jul 2020 08:54: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=gLSS6baTpNu7mOgHOxx0N3L8oPtqQWizER6n/Vw+aDk=; b=IBAOlnYWsZQC7BDFALoxdBkhg9xzf3ftolhw1nKR3pbdJcQzeVjMJZtUiLYAGqBEQUYX2HzeU2roUEDQRj1z0IE8C8V6P9Dzv1oRjpcgeGCOKKwcFD7xxl5lFpucDPvxPO6fRKr/LaoJihE/LHbFatXisUIF1rFB0MCHJ6ry/8o= Received: from DB6PR07CA0108.eurprd07.prod.outlook.com (2603:10a6:6:2c::22) by VI1PR08MB5550.eurprd08.prod.outlook.com (2603:10a6:803:f3::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.24; Wed, 1 Jul 2020 15:54:45 +0000 Received: from DB5EUR03FT038.eop-EUR03.prod.protection.outlook.com (2603:10a6:6:2c:cafe::21) by DB6PR07CA0108.outlook.office365.com (2603:10a6:6:2c::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.8 via Frontend Transport; Wed, 1 Jul 2020 15:54:45 +0000 X-MS-Exchange-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 DB5EUR03FT038.mail.protection.outlook.com (10.152.21.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Wed, 1 Jul 2020 15:54:45 +0000 Received: ("Tessian outbound 2dd9eeca983c:v62"); Wed, 01 Jul 2020 15:54:45 +0000 X-CR-MTA-TID: 64aa7808 Received: from 024cd2bb1820.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 923A806C-CD8A-4497-B3D2-65BB4E1E92B1.1; Wed, 01 Jul 2020 15:54:40 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 024cd2bb1820.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 01 Jul 2020 15:54:40 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kk/8xRGacJRoPF3BnWFoKRNRaM9G14dHV8EZmqNvgQZ+N8PhL6RaiNXy4FsTCe+PuBF+PgkN1pVqgXNGGZAIG8kcHSbK4VGMd33bZChA2mvyRVmSatChaOTXqm4da3OFQYWg129a68DyA5mjsT/mez3ghEXZ5Bv1sg2sqKpyGspuwSlEvSMLrWLKzwshATNTchihHOAEgp0OSCaYVA60h+EXgUACCwkNN1nzjWEypbXhdxzlfFW1I3zJzVOutD5bCoB7puNV781QnExHa1rtgxKKsAIgndP2W6FwJ0HYOy7io6jzCTGtd8/BcnYfQz0vWQvrNZ52aS+Ns31Gv38hzA== 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=gLSS6baTpNu7mOgHOxx0N3L8oPtqQWizER6n/Vw+aDk=; b=HCCLb/YAw2Lqyd0YUV/FwI13q3O+dRZR0f9kKz4SzTvdbeAQz8Kfk1V3uBxN7Zv0LAf+2fDFSGLK01XE6ptsfUFLG6c61gNTIQIJCsq79JhpvPyLDKKJuBe3EoZmIxPm5YRAh/PMPPbVMAtjU4z0LZpvWrCoJhP6k4lDNtZF8qaC/d1YJJdNJYiADUZAp1CxWMDQPq67V+0jLYX8+6fB+hNjejvPY+/v/Rs1w3LwD6J21bvbzwa/lAjQIB45rCAFiVd176mpSMEE4XWO9xZ4Zab2AhEVsvfOK0c06GV11nJXa0yHN8SV8LK1xQHjZ02IJEESH9OLkKsQ+zENdmkP3w== 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=gLSS6baTpNu7mOgHOxx0N3L8oPtqQWizER6n/Vw+aDk=; b=IBAOlnYWsZQC7BDFALoxdBkhg9xzf3ftolhw1nKR3pbdJcQzeVjMJZtUiLYAGqBEQUYX2HzeU2roUEDQRj1z0IE8C8V6P9Dzv1oRjpcgeGCOKKwcFD7xxl5lFpucDPvxPO6fRKr/LaoJihE/LHbFatXisUIF1rFB0MCHJ6ry/8o= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3601.eurprd08.prod.outlook.com (2603:10a6:208:e1::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.24; Wed, 1 Jul 2020 15:54:39 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3131.030; Wed, 1 Jul 2020 15:54:39 +0000 From: Hannes Tschofenig To: Yoav Nir , "" Thread-Topic: [TLS] Proposed change in TLS-Flags Thread-Index: AQHWTl0Ld6jfqArPY0aO0UjR/agUgajy4siA Date: Wed, 1 Jul 2020 15:54:39 +0000 Message-ID: References: <1CAC4193-E0CD-4C29-BC05-CED0617BEE19@gmail.com> In-Reply-To: <1CAC4193-E0CD-4C29-BC05-CED0617BEE19@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 0a3302ee-bde8-47ff-a665-41ef808a0906.0 x-checkrecipientchecked: true Authentication-Results-Original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.121.249] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 0348a93e-bd34-429a-2908-08d81dd71345 x-ms-traffictypediagnostic: AM0PR08MB3601:|VI1PR08MB5550: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:9508; x-forefront-prvs: 04519BA941 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: wG7+MfGCUQo1bc8Fml3X+xfyVZw5BVFkS1tGi2U+JLj2xy+w+Gpjdem/hhTNoctyK79ULOI2jBnvj9xbLSpbPhnGsf4eq4Jc7AyyOvbQfbFvbo7ODR+4lVlg0GOwZUHTZEhJ+BXif2hu4t25kMAzhcMKoKyFPMFmHVGCDRkLuINIiTMbClQS6IF2U+ElMgd8glerI5bkL6smOOrV5Cn+1SG/Y/7CBIHxI61u86oOx90Pe5fSarkUqJtmJl3u8imvxMFIy7RygzL21UkO26s3dCQCyeXbIxWd7+Hluy44KjC99PKd8Z/YIkWfIVgek3l5YFL0WDrHo8DZn9IGK1v861dVd3CkkHjwJm0Xj3E5SWhx+zeyQ8N6jnt16ySjIRdE6wP8dESNh91X5ZKxuX5ALVP/7HmxXgPjmpQe/MdbVvehdLnJXvJrrlvSJ1zi+0bv 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)(396003)(39860400002)(136003)(376002)(366004)(346002)(478600001)(9686003)(8936002)(186003)(26005)(71200400001)(53546011)(6506007)(52536014)(5660300002)(55016002)(83380400001)(64756008)(66446008)(66476007)(66556008)(110136005)(86362001)(316002)(8676002)(7696005)(76116006)(33656002)(2906002)(66946007)(166002)(966005)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: PCdtwNxRE+n4H4eiKPSCD7k411rQvplXTNmHbEZHORavzwxPesfPuSLGrhl7aFSC7HteutOifBJcnnj/JshMzXFB4qVt4CxD5vgKAb3Mw7XNvrHJ2wFAG31BWC1HX6GVL2Tc4oWJjns2u4F9ee2+arc5/BnXqDjG8cDGb6JC4QLsPZCJ9onsE2lkAJY1MiuaWIkWgrsq2sfuqdXyokclq88dy7tYSLtK8Xn4y7R6Vmu9kVmTKqJ4CV9kZTukw04ksR2zKKpZvBgUuG7c0IFMqgUrgf9m4BZwSOgoSYFHEIB1V7KAabebQRSjue9vKgaWACdB46/eytLzWqEC+Un01+wlG0w3d313PzABTkypDNZ/hzbKq5Ixuh+EySn9Ncj/Vh3CgezNyu4RXcYpMa2gYZ98buLNm3H4Gp9xzwFiflPxiyiw46+D3cqBHmJ+gbiatrKyqboAOXEt8XrCsztgfEBE4CFmod0oBVfSyx04A2ucaovmMVbShPZcmvrqS8kA x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR08MB3716E323B824825A375332EFFA6C0AM0PR08MB3716eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB3601 Original-Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT038.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)(39860400002)(136003)(346002)(376002)(396003)(46966005)(52536014)(83380400001)(9686003)(110136005)(316002)(81166007)(8676002)(8936002)(55016002)(5660300002)(356005)(26005)(478600001)(966005)(166002)(2906002)(186003)(82310400002)(33964004)(7696005)(336012)(33656002)(86362001)(70586007)(47076004)(70206006)(6506007)(53546011)(82740400003)(491001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 2422f86e-ac68-4782-66c5-08d81dd70fbf X-Forefront-PRVS: 04519BA941 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +tqAtGGfBjDVdmcOojqH/aG6sv5ekmoKHUkCZEGifzTIV1rCe5Xc8n/jTRhYC2dcX6JK7X6bC+sSd6T1jIpRo/ObHHPp8pADMn5lG4zskO0ex3rc69OLWKmlcpT+Yg2AlLHe8yKCY0THny1srvcvF5f7kLtzFzxu5OAZyJ/yGLLiO6LJNeSFuzP5mgGwnlJ6Znf/EfEOLL/ifgvBfBPjy+tDF7USCURH/mSdOU0BMTqvK0nh/0gQhA6teS4zocppFMv+sqsM0VAwIpxmCI1cc/GWImpIItSkS+PzbI4EHJpjz1KhsFkdFs5h5ZSB7GBUense/fkTjgqflUxaAb4tOVr3j2PKZNSiQ/Ocv0WJHu+Kl1h8WAuKFLIuPG8UOsapnXYsfJBX7xEu6qSYsggNC4VtcvgB6950Vu5233ALSNZYGqRTr5R9768B3lSLRfABhai1staR766jqEqnXiHHOq4tnRLxYGLowdrgWzE3M7vIYwM0bI9mNQmor3dG7DHi X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2020 15:54:45.1298 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 0348a93e-bd34-429a-2908-08d81dd71345 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-AuthSource: DB5EUR03FT038.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR08MB5550 Archived-At: Subject: Re: [TLS] Proposed change in TLS-Flags 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, 01 Jul 2020 15:55:05 -0000 --_000_AM0PR08MB3716E323B824825A375332EFFA6C0AM0PR08MB3716eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW9hdiwNCg0KSSBsb29rZWQgYXQgdGhlIGRyYWZ0IGFuZCB0aGUgUFIuIEkgYW0gZmluZSB3aXRo IHRoZSBwcm9wb3NlZCBjaGFuZ2VzLg0KVGhpcyBpcyBhIHNob3J0IGFuZCB1c2VmdWwgZHJhZnQu DQoNCkNpYW8NCkhhbm5lcw0KDQpGcm9tOiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPiBPbiBC ZWhhbGYgT2YgWW9hdiBOaXINClNlbnQ6IE1vbmRheSwgSnVuZSAyOSwgMjAyMCAxMTozNCBQTQ0K VG86IDx0bHNAaWV0Zi5vcmc+IDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbVExTXSBQcm9wb3Nl ZCBjaGFuZ2UgaW4gVExTLUZsYWdzDQoNCkhpDQoNCknigJl2ZSBqdXN0IHN1Ym1pdHRlZCB0aGUg Zm9sbG93aW5nIFBSOg0KDQpodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzLWZsYWdzL3B1bGwv NA0KDQpUaHJlZSBjaGFuZ2VzOg0KDQogICogICBJdCBpcyBubyBsb25nZXIgYWxsb3dlZCB0byBz ZW5kIGFuIGVtcHR5IGZsYWdzIGV4dGVuc2lvbi4gIElmIHlvdSBkb27igJl0IHN1cHBvcnQgYW55 IGZsYWdzLCBkb27igJl0IHNlbmQgdGhlIGV4dGVuc2lvbi4NCiAgKiAgIFRoZSBzZXJ2ZXIgaXMg bm8gbG9uZ2VyIGFsbG93ZWQgdG8gcmVzcG9uZCB3aXRoIGZsYWcgdHlwZXMgdGhhdCB0aGUgY2xp ZW50IGRpZG7igJl0IGluZGljYXRlIHN1cHBvcnQgZm9yIGZpcnN0Lg0KICAqICAgSeKAmXZlIHNw bGl0IHRoZSBleHRlbnNpb24gZGVzY3JpcHRpb24gc2VjdGlvbiBpbnRvIGEgZm9ybWF0IHNlY3Rp b24gYW5kIGEgcnVsZXMgc2VjdGlvbg0KDQpQbGVhc2UgY29tbWVudC4gQmFycmluZyBhbnkgb2Jq ZWN0aW9ucywgSeKAmWxsIG1lcmdlIHRoZSBQUiBqdXN0IGJlZm9yZSB0aGUgc3VibWlzc2lvbiBk ZWFkbGluZS4NCg0KWW9hdg0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhp cyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNv IGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRo ZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBv ciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3Uu DQo= --_000_AM0PR08MB3716E323B824825A375332EFFA6C0AM0PR08MB3716eurp_ 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 MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMg Ki8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEyODMwNzU2MTY7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjIxMTgwMzUwNzg7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Oi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb2F2LCA8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBsb29rZWQgYXQgdGhlIGRyYWZ0IGFuZCB0aGUgUFIuIEkgYW0gZmluZSB3aXRoIHRo ZSBwcm9wb3NlZCBjaGFuZ2VzLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGlzIGlzIGEgc2hvcnQgYW5kIHVzZWZ1bCBkcmFmdC4gPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNpYW88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhbm5lczxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ RnJvbTo8L2I+IFRMUyAmbHQ7dGxzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBP ZiA8L2I+DQpZb2F2IE5pcjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMjksIDIwMjAg MTE6MzQgUE08YnI+DQo8Yj5Ubzo8L2I+ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7ICZsdDt0bHNAaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtUTFNdIFByb3Bvc2VkIGNoYW5nZSBpbiBU TFMtRmxhZ3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZdmUganVzdCBzdWJt aXR0ZWQgdGhlIGZvbGxvd2luZyBQUjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3Rs cy1mbGFncy9wdWxsLzQiPmh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMtZmxhZ3MvcHVsbC80 PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaHJlZSBjaGFuZ2VzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ DQpJdCBpcyBubyBsb25nZXIgYWxsb3dlZCB0byBzZW5kIGFuIGVtcHR5IGZsYWdzIGV4dGVuc2lv bi4gJm5ic3A7SWYgeW91IGRvbuKAmXQgc3VwcG9ydCBhbnkgZmxhZ3MsIGRvbuKAmXQgc2VuZCB0 aGUgZXh0ZW5zaW9uLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj4NClRoZSBzZXJ2ZXIgaXMgbm8gbG9uZ2VyIGFsbG93ZWQgdG8g cmVzcG9uZCB3aXRoIGZsYWcgdHlwZXMgdGhhdCB0aGUgY2xpZW50IGRpZG7igJl0IGluZGljYXRl IHN1cHBvcnQgZm9yIGZpcnN0LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCknigJl2ZSBzcGxpdCB0aGUgZXh0ZW5zaW9uIGRl c2NyaXB0aW9uIHNlY3Rpb24gaW50byBhIGZvcm1hdCBzZWN0aW9uIGFuZCBhIHJ1bGVzIHNlY3Rp b248bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UGxlYXNlIGNvbW1lbnQuIEJhcnJpbmcgYW55IG9iamVjdGlvbnMsIEnigJlsbCBtZXJn ZSB0aGUgUFIganVzdCBiZWZvcmUgdGhlIHN1Ym1pc3Npb24gZGVhZGxpbmUuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvYXY8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBv ZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xv c2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBv c2UsDQogb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhh bmsgeW91Lg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_AM0PR08MB3716E323B824825A375332EFFA6C0AM0PR08MB3716eurp_-- From nobody Wed Jul 1 09:00: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 C04023A11BF for ; Wed, 1 Jul 2020 09:00:25 -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=8ypq3aTC; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=8ypq3aTC 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 1eMNqavKBQyo for ; Wed, 1 Jul 2020 09:00:23 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2045.outbound.protection.outlook.com [40.107.22.45]) (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 65E583A11A3 for ; Wed, 1 Jul 2020 09:00:23 -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=Jtpd9U5BtyBzfC4pTfRBudH7dAMt5gKnGLxq43OYgPk=; b=8ypq3aTC6wXCPUNxe1JqzazLDcW1+zov2tWCWnyAk5edWnyl2g/aYZg1zkLfEWnkZc2txIsfeUrFRVTNT6EoGMLSO+D9Q/j9xaEMINcMmlNmf9liYc+yPxgRIS1xprSwWmWgHOIsT0+XaTQKTPOpeRfnNNyg0z+jZlHD8h3oaKM= Received: from DB6PR0601CA0028.eurprd06.prod.outlook.com (2603:10a6:4:17::14) by DB8PR08MB3945.eurprd08.prod.outlook.com (2603:10a6:10:a3::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.24; Wed, 1 Jul 2020 16:00:19 +0000 Received: from DB5EUR03FT049.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:17:cafe::9a) by DB6PR0601CA0028.outlook.office365.com (2603:10a6:4:17::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.20 via Frontend Transport; Wed, 1 Jul 2020 16:00:19 +0000 X-MS-Exchange-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.3131.20 via Frontend Transport; Wed, 1 Jul 2020 16:00:19 +0000 Received: ("Tessian outbound 4e683f4039d5:v62"); Wed, 01 Jul 2020 16:00:19 +0000 X-CR-MTA-TID: 64aa7808 Received: from 021df120ea89.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 86D9CF3A-2DF6-4205-967F-1B8D31EC9FEA.1; Wed, 01 Jul 2020 16:00:14 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 021df120ea89.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 01 Jul 2020 16:00:14 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VKhaPbB4MWcGz/Qr5gNCZ1IzoYtVoqRXVDzzsH5BftvCmpyE2Vftfjib90+KQktwstQeVlMcGNFaU7kjIufiNglD+ULGzc3cUQ35FmMCqOclXKvoPTx6dFqEQe2bPMnZ4JuX1bYlyTnMe5ysfaMx2C8++28FSkbUi9vSnjVzxj9WtV4XNTE21mc7DyH/cfszzKGHRvy/QhIkKCzIZA0ZVB4tsMnSawWyYj5VrZsmXTSO+W2s/nwBStoQdaXZwpGzDdJuP4Xk5gfRFWu+Whm5zr+OsS4/m0kZOdHlyWLyBRK3FmSIyAJ8BgaUCBCYJlhZV861GMGhz8xbqcimInZMKA== 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=Jtpd9U5BtyBzfC4pTfRBudH7dAMt5gKnGLxq43OYgPk=; b=RWFCOUvYbLSWcvu+N4UNd9CRc3OXjh83MwbTPzjFYHEH8sjugkqbDfpGk3ueSbbhef0bV+hwySyU25y9ceBcFVz0XjT+S5PgB09l2ujj5WzYfZwh/njS9a8UMvY4DhJ9amQE0uGlXT4sjTXUuAMHqty8l3gtsTdb2BS9Qb6cUmtQcDqc8tzMnv987b072oNC6X5dcuSrbJo2f+Eep1mU2a8vnBCyBrutNN9UDYnXE9byQuUhsQbB4e8c6hZWuYICcJjEbxQIfRksNwJI1hCY5K4TOhA7TAVeXd/XkXtIy/mlWC9cR9Zg6945fr3+psD4h5agf1XFbplf2PfLhCUTGg== 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=Jtpd9U5BtyBzfC4pTfRBudH7dAMt5gKnGLxq43OYgPk=; b=8ypq3aTC6wXCPUNxe1JqzazLDcW1+zov2tWCWnyAk5edWnyl2g/aYZg1zkLfEWnkZc2txIsfeUrFRVTNT6EoGMLSO+D9Q/j9xaEMINcMmlNmf9liYc+yPxgRIS1xprSwWmWgHOIsT0+XaTQKTPOpeRfnNNyg0z+jZlHD8h3oaKM= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB5251.eurprd08.prod.outlook.com (2603:10a6:208:161::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.21; Wed, 1 Jul 2020 16:00:13 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3131.030; Wed, 1 Jul 2020 16:00:13 +0000 From: Hannes Tschofenig To: Yoav Nir , "" Thread-Topic: [TLS] Proposed change in TLS-Flags Thread-Index: AQHWTl0Ld6jfqArPY0aO0UjR/agUgajy4siAgAAA2dA= Date: Wed, 1 Jul 2020 16:00:13 +0000 Message-ID: References: <1CAC4193-E0CD-4C29-BC05-CED0617BEE19@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: ee451ebd-d69c-4804-9211-3e8485aad93d.0 x-checkrecipientchecked: true Authentication-Results-Original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.121.249] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 04a3a0c8-610c-4a31-75bd-08d81dd7dab4 x-ms-traffictypediagnostic: AM0PR08MB5251:|DB8PR08MB3945: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 04519BA941 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 5z9hr+s9zTVsi/xX47U8Jl1HQ464CM2FCjRqEKNIDiHdaHqm6irZ4xURHreKg1QE/r8ONZaSHQkM30G31vcPGH8bq21fGN3+vzf2HEZhUkbrKl2WNF5mhkdZrjkTyacfth9X7losdHVP4Pte5XLIL93Ge7+nfL9WahLNEJFwuRuyvs4Wys2hnCxR13SvcgK/lqVBeWsc2MUKCAUHa+a0qMDiTFh40zNaa3AlzXENAySvJgLVn0TUPfCA6deSxxaWzlqMn0JPk59Rkc9a0X0bZkBjrZi3gYw0KbtbRpwLk29VCJ6o7VU3p+9Bm6GhDRECjem+AgXcbF+ybz5xHhP6qt6pH5ehZ0uSq8lTz+TdkRFPf9kzXVmS2nj1G8phbIuRVHFheIaTN6QB6DmB1m2PqOYFm20eqYuwUNuRL9xnlFq8/YB44ZosJMKqIQtaVUjK 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)(366004)(376002)(396003)(39860400002)(136003)(346002)(110136005)(316002)(478600001)(2906002)(66946007)(66476007)(66556008)(76116006)(64756008)(66446008)(83380400001)(33656002)(9686003)(8936002)(8676002)(55016002)(966005)(26005)(186003)(2940100002)(5660300002)(53546011)(86362001)(7696005)(71200400001)(52536014)(6506007)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: WVs1iIBNJPm+jICoV8Ckamxn/10mNWCuaRVHR2pk9TEpi5cHXFFPkZmSGWtoMoDIai+HjVVBy7Xbv4s9yBf+l0xiV8NUscq02/4boX2OiXF7c+J6jz8KomBvQKltKetWBX8meKUbZieQC83nlVcLW+nX/DKJbNm3hU+Xysf2HrJfXijNJ/SkkFSyW1/ffqA6oxmCb5+zLK7uI7PZbZBhjOOLkz/cP8cfxeDsMI+dGLybh6z+lPC3rIa+Fbv4fx/xNxkyeDqaQBtWGsZWAj/g3HQfDxJ/o9OCrv2h45tweZpB3MUa3+FUwJUMW59sY39CSoVEn8qkHrNAK5vHDPHlNHgwDgYEIyg8vSG6zXbMw4xQPs3VVAAE2B8CTnj3HqA6mOXDBo1tgUHfPiaMyPwzmzKEUaCM4wIPLRCdc5ANWQ/iuIdRAbhwWCGggJgLO4BnGjDkcGB2Iusnh/yhAPOkCfChbXhv6CfXgs9X2bc6Nug3iEtLuaEYi5WOxk1fedmM 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: AM0PR08MB5251 Original-Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=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:(4636009)(346002)(376002)(396003)(136003)(39860400002)(46966005)(82310400002)(6506007)(55016002)(26005)(53546011)(316002)(186003)(70586007)(33656002)(52536014)(5660300002)(9686003)(70206006)(110136005)(478600001)(966005)(2940100002)(7696005)(2906002)(86362001)(83380400001)(81166007)(8676002)(356005)(47076004)(82740400003)(336012)(8936002)(491001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 20faff33-689f-4a7f-3564-08d81dd7d6e0 X-Forefront-PRVS: 04519BA941 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: nCu+VzmPiz9ERf6WI/SunMYzXiu3i2XDHN8ifAlh8HKggxkz8i1/1PDsutrcwwRQujYgSaZ/tMVeCZ+yjJfuqJSKiwSfpCvNADjfqYtMKXZWFlRD6TqcWmtsBx2gOqe7YQ+1m6qrgSB1hNVIJKpfOza/REILcWFDz4yFRRY5MKW9wqJPFlgPqnnL5OqYNDufD1GMMRy7IcWS/7mJsg6E5TAjZJyDtjkEAojG/PSKec0cR98VMaOE64LU3s2x4YJO2ZWFZmfvY8p9tBiVkIQhtlSomqvMxvAkkaJ7RtCL8tfV8j9CguS5hi7O5pHkzxsYbCWFY2vUySS2nNo1CNuCd1ZzTZAgOqJtr/kPazuzCMBmxp3aCoNjgPxTd4gM81DVQvIQhoVORcqXlx+0cXW6RnI0CwNV3AWYbjKdiewzntBGSbFQDw1yK+EtAI84Xrx7bVSjgR3GimUhR3HRPEjiYbaL4oSMdJ2rUqwK03tX0nUgXVmlXDetLw4MT4+DV4ps X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2020 16:00:19.7169 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 04a3a0c8-610c-4a31-75bd-08d81dd7dab4 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-AuthSource: DB5EUR03FT049.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR08MB3945 Archived-At: Subject: Re: [TLS] Proposed change in TLS-Flags 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, 01 Jul 2020 16:00:34 -0000 T25lIHF1ZXN0aW9uOiBXb3VsZG7igJl0IHlvdSB3YW50IHRvIHJlZ2lzdGVyIGEgZmxhZyBmb3Ig IlBvc3QtSGFuZHNoYWtlIENsaWVudCBBdXRoZW50aWNhdGlvbiIgaW4gdGhpcyBkb2N1bWVudD8N Cg0KQ2lhbw0KSGFubmVzDQoNCg0KRnJvbTogVExTIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIEhhbm5lcyBUc2Nob2ZlbmlnDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMSwgMjAy MCA1OjU1IFBNDQpUbzogWW9hdiBOaXIgPHluaXIuaWV0ZkBnbWFpbC5jb20+OyA8dGxzQGlldGYu b3JnPiA8dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIFByb3Bvc2VkIGNoYW5nZSBp biBUTFMtRmxhZ3MNCg0KWW9hdiwNCg0KSSBsb29rZWQgYXQgdGhlIGRyYWZ0IGFuZCB0aGUgUFIu IEkgYW0gZmluZSB3aXRoIHRoZSBwcm9wb3NlZCBjaGFuZ2VzLg0KVGhpcyBpcyBhIHNob3J0IGFu ZCB1c2VmdWwgZHJhZnQuDQoNCkNpYW8NCkhhbm5lcw0KDQpGcm9tOiBUTFMgPHRscy1ib3VuY2Vz QGlldGYub3JnPiBPbiBCZWhhbGYgT2YgWW9hdiBOaXINClNlbnQ6IE1vbmRheSwgSnVuZSAyOSwg MjAyMCAxMTozNCBQTQ0KVG86IDx0bHNAaWV0Zi5vcmc+IDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBbVExTXSBQcm9wb3NlZCBjaGFuZ2UgaW4gVExTLUZsYWdzDQoNCkhpDQoNCknigJl2ZSBqdXN0 IHN1Ym1pdHRlZCB0aGUgZm9sbG93aW5nIFBSOg0KDQpodHRwczovL2dpdGh1Yi5jb20vdGxzd2cv dGxzLWZsYWdzL3B1bGwvNA0KDQpUaHJlZSBjaGFuZ2VzOg0K4oCiIEl0IGlzIG5vIGxvbmdlciBh bGxvd2VkIHRvIHNlbmQgYW4gZW1wdHkgZmxhZ3MgZXh0ZW5zaW9uLiAgSWYgeW91IGRvbuKAmXQg c3VwcG9ydCBhbnkgZmxhZ3MsIGRvbuKAmXQgc2VuZCB0aGUgZXh0ZW5zaW9uLg0K4oCiIFRoZSBz ZXJ2ZXIgaXMgbm8gbG9uZ2VyIGFsbG93ZWQgdG8gcmVzcG9uZCB3aXRoIGZsYWcgdHlwZXMgdGhh dCB0aGUgY2xpZW50IGRpZG7igJl0IGluZGljYXRlIHN1cHBvcnQgZm9yIGZpcnN0Lg0K4oCiIEni gJl2ZSBzcGxpdCB0aGUgZXh0ZW5zaW9uIGRlc2NyaXB0aW9uIHNlY3Rpb24gaW50byBhIGZvcm1h dCBzZWN0aW9uIGFuZCBhIHJ1bGVzIHNlY3Rpb24NCg0KUGxlYXNlIGNvbW1lbnQuIEJhcnJpbmcg YW55IG9iamVjdGlvbnMsIEnigJlsbCBtZXJnZSB0aGUgUFIganVzdCBiZWZvcmUgdGhlIHN1Ym1p c3Npb24gZGVhZGxpbmUuDQoNCllvYXYNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRz IG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBt YXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNj bG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVy cG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhh bmsgeW91Lg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5k IGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxl Z2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMg dG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3Ig Y29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Wed Jul 1 09:52: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 C264E3A133D for ; Wed, 1 Jul 2020 09:52:29 -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=x51n8xVS; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=x51n8xVS 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 JTpJGQ6ryorD for ; Wed, 1 Jul 2020 09:52:27 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00074.outbound.protection.outlook.com [40.107.0.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 79CA53A133F for ; Wed, 1 Jul 2020 09:52:27 -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=qK4b+uGSLloDT5ahIgPxLK+LFuZs5eCtJoy2hXdUYyM=; b=x51n8xVSyN1Sd4hRHdjAURoC445HoTxi95HLAcehHtPxS/PFt8mMEKdyPjlifd6EV4VHVET4eNPudPiqE+rT2MpVy5n5/oFueqbsJU362956dHnQSG3M8X9eYQWQc+qWhvJ8h0ZonO5QsDp8/HxBLe9bRewAL9cTSUJ7j1vmrk8= Received: from AM6PR05CA0034.eurprd05.prod.outlook.com (2603:10a6:20b:2e::47) by AM5PR0802MB2577.eurprd08.prod.outlook.com (2603:10a6:203:a1::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.21; Wed, 1 Jul 2020 16:52:25 +0000 Received: from AM5EUR03FT050.eop-EUR03.prod.protection.outlook.com (2603:10a6:20b:2e:cafe::de) by AM6PR05CA0034.outlook.office365.com (2603:10a6:20b:2e::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.20 via Frontend Transport; Wed, 1 Jul 2020 16:52:24 +0000 X-MS-Exchange-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 AM5EUR03FT050.mail.protection.outlook.com (10.152.17.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Wed, 1 Jul 2020 16:52:24 +0000 Received: ("Tessian outbound 4e683f4039d5:v62"); Wed, 01 Jul 2020 16:52:24 +0000 X-CR-MTA-TID: 64aa7808 Received: from 54dce5f09b76.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id D51D2013-4248-4532-AEBE-781BC0551973.1; Wed, 01 Jul 2020 16:52:19 +0000 Received: from EUR04-HE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 54dce5f09b76.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Wed, 01 Jul 2020 16:52:19 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FJ7+IuiZ0gaz/COk7sU5Yq7Fr+OlYcTWLWIZcPkjmvClHke09GEhPA/TaNJkMVGsPwMMaf3uqHvhc1EBBdSkKjDSVO8+4NjLe6EmI6/MkJx/0HYAH0pI3zVnTZxaObQvQpbtGfyX6+/oPJqrIDkkRgZ47NJZeO9fk7m1bzeL0Unz2SoX74LakbOl2jrA5/Iq3+jWlfJL95AZTVqtxFDesfLQuw4Xn21vVwHOjbYNN0PcvDSmrEjZFPbvphpblw+XiPh+M9sksoE3uLN+YiAQafOGXKPWwgkIQDQVxheEH714ZqjIpEDaCAn6LgI1kXvURlfnmoyg8BvHcYF5tNHvmA== 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=qK4b+uGSLloDT5ahIgPxLK+LFuZs5eCtJoy2hXdUYyM=; b=QzQeFEp2rMx7obUYIWaMkYN+rq/0MQ9oborx2rtw0A21uJznPCSsOfLUfKAXN/Rqtw3oGL0QTUPSL9itgd01YMFnArPAA901S/a1CI58lm7/PvrDKF1ybNesGjL2OPZOFvdUfcJga0aQyNJK0V3hBWMLJ/9o4qDyF+sALkPUubHYGtpQrmiOFysh3Fl1pfmQrFsdIF8jjLxQaITUMfVmufuFn89sTqey1jfbBet8qBncvCzL0Xlw9t4i620K3+sJVY2asTvEbUgqpx8CxQxhLK+3vWaJHx94iKr3C6tZe3VqZPgLvfapCdSuTZR0ZIBIL/5wiLDGyaNGGQXoWBbNmg== 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=qK4b+uGSLloDT5ahIgPxLK+LFuZs5eCtJoy2hXdUYyM=; b=x51n8xVSyN1Sd4hRHdjAURoC445HoTxi95HLAcehHtPxS/PFt8mMEKdyPjlifd6EV4VHVET4eNPudPiqE+rT2MpVy5n5/oFueqbsJU362956dHnQSG3M8X9eYQWQc+qWhvJ8h0ZonO5QsDp8/HxBLe9bRewAL9cTSUJ7j1vmrk8= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3396.eurprd08.prod.outlook.com (2603:10a6:208:dd::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.25; Wed, 1 Jul 2020 16:52:18 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3131.030; Wed, 1 Jul 2020 16:52:18 +0000 From: Hannes Tschofenig To: "" Thread-Topic: draft-ietf-tls-ticketrequests-05 Thread-Index: AdZPwyuzW8DO++UhTr2C4GnWMXxBhg== Date: Wed, 1 Jul 2020 16:52:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 237ad8e8-14e2-48b9-9719-27e14faeb942.0 x-checkrecipientchecked: true Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.121.249] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 261ec202-9797-4f3f-e4aa-08d81ddf2171 x-ms-traffictypediagnostic: AM0PR08MB3396:|AM5PR0802MB2577: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:8882;OLM:10000; x-forefront-prvs: 04519BA941 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: n7pEEjFBES3xKQXsV02xY00Ccudx5rahWKoLIBu9hSf7nFLOYt3wpfGkpfEBMPDJjYUcqsNTEHxs6qDb+cZcamH3LKWCsvvMoJ+xcEXFDy4HYN6muBZBHIhyhK+u/a1h0c53yNBuRuyGTb4Ub+CmWtbiZ3zoHUl62MxtXg/NtCrM/OQY8Eoc2WcWpMpivzW0nsQ7tLHLHt8cOZBa5GLKCKvkE32IF4fbRvw1CCOIq6B/LmWLv+lPSLAbkoT1WKQSDqKQFzbmg0k4WBSdvekX8+k31gDn8URRBSuxWCYT7xSLa3OkfNh5BK9L8tTIZ8PbxD526eFxk20JHjFg/r5Tf00P+MFH5NyD8kDj9eZPbDTd2UuyJncH2EnlYu2Hnevx 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)(396003)(39860400002)(136003)(346002)(376002)(366004)(71200400001)(66556008)(76116006)(66476007)(33656002)(186003)(55016002)(83380400001)(26005)(66946007)(2906002)(9686003)(66446008)(64756008)(316002)(86362001)(478600001)(8676002)(6506007)(8936002)(7696005)(5660300002)(52536014)(491001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: wxNpMER0zRc/JhAC8+uMqcV5WzXsFqAFqXKtIirbFTCAwJ2NHg9v0fl7aOhI+gu5bMp7ensBE7mZsixIa52IuSXk0ywE5K9cPoLbQI14yiyaAMUUa/0ovgIbOIi+TnKZD20/BnrDozYyXzUSLsUYqzwcVlN/k4l56omWoTFvo5LyR7cDTh0yDMf0ujRLvr3YlHhhF0SpzWHoOsMKHWuel4qHLl1RwTpOFfvBg8h4Ip+K54mR4a2VlNBK4c3mJXFds/zIaHwsX8FFeQJtmrgsHjDtqbq8BpwaWSR0HS508cPk0tlcE3K0AiH1g9QMorpUWJh7OnPL7of5G4+SD/2zBtvQC6GweSXE3NlvR16psHHeSQWYV0W2Jf9ucWR/sLWWOX9jBZb+6BAAPfEPi9NJJX5gnkdP6RyahD57RP6tcvmETO7d6TNcN/Ddz1yLlqq+g3SbFCc5kNl3ATztDgg0saH4bep52K7EIE0lZxDsjqiTbvjVF17koWJhIXM/t0ax 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: AM0PR08MB3396 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT050.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)(396003)(136003)(39860400002)(46966005)(5660300002)(70206006)(47076004)(55016002)(83380400001)(6506007)(8676002)(86362001)(8936002)(82310400002)(9686003)(356005)(7696005)(33656002)(478600001)(336012)(52536014)(70586007)(2906002)(81166007)(82740400003)(186003)(26005)(316002)(36906005)(491001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 00d12d16-0d78-440e-2dd1-08d81ddf1dae X-Forefront-PRVS: 04519BA941 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +O6Ljz8CTUG0o9Pask1nth8sa325j26//dOhSrQpYgWSQrKb/7zzbjCniRufnz60si0AWtVrUCN7zQJyv60mCkCmePY+oIMKPzoJxLubV37EA3imw7hy4vLKD1EspP9TH2+qx8qK9QHNUN3sz6A6pZAKIHZoBqhpvuy5qOMOemHsELpU5Y/K5DRabNgyRrD9SDYOB0Q9j8+nkmE5cbrX5BTDl0FRKuID2Mj+Ihv+yiDOfc1PDtrqTI93NO25PGE12Nlj5rPIVfQj9IPRzbf8YGxlzJvXdn60NFeHfYBj7N0HVeNCUMBHL8s6d1JVLLfECTVzh7VoJrMIAMs4fi1f6K7IMNn/7IIyoq3KFByrXqRShyxkMeC5ReO2ACDWZJyYofWon6v5vyZ+a0VUHWOaa4HAbQUhGWkiWXA5eW1rBdk= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Jul 2020 16:52:24.8360 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 261ec202-9797-4f3f-e4aa-08d81ddf2171 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-AuthSource: AM5EUR03FT050.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0802MB2577 Archived-At: Subject: [TLS] draft-ietf-tls-ticketrequests-05 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, 01 Jul 2020 16:52:30 -0000 Hi Tommy, Hi David, Hi Chris, I read through the draft and have a few questions. 1) Is it really necessary for the client to use two values to differentiate= the tickets it wants with a new session and with resumption. It feels a bi= t over-designed. I would just have one value and that alone would be super = useful already. 2) This sentence confuses me: " Servers SHOULD NOT send more tickets than requested for the handshake type selected by the server (resumption or full handshake). Moreover, servers SHOULD place a limit on the number of tickets they are willing to send, whether for full handshakes or resumptions, to save resources. " Shouldn't the sentence say: " Servers SHOULD NOT send more tickets than requested for the handshake type (resumption or full handshake) indicated by the client. " Even then, I believe the sentence should actually say MUST NOT instead of S= HOULD NOT. If the client is already taking the effort to indicate that it d= oes not want more than a certain number of tickets then it might have a rea= son. I am thinking about the case where the client indicates that it does n= ot want any tickets then it would be strange for the server expressing supp= ort for the extension and still send tickets. 3) Does the server really need to send the number of tickets it is planning= to send back to the client? In the draft you already indicate that the ser= ver may send fewer tickets than requested by the client. So, the number exp= ressed by the client is an upper limit anyway. 4) I believe it would make sense to define a ticket flag for the case where= the client does not want to receive any tickets. 5) If a client sends the ClientTicketRequest extension during the full hand= shake is there an expectation that it sends it again in the resumption exch= ange? Would you assume that the server memorizes how many tickets the clien= t wanted across the resumption handshakes? For example, in the full handsha= ke I use the extension and indicate that I want 5 tickets. I get two ticket= s from the server. Then, I run a resumption handshake without transmitting = the extension. Is the server expected to remember to still send 3 more tick= ets till the quota is exhausted? 6) The topic of when to send the tickets is something you mention in the do= cument and it is indeed an issue. Have you thought about allowing the clien= t to signal to the server when to send the tickets? Even making a distincti= on between "send me all tickets in a batch" and "send one after the other w= ith some reasonable time in between" would be helpful. 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. From nobody Wed Jul 1 11:01: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 6E4473A08F9 for ; Wed, 1 Jul 2020 11:01:38 -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 aWEl1qiKvore for ; Wed, 1 Jul 2020 11:01:36 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 75DAB3A0900 for ; Wed, 1 Jul 2020 11:01:36 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id dm19so14600575edb.13 for ; Wed, 01 Jul 2020 11:01:36 -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=q78rFhW/d445ryrFT9M2E5YDptNboGdEJp8dlvWZWuI=; b=TvU7bIZV77MEEo9jhBEmsKdwuRfhcYo3qpxDoJkEcycc8m1ePCQVjIY+ndBsphij/C I8QnqCZTKTwxrYIYoMA1eeuXdBYLwzvEloMknPdvEi3GshUbzXqGGHLok+0twvGLYFj0 jxZmsHMHRV+/fyXBAktIILAoQR7Vlc1mveQDHK/m744fGkGh6ScXGzdyO7r60O8M3Vzw KdDS/8nsTAa7Hvt9nkxzxml4c0H/44pRHgXWlfz7Pu2paDa8cXgdLcGczIL46Wbkf8kB DOHA5bN0dgySn6ymtTFPB1uxJN+kzb9mRL/rulrm/iim/htx7I+INveddISdolonrKre TvBg== 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=q78rFhW/d445ryrFT9M2E5YDptNboGdEJp8dlvWZWuI=; b=Kj7uHE9mwXaUT3MUXP4lNqcf9hoCHJBeKYZWd4OeUQF31NCDlvDVdWqLh5I3IADbYA Zf3sMgcx1Ftez9EAzjt+hspnCOkK8Q/XoR03wQGvyhyqh7pMCfFhw2BzNX9F4eQ0+eQ/ v//gbt5x+Um4SdUTxd/YQQ5JESht95QZ9fGsJJsKkfmQ6VE0Uww/+V1Irtucwh4l10FI M/YmHizFp6C0C8iDigpNmr/wIoQw7ta53zn1g+YdSZGO31HgsPMDl8ZIFQim5n+Cy8dI iOxQ30WS/m9RCkQO5KMbQepKomrpXXm/Pj71vcxp7y228QNNG9BRzTpJkzjQwdIi0n0A ss3g== X-Gm-Message-State: AOAM531rR0llKVOyYkhh2a5RLmAOR9uDmBiDFLamEIktg/nPRTq4OZcD fGdVIB/LQ0C0sxdKhlkCIkhZ77Cx X-Google-Smtp-Source: ABdhPJwq9C4d/hmL2oFabfoN8TioaeC34d+xqRoaOOhr0oG01PqDkK6hd4JbF31fp4Q+DbHyOUnq2A== X-Received: by 2002:a05:6402:202e:: with SMTP id ay14mr30413730edb.233.1593626494988; Wed, 01 Jul 2020 11:01:34 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id z20sm6871216edq.97.2020.07.01.11.01.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Jul 2020 11:01:34 -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: Wed, 1 Jul 2020 21:01:32 +0300 Cc: "" Content-Transfer-Encoding: quoted-printable Message-Id: <600AA31E-8DB0-4398-863A-208759B1AEC2@gmail.com> References: <1CAC4193-E0CD-4C29-BC05-CED0617BEE19@gmail.com> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [TLS] Proposed change in TLS-Flags 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, 01 Jul 2020 18:01:39 -0000 I don=E2=80=99t know. There already is an extension for this. We haven=E2=80=99t discussed whether we want to =E2=80=9Ccover=E2=80=9D = semantics that already exist in other extensions. If that=E2=80=99s something the group wants, we can add it, but it=E2=80=99= s not generally a good thing for a protocol to have two ways of = expressing the same thing. Yoav > On 1 Jul 2020, at 19:00, Hannes Tschofenig = wrote: >=20 > One question: Wouldn=E2=80=99t you want to register a flag for = "Post-Handshake Client Authentication" in this document? >=20 > Ciao > Hannes >=20 >=20 > From: TLS On Behalf Of Hannes Tschofenig > Sent: Wednesday, July 1, 2020 5:55 PM > To: Yoav Nir ; > Subject: Re: [TLS] Proposed change in TLS-Flags >=20 > Yoav, >=20 > I looked at the draft and the PR. I am fine with the proposed changes. > This is a short and useful draft. >=20 > Ciao > Hannes >=20 > From: TLS On Behalf Of Yoav Nir > Sent: Monday, June 29, 2020 11:34 PM > To: > Subject: [TLS] Proposed change in TLS-Flags >=20 > Hi >=20 > I=E2=80=99ve just submitted the following PR: >=20 > https://github.com/tlswg/tls-flags/pull/4 >=20 > Three changes: > =E2=80=A2 It is no longer allowed to send an empty flags extension. = If you don=E2=80=99t support any flags, don=E2=80=99t send the = extension. > =E2=80=A2 The server is no longer allowed to respond with flag types = that the client didn=E2=80=99t indicate support for first. > =E2=80=A2 I=E2=80=99ve split the extension description section into a = format section and a rules section >=20 > Please comment. Barring any objections, I=E2=80=99ll merge the PR just = before the submission deadline. >=20 > Yoav >=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. > 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. From nobody Wed Jul 1 11:17: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 5EB933A09E3 for ; Wed, 1 Jul 2020 11:17:39 -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 G0BE43vscgqp for ; Wed, 1 Jul 2020 11:17:37 -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 EAE843A09DC for ; Wed, 1 Jul 2020 11:17:36 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id d21so14256655lfb.6 for ; Wed, 01 Jul 2020 11:17:36 -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=AWYfgfghIeg3uCklD+cF1q5T7JdZnK+QQgjTDYezOmM=; b=IwUSSnt1RLROr00kTQDHSqnwsL2/DL1jElnxGFclnDo8avrsGDNwUG7tXzxqOWczqB UZ8eSBA0BpPlUhIarOLKZ4dRfap2Ce9i6XBC1OmQdaPEBVWmfDqxXakowrcz9mCTGW8k HeiJvo8mAv7lCULTQ3TmBy9vA2G3Ha7whR0hrEnGPQNyUY2e8NvmvvT9XKk4yqE7eHqc 5fx790wEt2BXYRAlSxSrkvCiK0jXP2SjUHDSAyCuLv/Jtd/QMYMersZvT/pnzpjH1uWR emeW1LtZysY/J5LW8BG7nd3OWrOq39NJXuWRLoOnOKueffUkAYWfnqc4eJ7EFhtd/Usu +rFA== 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=AWYfgfghIeg3uCklD+cF1q5T7JdZnK+QQgjTDYezOmM=; b=G3tZ4HovAuvRIy2hiEz1+OHH2vKwVuLRWRtNtwkdzFZH2AZAVWz2FUCAgPBNssIxM6 cbhb/9GMNpEBsc8OGBgo0My/oZtZK0tsLxUBD1E3WKCZOmjqx+Y8ydBJxruJXiltYXMy REyexXDmL90lo4Pa+KjGJdSSgH04WEFWS/TFs14qVYW8JgfjhiRRn2CNP0Pg4Fu+WW60 oM10zY70dsZDKc/7Rfq7E8lXSy32QiGKr8r9oc9yWOotu8XD09qDQUYu5gXV6cbQPpRi +PU84G6SpbBib+JFDWL2aH6tRZF3jdS39wN+0E0q35DDY2SjQHC8KBaXqBapJ8vuvJzs NR6g== X-Gm-Message-State: AOAM533VeAjiXBaDR0y0K6ykHAHFED/QP3SvvD2SA9rAqI3moIDuM1jo 9wyKBUjB8iKaqQovQIEmc6BMM8BV/LIduAjOKnuk8A== X-Google-Smtp-Source: ABdhPJwKuZxBYS5aJkjtgTPoktoW764bcqOpVQOHMYAFzyTJ2JhH33IsR5LWe2etN6jcuCgFnU1Njr56H0YLRM+h1Go= X-Received: by 2002:ac2:5467:: with SMTP id e7mr15609839lfn.122.1593627454981; Wed, 01 Jul 2020 11:17:34 -0700 (PDT) MIME-Version: 1.0 References: <1CAC4193-E0CD-4C29-BC05-CED0617BEE19@gmail.com> <1496E3F4-FB87-46EE-9F76-86C058A55954@gmail.com> In-Reply-To: From: David Schinazi Date: Wed, 1 Jul 2020 11:17:23 -0700 Message-ID: To: Martin Thomson Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005bca6f05a9654ed5" Archived-At: Subject: Re: [TLS] Proposed change in TLS-Flags 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, 01 Jul 2020 18:17:40 -0000 --0000000000005bca6f05a9654ed5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the context, everyone! Based on that, PR looks good to me. Ship it! David On Tue, Jun 30, 2020 at 9:18 PM Martin Thomson wrote: > More to the point, this makes it more difficult to analyze relative to an > empty "flag" extension of the likes we currently use. > > I haven't implemented this, but I imagine one strategy would be to rewrit= e > these flags and pretend that they were empty extensions. That would allo= w > implementations to reuse a lot of infrastructure, like the stuff we added > for custom extensions. That would be more difficult if the server can > speak first. > > On Wed, Jul 1, 2020, at 14:03, Yoav Nir wrote: > > Yeah, the thread that Nick mentioned. > > > > Also, since there are no such extensions defined in the base TLS 1.3 > > spec, the server can=E2=80=99t assume that the client knows what either= the > > specific flag means, or the entire flags extension means. > > > > So suppose we invent some new client authentication scheme for TLS, it > > does make sense for the server to signal that it supports this so that > > the client can do. But I don=E2=80=99t think it=E2=80=99s too onerous t= o require that > > the client indicate support first. > > > > Yoav > > > > > On 1 Jul 2020, at 2:30, David Schinazi > wrote: > > > > > > Hi Yoav, > > > > > > Could you elaborate on the rationale for this change please? > > > I was assuming that the ability for servers to send extensions not > requested by clients was useful. > > > > > > Thanks, > > > David > > > > > > On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir wrote: > > >> Hi > > >> > > >> I=E2=80=99ve just submitted the following PR: > > >> > > >> https://github.com/tlswg/tls-flags/pull/4 > > >> > > >> Three changes: > > >> * It is no longer allowed to send an empty flags extension. If you > don=E2=80=99t support any flags, don=E2=80=99t send the extension. > > >> * The server is no longer allowed to respond with flag types that > the client didn=E2=80=99t indicate support for first. > > >> * I=E2=80=99ve split the extension description section into a forma= t section > and a rules section > > >> > > >> Please comment. Barring any objections, I=E2=80=99ll merge the PR ju= st before > the submission deadline. > > >> > > >> Yoav > > >> > > >> _______________________________________________ > > >> 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 > --0000000000005bca6f05a9654ed5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the context, everyone!
Based on = that, PR looks=C2=A0good to me. Ship it!

David
On T= ue, Jun 30, 2020 at 9:18 PM Martin Thomson <mt@lowentropy.net> wrote:
More to the point, this makes it more difficult t= o analyze relative to an empty "flag" extension of the likes we c= urrently use.

I haven't implemented this, but I imagine one strategy would be to rewr= ite these flags and pretend that they were empty extensions.=C2=A0 That wou= ld allow implementations to reuse a lot of infrastructure, like the stuff w= e added for custom extensions.=C2=A0 That would be more difficult if the se= rver can speak first.

On Wed, Jul 1, 2020, at 14:03, Yoav Nir wrote:
> Yeah, the thread that Nick mentioned.
>
> Also, since there are no such extensions defined in the base TLS 1.3 <= br> > spec, the server can=E2=80=99t assume that the client knows what eithe= r the
> specific flag means, or the entire flags extension means.
>
> So suppose we invent some new client authentication scheme for TLS, it=
> does make sense for the server to signal that it supports this so that=
> the client can do. But I don=E2=80=99t think it=E2=80=99s too onerous = to require that
> the client indicate support first.
>
> Yoav
>
> > On 1 Jul 2020, at 2:30, David Schinazi <dschinazi.ietf@gmail.com> wr= ote:
> >
> > Hi Yoav,
> >
> > Could you elaborate on the rationale for this change please?
> > I was assuming that the ability for servers to send extensions no= t requested by clients was useful.
> >
> > Thanks,
> > David
> >
> > On Mon, Jun 29, 2020 at 2:34 PM Yoav Nir <ynir.ietf@gmail.com> wrote:
> >> Hi
> >>
> >> I=E2=80=99ve just submitted the following PR:
> >>
> >> https://github.com/tlswg/tls-flags/pull/4=
> >>
> >> Three changes:
> >>=C2=A0 * It is no longer allowed to send an empty flags extens= ion. If you don=E2=80=99t support any flags, don=E2=80=99t send the extensi= on.
> >>=C2=A0 * The server is no longer allowed to respond with flag = types that the client didn=E2=80=99t indicate support for first.
> >>=C2=A0 * I=E2=80=99ve split the extension description section = into a format section and a rules section
> >>
> >> Please comment. Barring any objections, I=E2=80=99ll merge th= e PR just before the submission deadline.
> >>
> >> Yoav
> >>
> >> _______________________________________________
> >>=C2=A0 TLS mailing list
> >> TLS@ietf.or= g
> >> 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
--0000000000005bca6f05a9654ed5-- From nobody Wed Jul 1 11:48: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 D8D233A0BCE for ; Wed, 1 Jul 2020 11:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 zEVMsFfqXJgr for ; Wed, 1 Jul 2020 11:48:53 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2b.welho.com [83.102.41.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0263A0BCC for ; Wed, 1 Jul 2020 11:48:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id EAD4BD01EE; Wed, 1 Jul 2020 21:48:50 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id npfEYNvLFr1N; Wed, 1 Jul 2020 21:48:50 +0300 (EEST) Received: from LK-Perkele-VII (84-253-234-84.bb.dnainternet.fi [84.253.234.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 9E75C2308; Wed, 1 Jul 2020 21:48:48 +0300 (EEST) Date: Wed, 1 Jul 2020 21:48:46 +0300 From: Ilari Liusvaara To: Hannes Tschofenig Cc: "" Message-ID: <20200701184846.GA41980@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] draft-ietf-tls-ticketrequests-05 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, 01 Jul 2020 18:48:56 -0000 On Wed, Jul 01, 2020 at 04:52:18PM +0000, Hannes Tschofenig wrote: > Hi Tommy, Hi David, Hi Chris, > > I read through the draft and have a few questions. > > 1) Is it really necessary for the client to use two values to > differentiate the tickets it wants with a new session and with > resumption. It feels a bit over-designed. I would just have one > value and that alone would be super useful already. Consider a client that does: - Parallel connections - Does not reuse tickets Such client needs enough tickets to cover the multiple connections in case of fresh handshake (might be 5-10 or so), but only needs to replace the tickets for current connection (1 or 2) in case of resumption. So any single value will result in oversupply or undersupply. > 2) This sentence confuses me: > " > Servers SHOULD NOT send more tickets than requested for the handshake > type selected by the server (resumption or full handshake). > Moreover, servers SHOULD place a limit on the number of tickets they > are willing to send, whether for full handshakes or resumptions, to > save resources. > " > > Shouldn't the sentence say: > " > Servers SHOULD NOT send more tickets than requested for the handshake > type (resumption or full handshake) indicated by the client. > " The server might not want to actually honor request to send 255 tickets. Even if ticket minting is a fast operation, 255 of them might take non- trivial time (and bandwidth). > Even then, I believe the sentence should actually say MUST NOT instead > of SHOULD NOT. If the client is already taking the effort to indicate > that it does not want more than a certain number of tickets then it > might have a reason. I am thinking about the case where the client > indicates that it does not want any tickets then it would be strange > for the server expressing support for the extension and still send > tickets. If the client signals 0 tickets for handshake and 0 tickets for resumption, then reasonable interpretation is that client does not support resumption at all, and it is waste of resources to send it any tickets. But how should server interpret client saying it wants 1 ticket for full handshake and 0 tickets for resumption? A reasonable interpretation is that client does support tickets and is is willing to reuse tickets. So if the server is not willing to reuse tickets, the most reasonable action is to send 1 ticket to the client on resumption (if server is willing to reuse tickets, the most reasonable act is not send any tickets on resumption). Basically, there can be good reasons to send more tickets than requested. Just that most of the time, sending more tickets will lead to oversupply. > 4) I believe it would make sense to define a ticket flag for the > case where the client does not want to receive any tickets. The sensible way to indicate that is to send (0,0) as requested ticket count. > 5) If a client sends the ClientTicketRequest extension during the > full handshake is there an expectation that it sends it again in > the resumption exchange? Would you assume that the server memorizes > how many tickets the client wanted across the resumption handshakes? > For example, in the full handshake I use the extension and indicate > that I want 5 tickets. I get two tickets from the server. Then, I > run a resumption handshake without transmitting the extension. Is > the server expected to remember to still send 3 more tickets till > the quota is exhausted? I expect each connection to have its own ticket request counts. In general, it is unsafe to cache extension values across connections in session. Sure, one probably can not cause anything bad with this extension, but with things like server_name, very bad stuff can happen if those are not taken from connection handshake. > 6) The topic of when to send the tickets is something you mention > in the document and it is indeed an issue. Have you thought about > allowing the client to signal to the server when to send the > tickets? Even making a distinction between "send me all tickets in > a batch" and "send one after the other with some reasonable time in > between" would be helpful. What usecases would there be in spreading tickets in time? -Ilari From nobody Wed Jul 1 15:07: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 272243A0E45 for ; Wed, 1 Jul 2020 15:07: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, SPF_HELO_NONE=0.001, 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 A-ZuoFlyFgvL for ; Wed, 1 Jul 2020 15:07:37 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2DA23A0E3D for ; Wed, 1 Jul 2020 15:07:36 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 1 Jul 2020 15:07:29 -0700 From: Jim Schaad To: 'Christopher Wood' CC: References: <045601d64fea$e0d7f800$a287e800$@augustcellars.com> In-Reply-To: Date: Wed, 1 Jul 2020 15:07:27 -0700 Message-ID: <046301d64ff4$0398fa20$0acaee60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQJKcycXoPg67pLJAT3vSEDhcRD9xgIIH6r0p/rAmWA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [TLS] [Cfrg] Review of draft-ietf-tls-external-psk-guidance-00 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, 01 Jul 2020 22:07:42 -0000 Yes I did mean to send this to tls not cfrg - I had just sent mail there and did not look hard. > -----Original Message----- > From: Christopher Wood > Sent: Wednesday, July 1, 2020 2:09 PM > To: Jim Schaad > Subject: Re: [Cfrg] Review of draft-ietf-tls-external-psk-guidance-00 > > (-lists) > > Hi Jim, > > Before replying, did you mean to cc tls@ instead of cfrg@? > > Thanks! > Chris > > On Wed, Jul 1, 2020, at 2:02 PM, Jim Schaad wrote: > > * In section 4 there is a statement that switching the roles of > > servers which use PSKs will lead to weakening of security properties. > > As this is a common scenario today in situations where you are doing > > server-to-server communication, it would be useful to discuss just how > > and how much this weakening occurs. This was a complete surprise to > > me and I don't know if it was supposed to be one. Are there mitigations that > can be made? > > > > * In section 7, The first sentence does not read, also It seems a bit > > difficult to have a MUST in there when most of the items below are SHOULDs. > > That seems to be a dissonance. > > > > * Section 7.1.1 - The idea of having domain name suffixes on PSKs > > seems to me to be a bad idea as this would seem to lower privacy levels. > > > > * Section 7.1.2 - There seem to me to be three different places where > > collisions will occur. The importer function could get a collision, > > there could be collisions with pre-TLS 1.2 external identifiers and > > there could be collision with resumption keys. There has been a huge > > discussion about this in the EMU group and I don't find the text here > > to be sensible in term of whether this is or is not a problem. > > > > * Section 7.1.2 - One of the things that I kept meaning to get to and > > just haven't done so yet, is dealing with the question of can the TLS > > Key binders in the handshake to distinguish between multiple keys that > > happen to have the same identity. Perhaps you should look to see if > > this does work and if it is safe. > > > > Jim > > > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > https://www.irtf.org/mailman/listinfo/cfrg > > From nobody Thu Jul 2 02:06: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 59BB33A081C for ; Thu, 2 Jul 2020 02:05:59 -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=FjX9uIUh; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=FjX9uIUh 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 4R4zpiTUglYR for ; Thu, 2 Jul 2020 02:05:57 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00089.outbound.protection.outlook.com [40.107.0.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 EE1043A0817 for ; Thu, 2 Jul 2020 02:05:56 -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=j6wZuNoDskUwUksbHo4Fw6k63mHM7YFZCIxnOV5JyxU=; b=FjX9uIUh2xhca14e8i+0rpgOOPEECjXSaG8JCXKeaT8knzQ5J3MD/0DdalX6OxWPpZel4ZjNDJDzOf+H9wde2i5/YyGzEgD9Jud4BQIrK20VUnpvAgYUS2ggRdEaFK0lqxs10jZhxwZx+70wtA8beTvICTW4Qp/yXXBraD3sDKc= Received: from AM6P194CA0036.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:90::49) by AM6PR08MB5207.eurprd08.prod.outlook.com (2603:10a6:20b:ea::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.23; Thu, 2 Jul 2020 09:05:54 +0000 Received: from AM5EUR03FT029.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:90:cafe::42) by AM6P194CA0036.outlook.office365.com (2603:10a6:209:90::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.23 via Frontend Transport; Thu, 2 Jul 2020 09:05:54 +0000 X-MS-Exchange-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 AM5EUR03FT029.mail.protection.outlook.com (10.152.16.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.24 via Frontend Transport; Thu, 2 Jul 2020 09:05:54 +0000 Received: ("Tessian outbound 114f46c34313:v62"); Thu, 02 Jul 2020 09:05:54 +0000 X-CR-MTA-TID: 64aa7808 Received: from 9c1a25f83a60.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 2CBBF7E2-0223-4133-BF8E-5A4551E47A38.1; Thu, 02 Jul 2020 09:05:49 +0000 Received: from EUR02-AM5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 9c1a25f83a60.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Thu, 02 Jul 2020 09:05:49 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UomrtAg7tU/Y5DPWhBdAukOhmey7sfihuqZzV0GouXlvBAbStBZVDF+stTGMhB3khfJ7ipydrEzmtTDkhKBpsTkxWMH5YEa4f+uAaFA8kMs/Oi3R15cPaiV/ChSL7I2isvgNOHvTyb9V/j7MbOvIev4nQbUaCy1ZgF3mutehhnDMbsykvufH2OgeiD90sL2gXJE5Igon4L0nF+kiSsVEIFXXvy3Um2AN7a7HHp37YW14RQH5H/kzTffyn6+ZXKW/WhLb/Z/j581tl6UD3aAREl27uPgflWeB9Cz9nYUPKqe5EloGeD4WfoesjMLLuGIp8M3oNIAn2jFU5uH55axAVg== 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=j6wZuNoDskUwUksbHo4Fw6k63mHM7YFZCIxnOV5JyxU=; b=NOIzef1U7OBgOnQ5nkZv0jr1PMVWe+PuMeAT3FWv0DKflIVqJAogfqTD76eTdyprPOAEq7sXg7J4GhVy/7Pnpd9DAcwsDJEfT//m721s0pd3nFtusuSHQtq3+RNi8dEJQmG27B/kiITGuV5OyX+xxjjuKNtAv9tz0DoCLgjoXhUy7Ei5TnjwJ50Eh1OpVKnBuSFtf7LzncvSuwpoqEr4MPX+7u/bdikv6DFSAMqKlRXb3LCcEa/puP1mOauaDi+ry/UFc6eX/fHoH5hfTBXaCJfETSpId57pYRCdPex4jJdWzUgLxmMBBQ1z+izV9sUkELcGhcxcieVo9f90CfGINg== 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=j6wZuNoDskUwUksbHo4Fw6k63mHM7YFZCIxnOV5JyxU=; b=FjX9uIUh2xhca14e8i+0rpgOOPEECjXSaG8JCXKeaT8knzQ5J3MD/0DdalX6OxWPpZel4ZjNDJDzOf+H9wde2i5/YyGzEgD9Jud4BQIrK20VUnpvAgYUS2ggRdEaFK0lqxs10jZhxwZx+70wtA8beTvICTW4Qp/yXXBraD3sDKc= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB4004.eurprd08.prod.outlook.com (2603:10a6:208:12a::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.23; Thu, 2 Jul 2020 09:05:46 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3153.024; Thu, 2 Jul 2020 09:05:46 +0000 From: Hannes Tschofenig To: Yoav Nir CC: "" Thread-Topic: [TLS] Proposed change in TLS-Flags Thread-Index: AQHWTl0Ld6jfqArPY0aO0UjR/agUgajy4siAgAAA2dCAACLyAIAA/Cqw Date: Thu, 2 Jul 2020 09:05:46 +0000 Message-ID: References: <1CAC4193-E0CD-4C29-BC05-CED0617BEE19@gmail.com> <600AA31E-8DB0-4398-863A-208759B1AEC2@gmail.com> In-Reply-To: <600AA31E-8DB0-4398-863A-208759B1AEC2@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 448360d7-6c0c-4be7-9269-b1e7bca3f58e.1 x-checkrecipientchecked: true Authentication-Results-Original: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.121.249] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 2674a7a6-1322-4291-dd87-08d81e672034 x-ms-traffictypediagnostic: AM0PR08MB4004:|AM6PR08MB5207: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 0452022BE1 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: RbtXucjnxBoOCwP4RrCSk9MEPeucPRq4mo88wCclv635fRWB5krCv43o0ok3mgVG0viqMzsDE1A1bT7rw8wpYGSKxglNVEJ4pu8nMklZEUcSEAQM0JWGoXewvz9Pmo5rSOIhf2jTR4X7W9sksrYhqF/wVQRD7qieA+IznEliT3wjyNz/kqrfyz9q4mQ73QnFRnENYK2zlGNuwO465nXZZ5qwDwBlUgrW9nCdf/iBiGy1bi/XdDMALXrGH8Ezw/WvAmiKU/s+aWXGIT3bUXWy588dyuh2XOgrAwo+eC20EiuhrpXx4SwSvg4lIDLiRc01vYKuXT9XBJAQkn0+Fpct+G2XaxUflyZM44BtfiRUgWZsKFjMK1Ypec0v1jeKgRgQn5Abe1+zaWUHpRaIO6VKjw== 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)(136003)(346002)(376002)(39860400002)(396003)(366004)(316002)(7696005)(9686003)(55016002)(5660300002)(8676002)(6916009)(8936002)(2906002)(4326008)(26005)(52536014)(33656002)(71200400001)(966005)(64756008)(186003)(86362001)(66556008)(76116006)(66476007)(83380400001)(478600001)(53546011)(66946007)(6506007)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 63KOD+463hcF//g2259f209ngSm0YMZQRgWjwwU/xvbF4qYzsAi9BvOiMu9TJwuI1fHdTS1/MQgp1PHw+jJVFroxllvjdu6xjtWE3F6oJMBOwpoaj/h+vXrc7MKr0jseMJaizWhSm83vhbvddiyY1d38G3f8TZ+5nA+R0NFH6Mi1e8MZIOFxAkeg5ljUvChT9sSLtwj1ZbvdNSV1fw43q+kGuv9FEKRrcOg285Fy5dctH/hpviekZlWveVNywBq+4FuLS8YNKZh7jUB43wiiWKPI9Wh/P1TnYqeq6dFxvJFB6P8HAhcUwRl94bVynihT73gz2CvUzy3KSt4hR/+CSfLrGM8opGjQ/Wte+cQ1+wHM7ge2OYx+dZHnYHLxcdxUDs5pGCKyEABWOKIKqC0F+VRP1CdS2f7xBBFyCKfurPQLfTTWIlpk8AI/1CjPJdkznayDFWk3wLDStp4HmtYZ6kt+qAVPuaIubjHb6LOia/J1f9M5hpKeC/j0Qvf2x8GT 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: AM0PR08MB4004 Original-Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT029.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)(396003)(39850400004)(46966005)(6862004)(6506007)(966005)(53546011)(7696005)(9686003)(2906002)(47076004)(70206006)(5660300002)(86362001)(8676002)(82740400003)(81166007)(52536014)(336012)(8936002)(70586007)(82310400002)(36906005)(33656002)(356005)(478600001)(55016002)(26005)(4326008)(316002)(186003)(83380400001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: 52fc663c-6b11-4271-ba9f-08d81e671b8d X-Forefront-PRVS: 0452022BE1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3Ly2e8pYXnan5RgECS2dxKtxrh+eutRa0+SQNc9AR1pp3MdhGXqetUb/HGqg4DEhQ2tvWvAIAswTRnNYf3+DEp7MikjVqSFFp6HHl0WCj0kC5r/RrXnYN2aZCKrC7Ysj+f0qeBlhHsAFmubPkHtEiklFBckNNx089tPM0XgdprqEdFDAh+dZbGig+z2vGXsjsoBpMf7+bBAYIsSm/aXuGiNQwtt8n6DWa5g5YTyLFHEl5nfGDSYmmCjKOX6h+Yi+Q0jRxhJRntUd0ftSMf3YMjGD89Ae2MHs6ER44WxBE+j0I1sDqZR4Z/ceZne7CPTLONvnWNAHFOtyRTpYrCF2nNoVG1K5UVHViF4inqeTrlT0P5or3ZoybdpPBXAY0Pnv+I3amrknLso6FpvbDUtbhlcHEMRTqlvodDnyHmciXQhy6qRBYFb5lCLsCjjuFXiFMbWvcTOX9OiAEXk2yeVl/QWzZDcGclYwhSRjHKfUSSU= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Jul 2020 09:05:54.3205 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 2674a7a6-1322-4291-dd87-08d81e672034 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-AuthSource: AM5EUR03FT029.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5207 Archived-At: Subject: Re: [TLS] Proposed change in TLS-Flags 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 Jul 2020 09:05:59 -0000 SGkgWW9hdiwNCg0KPiBJZiB0aGF04oCZcyBzb21ldGhpbmcgdGhlIGdyb3VwIHdhbnRzLCB3ZSBj YW4gYWRkIGl0LCBidXQgaXTigJlzIG5vdCBnZW5lcmFsbHkgYSBnb29kIHRoaW5nIGZvciBhIHBy b3RvY29sIHRvIGhhdmUgdHdvIHdheXMgb2YgZXhwcmVzc2luZyB0aGUgc2FtZSB0aGluZy4NCkkg c2F3IGl0IG1vcmUgYXMgYSAiY29tcHJlc3Npb24iIG1lY2hhbmlzbSBmb3IgdGhvc2UgY2FzZXMg d2hlcmUgYW4gZXh0ZW5zaW9uIGRvZXNuJ3QgY2FycnkgYWRkaXRpb25hbCBjb250ZW50Lg0KDQpD aWFvDQpIYW5uZXMNCg0KWW9hdg0KDQo+IE9uIDEgSnVsIDIwMjAsIGF0IDE5OjAwLCBIYW5uZXMg VHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4gd3JvdGU6DQo+DQo+IE9uZSBx dWVzdGlvbjogV291bGRu4oCZdCB5b3Ugd2FudCB0byByZWdpc3RlciBhIGZsYWcgZm9yICJQb3N0 LUhhbmRzaGFrZSBDbGllbnQgQXV0aGVudGljYXRpb24iIGluIHRoaXMgZG9jdW1lbnQ/DQo+DQo+ IENpYW8NCj4gSGFubmVzDQo+DQo+DQo+IEZyb206IFRMUyA8dGxzLWJvdW5jZXNAaWV0Zi5vcmc+ IE9uIEJlaGFsZiBPZiBIYW5uZXMgVHNjaG9mZW5pZw0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkg MSwgMjAyMCA1OjU1IFBNDQo+IFRvOiBZb2F2IE5pciA8eW5pci5pZXRmQGdtYWlsLmNvbT47IDx0 bHNAaWV0Zi5vcmc+IDx0bHNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbVExTXSBQcm9wb3Nl ZCBjaGFuZ2UgaW4gVExTLUZsYWdzDQo+DQo+IFlvYXYsDQo+DQo+IEkgbG9va2VkIGF0IHRoZSBk cmFmdCBhbmQgdGhlIFBSLiBJIGFtIGZpbmUgd2l0aCB0aGUgcHJvcG9zZWQgY2hhbmdlcy4NCj4g VGhpcyBpcyBhIHNob3J0IGFuZCB1c2VmdWwgZHJhZnQuDQo+DQo+IENpYW8NCj4gSGFubmVzDQo+ DQo+IEZyb206IFRMUyA8dGxzLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBZb2F2IE5p cg0KPiBTZW50OiBNb25kYXksIEp1bmUgMjksIDIwMjAgMTE6MzQgUE0NCj4gVG86IDx0bHNAaWV0 Zi5vcmc+IDx0bHNAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFtUTFNdIFByb3Bvc2VkIGNoYW5nZSBp biBUTFMtRmxhZ3MNCj4NCj4gSGkNCj4NCj4gSeKAmXZlIGp1c3Qgc3VibWl0dGVkIHRoZSBmb2xs b3dpbmcgUFI6DQo+DQo+IGh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy90bHMtZmxhZ3MvcHVsbC80 DQo+DQo+IFRocmVlIGNoYW5nZXM6DQo+IOKAoiBJdCBpcyBubyBsb25nZXIgYWxsb3dlZCB0byBz ZW5kIGFuIGVtcHR5IGZsYWdzIGV4dGVuc2lvbi4gIElmIHlvdSBkb27igJl0IHN1cHBvcnQgYW55 IGZsYWdzLCBkb27igJl0IHNlbmQgdGhlIGV4dGVuc2lvbi4NCj4g4oCiIFRoZSBzZXJ2ZXIgaXMg bm8gbG9uZ2VyIGFsbG93ZWQgdG8gcmVzcG9uZCB3aXRoIGZsYWcgdHlwZXMgdGhhdCB0aGUgY2xp ZW50IGRpZG7igJl0IGluZGljYXRlIHN1cHBvcnQgZm9yIGZpcnN0Lg0KPiDigKIgSeKAmXZlIHNw bGl0IHRoZSBleHRlbnNpb24gZGVzY3JpcHRpb24gc2VjdGlvbiBpbnRvIGEgZm9ybWF0IHNlY3Rp b24gYW5kIGEgcnVsZXMgc2VjdGlvbg0KPg0KPiBQbGVhc2UgY29tbWVudC4gQmFycmluZyBhbnkg b2JqZWN0aW9ucywgSeKAmWxsIG1lcmdlIHRoZSBQUiBqdXN0IGJlZm9yZSB0aGUgc3VibWlzc2lv biBkZWFkbGluZS4NCj4NCj4gWW9hdg0KPg0KPiBJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVu dHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5k IG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNp cGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90IGRp c2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFueSBw dXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBU aGFuayB5b3UuDQo+IElNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBvZiB0aGlzIGVtYWls IGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5IGFsc28gYmUgcHJp dmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRl bnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3Jl IG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCg0KSU1Q T1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2ht ZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3Ug YXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVy IHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5m b3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsgeW91Lg0K From nobody Thu Jul 2 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 0A8AF3A0874 for ; Thu, 2 Jul 2020 07:20: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 7WVEbBT_tZF1 for ; Thu, 2 Jul 2020 07:20:39 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 72FDD3A0867 for ; Thu, 2 Jul 2020 07:20:39 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id q15so8760728uap.4 for ; Thu, 02 Jul 2020 07:20: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 :cc; bh=yRPPOL3HO5fiqowwFHi7HjpDHHTiSkGqpCaYZABvRoQ=; b=rfMe+stzapYCBvPS3T6+W09PwvyGtjRBHgDGMeHHYtD2yohsSMrdxXheuxK86g9sFw G2OvskxqByUrlrarmdIB32xFISG6YFB6nzLzQHKiwV0uM56Cv5/0Ob2fSOaUpa2YoUmM neZLcxVMoH5NDFD5TJnEpgTPXuaExjLZ6v1Wj8rpTtMukz3nSgsPuAKxjDd9MsgpUqHb xjrGWuFXRof86AspiczdvA4FxFLcH6E84R+4nFbpi5Z1wAW/9wQaJ4t6K3VzH063iCTP 0dW0GpZ48NffGjMrljHlzW479tHKu+6RYnNz0h77m7aMmbrRAYxfDzV5c8c2J8aKdSzl QrHA== 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=yRPPOL3HO5fiqowwFHi7HjpDHHTiSkGqpCaYZABvRoQ=; b=YR4kdcio2aL26gcp3cJ8nNLbgjxeqCYK8QIW978WTrKg/358rUEHQRWxPCrsDkScMl oFfC3x24ZS08mizs7F3ehDIzlCWvvNpuQKlDTPoeibL/68zTQKsXm5Bn6MIhm5sHllVP 76jtxPej4lbt4nrjOA5WVpSoTiv1PM+oHPpVrWOoZbP4RyEN/MGWl+mNDsmhL3O7ibOZ msZFNTA1Vc/bnmhkAnzqUYoqoVBZW60Vd0Xk/I8P8CG8fAsExzHjvRT8x+6K/zitxnCK KQsgYn9YkqlASOZbA0xIbBM48NHv4MgiPlBFHpZ3hM3Htm3tVbRBKnOYG5gLgtla5p8s H0ww== X-Gm-Message-State: AOAM531CWlejgCYtc2fD6btjf2lBO7+tqqLcTJAyY059cpEzJrz8QGZ2 TAPVunQyBpGno4WAzyOaUtZDosNg1gMIC3RFDG+phc5Pgv4= X-Google-Smtp-Source: ABdhPJzwQFY94bWX9bLMk0JUwo/dqMcnUtFOSatC/n2GFDaqePR+/nS1dKeBgrUIDu7UHg60bDSVC3XRutcj7hY2r6w= X-Received: by 2002:a9f:36e5:: with SMTP id p92mr1783077uap.27.1593699638403; Thu, 02 Jul 2020 07:20:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Hoyland Date: Thu, 2 Jul 2020 15:20:25 +0100 Message-ID: To: Joseph Salowey Cc: "" Content-Type: multipart/alternative; boundary="000000000000d395f305a9761c69" Archived-At: Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS 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 Jul 2020 14:20:41 -0000 --000000000000d395f305a9761c69 Content-Type: text/plain; charset="UTF-8" Hi All, For those interested, I've been working on a formal analysis of DCs the results of which should appear online in the next few days. I'll post to the list when it's up. In summary I managed to prove a server only version of DCs secure (i.e. does not violate any of the properties in Appendix E.1) under the Dolev-Yao model without resumption, and work on a more general result is ongoing. Regards, Jonathan On Mon, 29 Jun 2020 at 16:59, Joseph Salowey wrote: > This is the second working group last call for Delegated Credentials for > TLS. The latest draft can be found here: > https://tools.ietf.org/html/draft-ietf-tls-subcerts-09. There have been > 2 revisions since the last review. Draft 8 contains changes that were not > committed in time for draft 7 and draft 9 contains revisions from the > previous WGLC. Links to the Diffs between the draft 9 and draft 7 can be > found at the end of this message. Please focus your review on the changes > between draft 7 and draft 9. Please send your comments to the list by July > 13, 2020. > > Thanks, > > Sean and Joe > > [Inline Diff] > https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tls-subcerts-09.txt&url1=draft-ietf-tls-subcerts-07.txt > [Side-by-side Diff] > https://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-09.txt&url1=draft-ietf-tls-subcerts-07.txt > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000d395f305a9761c69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

For those interested= , I've been working on a formal analysis of DCs the results of which sh= ould appear online in the next few days.
I'll post to th= e list when it's up.

In summary I managed to p= rove a server only version of DCs secure (i.e. does not violate any of the = properties in Appendix E.1) under the Dolev-Yao model without resumption, a= nd work on a more general result is ongoing.

= Regards,

Jonathan

On Mon, 29 Jun 2020 at = 16:59, Joseph Salowey <joe@salowey.ne= t> wrote:
This is the second working group last call for=C2=A0= Delegated Credentials for TLS.=C2=A0 The latest draft can be found here:=C2= =A0https://tools.ietf.org/html/draft-ietf-tls-subcerts-09.=C2= =A0 There have been 2 revisions since the last review.=C2=A0 Draft 8 contai= ns changes that were not committed=C2=A0in time for draft 7 and draft 9 con= tains revisions from the previous WGLC.=C2=A0 Links to the Diffs between th= e draft 9 and draft 7 can be found at the end of this message.=C2=A0 =C2=A0= Please focus your review on the changes between draft 7 and draft 9.=C2=A0 = Please send your comments to the list by July 13, 2020.=C2=A0=C2=A0

Thanks,

Sean and Joe

[Side-by-side Diff]=C2=A0<= a href=3D"https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-subcerts-09.= txt&url1=3Ddraft-ietf-tls-subcerts-07.txt" target=3D"_blank">https://to= ols.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-subcerts-09.txt&url1=3Ddraft= -ietf-tls-subcerts-07.txt

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000d395f305a9761c69-- From nobody Thu Jul 2 14:45: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 6881D3A0BE2 for ; Thu, 2 Jul 2020 14:45:51 -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 hLK2o6CJtzUZ for ; Thu, 2 Jul 2020 14:45:49 -0700 (PDT) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 B4E873A0BE0 for ; Thu, 2 Jul 2020 14:45:49 -0700 (PDT) Received: by mail-vk1-xa2a.google.com with SMTP id d64so6690859vke.4 for ; Thu, 02 Jul 2020 14:45:49 -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=Pf8KrFs520HTAxDyHclFToNCMvifqAt/JsjAE943xfU=; b=Gd/pRjuB5sJt+TlbJL4A5DZZvZRzIgcUW1+WCBJwM5OOdpZKEpDfjA7fTvJ2S/P3S7 xUmNGriRz+ekYNoHw4yRkoqW9wJzAHU0sN+v/Qaah0nJZBY4SPl6Bp3Utv56235vDN5K /5OpgAyv9fEPYqoCDFckaoLcQyoE9ib37e/xKr/Ntjk8lNSPT2zaWZinGSrgVnWrvXfi T7FqAGkHrzg1MzfuQpms8klEsJCI84FE76DwAAw9Ek9w6Bd+ZSAKq5/RoPF9C9dDtq7v wWnZHothgzvML0Tw8Vj/go9LGujcRVNcnOBGAeKjsN30kgKUMQ5yDKVKR8ewwoHOqKMK QRDg== 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=Pf8KrFs520HTAxDyHclFToNCMvifqAt/JsjAE943xfU=; b=VYqUxpmlhICca2mpAirUuAy1wl0b3b+RO4UUd/Y6ffvzDXF4L3PQvtFMz6ZjSd0CEr N2qC2/BpatzE91n5qe6HFQMcT5FtwXv/wJKeNcEfWnyvPZh4c2bMUC7qcAGVrDBp020s gOZBBNWnSgGoqC2HQI57SJJj93uHSkJCZPFnEMS/uGrXZakSKjyhnLPIauHIUPpvrBAl 4xTlu2/bGStlcXBIOconrSUUH7MA8Y4oO51uVLWeFtqpFertqMtbDNMR9+RFNnjat4st a44c3L4iGINqUMZu39dy32XrMNKQUER1u71NLC7M0MfAibQt/onyUndqPIZM2hbUiwZY cEoA== X-Gm-Message-State: AOAM533kas/q5EgOcHCPzykhBAMqw/0sXnVQNnXBlzIP0ppmjaUsAld/ wKTy9+Wlt8obSvJ2tuTABWtzjHxj7V13GK2zaFA= X-Google-Smtp-Source: ABdhPJx2gbceNgyW426/FP1Jfr63WVuIxs3W0zK0lr/7ECxFqNSIhVwxZi27zkJ0C90ZKEgymI6w/eRigDsFrME9khM= X-Received: by 2002:a1f:d642:: with SMTP id n63mr8783961vkg.77.1593726348590; Thu, 02 Jul 2020 14:45:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Thu, 2 Jul 2020 17:45:37 -0400 Message-ID: To: Jonathan Hoyland Cc: Joseph Salowey , "" Content-Type: multipart/alternative; boundary="000000000000e0828805a97c5458" Archived-At: Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS 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 Jul 2020 21:45:51 -0000 --000000000000e0828805a97c5458 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 2, 2020 at 10:21 AM Jonathan Hoyland wrote: > Hi All, > > For those interested, I've been working on a formal analysis of DCs the > results of which should appear online in the next few days. > I'll post to the list when it's up. > > Great! Thanks. > In summary I managed to prove a server only version of DCs secure (i.e. > does not violate any of the properties in Appendix E.1) under the Dolev-Yao > model without resumption, and work on a more general result is ongoing. > > Regards, > > Jonathan > > On Mon, 29 Jun 2020 at 16:59, Joseph Salowey wrote: > >> This is the second working group last call for Delegated Credentials for >> TLS. The latest draft can be found here: >> https://tools.ietf.org/html/draft-ietf-tls-subcerts-09. There have been >> 2 revisions since the last review. Draft 8 contains changes that were not >> committed in time for draft 7 and draft 9 contains revisions from the >> previous WGLC. Links to the Diffs between the draft 9 and draft 7 can be >> found at the end of this message. Please focus your review on the changes >> between draft 7 and draft 9. Please send your comments to the list by July >> 13, 2020. >> >> Thanks, >> >> Sean and Joe >> >> [Inline Diff] >> https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tls-subcerts-09.txt&url1=draft-ietf-tls-subcerts-07.txt >> [Side-by-side Diff] >> https://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-09.txt&url1=draft-ietf-tls-subcerts-07.txt >> >> _______________________________________________ >> 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 > -- Daniel Migault Ericsson --000000000000e0828805a97c5458 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jul 2, 2020 at 10:21 AM Jonat= han Hoyland <jonathan.hoyl= and@gmail.com> wrote:
Hi All,

For tho= se interested, I've been working on a formal analysis of DCs the result= s of which should appear online in the next few days.
I'= ll post to the list when it's up.

Great! Thanks.=C2=A0=C2=A0
In summary I managed to prov= e a server only version of DCs secure (i.e. does not violate any of the pro= perties in Appendix E.1) under the Dolev-Yao model without resumption, and = work on a more general result is ongoing.

Reg= ards,

Jonathan

On Mon, 29 Jun 2020 at 16:= 59, Joseph Salowey <joe@salowey.net> wrote:
This is the second working group last= call for=C2=A0Delegated Credentials for TLS.=C2=A0 The latest draft can be= found here:=C2=A0https://tools.ietf.org/html/draft-ietf-tls-subc= erts-09.=C2=A0 There have been 2 revisions since the last review.=C2=A0= Draft 8 contains changes that were not committed=C2=A0in time for draft 7 = and draft 9 contains revisions from the previous WGLC.=C2=A0 Links to the D= iffs between the draft 9 and draft 7 can be found at the end of this messag= e.=C2=A0 =C2=A0Please focus your review on the changes between draft 7 and = draft 9.=C2=A0 Please send your comments to the list by July 13, 2020.=C2= =A0=C2=A0

Thanks,

_______________________________________________
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


--
Daniel Migault
Ericsson
--000000000000e0828805a97c5458-- From nobody Thu Jul 2 17:24:11 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 10D3D3A0ACC; Thu, 2 Jul 2020 17:21:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: tls@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373570105.29538.14134067775879602364@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:21:41 -0700 Archived-At: Subject: [TLS] tls - Requested session has been scheduled for IETF 108 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 Jul 2020 00:21:50 -0000 Dear Joseph Salowey, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tls Session 1 (1:40 requested) Tuesday, 28 July 2020, Session III 1410-1550 Room Name: Room 6 size: 6 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/sessions/tls.ics Request Information: --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Joseph Salowey Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 120 Conflicts to Avoid: Chair Conflict: pearg git mls emu Technology Overlap: cfrg dprive dnsop lake Key Participant Conflict: quic httpbis taps secdispatch saag People who must be present: Eric Rescorla Rich Salz Sean Turner Joseph A. Salowey Yoav Nir Benjamin Kaduk Christopher A. Wood Nick Sullivan Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jul 2 20:00: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 1FEFE3A0B97 for ; Thu, 2 Jul 2020 20:00:42 -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 NVZKm6RJdXaI for ; Thu, 2 Jul 2020 20:00:40 -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 AFA393A0B98 for ; Thu, 2 Jul 2020 20:00:40 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id e12so22930147qtr.9 for ; Thu, 02 Jul 2020 20:00:40 -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=8vEQI3oFIv6V30oSBETW0tpvcnL3sRr4JxKHlbIt2sY=; b=Hk37Jt9yT4NKbKsrvy5YGxhLiMjC3ae98dbeGYHZbDxG2CgyKtn1Y9YO0XAlimBROR em68tzRNDSJ40egS9aNS3jbc/nRCf4eeq2YxfL+bTA5ydnx6Pk6p9U1cpveNgF9OkqAU fg0PbBUZVBndP/IiWu9Ib5Xb+rds8tSZsgFmg= 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=8vEQI3oFIv6V30oSBETW0tpvcnL3sRr4JxKHlbIt2sY=; b=Pl7qhc/galjKNYdhC02lTzXYAuK/CuVez8grBbBSO0EsKsMb1sXir/GF8rTmE2JEEU CJJDOL96sUj6qjZMzvJkdAA9JCxo1dqSQDnF/WUKjUpiJqZxh4MjgCudOJ8wiZgZsQ2R CJBAaTGQcaY77v6HBgKfBoHVKl9ZESEpxRMi1iG4TaFT6PhdycMcj1b27+HVfbAqe04R 8i/X6h5UrIE1YDBRoznUV58WqM7RU3zuWBmpntyfQk2YH8cjuxFV0H4j0WKDtpDl93We dRxTNbn4go2pf/YRZds+qoKAMu6z6xzb5MyYGEUeM3n9UzQX1/jpZ2PUTFNwIQktSOyH H9dg== X-Gm-Message-State: AOAM531QIAmMM4ZK9ySAbMfP2xEjcZNj1nQ009N1xrn6cLQ0nIbnkB8y jD5KVu17wbLdE8xrR00t/NmvvTpGCVI= X-Google-Smtp-Source: ABdhPJyezWWH9NjUv+i0t4ScrKTj3YBvY+JRzbmgwvIMuEZtmA2T1E07QZPO7NcSTee+LmKn37wiBA== X-Received: by 2002:ac8:f8b:: with SMTP id b11mr35154346qtk.361.1593745239286; Thu, 02 Jul 2020 20:00:39 -0700 (PDT) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id f65sm9750574qtd.61.2020.07.02.20.00.38 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jul 2020 20:00:38 -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\)) Date: Thu, 2 Jul 2020 23:00:37 -0400 References: <159245090001.15841.1005352632597031983@ietfa.amsl.com> <50D6989E-E267-4865-9AA7-9554AADEEE17@sn3rd.com> To: TLS List In-Reply-To: <50D6989E-E267-4865-9AA7-9554AADEEE17@sn3rd.com> Message-Id: <1A25C3BB-7497-475C-9FB6-C43851A0D395@sn3rd.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-external-psk-guidance-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: Fri, 03 Jul 2020 03:00:42 -0000 Just a reminder to please have a look at this draft. spt > On Jun 19, 2020, at 23:39, Sean Turner wrote: >=20 > Thanks to Chris for uploading the WG version of the draft. >=20 > If you have some time over the next couple of weeks please take the = time to review this draft. The intent is to issue a WGLC after IETF 108 = barring any discontent prior that. >=20 > spt >=20 >> On Jun 17, 2020, at 23:28, internet-drafts@ietf.org wrote: >>=20 >>=20 >> 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. >>=20 >> Title : Guidance for External PSK Usage in TLS >> Authors : Russ Housley >> Jonathan Hoyland >> Mohit Sethi >> Christopher A. Wood >> Filename : draft-ietf-tls-external-psk-guidance-00.txt >> Pages : 12 >> Date : 2020-06-17 >>=20 >> 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. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> = https://datatracker.ietf.org/doc/draft-ietf-tls-external-psk-guidance/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tls-external-psk-guidance-00 >> = https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-guidance= -00 >>=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 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Thu Jul 2 20:10: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 9930D3A0BA0 for ; Thu, 2 Jul 2020 20:10:31 -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 oGqFxl5LMqj7 for ; Thu, 2 Jul 2020 20:10:29 -0700 (PDT) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 C989F3A0B9F for ; Thu, 2 Jul 2020 20:10:29 -0700 (PDT) Received: by mail-qv1-xf2a.google.com with SMTP id d12so13726355qvn.0 for ; Thu, 02 Jul 2020 20:10:29 -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=mTYnr94AAKqmUvLjDBd0BwfizXJ1933uflO9R1CzApQ=; b=ZkECSzgsFXodqeO9+YuJ/+pT6/3UlpUj18H2G/j0htZr2V+hRMklx0FFh+fBGChEpF p/Bk3kxuUZXl+RVNQOsRHv77yg1z34uZs+B0Nm05jT4nzw8Gdeg6ORemo7ps7mtnlHsf V9XKiT7AQEUiQdExcWQ89IfB26zcmwuaduJsk= 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=mTYnr94AAKqmUvLjDBd0BwfizXJ1933uflO9R1CzApQ=; b=IWlDPRI3I58pEcBaE2h6UVUqU+pS6XVoNMZXmx251U+l9tOSFX+zFoHK7Se4YdWd4I XPe4NXYHSN8iv8/Ku5TZw+a6xPmFgP7/tl4yDtmghvfEsqf4fbgfu9v3TKDSkWD5Yp+w X/mSvL1z5CCsDRHvClZDlSeggB/ebNAlfaNtV+o9nwohqpZgvbS1KjoRxaRBcpUY4pyM vRcop6DPI4U9PiwKhHF0qdHWw8Cd7YAdnNbOsmtUArJZRYU3KLheevVE/w3f0dPf8zsL EukA7OacqRqThfGCq4vTTVbnP6cNRQahdAwCZJcMOlcVDgRK9RCtFWjRU8X+RA1Q/nEA r8GQ== X-Gm-Message-State: AOAM5333n1P7gC8Jq+6hBkbKGnRnGnqS46qwuNR40HCxHJHsy/YG3iRA 6ADY/hmF9a1pdci46mkl78PGKw== X-Google-Smtp-Source: ABdhPJy8imu3fi1tlAdE0aOa3PPRReiL28+DRbY4UYPVyPWpSYXSb5xkbtDmkqFxGYuIU/TyqGRMKg== X-Received: by 2002:a0c:9e4f:: with SMTP id z15mr32132575qve.119.1593745828658; Thu, 02 Jul 2020 20:10:28 -0700 (PDT) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id n143sm9332819qkn.94.2020.07.02.20.10.27 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jul 2020 20:10:27 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Sean Turner In-Reply-To: Date: Thu, 2 Jul 2020 23:10:27 -0400 Cc: TLS List Content-Transfer-Encoding: quoted-printable Message-Id: <66465628-8B7F-4246-B893-C92F3F8A32F2@sn3rd.com> References: <16B2E133-DE69-4850-A23D-554FBCADEE5A@sn3rd.com> <1754FC7C-E06C-47C6-BCB0-84191EB15974@sn3rd.com> <600F08CB-490A-477E-B92F-AFDA8E1F0B69@sn3rd.com> To: Nick Sullivan X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [TLS] Closing WGLC (was Re: 3rd WGLC for draft-ietf-tls-exported-authenticators) 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 Jul 2020 03:10:32 -0000 Great! This document is now ready to progress to the AD. spt > On Jun 26, 2020, at 20:00, Nick Sullivan wrote: >=20 > TLSWG and Chairs, >=20 > I've submitted draft -13 with the appropriate changes. >=20 > Best, > Nick >=20 > On Tue, Jun 16, 2020 at 10:23 AM Sean Turner wrote: > Hi! >=20 > This message closes out the 3rd WGLC for = draft-ietf-tls-exported-authenticators. I have created GH issues for the = two issues raised during WGLC: > https://github.com/tlswg/tls-exported-authenticator/issues/62 > https://github.com/tlswg/tls-exported-authenticator/issues/63 > Once addressed, and assuming the changes are not large, we will = progress this draft towards our AD. >=20 > I will put the draft in Waiting for WG Chair Go-Ahead / Revised I-D = needed awaiting resolution of the two issues. >=20 > spt (for the chairs) >=20 > > On Jun 5, 2020, at 07:29, Watson Ladd wrote: > >=20 > > On Thu, Jun 4, 2020 at 9:48 PM Sean Turner wrote: > >>=20 > >> Another reminder ... > >>=20 > >>> On May 22, 2020, at 09:23, Sean Turner wrote: > >>>=20 > >>> This is the 3rd WGLC for "Exported Authenticators in TLS" draft = available at = https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/. = The secdir review during IETF LC raised some issues and as a result = there have been a couple of new versions. Please respond to the list = with any comments by 2359 UTC on 8 June 2020. > >=20 > > I've implemented earlier drafts. I do have a concern with the > > validate API as presented in the draft: it treats empty = authenticators > > as valid, and then returns the identity as a certificate chain that > > must be validated by the application. Similar APIs have lead to = easily > > foreseeable pwnage. Instead I would recommend the validate API carry > > out X509 validation against a trust store or validation function and > > treat the empty authenticator as invalid. That way someone has to > > think before not checking the certificate returned. > >=20 > > Sincerely, > > Watson Ladd >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Jul 2 20:12:14 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 616093A0BA0; Thu, 2 Jul 2020 20:12:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Cc: Christopher Wood , sean@sn3rd.com, tls-chairs@ietf.org, iesg-secretary@ietf.org, tls@ietf.org, Sean Turner Message-ID: <159374593238.10526.536358807732843857@ietfa.amsl.com> Date: Thu, 02 Jul 2020 20:12:12 -0700 Archived-At: Subject: [TLS] Publication has been requested for draft-ietf-tls-exported-authenticator-13 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 Jul 2020 03:12:12 -0000 Sean Turner has requested publication of draft-ietf-tls-exported-authenticator-13 as Proposed Standard on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ From nobody Fri Jul 3 00:52: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 A72203A03F2 for ; Fri, 3 Jul 2020 00:52:49 -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=IiaURm+E; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=IiaURm+E 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 TLLtsauGvCY9 for ; Fri, 3 Jul 2020 00:52:47 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150087.outbound.protection.outlook.com [40.107.15.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 C88843A011B for ; Fri, 3 Jul 2020 00:52: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=q8AuVpmBN3wvucn3yDwpdzQmr10tavTcOmu0gFKUY3E=; b=IiaURm+Euym2m3JD4UbYTPzjpeBrHdyD+0DvhTtp8IOICR4lAjsQgD5LdEAYQ3G8MHc56HQVMuWoiS3WDpzdORC1rGkXIeF0NfXHH4sYxfQWL9QcIFB8CsukKw25pnRmtvZrfYFOBNo8kQyc0qXArbptbKvbZk8GHhMCB/sb/II= Received: from AM6P192CA0021.EURP192.PROD.OUTLOOK.COM (2603:10a6:209:83::34) by AM6PR08MB5287.eurprd08.prod.outlook.com (2603:10a6:20b:b0::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.24; Fri, 3 Jul 2020 07:52:44 +0000 Received: from VE1EUR03FT058.eop-EUR03.prod.protection.outlook.com (2603:10a6:209:83:cafe::79) by AM6P192CA0021.outlook.office365.com (2603:10a6:209:83::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.22 via Frontend Transport; Fri, 3 Jul 2020 07:52:44 +0000 X-MS-Exchange-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 VE1EUR03FT058.mail.protection.outlook.com (10.152.19.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.24 via Frontend Transport; Fri, 3 Jul 2020 07:52:43 +0000 Received: ("Tessian outbound a4b10e5b482d:v62"); Fri, 03 Jul 2020 07:52:43 +0000 X-CR-MTA-TID: 64aa7808 Received: from 182144b66872.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 477344E0-A38F-47AC-ACEB-5967FE3F6D04.1; Fri, 03 Jul 2020 07:52:38 +0000 Received: from EUR01-VE1-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 182144b66872.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 03 Jul 2020 07:52:38 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RaL4n8uRnw7tcbsudmjFj0ImQ3GsRQuBqHUUM/5hbG2QpNSTRLiDyyNP110pKgQ2oUgzQnZaWuXJgmU8Kce6Z59OZ/JR7ip2uvUDeM0i+l3ZSY2idBSl5Nd4741C5r4BZZwXDk+D5D20AXk1dOUsceH2NAjE971ROKRYALUN2jKxi5r4PcZWx8Mplvvo5SxEjvsgvXFTsj71bCes/eIvt+L0JYZhxVlarjnf2JS47xjCkXbaS1Z+/SEuWd49atVmPiE5BLWpc2qD/uMS+Wu5VYr5pX/PEA9ilFW6Q8BD75aWPP1iil9RFgTiTxeCSbUaGWlMqpGZcRwL9DyE4dqa3A== 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=q8AuVpmBN3wvucn3yDwpdzQmr10tavTcOmu0gFKUY3E=; b=a9BrKjzTb7omRnOZIUAgHjp+ffr3rByM+FqqOXwOEFMQSJefKnpe4Je4FIG5x1nSAln/fUB9wrXEw6RMZKRRK0hNcm7d5OcvSmX6hdAIBKE/yWN1ugwxYeQLqDBeJevUlykitwDpAr91h1aAU16lzzNcg8WWgnp9vzuiT4Q7ZtmEd9gvpXQz4Aj7EAihPtystwNQ0GW6MY67bIN5+AUbhi9afUky0xh14DG5A8CpwEBhDmCEqOz63Mtky21orQwQeoa1Jw9ju+ihbaJeAdYrJSN5bmuOeSSRXqZLKFGaIyizHUOrzf/XJqWwxooRNTXyh1vTkEpzU/YzVVU6KShOEg== 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=q8AuVpmBN3wvucn3yDwpdzQmr10tavTcOmu0gFKUY3E=; b=IiaURm+Euym2m3JD4UbYTPzjpeBrHdyD+0DvhTtp8IOICR4lAjsQgD5LdEAYQ3G8MHc56HQVMuWoiS3WDpzdORC1rGkXIeF0NfXHH4sYxfQWL9QcIFB8CsukKw25pnRmtvZrfYFOBNo8kQyc0qXArbptbKvbZk8GHhMCB/sb/II= Received: from AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) by AM0PR08MB3716.eurprd08.prod.outlook.com (2603:10a6:208:106::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.23; Fri, 3 Jul 2020 07:52:36 +0000 Received: from AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae]) by AM0PR08MB3716.eurprd08.prod.outlook.com ([fe80::39f5:e4d9:51ff:eae%7]) with mapi id 15.20.3153.024; Fri, 3 Jul 2020 07:52:36 +0000 From: Hannes Tschofenig To: "ilariliusvaara@welho.com" CC: "" Thread-Topic: [TLS] draft-ietf-tls-ticketrequests-05 Thread-Index: AdZPwyuzW8DO++UhTr2C4GnWMXxBhgAFRRUAAB7G07A= Date: Fri, 3 Jul 2020 07:52:36 +0000 Message-ID: References: <20200701184846.GA41980@LK-Perkele-VII> In-Reply-To: <20200701184846.GA41980@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 1773523c-15ed-4a06-81b9-c249d6ff61a2.0 x-checkrecipientchecked: true Authentication-Results-Original: welho.com; dkim=none (message not signed) header.d=none;welho.com; dmarc=none action=none header.from=arm.com; x-originating-ip: [80.92.121.249] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 54efdc1f-99c2-4983-df15-08d81f2611a8 x-ms-traffictypediagnostic: AM0PR08MB3716:|AM6PR08MB5287: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 045315E1EE X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: QFW1Z/xfNnGZlFhuSoZ/Qjw90chfgWjy4o5bwp/iVnED5c1UhYfgmANf23ik+DtS9RRnWee0CNGhWUnf5RaAzq+rnwaQuyJ4H/M6t8K7yVkCdRYlaMZAm4KPkmxbd9uGhL47TO8Psa+avMoq/uKaO/SHPrtZZURTgfrTdBW8lxikvwPy21CHeiBf8foMi9LEKLU5GzRRpAU7oHH6nYDraOK1T7gwiUd4ocP67Xb7XJm9Tp1/CVEBuHVT5ghPOc/H7YMmN9tbYcIAPMycrNbU8jYgXCBc4MhvM5eacww1YH8ZTWo8HC1FxqDRcC+4Flwl8V4JVQIlsk+uD6N9ulZ46DRUyiai4Vee0eWrAY6F1SXbhIxeLkyIrmQvcEL/tGTAq978NcLc3vFtaiBd36WsNg== 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)(396003)(376002)(136003)(39860400002)(346002)(366004)(9686003)(71200400001)(478600001)(26005)(186003)(8936002)(2906002)(66446008)(86362001)(66946007)(53546011)(5660300002)(64756008)(316002)(66476007)(6506007)(66556008)(83380400001)(33656002)(6916009)(8676002)(4326008)(76116006)(55016002)(52536014)(966005)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: TRB6X594xfxxRfJqVwAUTAEIiuo4FXmvzOTLesr9GT8p79E/OUD9QT9u0auQJzrPNJfIujVXDZahgzaV7Q4gDtOpPpu1jU1O0YH9N5lQNcleUzL585AgCFaU3qa/u8w9++8WLRFKjvYjntApSCAE8ed5oGXfsn8ywhE3i3asDJMs/l3CfkkpvWpYIHYinSczuMDwBDGbiPEJK+MdpkZT/RaO7elAbSsKXVDLVd+KO5XvusYMwnu/caKX6kpOuIpRqzZfaPBQ817cznyZZC/3LrmuHFo5jSXfP68Wl+tJMkhgPgEl6jpjOeZR+QgkLdoPaCPYtN003Xh3hZcKY3vuY8qOjXOlcmCP7z5rXbIfaAOi58WV+Bnz6kAa/Xx69S59AN9u2c15AL0fQ1LlBUZ/w1aoUij8SjB0DevkCvFPoV0bBbW8C0dyqoTVtfRyOsQeTQe8g3dDu/+ByVQmGF0a7kiPwybeETz6ltRYlNHuowTQpRiP89DbV+my6cMhfn6x 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: AM0PR08MB3716 Original-Authentication-Results: welho.com; dkim=none (message not signed) header.d=none;welho.com; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT058.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)(396003)(376002)(346002)(46966005)(70206006)(5660300002)(6862004)(356005)(2906002)(186003)(26005)(55016002)(86362001)(81166007)(8936002)(336012)(82310400002)(8676002)(36906005)(33656002)(82740400003)(966005)(47076004)(316002)(9686003)(53546011)(6506007)(4326008)(52536014)(7696005)(70586007)(478600001)(83380400001); DIR:OUT; SFP:1101; X-MS-Office365-Filtering-Correlation-Id-Prvs: f670c16a-d0d5-4090-ec5c-08d81f260d66 X-Forefront-PRVS: 045315E1EE X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: uaxiQQeQ00DeLhCBshWxccJDi8cHB9Kd2k3BQt3sVybRaq+2rbDKMTAJ2XCfZcKCwOdMQYyoZYjGyTvRz6bA7aDHR+Fw+8BMhFG5nZjIMLadBQiQ/buFa2IfMYTeW1lkxT44gxgJHnuBQf+MwYC+PKFtU0UXoW6TeOgOUk2NUlSf/fGCclMJ1qrezM1gaVe5WyaLZfPq2UOwIbgMOKdKkJ6eunPBih3RsR76Xrt3gYMuy+VllWAmMP73ryF51AabGPf/cwSaqiJ3FqsQKqFirl4YsQtg/fmSi5s7r62iUtG9+mtoWPyVto/xJTBzcXd3V2o2iJoNpmoZB6pLYom3izHWSFP9tFmG/3KyonJTMt6Yw0ExAY4g5WAegoj271Pjqx0eHbBYXKMK+UyFhWlFWuIHzg/CTXCBO8MdnO7wBA6dnc3zCPxd+s0Am9xpaBDR/BG66hMhaGOr31bG5zSgNRy0wcy5YxhO/9nTRRTbuoU= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jul 2020 07:52:43.7013 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 54efdc1f-99c2-4983-df15-08d81f2611a8 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-AuthSource: VE1EUR03FT058.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5287 Archived-At: Subject: Re: [TLS] draft-ietf-tls-ticketrequests-05 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 Jul 2020 07:52:50 -0000 SGkgSWxhcmksDQoNClBsZWFzZSBzZWUgbXkgY29tbWVudHMgYmVsb3cuDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbGFyaWxpdXN2YWFyYUB3ZWxoby5jb20gPGlsYXJpbGl1 c3ZhYXJhQHdlbGhvLmNvbT4NClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxLCAyMDIwIDg6NDkgUE0N ClRvOiBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT4NCkNjOiA8 dGxzQGlldGYub3JnPiA8dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIGRyYWZ0LWll dGYtdGxzLXRpY2tldHJlcXVlc3RzLTA1DQoNCk9uIFdlZCwgSnVsIDAxLCAyMDIwIGF0IDA0OjUy OjE4UE0gKzAwMDAsIEhhbm5lcyBUc2Nob2ZlbmlnIHdyb3RlOg0KPiBIaSBUb21teSwgSGkgRGF2 aWQsIEhpIENocmlzLA0KPg0KPiBJIHJlYWQgdGhyb3VnaCB0aGUgZHJhZnQgYW5kIGhhdmUgYSBm ZXcgcXVlc3Rpb25zLg0KPg0KPiAxKSBJcyBpdCByZWFsbHkgbmVjZXNzYXJ5IGZvciB0aGUgY2xp ZW50IHRvIHVzZSB0d28gdmFsdWVzIHRvDQo+IGRpZmZlcmVudGlhdGUgdGhlIHRpY2tldHMgaXQg d2FudHMgd2l0aCBhIG5ldyBzZXNzaW9uIGFuZCB3aXRoDQo+IHJlc3VtcHRpb24uIEl0IGZlZWxz IGEgYml0IG92ZXItZGVzaWduZWQuIEkgd291bGQganVzdCBoYXZlIG9uZSB2YWx1ZQ0KPiBhbmQg dGhhdCBhbG9uZSB3b3VsZCBiZSBzdXBlciB1c2VmdWwgYWxyZWFkeS4NCg0KQ29uc2lkZXIgYSBj bGllbnQgdGhhdCBkb2VzOg0KDQotIFBhcmFsbGVsIGNvbm5lY3Rpb25zDQotIERvZXMgbm90IHJl dXNlIHRpY2tldHMNCg0KU3VjaCBjbGllbnQgbmVlZHMgZW5vdWdoIHRpY2tldHMgdG8gY292ZXIg dGhlIG11bHRpcGxlIGNvbm5lY3Rpb25zIGluIGNhc2Ugb2YgZnJlc2ggaGFuZHNoYWtlIChtaWdo dCBiZSA1LTEwIG9yIHNvKSwgYnV0IG9ubHkgbmVlZHMgdG8gcmVwbGFjZSB0aGUgdGlja2V0cyBm b3IgY3VycmVudCBjb25uZWN0aW9uICgxIG9yIDIpIGluIGNhc2Ugb2YgcmVzdW1wdGlvbi4gU28g YW55IHNpbmdsZSB2YWx1ZSB3aWxsIHJlc3VsdCBpbiBvdmVyc3VwcGx5IG9yIHVuZGVyc3VwcGx5 Lg0KDQpbSGFubmVzXSBUaGUgY2xpZW50IGlzIHByb2JhYmx5IGluIHRoZSBiZXN0IHBvc2l0aW9u IHRvIGtub3cgaG93IG1hbnkgdGlja2V0cyBpdCB3YW50cy4gSSBkb24ndCBzZWUgdGhlIGNhc2Ug d2hlcmUgaXQgaXMgbmVjZXNzYXJ5IHRvIGRpc3Rpbmd1aXNoIHR3byB0eXBlcyBvZiB0aWNrZXRz IHdpdGggdGhpcyBleHRlbnNpb24uIEkgd2FudCB0aGlzIHRvIGJlIGFzIHNpbXBsZSBhcyBwb3Nz aWJsZS4NCg0KPiAyKSBUaGlzIHNlbnRlbmNlIGNvbmZ1c2VzIG1lOg0KPiAiDQo+ICAgIFNlcnZl cnMgU0hPVUxEIE5PVCBzZW5kIG1vcmUgdGlja2V0cyB0aGFuIHJlcXVlc3RlZCBmb3IgdGhlIGhh bmRzaGFrZQ0KPiAgICB0eXBlIHNlbGVjdGVkIGJ5IHRoZSBzZXJ2ZXIgKHJlc3VtcHRpb24gb3Ig ZnVsbCBoYW5kc2hha2UpLg0KPiAgICBNb3Jlb3Zlciwgc2VydmVycyBTSE9VTEQgcGxhY2UgYSBs aW1pdCBvbiB0aGUgbnVtYmVyIG9mIHRpY2tldHMgdGhleQ0KPiAgICBhcmUgd2lsbGluZyB0byBz ZW5kLCB3aGV0aGVyIGZvciBmdWxsIGhhbmRzaGFrZXMgb3IgcmVzdW1wdGlvbnMsIHRvDQo+ICAg IHNhdmUgcmVzb3VyY2VzLg0KPiAiDQo+DQo+IFNob3VsZG4ndCB0aGUgc2VudGVuY2Ugc2F5Og0K PiAiDQo+ICAgIFNlcnZlcnMgU0hPVUxEIE5PVCBzZW5kIG1vcmUgdGlja2V0cyB0aGFuIHJlcXVl c3RlZCBmb3IgdGhlIGhhbmRzaGFrZQ0KPiAgICB0eXBlIChyZXN1bXB0aW9uIG9yIGZ1bGwgaGFu ZHNoYWtlKSBpbmRpY2F0ZWQgYnkgdGhlIGNsaWVudC4NCj4gIg0KDQpUaGUgc2VydmVyIG1pZ2h0 IG5vdCB3YW50IHRvIGFjdHVhbGx5IGhvbm9yIHJlcXVlc3QgdG8gc2VuZCAyNTUgdGlja2V0cy4N CkV2ZW4gaWYgdGlja2V0IG1pbnRpbmcgaXMgYSBmYXN0IG9wZXJhdGlvbiwgMjU1IG9mIHRoZW0g bWlnaHQgdGFrZSBub24tIHRyaXZpYWwgdGltZSAoYW5kIGJhbmR3aWR0aCkuDQoNCltIYW5uZXNd IEkgd2FzIHRyeWluZyB0byBwb2ludCBvdXQgdGhhdCB0aGVyZSBhcHBlYXJzIHRvIGJlIGEgYnVn IGluIHRoZSBzZW50ZW5jZS4NCihhdCBsZWFzdCB0aGF0J3MgbXkgdW5kZXJzdGFuZGluZyBhcyBh IG5vbi1FbmdsaXNoIG5hdGl2ZSBzcGVha2VyKQ0KDQo+IEV2ZW4gdGhlbiwgSSBiZWxpZXZlIHRo ZSBzZW50ZW5jZSBzaG91bGQgYWN0dWFsbHkgc2F5IE1VU1QgTk9UIGluc3RlYWQNCj4gb2YgU0hP VUxEIE5PVC4gSWYgdGhlIGNsaWVudCBpcyBhbHJlYWR5IHRha2luZyB0aGUgZWZmb3J0IHRvIGlu ZGljYXRlDQo+IHRoYXQgaXQgZG9lcyBub3Qgd2FudCBtb3JlIHRoYW4gYSBjZXJ0YWluIG51bWJl ciBvZiB0aWNrZXRzIHRoZW4gaXQNCj4gbWlnaHQgaGF2ZSBhIHJlYXNvbi4gSSBhbSB0aGlua2lu ZyBhYm91dCB0aGUgY2FzZSB3aGVyZSB0aGUgY2xpZW50DQo+IGluZGljYXRlcyB0aGF0IGl0IGRv ZXMgbm90IHdhbnQgYW55IHRpY2tldHMgdGhlbiBpdCB3b3VsZCBiZSBzdHJhbmdlDQo+IGZvciB0 aGUgc2VydmVyIGV4cHJlc3Npbmcgc3VwcG9ydCBmb3IgdGhlIGV4dGVuc2lvbiBhbmQgc3RpbGwg c2VuZA0KPiB0aWNrZXRzLg0KDQpJZiB0aGUgY2xpZW50IHNpZ25hbHMgMCB0aWNrZXRzIGZvciBo YW5kc2hha2UgYW5kIDAgdGlja2V0cyBmb3IgcmVzdW1wdGlvbiwgdGhlbiByZWFzb25hYmxlIGlu dGVycHJldGF0aW9uIGlzIHRoYXQgY2xpZW50IGRvZXMgbm90IHN1cHBvcnQgcmVzdW1wdGlvbiBh dCBhbGwsIGFuZCBpdCBpcyB3YXN0ZSBvZiByZXNvdXJjZXMgdG8gc2VuZCBpdCBhbnkgdGlja2V0 cy4NCg0KW0hhbm5lc10gQ29ycmVjdC4gVGhpcyBpcyB3aGF0IEkgYW0gc2F5aW5nLiBDdXJyZW50 bHkgdGhlIHRleHQgYWxsb3dzIHRoZSBzZXJ2ZXIgdG8gc3RpbGwgc2VuZCBhIHRpY2tldCBldmVu IHRob3VnaCB0aGUgY2xpZW50IHNheXMgImRvbid0IHNlbmQgaXQiLg0KDQpCdXQgaG93IHNob3Vs ZCBzZXJ2ZXIgaW50ZXJwcmV0IGNsaWVudCBzYXlpbmcgaXQgd2FudHMgMSB0aWNrZXQgZm9yIGZ1 bGwgaGFuZHNoYWtlIGFuZCAwIHRpY2tldHMgZm9yIHJlc3VtcHRpb24/IEEgcmVhc29uYWJsZSBp bnRlcnByZXRhdGlvbiBpcyB0aGF0IGNsaWVudCBkb2VzIHN1cHBvcnQgdGlja2V0cyBhbmQgaXMg aXMgd2lsbGluZyB0byByZXVzZSB0aWNrZXRzLg0KU28gaWYgdGhlIHNlcnZlciBpcyBub3Qgd2ls bGluZyB0byByZXVzZSB0aWNrZXRzLCB0aGUgbW9zdCByZWFzb25hYmxlIGFjdGlvbiBpcyB0byBz ZW5kIDEgdGlja2V0IHRvIHRoZSBjbGllbnQgb24gcmVzdW1wdGlvbiAoaWYgc2VydmVyIGlzIHdp bGxpbmcgdG8gcmV1c2UgdGlja2V0cywgdGhlIG1vc3QgcmVhc29uYWJsZSBhY3QgaXMgbm90IHNl bmQgYW55IHRpY2tldHMgb24gcmVzdW1wdGlvbikuDQoNCltIYW5uZXNdIElmIHRoZSBjbGllbnQg c2F5cyBpdCBvbmx5IHdhbnRzIG9uZSB0aWNrZXQgdGhlbiBoZSBzaG91bGQgb25seSBnZXQgb25l IHRpY2tldC4gSWYgaXQgd2FudHMgYW5vdGhlciB0aWNrZXQgd2hlbiBpdCByZXN1bWVzIHRoZSBz ZXNzaW9uIHRoZW4gdGhlIGNsaWVudCBjYW4gYXNrIGZvciBhbm90aGVyIHRpY2tldC4NCg0KQmFz aWNhbGx5LCB0aGVyZSBjYW4gYmUgZ29vZCByZWFzb25zIHRvIHNlbmQgbW9yZSB0aWNrZXRzIHRo YW4gcmVxdWVzdGVkLiBKdXN0IHRoYXQgbW9zdCBvZiB0aGUgdGltZSwgc2VuZGluZyBtb3JlIHRp Y2tldHMgd2lsbCBsZWFkIHRvIG92ZXJzdXBwbHkuDQoNCltIYW5uZXNdIEl0IHdvdWxkIGJlIGdv b2QgdG8gZGVjaWRlIHdobyBtYWtlcyB0aGUgZGVjaXNpb25zIGluIHRoaXMgcHJvY2Vzcy4gSWYg d2Ugd2FudCB0byBnaXZlIHRoZSBjbGllbnQgdGhlIHBvc3NpYmlsaXR5IHRvIGluZGljYXRlIGhv dyBtdWNoIGl0IHdhbnRzIHRvIHJlY2VpdmUgYW5kIHlvdSBjYW4gc3RpbGwgZ2l2ZSB0aGUgc2Vy dmVyIHRoZSBhYmlsaXR5IHRvIHNlbmQgbGVzcy4gQ3VycmVudGx5LCB0aGUgYXV0aG9ycyBkaWQg bm90IGRlY2lkZSB3aGF0IHRoZXkgd2FudC4NCg0KPiA0KSBJIGJlbGlldmUgaXQgd291bGQgbWFr ZSBzZW5zZSB0byBkZWZpbmUgYSB0aWNrZXQgZmxhZyBmb3IgdGhlIGNhc2UNCj4gd2hlcmUgdGhl IGNsaWVudCBkb2VzIG5vdCB3YW50IHRvIHJlY2VpdmUgYW55IHRpY2tldHMuDQoNClRoZSBzZW5z aWJsZSB3YXkgdG8gaW5kaWNhdGUgdGhhdCBpcyB0byBzZW5kICgwLDApIGFzIHJlcXVlc3RlZCB0 aWNrZXQgY291bnQuDQoNCltIYW5uZXNdIEkgYW0gc3VnZ2VzdGluZyB0byB1c2UgdGhlIG5ld2x5 IGRlZmluZWQgZmxhZ3MgZXh0ZW5zaW9uIGRyYWZ0IChzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdGxzLXRsc2ZsYWdzLTAyKSBmb3IgdGhpcyBwdXJwb3NlLg0KDQoN Cj4gNSkgSWYgYSBjbGllbnQgc2VuZHMgdGhlIENsaWVudFRpY2tldFJlcXVlc3QgZXh0ZW5zaW9u IGR1cmluZyB0aGUgZnVsbA0KPiBoYW5kc2hha2UgaXMgdGhlcmUgYW4gZXhwZWN0YXRpb24gdGhh dCBpdCBzZW5kcyBpdCBhZ2FpbiBpbiB0aGUNCj4gcmVzdW1wdGlvbiBleGNoYW5nZT8gV291bGQg eW91IGFzc3VtZSB0aGF0IHRoZSBzZXJ2ZXIgbWVtb3JpemVzIGhvdw0KPiBtYW55IHRpY2tldHMg dGhlIGNsaWVudCB3YW50ZWQgYWNyb3NzIHRoZSByZXN1bXB0aW9uIGhhbmRzaGFrZXM/DQo+IEZv ciBleGFtcGxlLCBpbiB0aGUgZnVsbCBoYW5kc2hha2UgSSB1c2UgdGhlIGV4dGVuc2lvbiBhbmQg aW5kaWNhdGUNCj4gdGhhdCBJIHdhbnQgNSB0aWNrZXRzLiBJIGdldCB0d28gdGlja2V0cyBmcm9t IHRoZSBzZXJ2ZXIuIFRoZW4sIEkgcnVuDQo+IGEgcmVzdW1wdGlvbiBoYW5kc2hha2Ugd2l0aG91 dCB0cmFuc21pdHRpbmcgdGhlIGV4dGVuc2lvbi4gSXMgdGhlDQo+IHNlcnZlciBleHBlY3RlZCB0 byByZW1lbWJlciB0byBzdGlsbCBzZW5kIDMgbW9yZSB0aWNrZXRzIHRpbGwgdGhlDQo+IHF1b3Rh IGlzIGV4aGF1c3RlZD8NCg0KSSBleHBlY3QgZWFjaCBjb25uZWN0aW9uIHRvIGhhdmUgaXRzIG93 biB0aWNrZXQgcmVxdWVzdCBjb3VudHMuDQoNCltIYW5uZXNdIEkgZG9uJ3QgdGhpbmsgSSBoYXZl IHJlYWQgdGhpcyBpbiB0aGUgZHJhZnQuDQoNCkluIGdlbmVyYWwsIGl0IGlzIHVuc2FmZSB0byBj YWNoZSBleHRlbnNpb24gdmFsdWVzIGFjcm9zcyBjb25uZWN0aW9ucyBpbiBzZXNzaW9uLg0KDQpb SGFubmVzXSBJcyBpdCB1bnNhZmU/IEluIGdlbmVyYWwsIHJlc3VtcHRpb24gaXMgYSBtZWNoYW5p c20gdG8gY2FjaGUgZGF0YSBhY3Jvc3MgY29ubmVjdGlvbnMuDQoNClN1cmUsIG9uZSBwcm9iYWJs eSBjYW4gbm90IGNhdXNlIGFueXRoaW5nIGJhZCB3aXRoIHRoaXMgZXh0ZW5zaW9uLCBidXQgd2l0 aCB0aGluZ3MgbGlrZSBzZXJ2ZXJfbmFtZSwgdmVyeSBiYWQgc3R1ZmYgY2FuIGhhcHBlbiBpZiB0 aG9zZSBhcmUgbm90IHRha2VuIGZyb20gY29ubmVjdGlvbiBoYW5kc2hha2UuDQoNCltIYW5uZXNd IEJ1dCBJIGFtIG5vdCB0YWxraW5nIGFib3V0IHNlcnZlcl9uYW1lIGJ1dCBpbnN0ZWFkIGFib3V0 IGhvdyBtYW55IHRpY2tldHMgYXJlIGxlZnQgdG8gYmUgc2VudCB0byB0aGUgY2xpZW50Lg0KDQo+ IDYpIFRoZSB0b3BpYyBvZiB3aGVuIHRvIHNlbmQgdGhlIHRpY2tldHMgaXMgc29tZXRoaW5nIHlv dSBtZW50aW9uIGluDQo+IHRoZSBkb2N1bWVudCBhbmQgaXQgaXMgaW5kZWVkIGFuIGlzc3VlLiBI YXZlIHlvdSB0aG91Z2h0IGFib3V0DQo+IGFsbG93aW5nIHRoZSBjbGllbnQgdG8gc2lnbmFsIHRv IHRoZSBzZXJ2ZXIgd2hlbiB0byBzZW5kIHRoZSB0aWNrZXRzPw0KPiBFdmVuIG1ha2luZyBhIGRp c3RpbmN0aW9uIGJldHdlZW4gInNlbmQgbWUgYWxsIHRpY2tldHMgaW4gYSBiYXRjaCIgYW5kDQo+ ICJzZW5kIG9uZSBhZnRlciB0aGUgb3RoZXIgd2l0aCBzb21lIHJlYXNvbmFibGUgdGltZSBpbiBi ZXR3ZWVuIiB3b3VsZA0KPiBiZSBoZWxwZnVsLg0KDQpXaGF0IHVzZWNhc2VzIHdvdWxkIHRoZXJl IGJlIGluIHNwcmVhZGluZyB0aWNrZXRzIGluIHRpbWU/DQoNCltIYW5uZXNdIElmIHlvdSB3YW50 IHRvIG9wZW4gcGFyYWxsZWwgY29ubmVjdGlvbnMgcXVpY2tseSB0aGVuIGl0IG1ha2VzIHNlbnNl IHRvIG9idGFpbiB0aGUgdGlja2V0cyBpbiBiYXRjaC4NCklmIHlvdSBkbyBub3Qgd2FudCB0byBv cGVuIHBhcmFsbGVsIGNvbm5lY3Rpb25zIGJ1dCByYXRoZXIgd2FudCB0byB1c2UgdGhlIHRpY2tl dCBtZWNoYW5pc20gdG8gcmVkdWNlIHRoZSBjb21wdXRhdGlvbmFsIG92ZXJoZWFkIGFuZCB5b3Ug YXJlIHdvcmtpbmcgb24gYSBsb3cgYmFuZHdpZHRoIGNvbm5lY3Rpb24gdGhlbiBpdCBpcyBiZXR0 ZXIgdG8gc3ByZWFkIHRoZSB0cmFuc21pc3Npb24gIGluIHRpbWUuIFRoZSBsYXR0ZXIgY2FzZSB3 b3VsZCBiZSBhbiBJb1Qgc2NlbmFyaW8gd2hpbGUgdGhlIGZvcm1lciBpcyBhIHdlYiBzY2VuYXJp by4NCg0KQ2lhbw0KSGFubmVzDQoNCg0KLUlsYXJpDQpJTVBPUlRBTlQgTk9USUNFOiBUaGUgY29u dGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGFyZSBjb25maWRlbnRpYWwg YW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQgZG8gbm90 IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVyc29uLCB1c2UgaXQgZm9yIGFu eSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVt LiBUaGFuayB5b3UuDQo= From nobody Fri Jul 3 15:20:58 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 222043A0993; Fri, 3 Jul 2020 15:20:51 -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: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tls@ietf.org Message-ID: <159381485106.7512.2312325708409175916@ietfa.amsl.com> Date: Fri, 03 Jul 2020 15:20:51 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tlsflags-03.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, 03 Jul 2020 22:20:51 -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 : A Flags Extension for TLS 1.3 Author : Yoav Nir Filename : draft-ietf-tls-tlsflags-03.txt Pages : 8 Date : 2020-07-03 Abstract: A number of extensions are proposed in the TLS working group that carry no interesting information except the 1-bit indication that a certain optional feature is supported. Such extensions take 4 octets each. This document defines a flags extension that can provide such indications at an average marginal cost of 1 bit each. More precisely, it provides as many flag extensions as needed at 4 + the order of the last set bit divided by 8. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tlsflags-03 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tlsflags-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tlsflags-03 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 Jul 5 00:32: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 07AF43A0AC6 for ; Sun, 5 Jul 2020 00:32:30 -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=cCntxIms; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SS2YeCoJ 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 brcuit8EaBuY for ; Sun, 5 Jul 2020 00:32:28 -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 ED9643A0AC8 for ; Sun, 5 Jul 2020 00:32:27 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 478AF5C0091 for ; Sun, 5 Jul 2020 03:32:27 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 05 Jul 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= fm3; bh=7aBjazT0/jp87Rnh4e2YDLq7X2ka71WZNPoEDrhpkYQ=; b=cCntxIms DF+9hQJNLNJvMhGtrErIlKFC3zcyxLg6VZIHISd1oXWpsUzvLkv5qLlck1aa3IJM TzOFTv42pvJPLJwChVkENCYku9olM8BVYcQxpVOdIEJgyOQBNYBQ2ZAYYDsCMUTt QmZE7SmzW35LnRRVMXJdN7cry4vZ820pqagao1MESnEK2OU10ksgcAkSOtZbJvPq vrkE69zt5d0p4i/sE4eW5t9G3sv5eu/AsxuD6eUwZKprKazLI3L52VsHn4eHQS8n HsK4h6/3dQh7ZI5TVbGmtq6GzEuBBSeNI52ygLJTpm3N00bS3lQzNGO5M7niKF7g pioGWmBnpNOrgw== 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=fm3; bh=7aBjazT0/jp87Rnh4e2YDLq7X2ka7 1WZNPoEDrhpkYQ=; b=SS2YeCoJgexe21uL3enVGjV2HSSV5+OcyX5ZuJLPsKQRd zPhhagelM8+skvA/eteMuqL2r1/U+EGcLtg9ZZmjzfy/OV1TBYG++KFyuzz/XNUR kV7v6/yKbVyAmpkbywnpj7Ttoj8Tx4rsH81nhwua9NfxES2OO+Oh6BQzAnkVPy6t 2zIJcjncNSC52LyGVHNOxmyLggxMoLXFHMqCPRAAtH/R0xM2ocJEn1asBbykmKSK ApkHI3HUUU6aBrez6IhWoRzV5ngUYuEXXWjTpMb5YEvRxfH9ysKocNOgqBoZl53T DaM1hm2ezEjCu/5t0jHYPq7aK4sZI1PqoxnKCCxpg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddtgddvfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtthgvrh hnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudeiteen ucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeehvddrudejhedrvdegjedrle efnecuvehluhhsthgvrhfuihiivgepvdenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az131.internal.cloudapp.net (unknown [52.175.247.93]) by mail.messagingengine.com (Postfix) with ESMTPA id ECDB130682FC for ; Sun, 5 Jul 2020 03:32:26 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============4999040075515707980==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: tls@ietf.org Message-Id: <20200705073226.ECDB130682FC@mailuser.nyi.internal> Date: Sun, 5 Jul 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, 05 Jul 2020 07:32:37 -0000 --===============4999040075515707980== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Issues ------ * tlswg/tls-exported-authenticator (+0/-1/=F0=9F=92=AC1) 1 issues received 1 new comments: - #63 WGLC Issue: Watson (1 by seanturner) https://github.com/tlswg/tls-exported-authenticator/issues/63=20 1 issues closed: - WGLC Issue: Watson https://github.com/tlswg/tls-exported-authenticator/= issues/63=20 Pull requests ------------- * tlswg/tls-flags (+1/-1/=F0=9F=92=AC0) 1 pull requests submitted: - Disallow unsolicited flag types in server extensions (by yoavnir) https://github.com/tlswg/tls-flags/pull/4=20 1 pull requests merged: - Disallow unsolicited flag types in server extensions https://github.com/tlswg/tls-flags/pull/4=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 --===============4999040075515707980== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday July 05, 2020

Issues

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

1 issues received 1 new comments:

1 issues closed:

Pull requests

tlswg/tls-flags (+1/-1/=F0=9F=92=AC0)

1 pull requests submitted:

1 pull requests merged:

Repositories tracked by this digest:

--===============4999040075515707980==-- From nobody Mon Jul 6 03:10: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 6A48D3A12D6; Mon, 6 Jul 2020 03:10:25 -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 ltrB3BGEbm47; Mon, 6 Jul 2020 03:10:23 -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 42AC23A12D7; Mon, 6 Jul 2020 03:10:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XsCgeGMBT7kM9zt5cumFXmjlvSjkfaRY0CLGS56txjRmvUY3jy0N9ZbxUEsGW/R/fNO1p/DJz37XLmUslTIm8ZosTbKasdJxUFuZu/htSHNPnz0B/uT4xei36E0NqZnvI3b3CS3LFosK487bnwrtQKHwaQ8QkfAUUALbRWKWb6FtKtncKQFWhxaQAVPSG+EiEtEDl6ShRYZZYf7JFBId4VgMDNzeizPiJMmw6yvpydUcqAGPFJNRw2cmj2Fzjj+Ikpeuxby23KKZAfY9kWEu9oVExsR4+sim1BVsyvq3qK7l03DZpfAuTUQNDIOMrZBWuWM2OUKFxiOZzQ0O5EZ0Lg== 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=JlH4rPFsf8F3OXieXok1kU7Xo8cLJFHCzoOC3z+cMGY=; b=ct9LQBmIhbBsY5ymTdixAA7TBfwI5wjbLM8PkLXxJ/ibhFWnH1QF5Uf70N2UQPigfvQZS7x30Kip2dQGIOGGgZQEAfYQqhDuZDtvhjHr6ayy1dV/uGXcRn8+g6xIeXGPeg/3d4hhNZbO1bhaKoNn+oLJuk2XYJrVyoHYRveGwNgdPR8gCjPtgkxv15BO1myhq6AVBMMIPY4bZRW/Mra4HMY/KHy9BHG1LaqIIOcFsBIkYKtYlFeX50sDv0jyvXWWcXWAclBaczWL4Tsj8tQv6HW/GBuQfP++2xq4IXakKLReSsqdMC18DauNgcSoytHnU5DK6hlZlWoY6MaU4X9ikw== 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=JlH4rPFsf8F3OXieXok1kU7Xo8cLJFHCzoOC3z+cMGY=; b=af8qsZC/sB8FTh3XqqLyLu642J4gaxynRAPjHmPmRrI45vr3HQs7dAjnE3EoQUZWRVoxHSfJ5pkjvKXr6u+hAoo0F/MIVtsTxydhodiWog1gjyDPzRlaWG3yXl+PntXjgcZMhMXi/R9u38Ee0X9V9JoI+T1/2BQ6XwfGBs65kEg= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR07MB4156.eurprd07.prod.outlook.com (2603:10a6:7:9b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.8; Mon, 6 Jul 2020 10:10:19 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::d6e:6298:19a7:7c99]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::d6e:6298:19a7:7c99%5]) with mapi id 15.20.3174.019; Mon, 6 Jul 2020 10:10:19 +0000 From: Mohit Sethi M To: Jim Schaad , "draft-ietf-tls-external-psk-guidance@ietf.org" CC: "TLS@ietf.org" Thread-Topic: Review of draft-ietf-tls-external-psk-guidance-00 Thread-Index: AQHWU32mq0e1idfoLE2Dgf3tNNTFWQ== Date: Mon, 6 Jul 2020 10:10:19 +0000 Message-ID: References: <045601d64fea$e0d7f800$a287e800$@augustcellars.com> In-Reply-To: <045601d64fea$e0d7f800$a287e800$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:140:10de:c8af:53f7:f0d6:ed49] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bcb719eb-a0fe-44dc-95ae-08d82194c985 x-ms-traffictypediagnostic: HE1PR07MB4156: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: R09JhqmV194Kqw4mB0Rwm0R6ONV3h/+uKlPm1/EJLrRsvoURdcCwQ8LOaRLCjrfKEO/E3RKhHGcEic8MvzDoP4i45qKrFzDKD8XGVVND6+kHIF2D/2sFcKKikGmNoivxAffer5pj5/Z04im0ea8Oxwb3izGwEcDsAP2x/jxwsNOeHKnVwq83LP2V1/Y5JOLc7+bSF4R11CtXFjGHCHuOK/+S5Dyr6P4SAngImEHPParPyfCJWUspdu7BWDto0O0xRiaTVBCD/ymTZOIcDjRFD+1ZRDIzhs8fHbSTHHY1hl48kB1wWgL+erujjRAaD9CipQ87mWR8gUX5/BveegE71t29vtMTGCH/2Qun5KJvR/Q0oSlXZ+PAz6/DlUsKVHKR x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(376002)(39860400002)(366004)(396003)(186003)(6512007)(31686004)(66446008)(31696002)(66556008)(64756008)(76116006)(86362001)(110136005)(53546011)(6506007)(316002)(66476007)(5660300002)(66946007)(83380400001)(2616005)(8936002)(2906002)(8676002)(71200400001)(6486002)(478600001)(4326008)(36756003)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: tSuRnExCv8130IXW2oOQ85bseMRzZNe7/UWjh55WgINRgA3zmYa4KGbSLLdBwwiyeBuuhwN1qvk+nUO0804myJbC6qpioKNxDHVMGuvTFGQQ2umb9crvL/TWsH/96YRLZXAdESbGHSIKQ2l7dgceER6rEYs8jdS5DY3Rs7h2SgKxC6fcghwHKoheRoNXhyQg9s0m9DXtZZ2xu65YlNsjaEfVOSL73IikFSlREwUUc2FT41Wg5bI2UJFgd7AdLoAshqJI8YvLYsm840vmzC70SIXzA+vvc6818dbicVFnsiUqdGaHdqfLtfgLOUGGKtU0YSQqHkvTDcy+tCIOKbYVb5W7nqA5+9B+EHunyjZcxh66VBtck0mDE4IuAHoh3eY9qBJVR21xc1yrepdjb/iVki2MVoGgEcVix3G8+looXy4V4iCLv7XvSX1i+yAFuGd9widfoVqh0mNeyIBb4meerdjgL47KonTu865wpMD5StZZrf9DSluTLmgG4gozYLEGcnPDsLnXlNMr1U+3WHrBLBHi/mLIxHWcXOPiBUi64bAoH+EmWXBiAgBvjqzJfe+I x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3386.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bcb719eb-a0fe-44dc-95ae-08d82194c985 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2020 10:10:19.1507 (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: VrNlt32f6r6iPmBlDwuR0gEp0NtvQEeEYin5ecV82f3QhdWBh/18VOOWnX0LBYVoRnp1Dt6BQGF26nB7s4Y3/1D2+98BvBm9rF+4w05r4+Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4156 Archived-At: Subject: Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00 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 Jul 2020 10:10:26 -0000 SGkgSmltLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuIEEgY2xhcmlmeWluZyBxdWVzdGlvbiBp bi1saW5lLg0KDQpPbiA3LzIvMjAgMTI6MDIgQU0sIEppbSBTY2hhYWQgd3JvdGU6DQo+ICogSW4g c2VjdGlvbiA0IHRoZXJlIGlzIGEgc3RhdGVtZW50IHRoYXQgc3dpdGNoaW5nIHRoZSByb2xlcyBv ZiBzZXJ2ZXJzDQo+IHdoaWNoIHVzZSBQU0tzIHdpbGwgbGVhZCB0byB3ZWFrZW5pbmcgb2Ygc2Vj dXJpdHkgcHJvcGVydGllcy4gIEFzIHRoaXMgaXMgYQ0KPiBjb21tb24gc2NlbmFyaW8gdG9kYXkg aW4gc2l0dWF0aW9ucyB3aGVyZSB5b3UgYXJlIGRvaW5nIHNlcnZlci10by1zZXJ2ZXINCj4gY29t bXVuaWNhdGlvbiwgaXQgd291bGQgYmUgdXNlZnVsIHRvIGRpc2N1c3MganVzdCBob3cgYW5kIGhv dyBtdWNoIHRoaXMNCj4gd2Vha2VuaW5nIG9jY3Vycy4gIFRoaXMgd2FzIGEgY29tcGxldGUgc3Vy cHJpc2UgdG8gbWUgYW5kIEkgZG9uJ3Qga25vdyBpZiBpdA0KPiB3YXMgc3VwcG9zZWQgdG8gYmUg b25lLiAgQXJlIHRoZXJlIG1pdGlnYXRpb25zIHRoYXQgY2FuIGJlIG1hZGU/DQo+DQo+ICogSW4g c2VjdGlvbiA3LCBUaGUgZmlyc3Qgc2VudGVuY2UgZG9lcyBub3QgcmVhZCwgYWxzbyBJdCBzZWVt cyBhIGJpdA0KPiBkaWZmaWN1bHQgdG8gaGF2ZSBhIE1VU1QgaW4gdGhlcmUgd2hlbiBtb3N0IG9m IHRoZSBpdGVtcyBiZWxvdyBhcmUgU0hPVUxEcy4NCj4gVGhhdCBzZWVtcyB0byBiZSBhIGRpc3Nv bmFuY2UuDQo+DQo+ICogU2VjdGlvbiA3LjEuMSAtIFRoZSBpZGVhIG9mIGhhdmluZyBkb21haW4g bmFtZSBzdWZmaXhlcyBvbiBQU0tzIHNlZW1zIHRvDQo+IG1lIHRvIGJlIGEgYmFkIGlkZWEgYXMg dGhpcyB3b3VsZCBzZWVtIHRvIGxvd2VyIHByaXZhY3kgbGV2ZWxzLg0KDQpJIHRoaW5rIHlvdSBh cmUgcmVmZXJyaW5nIHRvIHRoZSBQU0sgaWRlbnRpdHkgYW5kIG5vdCB0byB0aGUgUFNLLg0KDQpB cyB5b3Uga25vdywgdGhlIE5ldHdvcmsgQWNjZXNzIElkZW50aWZpZXJzIChOQUlzKSB1c2VkIGlu IEVBUCB0eXBpY2FsbHkgDQpuZWVkIHRoZSBkb21haW4gbmFtZSBzdWZmaXggZm9yIHJvYW1pbmcs IGZlZGVyYXRpb24sIGV0Yy4NCg0KSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgdGhlIG5hdHVy ZSBvZiB0aGUgcmVzdWx0aW5nIHByaXZhY3kgbG9zcy4gSXMgDQppdCB0aGF0IGEgcGFzc2l2ZSBh dHRhY2tlciBjYW4gbm93IGVhc2lseSBkZXRlcm1pbmUgdGhlIHNlcnZlciB3aGljaCANCmlzc3Vl ZCB0aGUgUFNLIGlkZW50aXR5IChhbmQgdGhlIHNlcnZlciB3aGVyZSBpdCB3aWxsIGV2ZW50dWFs bHkgYmUgdXNlZCk/DQoNCi0tTW9oaXQNCg0KPg0KPiAqIFNlY3Rpb24gNy4xLjIgLSBUaGVyZSBz ZWVtIHRvIG1lIHRvIGJlIHRocmVlIGRpZmZlcmVudCBwbGFjZXMgd2hlcmUNCj4gY29sbGlzaW9u cyB3aWxsIG9jY3VyLiAgVGhlIGltcG9ydGVyIGZ1bmN0aW9uIGNvdWxkIGdldCBhIGNvbGxpc2lv biwgdGhlcmUNCj4gY291bGQgYmUgY29sbGlzaW9ucyB3aXRoIHByZS1UTFMgMS4yIGV4dGVybmFs IGlkZW50aWZpZXJzIGFuZCB0aGVyZSBjb3VsZCBiZQ0KPiBjb2xsaXNpb24gd2l0aCByZXN1bXB0 aW9uIGtleXMuICBUaGVyZSBoYXMgYmVlbiBhIGh1Z2UgZGlzY3Vzc2lvbiBhYm91dCB0aGlzDQo+ IGluIHRoZSBFTVUgZ3JvdXAgYW5kIEkgZG9uJ3QgZmluZCB0aGUgdGV4dCBoZXJlIHRvIGJlIHNl bnNpYmxlIGluIHRlcm0gb2YNCj4gd2hldGhlciB0aGlzIGlzIG9yIGlzIG5vdCBhIHByb2JsZW0u DQo+DQo+ICogU2VjdGlvbiA3LjEuMiAtIE9uZSBvZiB0aGUgdGhpbmdzIHRoYXQgSSBrZXB0IG1l YW5pbmcgdG8gZ2V0IHRvIGFuZCBqdXN0DQo+IGhhdmVuJ3QgZG9uZSBzbyB5ZXQsIGlzIGRlYWxp bmcgd2l0aCB0aGUgcXVlc3Rpb24gb2YgY2FuIHRoZSBUTFMgS2V5IGJpbmRlcnMNCj4gaW4gdGhl IGhhbmRzaGFrZSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIG11bHRpcGxlIGtleXMgdGhhdCBoYXBw ZW4gdG8gaGF2ZQ0KPiB0aGUgc2FtZSBpZGVudGl0eS4gIFBlcmhhcHMgeW91IHNob3VsZCBsb29r IHRvIHNlZSBpZiB0aGlzIGRvZXMgd29yayBhbmQgaWYNCj4gaXQgaXMgc2FmZS4NCj4NCj4gSmlt DQo+DQo+DQo= From nobody Mon Jul 6 09:07: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 910B13A169B; Mon, 6 Jul 2020 09:07:13 -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, SPF_HELO_NONE=0.001, 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 Vt5VNUv5nJXT; Mon, 6 Jul 2020 09:07:10 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6740C3A1698; Mon, 6 Jul 2020 09:07:10 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 6 Jul 2020 09:06:59 -0700 From: Jim Schaad To: 'Mohit Sethi M' , CC: References: <045601d64fea$e0d7f800$a287e800$@augustcellars.com> In-Reply-To: Date: Mon, 6 Jul 2020 09:06:57 -0700 Message-ID: <006401d653af$7b029f80$7107de80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJKcycXoPg67pLJAT3vSEDhcRD9xgI5SobMqACnjoA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00 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 Jul 2020 16:07:14 -0000 > -----Original Message----- > From: Mohit Sethi M > Sent: Monday, July 6, 2020 3:10 AM > To: Jim Schaad ; draft-ietf-tls-external-psk- > guidance@ietf.org > Cc: tls@ietf.org > Subject: Re: Review of draft-ietf-tls-external-psk-guidance-00 >=20 > Hi Jim, >=20 > Thanks for the review. A clarifying question in-line. >=20 > On 7/2/20 12:02 AM, Jim Schaad wrote: > > * In section 4 there is a statement that switching the roles of > > servers which use PSKs will lead to weakening of security = properties. > > As this is a common scenario today in situations where you are doing > > server-to-server communication, it would be useful to discuss just = how > > and how much this weakening occurs. This was a complete surprise to > > me and I don't know if it was supposed to be one. Are there = mitigations that > can be made? > > > > * In section 7, The first sentence does not read, also It seems a = bit > > difficult to have a MUST in there when most of the items below are = SHOULDs. > > That seems to be a dissonance. > > > > * Section 7.1.1 - The idea of having domain name suffixes on PSKs > > seems to me to be a bad idea as this would seem to lower privacy = levels. >=20 > I think you are referring to the PSK identity and not to the PSK. >=20 > As you know, the Network Access Identifiers (NAIs) used in EAP = typically need > the domain name suffix for roaming, federation, etc. This is true, it is also true that EAP is very strong on saying that if = you have a choice, always send an anonymous version of the NAI if you = have to do it in the clear. This means that the domain can be used for = correlation, but you do not have the full identity for that purpose. I think that the EMU group is going to need to look at what level of = privacy protection it is going to desire when using a PSK, but in that = case there is no need for having a domain suffix as that information is = provided elsewhere. This might require keeping the TLS tunneling as an = option to deal with passive attacks. >=20 > I would like to understand the nature of the resulting privacy loss. = Is it that a > passive attacker can now easily determine the server which issued the = PSK > identity (and the server where it will eventually be used)? While it I true that at least some of the privacy information has = already been leaked in the PSK case, you know the address that is being = talked to and the PSK identity that is passed. If you look at using = thigs like ESNI, doing this would appear to potentially give away the = very information that is being hidden in that case. =20 The other problem with having domain based KIDs is that you could easily = get some amount of correlation between the KIDs that are assigned in = different domains. You could end up with mohit.ietf and mohit.amazon = and it would be quite reasonable to assume that both of those identities = are going to be for the same entity, just in different domains. Jim >=20 > --Mohit >=20 > > > > * Section 7.1.2 - There seem to me to be three different places = where > > collisions will occur. The importer function could get a collision, > > there could be collisions with pre-TLS 1.2 external identifiers and > > there could be collision with resumption keys. There has been a = huge > > discussion about this in the EMU group and I don't find the text = here > > to be sensible in term of whether this is or is not a problem. > > > > * Section 7.1.2 - One of the things that I kept meaning to get to = and > > just haven't done so yet, is dealing with the question of can the = TLS > > Key binders in the handshake to distinguish between multiple keys = that > > happen to have the same identity. Perhaps you should look to see if > > this does work and if it is safe. > > > > Jim > > > > From nobody Mon Jul 6 12:13: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 0A8163A09CC for ; Mon, 6 Jul 2020 12:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=unavailable 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 vW0xmsBODyrh for ; Mon, 6 Jul 2020 12:13:02 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 5619F3A09C6 for ; Mon, 6 Jul 2020 12:12:59 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id q7so33567934ljm.1 for ; Mon, 06 Jul 2020 12:12:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=gpF5lo7bAddunoqXtCAWWG5b8eN1zv6R+OQomFo6SZ8=; b=DgSos9Up71p445RYLMblv+4iOEeuJhxFKMqlmoz57ddQ2t2eCWSfxmtCymYm5KYoM6 SSqYYgkqwvJAEA6RacbOdUOB62eB89kD9LAHxyjJGugjwrj3ZY6CQyd6GzcwDTbM5rVB +/nrVqMXXRLQRLrvFY1XWp9ihGxIKWTTdL0k6qnRbVcwFroZTDC50bGf3uuG6jfv/No9 EcuJ5IQwD0mTrSZzc3BNQkuJkcG0v4DKK3FQRxaa8CJr+PnfPK/CCam+KnxdESXwi7VM fNAfDXlKQCkmaTGZlgjU6RFcS3enSGcThEMVFD9jwcXhdxd8fAXsXy2d5AI6YRn+Xg/V DDqw== 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=gpF5lo7bAddunoqXtCAWWG5b8eN1zv6R+OQomFo6SZ8=; b=ZdUnzBDHtIqHjVQUOdt4ly8Rcjir257DjJSpJDuAvqps7CxiWP/KOVWoTFUSeo3XBm S7hVP4rMRUFICdWjcyRiFKzLlh9AGDG36MHg5IshS45rxbFmis6+UN60L09MKD8Uwl6G wiYqLekSKGfRAk+B8fWfmOh+AyuCzRS7qM1nylEi6xsp2TOpNRBMyhOHo4IB+pC82e3O 0TwVanPEbEdCx0gUwmECpxAjtaNrN7ksBQWMjwf5aXXR0ZjomguuaaoG1ILzb8wmuzTy daic7ZDckyEfzWni2bSQQJtCwKGRyKepKi7Q4nAeEwopGS5cUCGFRlXJfXQ9G14vMswB qOZQ== X-Gm-Message-State: AOAM5320oXOc+Lrs8omHK5KpixZ4p77/retq+G6oDlcO0zADaC2iKmcO 6dK6V2lVT7W1solFnRljaOo8Lt3OQANevsjwryRXYCgydmY= X-Google-Smtp-Source: ABdhPJzmPpPGvJEaorPZysEl0nwIQ1kqmPpJqgYroNEiQxaSYNfsQ+J7eIrV3ky4TLi1eSQLO65Q8e1qSGD987TjfqM= X-Received: by 2002:a05:651c:106e:: with SMTP id y14mr1971885ljm.381.1594062776729; Mon, 06 Jul 2020 12:12:56 -0700 (PDT) MIME-Version: 1.0 From: Victor Vasiliev Date: Mon, 6 Jul 2020 15:12:45 -0400 Message-ID: To: "tls@ietf.org" , HTTP Working Group Content-Type: multipart/alternative; boundary="0000000000008f08ac05a9caa908" Archived-At: Subject: [TLS] Application-Layer Protocol Settings 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 Jul 2020 19:13:04 -0000 --0000000000008f08ac05a9caa908 Content-Type: text/plain; charset="UTF-8" Hello TLS and HTTP working groups, (QUIC WG bcc'd as this has been discussed there before) Currently, we use SETTINGS frames as an extensibility mechanism in HTTP/2 and HTTP/3. The SETTINGS frame is sent at the very beginning of TLS application data; this approach, while simple, has some drawbacks. The most notable one is that when SETTINGS are used to negotiate extensions, there is an entire round-trip where the client can send requests, but doesn't know yet about any server extensions, thus making any extension-dependant requests take an extra RTT. The proposed solution to this problem is to move HTTP SETTINGS frame into the TLS handshake. Here are some issues where this has been discussed before: - https://github.com/quicwg/base-drafts/issues/3086 - https://github.com/quicwg/base-drafts/issues/3622 - https://github.com/WICG/client-hints-infrastructure/pull/30 I wrote up a draft for the TLS extension that would solve this problem: https://tools.ietf.org/html/draft-vvv-tls-alps-00 I also wrote up a draft that explains how to use that extension with HTTP, and defines some settings (the ones discussed here ) that would not be possible without it: https://tools.ietf.org/html/draft-vvv-httpbis-alps-00 I would appreciate feedback on those drafts. Thanks, Victor. --0000000000008f08ac05a9caa908 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello TLS=C2=A0and HTTP working groups,

(QUIC= WG bcc'd as this has been discussed there before)

Currently, we use SETTINGS frames as an extensibility mechanism in HTTP/= 2 and HTTP/3.=C2=A0 The SETTINGS frame is sent at the very beginning of TLS= application data; this approach, while simple, has some drawbacks.=C2=A0 T= he most notable one is that when SETTINGS are used to negotiate extensions,= there is an entire round-trip where the client can send requests, but does= n't know yet about any server extensions, thus making any extension-dep= endant requests take an extra RTT.

The propose= d solution to this problem is to move HTTP SETTINGS frame into the TLS hand= shake.=C2=A0 Here are some issues where this has been discussed before:
I wrote up a draft for the TLS extension that would solve this p= roblem:=C2=A0https://tools.ietf.org/html/draft-vvv-tls-alps-00

I also wrote up a draft that explains how to us= e that extension with HTTP, and defines some settings (the ones discussed <= a href=3D"https://github.com/quicwg/base-drafts/issues/3622" target=3D"_bla= nk">here) that would not be possible without it:=C2=A0https://= tools.ietf.org/html/draft-vvv-httpbis-alps-00

= I would appreciate feedback on those drafts.

Thank= s,
=C2=A0 Victor.
--0000000000008f08ac05a9caa908-- From nobody Mon Jul 6 12:47: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 433183A09DF for ; Mon, 6 Jul 2020 12:47:44 -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 7jnbfwhVdERE for ; Mon, 6 Jul 2020 12:47:43 -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 D7D4A3A09DE for ; Mon, 6 Jul 2020 12:47:42 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id o4so23337342lfi.7 for ; Mon, 06 Jul 2020 12:47:42 -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; bh=AJ09914+ZVVoxABPZm06grn8fpB5p+PpCwfQyIeJ7Vs=; b=TbaWMIICdTdPFv16/jvh5uh6eYWcaVdJwJiGH2hhhkRyTdXZcZxl5+FP+PEFaz3N6t nwgkKgkFABJz5pnRNPBrB9oiO1vXCncqq+jRDW0OdC5IuliJf+F00qI5OOKpi6g7O1ir cMW/PIL3eFIdfIQkO7f5B264V70LwVy79W2kbkBHHNBP5cuHRR4Dt+TL/lZC83i8aHYL tBGWti+hVwUrrRn24RqhDHPxOM1BNX4/rCmmskAjVRjsnx3Gq0YfUuJCtPYZBvdTIKf6 VN6ZXzWN2oqFfftcPS7HMXtuSwC6DHwEioeuKxITSct+tOHBLOpiZIJNHimXeUdjTCr/ L3Xw== 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=AJ09914+ZVVoxABPZm06grn8fpB5p+PpCwfQyIeJ7Vs=; b=VFeaZVi1inyxOqfMnRIxLp8pnBGgu3qA/BSdAHOGthb+84h9+N6bV0F1K2V0Z/91b3 /bvtKGv1rhsSDzmKo6MNTjrqSNeWjcgugFjhbMP2w3axIZ3/yu6fj7qOZhJ9sSsiKJP3 nsIS0mzMoCVjFRg+ihuaAhMx0BEW3m/CFqqruXBlw07hOBlPSUw0qBXAevma9oDDoAJ4 U8GLRvYtP5m4lfNVjk22GuD0S/D6Bt7hwmU4gO7jv9+HAOnrUxNBp5L6MZpCW8z28vTr 6r4c2nUJDRY5fZGTtrm/Ai2Zl5aOQbVfQZXOVegBdvs6Y/xrjzTKPEGmOL3N5O5pA1m8 71rg== X-Gm-Message-State: AOAM530JVDBMauhiZv3HEijhspuhNryKoPwxUmX229OLO/ByHIDVUR2/ uRVGCJ4MoMhr3flZ6oJ3+yBTQA07dO2r5dWelivCFEadtaY= X-Google-Smtp-Source: ABdhPJwwv50LAe8MRGw/MydGNGn6NxNve8t3sGzg5K63+NMOG4mStzJRfcUGsAhqNZ18Trij4M1Wvrfun2Cj35jaB68= X-Received: by 2002:ac2:5691:: with SMTP id 17mr31403282lfr.209.1594064860562; Mon, 06 Jul 2020 12:47:40 -0700 (PDT) MIME-Version: 1.0 From: Watson Ladd Date: Mon, 6 Jul 2020 15:47:29 -0400 Message-ID: To: TLS List Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Review of draft-ietf-tls-external-psk-guidance 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 Jul 2020 19:47:44 -0000 Dear WG, I've taken a look at the draft and I think while its discussion of the properties and limitations of the external PSKs are good, I think the recommendations in section 7 could use some minor editorial work. In particular "SHOULD be combined with a DH exchange for forward secrecy." I would like to see rephrased to make clear that this is about the TLS PSK Key Exchange Mode. It wasn't immediately clear to me on first read, especially given the next sentence is (maybe) about key establishment outside of TLS. "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 SHOULD be employed". I have some questions about the meaning of this sentence. If it's about potential future additions to TLS ciphersuites, then it should be more clear that this doesn't currently exist and will in the future. If it's about designing an ad-hoc key distribution mechanism to be run one time ahead of PSK TLS, then I think we should say so more clearly and provide guidance on how to do this and think through the implications. Section 7.1.1. While it's a good idea to compare byte by byte, humans entering PSK identifiers may run into trouble due to all the ways visually identical strings may not actually be identical. It might be worth calling this out as a consideration. Sincerely, Watson Ladd From nobody Mon Jul 6 19:23: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 8DD763A090D for ; Mon, 6 Jul 2020 19:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 sZy0PXfEexo2 for ; Mon, 6 Jul 2020 19:23:35 -0700 (PDT) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 839FB3A090B for ; Mon, 6 Jul 2020 19:23:35 -0700 (PDT) Received: by mail-wr1-x431.google.com with SMTP id k6so43498880wrn.3 for ; Mon, 06 Jul 2020 19:23:35 -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 :cc; bh=9av0oJrmc4cUjawlYfgEm/4oTcqd3uVo09atCi+cC/c=; b=PFUsfeIIaUoVcDnube/gwJWH9ACiu4kOOzvXBglkazm5xWHxELEKP4GpPWKuewOg/W /NPPpDRoxOuMRxZ27CP0NhveutB2bF+IRgnCkEV0ps2SuK3NknLm4DMdbyM+mrqqjOaK SgZwruuVCNqOMlpjUSmIXX6NPzgWe5y31bmcr0n+gPTgGC1r37Hxefc4A4EJzy8bOwku 3mnpDXmYyEBOnO2mLGWhiMAaejozpgj7xfsOeZV6AtBUVqVsHfnMyMIdjGtbIefvAOYL Lh7G7Avm839idCOLx2+mNeRV3WSwoSpINOjmllSlJwv4MJ1cJXk5WeHpp1F0ZjgB8LLO YZNA== 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=9av0oJrmc4cUjawlYfgEm/4oTcqd3uVo09atCi+cC/c=; b=cNwsHomfvIGPf8NFKIw6Rhb9FsS9O4GWmmAYMBQhMWYkVtncUdC1qAhaikdkZusCUF 8Yp16p3ytZ/BXmw+q8whBLharQQMYzqO4lmRnMAwTmBAVF1SeWjS8IuuIpIWGnR1+DYy 7otKa+mFtfIbWdS6YMPBrN6XiJydqfLqEsxGAiPffyxFglGel4672wYl4KGiFQh1/UJP 9G67++6UnC7M/D75OLEMRbcIEVmi/qS8bdAh73BRijp+cSa5NIPf8VDxSwpJjXYxpn+8 o6CsmFFH/h7z7dxYYtcZPpVm8GMYb3NzYZLJvhLgxWrAXzrrxughvWkusi3/xMuNRt0E xX0w== X-Gm-Message-State: AOAM530qNp5IhftUwJNvMZ3QcuuNTiws1LoASPtj2t23GCC4vaYIyIFE ZLaYqe65oBg6vfzqhoyvU6sPGxA4bzDBuJbZy+M5AA== X-Google-Smtp-Source: ABdhPJwDp9gTlCZa01259gjmviGLUKHYujD9zVHNxa7Bj1cnxJMyuje387OkL9ELtWNTMDAfe09hEVSuqSxUQCrU0WQ= X-Received: by 2002:adf:e850:: with SMTP id d16mr53671621wrn.426.1594088613663; Mon, 06 Jul 2020 19:23:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Mon, 6 Jul 2020 22:23:22 -0400 Message-ID: To: Victor Vasiliev Cc: "tls@ietf.org" , HTTP Working Group Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000095000b05a9d0ad3b" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 02:23:37 -0000 --00000000000095000b05a9d0ad3b Content-Type: multipart/alternative; boundary="0000000000008f3d3205a9d0ad07" --0000000000008f3d3205a9d0ad07 Content-Type: text/plain; charset="UTF-8" Thanks for this draft. I believe this is an important problem for HTTP extensibility, and I'm glad to see work on a solution. It occurs to me that this solution requires pretty tight integration between the TLS termination and the HTTP backend. Some TLS load balancers already support ALPN, but they would have to be extended to support ALPS, and I would worry about the potential for skew between the TLS terminator's claimed settings and the backend's actual settings. The draft says 1. While the server is technically capable of sending configuration to the peer as soon as it sends its Finished message, most TLS implementations do not allow any application data to be sent until the Finished message is received from the client. Fixing this might require a change to some TLS implementations, but the change to implement ALPS also seems significant. The proposed 0-RTT interaction also seems like it would create a significant risk of skew when a load balancer is in use, if the backend settings can change. Deployments that can't guarantee uniform backends would have to disable 0-RTT (an unfortunate sacrifice for a feature that saves 1 RTT!). For load balancers, or any other situation where TLS and HTTP are loosely coupled, sending SETTINGS at 0.5-RTT would seem like a much simpler solution. I know the draft mentions a few cases where this doesn't work well, but perhaps there's a middle ground of some sort. For example: * If supporting generic 0.5-RTT forwarding is hard, TLS server implementations could offer a configuration to send an arbitrary fixed buffer at 0.5-RTT (depending on ALPN). No standards change is required. * The application protocol (here HTTP) could indicate what state is guaranteed to persist across session resumption. Although the preserved state here (SETTINGS) is ~static, in general this could include dynamic session state too. This would move the change to HTTP, instead of TLS. On Mon, Jul 6, 2020 at 3:13 PM Victor Vasiliev wrote: > Hello TLS and HTTP working groups, > > (QUIC WG bcc'd as this has been discussed there before) > > Currently, we use SETTINGS frames as an extensibility mechanism in HTTP/2 > and HTTP/3. The SETTINGS frame is sent at the very beginning of TLS > application data; this approach, while simple, has some drawbacks. The > most notable one is that when SETTINGS are used to negotiate extensions, > there is an entire round-trip where the client can send requests, but > doesn't know yet about any server extensions, thus making any > extension-dependant requests take an extra RTT. > > The proposed solution to this problem is to move HTTP SETTINGS frame into > the TLS handshake. Here are some issues where this has been discussed > before: > > - https://github.com/quicwg/base-drafts/issues/3086 > - https://github.com/quicwg/base-drafts/issues/3622 > - https://github.com/WICG/client-hints-infrastructure/pull/30 > > I wrote up a draft for the TLS extension that would solve this problem: > https://tools.ietf.org/html/draft-vvv-tls-alps-00 > > I also wrote up a draft that explains how to use that extension with HTTP, > and defines some settings (the ones discussed here > ) that would not be > possible without it: https://tools.ietf.org/html/draft-vvv-httpbis-alps-00 > > I would appreciate feedback on those drafts. > > Thanks, > Victor. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000008f3d3205a9d0ad07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for this draft.=C2=A0 I believe this is an importan= t problem for HTTP extensibility, and I'm glad to see work on a solutio= n.

It occurs to me that this solution requires pretty ti= ght integration between the TLS termination and the HTTP backend.=C2=A0 Som= e TLS load balancers already support ALPN, but they would have to be extend= ed to support ALPS, and I would worry about the potential for skew between = the TLS terminator's claimed settings and the backend's actual sett= ings.

The draft says
=C2=A0 =C2=A01.=C2= =A0 While the server is technically capable of sending configuration
=C2= =A0 =C2=A0 =C2=A0 =C2=A0to the peer as soon as it sends its Finished messag= e, most TLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0implementations do not allow any = application data to be sent
=C2=A0 =C2=A0 =C2=A0 =C2=A0until the Finishe= d message is received from the client.

Fixing = this might require a change to some TLS implementations, but the change to = implement ALPS also seems significant.

The propose= d 0-RTT interaction also seems like it would create a significant risk of s= kew when=C2=A0a load balancer is in use, if the backend settings can change= .=C2=A0 Deployments that can't guarantee uniform backends would have to= disable 0-RTT (an unfortunate sacrifice for a feature that saves 1 RTT!).<= /div>

For load balancers, or any other situation where T= LS and HTTP are loosely coupled, sending SETTINGS at 0.5-RTT would seem lik= e a much simpler solution.=C2=A0 I know the draft mentions a few cases wher= e this doesn't work well, but perhaps there's a middle ground of so= me sort.=C2=A0 For example:

* If supporting generi= c 0.5-RTT forwarding is hard, TLS server implementations could offer a conf= iguration to send an arbitrary fixed buffer at 0.5-RTT (depending on ALPN).= =C2=A0 No standards change is required.
* The application protoco= l (here HTTP) could indicate what state is guaranteed to persist across ses= sion resumption.=C2=A0 Although the preserved state here (SETTINGS) is ~sta= tic, in general this could include dynamic session state too.=C2=A0 This wo= uld move the change to HTTP, instead of TLS.

On Mon, Jul 6, 2020 at 3:= 13 PM Victor Vasiliev <vasilvv=3D40google.com@dmarc.ietf.org> wrote:
Hello TLS=C2=A0and HTTP= working groups,

(QUIC WG bcc'd as this has been discussed= there before)

Currently, we use SETTINGS frames as = an extensibility mechanism in HTTP/2 and HTTP/3.=C2=A0 The SETTINGS frame i= s sent at the very beginning of TLS application data; this approach, while = simple, has some drawbacks.=C2=A0 The most notable one is that when SETTING= S are used to negotiate extensions, there is an entire round-trip where the= client can send requests, but doesn't know yet about any server extens= ions, thus making any extension-dependant requests take an extra RTT.

The proposed solution to this problem is to move HT= TP SETTINGS frame into the TLS handshake.=C2=A0 Here are some issues where = this has been discussed before:

I also wrote up a draft that explains how to use that extension wit= h HTTP, and defines some settings (the ones discussed here) that w= ould not be possible without it:=C2=A0https://tools.ietf.org/html/= draft-vvv-httpbis-alps-00

I would appreciate f= eedback on those drafts.

Thanks,
=C2=A0 = Victor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000008f3d3205a9d0ad07-- --00000000000095000b05a9d0ad3b Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAH8qNflD4Mi9yKttXfRdHcwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDA2MDUwODIyMjhaFw0yMDEyMDIwODIyMjhaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kbyV9S0YLplF3kV 6t3GgD7IyHe8L29pJ7l+UR0Sj31uPgXOFdSSdTVwhPfQvxmB2OUDXWDgDtZdL2xu4DgHhrDyyOXT 8uDJqUCPw004ZSuUfUor1vz5u6+oYNfx2OTPTb81vtsQO2/khni3iAeQlKgO/rUI1c9+zvT6k3mR SZUypAlk/rCyG6NV7NMJMmOaU20/kPBXG297iP8+/F9w4xs+lyb3IkcSfoSUr3fVz7mYqESFato5 JnjRQGT2/f/ehxkc09jATqVGj9nyQMoD2GNPjiNnYyTVBwK5Ol/s9+E2VSL4TSLrgS2R07kY9zPi VOM3lhDDRnceboNSaqnfMwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUwJS1fB3cBxoLgZFatdIO9Vp5wOcwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQCC91PBn9rMxo8kSo1zNY2mxkTQDTVc0oyYk8s3y72y21IEp/d/+h1H VTCD2FR30aFUv8hTJkebJ5Z1/zue2L7sx/lLEOIHm9uYxyTkTWbKup3+XrE1vhODTHVx+ktMuOTY z447/fwjy4praSaFrQsOjTPbAoU6xuC8S2j2K2Yg6XQsctcKHKeAJjN6evZYChDaTBLmtYq9LTSH KVv3Et795vNK3gWKjhEkJtaBu4FfKLoopb1PENJ/zK6p/3edCLFgCRMSlbQ0SGtdVESSJcgezSwW WK2VB1Zcj2kyVzcL1pmV8m1xQuz2aBgUMn7peoVxKxYKP12gMtzeMvkzltYBMYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhAB/KjX5Q+DIvcirbV30XR3MA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCD8bPWFCbvrgvb4ihglEnHxdNG/+qEtodaL6bcLczpQFzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3MDcwMjIzMzRaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAHROMt1BM2kyphmonvD3cTxU3LrYlLFja9lLXhRdg5cHruZtVP6Ie/seu+WnuCbV7dCfkkRzG 69u92nyUOr6a11h93OW0zXyJus6sFS6bVYT2EmSNxTUe6eVC1zCAOY9ic4U+sciIuMM7WlGy4l+W arvP1BbkgJkanSvOua6KRLMKTxxSTgmib7W6c0i6ntfBduUb2RI38Tu6mQAZs4JjuryQoTfk2UbP R99cSOoSEuVBhq0EiawKpTXW2utPEA6dJHGMPAxGxPYRzAhIO5bk6uo0kRJLQVZgJyICktb/9ElB tsqUSnhgm+lm4q66MGwU67vdQzQLOw0UB8TdJnUEQQ== --00000000000095000b05a9d0ad3b-- From nobody Mon Jul 6 22:10: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 1FBB23A082E for ; Mon, 6 Jul 2020 22:10:14 -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=EFgZ8EAY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=egdaDnFj 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 vR2bMtcwdLUw for ; Mon, 6 Jul 2020 22:10:12 -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 5777B3A082D for ; Mon, 6 Jul 2020 22:10:12 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 732DF5C01A4; Tue, 7 Jul 2020 01:10:11 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 07 Jul 2020 01:10:11 -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=x8BQAiTVDwFhaxF8SWRzcO1LWksQWbq EmTt5IfMifKs=; b=EFgZ8EAYxGf3H83uec5wYkVyvIyhRmuTxTJGu+7QfW1xwHY E8aOa5T3Ya0rvGO2VqfdTnIGnKbiUGsiLsfDbwXyZIukFXMrLvtI7L7S2aJDrl4D 9DP/y0dyfpQNph8K2lYSjpcAdlh3vVsGZUqE836EwhFZvpvJJBz03YQW9ev32M4k z+5XV7eJxQzP2Oi11rSdPEofcP4Yypjf43NU4gSg05Rq/tpQ7goyLTnT66bmOLxs g+2gMmWJAt7WEnrZKXCcHCu7JlgqLgT5nPQRLGkZ2PQYMzPiiyou5R54en8tWVPN dTVSVhQkRGE7B3ZnIXfvrSsKiN70rkxqQFDFBlA== 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=fm3; bh=x8BQAi TVDwFhaxF8SWRzcO1LWksQWbqEmTt5IfMifKs=; b=egdaDnFj4Cm3bZVq5mDwiw lVq8t1Jroke6OrhCepnhYjzv9Am8+ZIvgWOT3sWbkdB8CNv5bP3pJ8J2Gm0/GeMX NF+kjzn6pNcODWfBS3C62wiheOzTTU5XNOdLlKbvgvPPjRtdm38LHed2/mCSSd6q Fe8jHPFSnocBvLi3qJrUoJoJAmsOaEQnLLBMVBfeRZziUSDQpBk6l+iD4YgfCcYq R7j/Ou4E0IxykKjT/f+B6bnM2Y/mA8uZfOz0v6cgNQDwLde8XLvInuIeEdJnUS39 TAvXXecmHWy4UGGVIYz1OsYM/Qs4jKIZCGyNhpZ7bSeNvNklVrBmiGrFPKNigU2w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeggdelgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepgfeuveevieffhfevheelie ejvdfgvdfhieettdffkeelkeegvdejgfeuudejleefnecuffhomhgrihhnpehhthhtphef thhhihhshhgrshhsohhmvghinhgtrhgvmhgvnhhtrghlvghffhgvtghtsggvhihonhguth hhrghtrdhinhdphhhtthhpshgvthhtihhnghhsfhhrrghmvghinhhtohhthhgvthhlshhh rghnughshhgrkhgvrdhhvghrvgdpghhithhhuhgsrdgtohhmpdhivghtfhdrohhrghenuc evlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhho figvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0EEBFE00B3; Tue, 7 Jul 2020 01:10:11 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668 Mime-Version: 1.0 Message-Id: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> In-Reply-To: References: Date: Tue, 07 Jul 2020 15:09:50 +1000 From: "Martin Thomson" To: tls@ietf.org, ietf-http-wg@w3.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 05:10:14 -0000 Hi Victor, For HTTP/2, this is essentially a noop, as endpoints are required to send SETTINGS immediately. Whether these bytes appear before Finished or not only affects endpoints that aren't inclined to wait for SETTINGS. This is somewhat complicated by the way that TLS 1.2 and TLS 1.3 differ, but if we assume TLS 1.3 here, any uncertainty is easily avoided. The main justification here appears to be based on the lack of 0.5-RTT send capability at some servers. I don't know how to assess whether the cost of greater integration with the TLS stack is preferable to fixing the 0.5-RTT send problem. For HTTP/3, this has some incremental effect beyond that. In effect, this deliberately introduces head-of-line blocking for settings. You can already do that in HTTP/3 if you are not prepared to deal with settings being in an ambiguous state. There's a little more determinism here in terms of where you look for the data that unblocks progress, but with retransmissions, this is not a difference worth worrying about. What this head-of-line blocking might allow is the development of new extensions that are unable to deal with uncertainty regarding SETTINGS. But isn't it also possible to address that problem by saying "if you implement extension X, then you MUST NOT send requests prior to receiving SETTINGS?" In QUIC, we decided that having the server repeat its configuration after 0-RTT was preferable to remembering it. This was after a non-trivial number of questions about that part of the specification. You seem to have taken the opposite approach. Is that deliberate? If so, why? On Tue, Jul 7, 2020, at 05:12, Victor Vasiliev wrote: > Hello TLS and HTTP working groups, > > (QUIC WG bcc'd as this has been discussed there before) > > Currently, we use SETTINGS frames as an extensibility mechanism in > HTTP/2 and HTTP/3. The SETTINGS frame is sent at the very beginning of > TLS application data; this approach, while simple, has some drawbacks. > The most notable one is that when SETTINGS are used to negotiate > extensions, there is an entire round-trip where the client can send > requests, but doesn't know yet about any server extensions, thus making > any extension-dependant requests take an extra RTT. > > The proposed solution to this problem is to move HTTP SETTINGS frame > into the TLS handshake. Here are some issues where this has been > discussed before: > * https://github.com/quicwg/base-drafts/issues/3086 > * https://github.com/quicwg/base-drafts/issues/3622 > * https://github.com/WICG/client-hints-infrastructure/pull/30 > I wrote up a draft for the TLS extension that would solve this problem: > https://tools.ietf.org/html/draft-vvv-tls-alps-00 > > I also wrote up a draft that explains how to use that extension with > HTTP, and defines some settings (the ones discussed here > ) that would not be > possible without it: > https://tools.ietf.org/html/draft-vvv-httpbis-alps-00 > > I would appreciate feedback on those drafts. > > Thanks, > Victor. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Jul 7 02:06: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 14A6E3A07A2 for ; Tue, 7 Jul 2020 02:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 43MkLubUMa89 for ; Tue, 7 Jul 2020 02:06:52 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3b.welho.com [83.102.41.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 802A93A07A0 for ; Tue, 7 Jul 2020 02:06:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 340CA16831; Tue, 7 Jul 2020 12:06:50 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id Sn67VxHMyBJe; Tue, 7 Jul 2020 12:06:50 +0300 (EEST) Received: from LK-Perkele-VII (84-253-234-84.bb.dnainternet.fi [84.253.234.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id E9C98286; Tue, 7 Jul 2020 12:06:46 +0300 (EEST) Date: Tue, 7 Jul 2020 12:06:46 +0300 From: Ilari Liusvaara To: Victor Vasiliev Cc: "tls@ietf.org" , HTTP Working Group Message-ID: <20200707090646.GA153416@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 09:06:55 -0000 On Mon, Jul 06, 2020 at 03:12:45PM -0400, Victor Vasiliev wrote: > Hello TLS and HTTP working groups, > > (QUIC WG bcc'd as this has been discussed there before) > > Currently, we use SETTINGS frames as an extensibility mechanism in HTTP/2 > and HTTP/3. The SETTINGS frame is sent at the very beginning of TLS > application data; this approach, while simple, has some drawbacks. The > most notable one is that when SETTINGS are used to negotiate extensions, > there is an entire round-trip where the client can send requests, but > doesn't know yet about any server extensions, thus making any > extension-dependant requests take an extra RTT. > > The proposed solution to this problem is to move HTTP SETTINGS frame into > the TLS handshake. Here are some issues where this has been discussed > before: I note at least two people have proposed just fixing TLS stacks to allow sending HTTP/2 SETTINGS in 0.5-RTT data. I used to have a server that actually did that (only if there was no CertificateRequest, due to interface limitations, this was not TLS library limitation). Unfortunately, this is not quite interoperable. There are HTTP/2 clients out there that just puke (with unexpected_message TLS alert, sent post-Finished) if one tries to send SETTINGS in 0.5-RTT data. I do not know what clients are involved (IIRC, I have heard about problems with at least Firefox and Chrome, versions unknown), but I would presume some sort of MITM by some client software is involved. That was quite painful to debug. Much nastier than e.g., debugging handshakes failing with illegal_parameter due to downnegotiation gone wrong due to server bug (this client is still using TLS 1.3 draft 23, and is still out there). -Ilari From avineshwar@gmail.com Sun Jun 28 18:57: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 8FBD43A1025 for ; Sun, 28 Jun 2020 18:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.838 X-Spam-Level: X-Spam-Status: No, score=-1.838 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, HTML_OBFUSCATE_05_10=0.26, 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 PGgWZpybuMrd for ; Sun, 28 Jun 2020 18:57:05 -0700 (PDT) Received: from mail-io1-xd42.google.com (mail-io1-xd42.google.com [IPv6:2607:f8b0:4864:20::d42]) (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 579783A1010 for ; Sun, 28 Jun 2020 18:57:05 -0700 (PDT) Received: by mail-io1-xd42.google.com with SMTP id y2so15531035ioy.3 for ; Sun, 28 Jun 2020 18:57:05 -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; bh=SLbOx0Ap78a+OWlEnO+tgFnKHgmzgz4T70GdoyPvJZ4=; b=WpdQyrXCHgUsScbQ+7eWdLZJfHM9rUHPN8mgumHL2mBtmWKXGbHoNzNEGzPCPqzYWB CkS8ck4ddFBjZTFZqwnoWIDoGu7dBF7OnRJ8kyCVN4I3LPk/dYDUOI5oUcyOxoquLVSU w1F5DwqgobDJLqkt7uYSOZMPjW4a1LNmlCd0EjeU7WARdMp3dIH072v9EtvUcfjvonpR RcIEL8xTFt6zB6wlWNVCPzie1M7iRmdO9Jfg0V+AQc1m3IA9wNj74/YPgKp5Ko+Wj3Uw Qq3faOQ416OYEB5KoXxxt2o4KAQK4tzU9BB9LHv3kAYjQJ20RXdFI6SYKkTth4FSHuJD eExA== 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=SLbOx0Ap78a+OWlEnO+tgFnKHgmzgz4T70GdoyPvJZ4=; b=ZMpqGOSyQ6nGF7VtSrLClL9v3vjny+jK9YDxRQbBL25ZEVaTgjAWh0GMWgOejDXRd5 Kd56ycB8wOzU79hDnq/Ze13Xi+VHf2w9fORe8X9NuIHvNriVntUtNgDOPuL9RDVrPNfq A7Sos76DKHoyFG5ceBgDBIUq+CjSmz+zE0kvrp/gIss0HBpRGK9lPnLFZ/50Kn8DJy6A Cd5h6nuasvqnnUnrfe940Hmb/xwIftqMJA7eZuUzZmxAAalq0edKN4bdofFsSda4VJ5s Db6uwwRGk3Ge49/EdkJpYB8wu1QJKDdA38EfDxGjjkDEAOQUd7jHOKTO5o5cNAQ0Kpyc goZA== X-Gm-Message-State: AOAM532F6hykALtVH3YjmF5fXqBjBAw9N+NHcxGqZJpUlSRFsVLZFakZ X/jnTk9f01PFb5Yz8gnLv2g98XxvsLI/ofA3QZU= X-Google-Smtp-Source: ABdhPJxTWmeol54Mn0YfPp+dGel2VV2nn0T2Sn2Y1dOomoRMT9BP/wK4pqbo3Qc7g/0FCxGzRjlcToVo4tl9tVtW/Do= X-Received: by 2002:a6b:730a:: with SMTP id e10mr15014790ioh.108.1593395824451; Sun, 28 Jun 2020 18:57:04 -0700 (PDT) MIME-Version: 1.0 From: Avineshwar Singh Date: Sun, 28 Jun 2020 20:56:53 -0500 Message-ID: To: draft-ietf-pkix-rfc3280bis@ietf.org Content-Type: multipart/alternative; boundary="0000000000001a63e105a92f601c" Archived-At: X-Mailman-Approved-At: Tue, 07 Jul 2020 07:54:08 -0700 Subject: [TLS] A query related to support the hard-failing when subdomain1.example.com tries to front example.com? 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, 29 Jun 2020 02:00:32 -0000 --0000000000001a63e105a92f601c Content-Type: text/plain; charset="UTF-8" In the context of TLS, what can be done to detect a MITM by *subdomain1.example.com * of *example.com *? Can the TLS checks fail (assuming cname contains wildcard)?. Let's say public key pinning isn't used. I could think of *blacklistedSubjectAlternativeName* such that they serve as an overriding *blacklist of SANs*. This may reinforce: - explicit intent - protection insider compromise/threats - undermine a controlling entities' *theoretical* powers --0000000000001a63e105a92f601c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the context of TLS, what can be done to detect a MITM b= y subdomain1.example.com=C2=A0of example.com?

<= /div>

Can the TLS checks fail (assuming cname c= ontains wildcard)?. Let's say public key pinning isn't used.

I could think of=C2=A0blacklistedSubjectAlternativeName=C2=A0such that they= serve as an overriding blacklist of SANs. This may reinforce= :

  • explicit intent

    • =

  • protecti= on insider compromise/threats

  • undermine a controlling entities' = theoretical powers

--0000000000001a63e105a92f601c-- From nobody Tue Jul 7 12:11: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 ED0143A07FB for ; Tue, 7 Jul 2020 12:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 AXaV5QnZRCQT for ; Tue, 7 Jul 2020 12:11:37 -0700 (PDT) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (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 D91DD3A07CA for ; Tue, 7 Jul 2020 12:11:37 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id cv18so1195095pjb.1 for ; Tue, 07 Jul 2020 12:11:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AxSEHCyku+hRfWl/qyihecqy+ApKO24ym4hGsL8IhY8=; b=aPlWccx7LQNlF1FT2bQz5FPfmUllhE+/Kw42HFwg/LVrW2SikUdMc4J/Fd86lzCRO3 oL6OtdEcMxfczfPpkWChfn2tw4hUC0d4m+KLOzfBK4UIGFbAaXB2QJ6IY0t1ToeZKbfw fH2Ka6kJ/TcO7Gg2npBZI9pGgTDZxVBcFccZ0= 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=AxSEHCyku+hRfWl/qyihecqy+ApKO24ym4hGsL8IhY8=; b=kbGrfuF0EdupTiSxXIXfIhV4Na6CsyEpjybdWr2qA43r4bJSGn6yRN6gzytc4NSA0l nLLkJI1vXbjuZcVk4Tk3Te+GFfmPxXNva5ZEogGwjjupotnkaG/PQpH+UrFD+ruhysMW 49viqecmonUkcWV+ANNP0He6DGJxmZhUQYJ8Y+QWZOOMlNazB8MPD9ZYclDDd43GWDYy WdUj6lshKE8VIdnwtKxbi2ybK63eLPDCLXXcIEtbyhBIVthfq/3KYq4eIfH4UAfV3A7M E/ksFtJ9RKYVc9o9e4E+Xu2ScCa9rA4CMOhDdS219GytUv2fwwXF16VCFmXLdslFmwS/ Gtig== X-Gm-Message-State: AOAM5334b4s0knm8rJvYWy13CTuzBIKzVcJ+HNS6+bIl4p58ijDkjRsU HtZCaCv6a7zW0qXaZ3S4g1GuUnSCMn0+0SgpuGg8SX1JqQ== X-Google-Smtp-Source: ABdhPJxEg9DqPNb8jEZMpTCglVD/haa/eMwEMsRxV31NeydCQOv1Z5Mg106ZFeTfUvZtMlA3u21v29ZvTj0kWUJne3s= X-Received: by 2002:a17:90a:aa83:: with SMTP id l3mr5755713pjq.73.1594149097000; Tue, 07 Jul 2020 12:11:37 -0700 (PDT) MIME-Version: 1.0 References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> In-Reply-To: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> From: David Benjamin Date: Tue, 7 Jul 2020 15:11:20 -0400 Message-ID: To: Martin Thomson Cc: "" , HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000a5b84605a9dec24a" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 19:11:40 -0000 --000000000000a5b84605a9dec24a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Martin, You=E2=80=99re right that this is closely related to half-RTT data. However= , I don=E2=80=99t think this is a no-op for HTTP/2. I=E2=80=99m not aware of HTTP/2 clients that wait for the SETTINGS frame to= day. Doing so costs a round-trip with servers that don=E2=80=99t send SETTINGS i= n half-RTT, and there's no indicator for whether the server will send it. I=E2=80=99ll see about testing some sites here and will report back, but I = expect most do not. We (correctly) designed TLS 1.3 as a drop-in replacement for TLS 1.2, which means that we don't get to key new I/O patterns on it. Half-RTT data is a very weird state and wouldn=E2=80=99t get used by defaul= t. This is the problem with =E2=80=9Cno standards change is required=E2=80=9D style= of thinking around simply changing I/O patterns. A protocol is more than its wire image. Changing the I/O patterns is a protocol change. This means we cannot get efficient and reliable feature negotiation today. Moreover, HTTP/2 servers today may send ServerHello..Finished without application data in their first flight, so we need *some* change to the TLS flight, be it ALPS or just some indicator. Let=E2=80=99s look at what it=E2=80=99d take to make half-RTT SETTINGS work= . We need some =E2=80=9CI will send half-RTT data, so you can safely wait for it=E2=80=9D = indicator. Then the client needs to know when it is done waiting. We could say it=E2=80=99s= one SETTINGS frame, but that only allows integer values. (Related: EXTENDED_SETTINGS and discussion .) Those currently need separate frames, and one cannot wait for the absence of a frame. Maybe we need an HTTP-level SETTINGS_WILL_SEND_HALF_RTT_XYZ_FRAME indicator to keep the delimiter in HTTP, or a TLS-level =E2=80=9Cend of half-RTT data=E2=80=9D delimiter. (Now= consider how that works in QUIC...) Next we need to tackle 0-RTT. Waiting for half-RTT data costs a round-trip in 0-RTT, so we need something to persist across the session, with semantics around mismatch and whatnot. (Another TLS-visible change.) Anything persisted in the session must have bounded size, and be delivered in something ordered with NewSessionTicket. If we place those bytes inside the handshake, we=E2=80=99ve reinvented ALPS= . If we place them outside, the NewSessionTicket ordering becomes complex, especially in QUIC . To your question about the server repeating its configuration vs. the client remembering it, I believe the issue was exactly that ordering mishap. ALPS avoids this because EncryptedExtensions and NewSessionTicket are ordered. On top of this, the half-RTT point in a non-0-RTT connection is a weird state. Not all connection properties (e.g. client certs) have been established yet, and writes out of turn are tricky. This message discusses some of the challenges here. I would argue something like ALPS is the settings design we should have had all along. David On Tue, Jul 7, 2020 at 1:10 AM Martin Thomson wrote: > Hi Victor, > > For HTTP/2, this is essentially a noop, as endpoints are required to send > SETTINGS immediately. Whether these bytes appear before Finished or not > only affects endpoints that aren't inclined to wait for SETTINGS. This i= s > somewhat complicated by the way that TLS 1.2 and TLS 1.3 differ, but if w= e > assume TLS 1.3 here, any uncertainty is easily avoided. > > The main justification here appears to be based on the lack of 0.5-RTT > send capability at some servers. I don't know how to assess whether the > cost of greater integration with the TLS stack is preferable to fixing th= e > 0.5-RTT send problem. > > For HTTP/3, this has some incremental effect beyond that. In effect, thi= s > deliberately introduces head-of-line blocking for settings. You can > already do that in HTTP/3 if you are not prepared to deal with settings > being in an ambiguous state. There's a little more determinism here in > terms of where you look for the data that unblocks progress, but with > retransmissions, this is not a difference worth worrying about. > > What this head-of-line blocking might allow is the development of new > extensions that are unable to deal with uncertainty regarding SETTINGS. > But isn't it also possible to address that problem by saying "if you > implement extension X, then you MUST NOT send requests prior to receiving > SETTINGS?" > > In QUIC, we decided that having the server repeat its configuration after > 0-RTT was preferable to remembering it. This was after a non-trivial > number of questions about that part of the specification. You seem to ha= ve > taken the opposite approach. Is that deliberate? If so, why? > > On Tue, Jul 7, 2020, at 05:12, Victor Vasiliev wrote: > > Hello TLS and HTTP working groups, > > > > (QUIC WG bcc'd as this has been discussed there before) > > > > Currently, we use SETTINGS frames as an extensibility mechanism in > > HTTP/2 and HTTP/3. The SETTINGS frame is sent at the very beginning of > > TLS application data; this approach, while simple, has some drawbacks. > > The most notable one is that when SETTINGS are used to negotiate > > extensions, there is an entire round-trip where the client can send > > requests, but doesn't know yet about any server extensions, thus making > > any extension-dependant requests take an extra RTT. > > > > The proposed solution to this problem is to move HTTP SETTINGS frame > > into the TLS handshake. Here are some issues where this has been > > discussed before: > > * https://github.com/quicwg/base-drafts/issues/3086 > > * https://github.com/quicwg/base-drafts/issues/3622 > > * https://github.com/WICG/client-hints-infrastructure/pull/30 > > I wrote up a draft for the TLS extension that would solve this problem: > > https://tools.ietf.org/html/draft-vvv-tls-alps-00 > > > > I also wrote up a draft that explains how to use that extension with > > HTTP, and defines some settings (the ones discussed here > > ) that would not be > > possible without it: > > https://tools.ietf.org/html/draft-vvv-httpbis-alps-00 > > > > I would appreciate feedback on those drafts. > > > > Thanks, > > Victor. > > _______________________________________________ > > 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 > --000000000000a5b84605a9dec24a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Martin,

You=E2=80=99re right that this is closel= y related to half-RTT data. However, I don=E2=80=99t think this is a no-op = for HTTP/2.

I=E2=80=99m not aware of HTTP/2 clients that wait for th= e SETTINGS frame today. Doing so costs a round-trip with servers that don= =E2=80=99t send SETTINGS in half-RTT, and there's no indicator for whet= her the server will send it. I=E2=80=99ll see about testing some sites here= and will report back, but I expect most do not. We (correctly) designed TL= S 1.3 as a drop-in replacement for TLS 1.2, which means that we don't g= et to key new I/O patterns on it. Half-RTT data is a very weird state and w= ouldn=E2=80=99t get used by default. This is the problem with =E2=80=9Cno s= tandards change is required=E2=80=9D style of thinking around simply changi= ng I/O patterns. A protocol is more than its wire image. Changing the I/O p= atterns is a protocol change.

This means we cannot get efficient and= reliable feature negotiation today. Moreover, HTTP/2 servers today may sen= d ServerHello..Finished without application data in their first flight, so = we need some change to the TLS flight, be it ALPS or just some indic= ator.

Let=E2=80=99s look at what it=E2=80=99d take to make half-RTT = SETTINGS work. We need some =E2=80=9CI will send half-RTT data, so you can = safely wait for it=E2=80=9D indicator. Then the client needs to know when i= t is done waiting. We could say it=E2=80=99s one SETTINGS frame, but that o= nly allows integer values. (Related: EXTENDED_SETTINGS and discussion.) Those currently need separate frames, and one cannot= wait for the absence of a frame. Maybe we need an HTTP-level SETTINGS_WILL= _SEND_HALF_RTT_XYZ_FRAME indicator to keep the delimiter in HTTP, or a TLS-= level =E2=80=9Cend of half-RTT data=E2=80=9D delimiter. (Now consider how t= hat works in QUIC...)

Next we need to tackle 0-RTT. Waiting for half= -RTT data costs a round-trip in 0-RTT, so we need something to persist acro= ss the session, with semantics around mismatch and whatnot. (Another TLS-vi= sible change.) Anything persisted in the session must have bounded size, an= d be delivered in something ordered with NewSessionTicket.

If we pla= ce those bytes inside the handshake, we=E2=80=99ve reinvented ALPS. If we p= lace them outside, the NewSessionTicket ordering becomes complex, especiall= y in QUIC. To your question about the server repeating its co= nfiguration vs. the client remembering it, I believe the issue was exactly = that ordering mishap. ALPS avoids this because EncryptedExtensions and NewS= essionTicket are ordered.

On top of this, the half-RTT point in a no= n-0-RTT connection is a weird state. Not all connection properties (e.g. cl= ient certs) have been established yet, and writes out of turn are tricky. <= a href=3D"https://mailarchive.ietf.org/arch/msg/tls/hymweZ66b2C8nnYyXF8cwj7= qopc/">This message=C2=A0discusses some of the challenges here. I would= argue something like ALPS is the settings design we should have had all al= ong.

David

On Tue, Jul 7, 2020 at 1:10 AM Martin Thomson <mt@lowentropy.net> wrote:
=
Hi Victor,

For HTTP/2, this is essentially a noop, as endpoints are required to send S= ETTINGS immediately.=C2=A0 Whether these bytes appear before Finished or no= t only affects endpoints that aren't inclined to wait for SETTINGS.=C2= =A0 This is somewhat complicated by the way that TLS 1.2 and TLS 1.3 differ= , but if we assume TLS 1.3 here, any uncertainty is easily avoided.

The main justification here appears to be based on the lack of 0.5-RTT send= capability at some servers.=C2=A0 I don't know how to assess whether t= he cost of greater integration with the TLS stack is preferable to fixing t= he 0.5-RTT send problem.

For HTTP/3, this has some incremental effect beyond that.=C2=A0 In effect, = this deliberately introduces head-of-line blocking for settings.=C2=A0 You = can already do that in HTTP/3 if you are not prepared to deal with settings= being in an ambiguous state.=C2=A0 There's a little more determinism h= ere in terms of where you look for the data that unblocks progress, but wit= h retransmissions, this is not a difference worth worrying about.

What this head-of-line blocking might allow is the development of new exten= sions that are unable to deal with uncertainty regarding SETTINGS.=C2=A0 Bu= t isn't it also possible to address that problem by saying "if you= implement extension X, then you MUST NOT send requests prior to receiving = SETTINGS?"

In QUIC, we decided that having the server repeat its configuration after 0= -RTT was preferable to remembering it.=C2=A0 This was after a non-trivial n= umber of questions about that part of the specification.=C2=A0 You seem to = have taken the opposite approach.=C2=A0 Is that deliberate?=C2=A0 If so, wh= y?

On Tue, Jul 7, 2020, at 05:12, Victor Vasiliev wrote:
> Hello TLS and HTTP working groups,
>
> (QUIC WG bcc'd as this has been discussed there before)
>
> Currently, we use SETTINGS frames as an extensibility mechanism in > HTTP/2 and HTTP/3. The SETTINGS frame is sent at the very beginning of=
> TLS application data; this approach, while simple, has some drawbacks.=
> The most notable one is that when SETTINGS are used to negotiate
> extensions, there is an entire round-trip where the client can send > requests, but doesn't know yet about any server extensions, thus m= aking
> any extension-dependant requests take an extra RTT.
>
> The proposed solution to this problem is to move HTTP SETTINGS frame <= br> > into the TLS handshake. Here are some issues where this has been
> discussed before:
>=C2=A0 * https://github.com/quicwg/base-drafts/= issues/3086
>=C2=A0 * https://github.com/quicwg/base-drafts/= issues/3622
>=C2=A0 * https://github.com/WICG/clie= nt-hints-infrastructure/pull/30
> I wrote up a draft for the TLS extension that would solve this problem= :
> https://tools.ietf.org/html/draft-vvv-tls-alps= -00
>
> I also wrote up a draft that explains how to use that extension with <= br> > HTTP, and defines some settings (the ones discussed here
> <https://github.com/quicwg/base-drafts/iss= ues/3622>) that would not be
> possible without it:
> https://tools.ietf.org/html/draft-vvv-htt= pbis-alps-00
>
> I would appreciate feedback on those drafts.
>
> Thanks,
>=C2=A0 Victor.
> _______________________________________________
> 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
--000000000000a5b84605a9dec24a-- From nobody Tue Jul 7 12:14: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 17C2B3A07CA for ; Tue, 7 Jul 2020 12:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 BaHY0A4C6vVB for ; Tue, 7 Jul 2020 12:14:31 -0700 (PDT) Received: from mail-pj1-x1044.google.com (mail-pj1-x1044.google.com [IPv6:2607:f8b0:4864:20::1044]) (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 79DF33A07FB for ; Tue, 7 Jul 2020 12:14:31 -0700 (PDT) Received: by mail-pj1-x1044.google.com with SMTP id cv18so1197035pjb.1 for ; Tue, 07 Jul 2020 12:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pEoX3OXK7ndDnHp20diuDcqRDQcv9rICLKjdjRj8CWY=; b=TFSSIICd4Qv96KPHos00q+37R5eoRvQzgxhr0jlAXypoobamtujek44zyK1bBaK7C+ Bz351D6KlD3spw5q3m7brRdUT+gmBXLQulZCFwNm/pkkrHhNxyU7SfrH7Ch4oDV80gKw NtwNtE+0WlVd41BROqmV63uPC5TK3me4OCmTE= 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=pEoX3OXK7ndDnHp20diuDcqRDQcv9rICLKjdjRj8CWY=; b=Ya100vH7ZoGx46TmDg7xyFEcfQ9MrSMSHsAL4+EVJcDXQBc1LuSMOm0JyPd0PD0KaA OWY5ge/r6cMOuk4bwgln0PlUarIkUa/OeHhAIGf7vXOPTxahDfL9F3A2yoZ6aB2Dwex0 9Zo/YcYBUSiarOao28iQsKwgzfFLtkiiRvtsI53Apu7mlhX2IpWLy9dcY9BBavMCnhI+ DhI7rf11L+K7X79+DBji/RsvA4WxdjC0voQv0F2xHh83CE06MF7MDVanVR4fhcRu82ta 0FTMUKmAhZLILuuLJwXl1SnWuy4IJsu367I/J/A+YGYLaxTkhyJvNTQeqXPz6LJdd5Rn qsGg== X-Gm-Message-State: AOAM533B9Rw4GSKf6ZIz7Y5fzp4uqBhZNy83AD0KOlhoaH/OKRRobah0 Jur18IUj87CexlvnfsN8kr8rr4HHmOlC97sPy++u X-Google-Smtp-Source: ABdhPJwXcAaC5J+EsZKHg2wjMCGiCoZHSFRkbW9FNGOq3sXexRxzeQq9rSiMAZGeIgU2SwV77WYwesmh+9ipu2Fdm/w= X-Received: by 2002:a17:90a:a78b:: with SMTP id f11mr5554838pjq.42.1594149270807; Tue, 07 Jul 2020 12:14:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Tue, 7 Jul 2020 15:14:14 -0400 Message-ID: To: Ben Schwartz Cc: Victor Vasiliev , "tls@ietf.org" , HTTP Working Group Content-Type: multipart/alternative; boundary="00000000000001ad4b05a9decd49" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 19:14:33 -0000 --00000000000001ad4b05a9decd49 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ben, (I=E2=80=99ve covered many of these points in my reply to Martin, so you ma= y want to read that first.) Any solution here involves a TLS change, even for servers which currently send half-RTT settings. See my reply to Martin for why. The question then is which is more complex. As a TLS implementor, ALPS would be a very straightforward extension to implement, while the work involved to make half-RTT SETTINGS work would be a mess. Transparently sending a fixed buffer of half-RTT data was indeed something we=E2=80=99d thought about and rejected. In some circumstances, it may caus= e deadlocks with TCP . And we still need an indicator for the client to safely wait for it. I/O patterns are part of the protocol. It=E2=80=99s also not the case that non-uniform backends must disable 0-RTT= . That is what 0-RTT rejection logic is for. Non-uniform deployments may get less 0-RTT than a uniform deployment, but it won=E2=80=99t break things. This is= already the case (ALPN must match) and unavoidable with any predictive mechanism like 0-RTT. Finally, you=E2=80=99re right to think about the coupling between TLS and H= TTP for 0-RTT, but I believe you have the conclusion backwards. The TLS stack must be deeply aware of what is stored in the TLS session, so the server can reject 0-RTT when the remembered values are incompatible with its current configuration (see HTTP/3 ). Otherwise the client will act thinking the server supports some extension when, in reality, it does not. (Perhaps the server had to roll the feature back.) The simpler that TLS/HTTP interaction, the looser the coupling we can manage, and checking opaque bytes for equality is the simplest possible option here. Tighter coupling could be aware that, e.g., SETTINGS_MAX_CONCURRENT_STREAMS =3D 500 is compatible with 1000 but not 100= . The draft starts with the simplest option, given settings don=E2=80=99t cha= nge much. It=E2=80=99s already the case that configuration changes, like cipher preferences, may reject 0-RTT. (Note settings which do change can still be sent in application data. ALPS=E2=80=99s purpose is to solve the reliable negotiation problem, and any changing setting won=E2=80=99t be reliable in = 0-RTT anyway. Moving them out of ALPS entirely seems fairly clean.) David On Mon, Jul 6, 2020 at 10:23 PM Ben Schwartz wrote: > Thanks for this draft. I believe this is an important problem for HTTP > extensibility, and I'm glad to see work on a solution. > > It occurs to me that this solution requires pretty tight integration > between the TLS termination and the HTTP backend. Some TLS load balancer= s > already support ALPN, but they would have to be extended to support ALPS, > and I would worry about the potential for skew between the TLS terminator= 's > claimed settings and the backend's actual settings. > > The draft says > 1. While the server is technically capable of sending configuration > to the peer as soon as it sends its Finished message, most TLS > implementations do not allow any application data to be sent > until the Finished message is received from the client. > > Fixing this might require a change to some TLS implementations, but the > change to implement ALPS also seems significant. > > The proposed 0-RTT interaction also seems like it would create a > significant risk of skew when a load balancer is in use, if the backend > settings can change.. Deployments that can't guarantee uniform backends > would have to disable 0-RTT (an unfortunate sacrifice for a feature that > saves 1 RTT!). > > For load balancers, or any other situation where TLS and HTTP are loosely > coupled, sending SETTINGS at 0.5-RTT would seem like a much simpler > solution. I know the draft mentions a few cases where this doesn't work > well, but perhaps there's a middle ground of some sort. For example: > > * If supporting generic 0.5-RTT forwarding is hard, TLS server > implementations could offer a configuration to send an arbitrary fixed > buffer at 0.5-RTT (depending on ALPN). No standards change is required. > * The application protocol (here HTTP) could indicate what state is > guaranteed to persist across session resumption. Although the preserved > state here (SETTINGS) is ~static, in general this could include dynamic > session state too. This would move the change to HTTP, instead of TLS. > > On Mon, Jul 6, 2020 at 3:13 PM Victor Vasiliev 40google.com@dmarc.ietf.org> wrote: > >> Hello TLS and HTTP working groups, >> >> (QUIC WG bcc'd as this has been discussed there before) >> >> Currently, we use SETTINGS frames as an extensibility mechanism in HTTP/= 2 >> and HTTP/3. The SETTINGS frame is sent at the very beginning of TLS >> application data; this approach, while simple, has some drawbacks. The >> most notable one is that when SETTINGS are used to negotiate extensions, >> there is an entire round-trip where the client can send requests, but >> doesn't know yet about any server extensions, thus making any >> extension-dependant requests take an extra RTT. >> >> The proposed solution to this problem is to move HTTP SETTINGS frame int= o >> the TLS handshake. Here are some issues where this has been discussed >> before: >> >> - https://github.com/quicwg/base-drafts/issues/3086 >> >> - https://github.com/quicwg/base-drafts/issues/3622 >> - https://github.com/WICG/client-hints-infrastructure/pull/30 >> >> I wrote up a draft for the TLS extension that would solve this problem: >> https://tools.ietf.org/html/draft-vvv-tls-alps-00 >> >> I also wrote up a draft that explains how to use that extension with >> HTTP, and defines some settings (the ones discussed here >> ) that would not be >> possible without it: >> https://tools.ietf.org/html/draft-vvv-httpbis-alps-00 >> >> I would appreciate feedback on those drafts. >> >> Thanks, >> Victor. >> _______________________________________________ >> 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 > --00000000000001ad4b05a9decd49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ben,

(I=E2=80=99ve covered many of these points = in my reply to Martin, so you may want to read that first.)

Any solu= tion here involves a TLS change, even for servers which currently send half= -RTT settings. See my reply to Martin for why. The question then is which i= s more complex. As a TLS implementor, ALPS would be a very straightforward = extension to implement, while the work involved to make half-RTT SETTINGS w= ork would be a mess.

Transparently sending a fixed buffer of half-RT= T data was indeed something we=E2=80=99d thought about and rejected. In som= e circumstances, it may=C2=A0cause deadlocks with TCP. And we s= till need an indicator for the client to safely wait for it. I/O patterns a= re part of the protocol.

It=E2=80=99s also not the case that non-uni= form backends must disable 0-RTT. That is what 0-RTT rejection logic is for= . Non-uniform deployments may get less 0-RTT than a uniform deployment, but= it won=E2=80=99t break things. This is already the case (ALPN must match) = and unavoidable with any predictive mechanism like 0-RTT.

Finally, y= ou=E2=80=99re right to think about the coupling between TLS and HTTP for 0-= RTT, but I believe you have the conclusion backwards. The TLS stack must be= deeply aware of what is stored in the TLS session, so the server can rejec= t 0-RTT when the remembered values are incompatible with its current config= uration (see HTTP/3). Otherwise the client will act thinkin= g the server supports some extension when, in reality, it does not. (Perhap= s the server had to roll the feature back.)

The simpler that TLS/HTT= P interaction, the looser the coupling we can manage, and checking opaque b= ytes for equality is the simplest possible option here. Tighter coupling co= uld be aware that, e.g., SETTINGS_MAX_CONCURRENT_STREAMS =3D 500 is compati= ble with 1000 but not 100. The draft starts with the simplest option, given= settings don=E2=80=99t change much. It=E2=80=99s already the case that con= figuration changes, like cipher preferences, may reject 0-RTT. (Note settin= gs which do change can still be sent in application data. ALPS=E2=80=99s pu= rpose is to solve the reliable negotiation problem, and any changing settin= g won=E2=80=99t be reliable in 0-RTT anyway. Moving them out of ALPS entire= ly seems fairly clean.)

David

On Mon, Jul 6, 2020 at 10:23 PM Ben= Schwartz <bemasc=3D40goo= gle.com@dmarc.ietf.org> wrote:
Thanks for this draft.=C2=A0 I belie= ve this is an important problem for HTTP extensibility, and I'm glad to= see work on a solution.

It occurs to me that this solut= ion requires pretty tight integration between the TLS termination and the H= TTP backend.=C2=A0 Some TLS load balancers already support ALPN, but they w= ould have to be extended to support ALPS, and I would worry about the poten= tial for skew between the TLS terminator's claimed settings and the bac= kend's actual settings.

The draft says
=C2=A0 =C2=A01.=C2=A0 While the server is technically capable of sending= configuration
=C2=A0 =C2=A0 =C2=A0 =C2=A0to the peer as soon as it send= s its Finished message, most TLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0implementati= ons do not allow any application data to be sent
=C2=A0 =C2=A0 =C2=A0 = =C2=A0until the Finished message is received from the client.

Fixing this might require a change to some TLS implementati= ons, but the change to implement ALPS also seems significant.
The proposed 0-RTT interaction also seems like it would create = a significant risk of skew when=C2=A0a load balancer is in use, if the back= end settings can change..=C2=A0 Deployments that can't guarantee unifor= m backends would have to disable 0-RTT (an unfortunate sacrifice for a feat= ure that saves 1 RTT!).

For load balancers, or any= other situation where TLS and HTTP are loosely coupled, sending SETTINGS a= t 0.5-RTT would seem like a much simpler solution.=C2=A0 I know the draft m= entions a few cases where this doesn't work well, but perhaps there'= ;s a middle ground of some sort.=C2=A0 For example:

* If supporting generic 0.5-RTT forwarding is hard, TLS server implementa= tions could offer a configuration to send an arbitrary fixed buffer at 0.5-= RTT (depending on ALPN).=C2=A0 No standards change is required.
*= The application protocol (here HTTP) could indicate what state is guarante= ed to persist across session resumption.=C2=A0 Although the preserved state= here (SETTINGS) is ~static, in general this could include dynamic session = state too.=C2=A0 This would move the change to HTTP, instead of TLS.
<= /div>
O= n Mon, Jul 6, 2020 at 3:13 PM Victor Vasiliev <vasilvv=3D40google.com@dmarc.ietf.o= rg> wrote:
Hello TLS=C2=A0and HTTP working groups,

(QU= IC WG bcc'd as this has been discussed there before)

=
Currently, we use SETTINGS frames as an extensibility mechanism in HTT= P/2 and HTTP/3.=C2=A0 The SETTINGS frame is sent at the very beginning of T= LS application data; this approach, while simple, has some drawbacks.=C2=A0= The most notable one is that when SETTINGS are used to negotiate extension= s, there is an entire round-trip where the client can send requests, but do= esn't know yet about any server extensions, thus making any extension-d= ependant requests take an extra RTT.

The propo= sed solution to this problem is to move HTTP SETTINGS frame into the TLS ha= ndshake.=C2=A0 Here are some issues where this has been discussed before:

I also wrote up a draft th= at explains how to use that extension with HTTP, and defines some settings = (the ones discussed here) that would not be possible without it:= =C2=A0https://tools.ietf.org/html/draft-vvv-httpbis-alps-00

I would appreciate feedback on those drafts.

Thanks,
=C2=A0 Victor.
_______________________________________________
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
--00000000000001ad4b05a9decd49-- From nobody Tue Jul 7 13:38: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 BCCB43A0A62 for ; Tue, 7 Jul 2020 13:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 r1DkRAdfPsjf for ; Tue, 7 Jul 2020 13:38:11 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 F1EF83A0A56 for ; Tue, 7 Jul 2020 13:38:10 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id o2so547807wmh.2 for ; Tue, 07 Jul 2020 13:38:10 -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 :cc; bh=sH+C9yNrqYFN/K1KKAvETl0RvXC/WK1p6ybqGRUfy5s=; b=fQwQUcmD2lVPh6WeP1/KvoZJqvJA5ll2K5mJEtkrxJOUbx4EPAXECjcCV9WoJ06dUu TFBzmQ+9E9Y4qRkelyV9DwLVZIia8PeUC6UrjDiVRqko+VYLyvFdiZ/KLPhosPAsOQ72 PuSknvSpqVv1Dp/cggXJbZRPWUl09ElLs4GsbypOQPHPZ184j8mgyM8x9o8iwVCIZQm4 1I+88tJidvqrqx/3JQFt2GaNeWrgGLYRroZh7QAyzaHElV7VdkXlHd3PSTkK7VRgMLM8 vxDF6zFcG0ISL4DmTd7A9drYhXdSX4VOaRSw3m2s5HV1SxOWtFLc0LtVwUbBfnaFNb0m oLqw== 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=sH+C9yNrqYFN/K1KKAvETl0RvXC/WK1p6ybqGRUfy5s=; b=qqVmM87IXUr9bsMl7SvqvqBJkvIm0o96NTTtddLc5TUlQNNNEWdLsJGHCYHhp4FDRC 2VnjqDu+ch+/zcVALXuo9LQgNgp8zHDLvIqaj6yiDD+TUqe0QjS8308yHhqpGsaLSvOn 1423gWAgdBSyMH17oSxw1uodvhbAj4GR7qCvmFkTlBIF80d5SeDVwaQBpi6RLp/nPCGc Zncw0/XL/dGn6F7Ru64BXd1SZUBbT/1hmYUPvC/YsAkUCwCLouA5caCRnWapiV7lxNyc S+OSSVsA/YJUhNusfqyW8W9r+O6SIoPGiFmg0n03tWme7d1kFMSkY/Fwo6QSyBk3IATT 3NGA== X-Gm-Message-State: AOAM531b7lMdMqcOSgAzXMFu/g5EyC4plInRkXsvXNbXhF7llBJREkW+ NEhKST+SwbPkhD3fgmu7fQK9a71UroWoDznr1ZvJ7w== X-Google-Smtp-Source: ABdhPJwfxEbztzGAl0jDdICN6Dw2NxJCzyQ5j+KBqASICm+Teo/owbdg3OS1h2yHC5mF6UZn7zhkb91S3aBTiZ/T5vA= X-Received: by 2002:a7b:c3c7:: with SMTP id t7mr5589914wmj.97.1594154289236; Tue, 07 Jul 2020 13:38:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Tue, 7 Jul 2020 16:37:57 -0400 Message-ID: To: David Benjamin Cc: Victor Vasiliev , "tls@ietf.org" , HTTP Working Group Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000002717f905a9dff89d" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 20:38:13 -0000 --0000000000002717f905a9dff89d Content-Type: multipart/alternative; boundary="00000000000020f8ec05a9dff88c" --00000000000020f8ec05a9dff88c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 7, 2020 at 3:14 PM David Benjamin wrote= : > Any solution here involves a TLS change, even for servers which currently > send half-RTT settings. ... > I think a new ALPN protocol ID ("h2-but-with-settings-from-the-server-asap-for-real") would suffice. It=E2=80=99s also not the case that non-uniform backends must disable 0-RTT= . That > is what 0-RTT rejection logic is for. ... > I would be impressed if there is any TLS load balancer architecture that supports 0-RTT rejection by the backend. This would require an interesting new metadata layer, quite different from the usual "decrypt and forward" approach. (Of course, I assume that most load balancers simply won't implement 0-RTT at all.) The simpler that TLS/HTTP interaction, the looser the coupling we can > manage, and checking opaque bytes for equality is the simplest possible > option here. > I'm not sure what equality check you're proposing; I don't see it in the draft. However, I agree with your conclusion: if the TLS server manages the settings-state, it can easily invalidate resumption across a settings change. Ultimately, I think I'm saying something obvious: if the TLS server represents multiple backends without distinction, it can't represent a property that those backends do not share. This is true of ALPN, and would be true of ALPS too. This is fine; the ALPS just has to represent the intersection of backend capabilities. All currently defined HTTP/2 Settings appear to support intersection in a reasonable way, although I'm not sure this is guaranteed in general. However, SETTINGS at 0.5-RTT would not have this problem; heterogeneous backends could each report their own SETTINGS. This is not an unreasonable design choice given the other constraints you've mentioned, but it is a limitation, and potentially a footgun (e.g. if someone forgets to revert the ALPS config change before rolling back the HTTP server config change). --00000000000020f8ec05a9dff88c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Jul 7, 2020 at 3:14 PM David Benjamin <davidben@chromium.org> wrote:
Any soluti= on here involves a TLS change, even for servers which currently send half-R= TT settings. ...

I think a new AL= PN protocol ID ("h2-but-with-settings-from-the-server-asap-for-real&qu= ot;) would suffice.

It=E2=80=99s also not the case that non-uni= form backends must disable 0-RTT. That is what 0-RTT rejection logic is for= . ...

I would be impressed if there i= s any TLS load balancer architecture that supports 0-RTT rejection by the b= ackend.=C2=A0 This would require an interesting new metadata layer, quite d= ifferent from the usual "decrypt and forward" approach.=C2=A0 (Of= course, I assume that most load balancers simply won't implement 0-RTT= at all.)

The simpler that TLS/HTTP interaction, the looser the= coupling we can manage, and checking opaque bytes for equality is the simp= lest possible option here.

I'm no= t sure what equality check you're proposing; I don't see it in the = draft.=C2=A0 However, I agree with your conclusion: if the TLS server manag= es the settings-state, it can easily invalidate resumption across a setting= s change.

Ultimately, I think I'm saying somet= hing obvious: if the TLS server represents multiple backends without distin= ction, it can't represent a property that those backends do not share.= =C2=A0 This is true of ALPN, and would be true of ALPS too.=C2=A0 This is f= ine; the ALPS just has to represent the intersection of backend capabilitie= s.=C2=A0 All currently defined HTTP/2 Settings appear to support intersecti= on in a reasonable way,=C2=A0although I'm not sure this is guaranteed i= n general.=C2=A0 However, SETTINGS at 0.5-RTT would not have this problem; = heterogeneous backends could each report their own SETTINGS.

=
This is not an unreasonable design choice given the other constr= aints you've mentioned, but it is a limitation, and potentially a footg= un (e.g. if someone forgets to revert the ALPS config change before rolling= back the HTTP server config change).
--00000000000020f8ec05a9dff88c-- --0000000000002717f905a9dff89d Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAH8qNflD4Mi9yKttXfRdHcwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDA2MDUwODIyMjhaFw0yMDEyMDIwODIyMjhaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kbyV9S0YLplF3kV 6t3GgD7IyHe8L29pJ7l+UR0Sj31uPgXOFdSSdTVwhPfQvxmB2OUDXWDgDtZdL2xu4DgHhrDyyOXT 8uDJqUCPw004ZSuUfUor1vz5u6+oYNfx2OTPTb81vtsQO2/khni3iAeQlKgO/rUI1c9+zvT6k3mR SZUypAlk/rCyG6NV7NMJMmOaU20/kPBXG297iP8+/F9w4xs+lyb3IkcSfoSUr3fVz7mYqESFato5 JnjRQGT2/f/ehxkc09jATqVGj9nyQMoD2GNPjiNnYyTVBwK5Ol/s9+E2VSL4TSLrgS2R07kY9zPi VOM3lhDDRnceboNSaqnfMwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUwJS1fB3cBxoLgZFatdIO9Vp5wOcwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQCC91PBn9rMxo8kSo1zNY2mxkTQDTVc0oyYk8s3y72y21IEp/d/+h1H VTCD2FR30aFUv8hTJkebJ5Z1/zue2L7sx/lLEOIHm9uYxyTkTWbKup3+XrE1vhODTHVx+ktMuOTY z447/fwjy4praSaFrQsOjTPbAoU6xuC8S2j2K2Yg6XQsctcKHKeAJjN6evZYChDaTBLmtYq9LTSH KVv3Et795vNK3gWKjhEkJtaBu4FfKLoopb1PENJ/zK6p/3edCLFgCRMSlbQ0SGtdVESSJcgezSwW WK2VB1Zcj2kyVzcL1pmV8m1xQuz2aBgUMn7peoVxKxYKP12gMtzeMvkzltYBMYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhAB/KjX5Q+DIvcirbV30XR3MA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCCNoHZIMTwbAKcmdQaQhBWW5KXvsYZUgqSreoJcXqTNWTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3MDcyMDM4MDlaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAcNAIMEfUCQhb0serdoYargXeIOXzylEKOat1dh8GkefQ93fABSWMEnrctaVzJwmUcmgJ/4P6 OGmt1mBRs9jqNpbusddcOqR2WYhDMvOoUsxdZChPRs9a9x0W3fDWGlASXgnKtTBsyaXfevIpi5HD HkgsKweahjRa6Cqfc0PnhmbPZnlsWy0hxwknjoFMPXfQ/DVqVe9WmBnsJmWv7x1LPCsPuyVNkRac h9m5TsbLIHvoVLi6bBw4g/WljoP11ZD/LMMAXXIFUyy5swFkpI6hRc4cCIW7Wan1kEg+pxExhAWM iLN64x58ggjAZSSQldPE1+91rmGqDq7iMCEYlhc8lg== --0000000000002717f905a9dff89d-- From nobody Tue Jul 7 14:17: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 CD4CD3A0ABC for ; Tue, 7 Jul 2020 14:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 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, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 lTUCh2md43mw for ; Tue, 7 Jul 2020 14:17:31 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 D30933A0ABB for ; Tue, 7 Jul 2020 14:17:31 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id d4so20586269pgk.4 for ; Tue, 07 Jul 2020 14:17:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oC7Mw/WeHX9FbK2yOqczRh/7oUjWGiOgZfqYecX+I1U=; b=OzUmOe4RNXPlO58GZ2Ts5gokYpCX9bFPyEZZR9XD2XtPYbCuh4fDhNneATlkcQ9pKr fuql4N565I032G8TlcSZe/cYl73XQ+8udU9u5m0gbq+UHLi63v4e+aPATGn3N0GKWoCK EUE37V6a+Gc7bhfpdYQM1Gy3owTEY1ZRllsfg= 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=oC7Mw/WeHX9FbK2yOqczRh/7oUjWGiOgZfqYecX+I1U=; b=i0RzpmKD5BD5SGZO19JY4rdbB/zk49gkiv+kyCpHJYMQYpnkXPMt2c2yUDQ6N3XtvX 7RUQA6P2BbhQzavaTfxuKK50l4ylzqkYEIMLojaM/sTuK2SMDqWjUwmCV9z8b8TpkUlw jj1BLxRS0qEeb2Co/KNPK0vFTLphVW/pTdWMDKn0coKWGaIZD9cZRWxZjwxOAgmMJQtQ dkE8puUB8mGkXPtdyC8s0TOlVVOActiC3BqffinyF8ORqmqdcHTVVslyfCfIVO3Nn55U 1tMpv3GShOLre6rBBCnM7DotxJHrnu83HGiVHdUPczSp4qjCTl226Tlw8gH2oCPiZYq6 y7Eg== X-Gm-Message-State: AOAM531NR2gL20W/oHt+rVrswMHxwmqskb8fYT7DBBrqiKss2VZZhdTA /S0I/kHgo1QZ4g+JiKExbirMeidlYDp62XI5MTNz X-Google-Smtp-Source: ABdhPJyVCh8ClTndi3AmH3a3YUGMJ4Dhzhfav9PLhFsNkEw7Z4WXgPLsha0HEf+sQMhVpKf0IzD5ptlsq34j3Umgxlo= X-Received: by 2002:a63:8f51:: with SMTP id r17mr41325326pgn.124.1594156651031; Tue, 07 Jul 2020 14:17:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Tue, 7 Jul 2020 17:17:14 -0400 Message-ID: To: Ben Schwartz Cc: Victor Vasiliev , "tls@ietf.org" , HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000e7064105a9e08464" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 21:17:34 -0000 --000000000000e7064105a9e08464 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 7, 2020 at 4:38 PM Ben Schwartz wrote: > > On Tue, Jul 7, 2020 at 3:14 PM David Benjamin > wrote: > >> Any solution here involves a TLS change, even for servers which currentl= y >> send half-RTT settings. ... >> > > I think a new ALPN protocol ID > ("h2-but-with-settings-from-the-server-asap-for-real") would suffice. > That doesn't suffice. Please see my reply to Martin. This would be one possible spelling of the indicator, but it would not provide the other components necessary for half-RTT data to work. > It=E2=80=99s also not the case that non-uniform backends must disable 0-R= TT. That >> is what 0-RTT rejection logic is for. ... >> > > I would be impressed if there is any TLS load balancer architecture that > supports 0-RTT rejection by the backend. This would require an interesti= ng > new metadata layer, quite different from the usual "decrypt and forward" > approach. (Of course, I assume that most load balancers simply won't > implement 0-RTT at all.) > HTTP/3 0-RTT *already* requires such an interaction. In fact, it requires an even more complex version than ALPS. The link was lost in the quoted reply, so I'll include it again: https://quicwg.org/base-drafts/draft-ietf-quic-http.html#section-7.2.4.2-7 This is fundamentally unavoidable if you want 0-RTT to be able to use negotiated parameters. Any negotiated parameter available to 0-RTT *must* b= e available predictively. Because it is predictive, mispredictions may occur. RFC8470 likewise contains recommendations which also require more than a "decrypt and forward" approach. > The simpler that TLS/HTTP interaction, the looser the coupling we can >> manage, and checking opaque bytes for equality is the simplest possible >> option here. >> > > I'm not sure what equality check you're proposing; I don't see it in the > draft. > It's right here: https://tools.ietf.org/html/draft-vvv-tls-alps-00#section-= 3 > For application protocols that support 0-RTT data, both the client > and the server have to remember the settings provided by the both > sides during the original connection. If the client sends 0-RTT data > and the server accepts it, the ALPS values SHALL be the same values > as were during the original connection. In all other cases > (including session resumption that does not result in server > accepting early data), new ALPS values SHALL be negotiated. > > If the client wishes to send different client settings for the 0-RTT > session, it MUST NOT offer 0-RTT. Conversely, if the server would > send different server settings, it MUST reject 0-RTT. Note that the > ALPN itself is similarly required to match the one in the original > connection, thus the settings only need to be remembered or checked > for a single application protocol. > However, I agree with your conclusion: if the TLS server manages the > settings-state, it can easily invalidate resumption across a settings > change. > > Ultimately, I think I'm saying something obvious: if the TLS server > represents multiple backends without distinction, it can't represent a > property that those backends do not share. This is true of ALPN, and wou= ld > be true of ALPS too. This is fine; the ALPS just has to represent the > intersection of backend capabilities. All currently defined HTTP/2 > Settings appear to support intersection in a reasonable way, although I'm > not sure this is guaranteed in general. However, SETTINGS at 0.5-RTT wou= ld > not have this problem; heterogeneous backends could each report their own > SETTINGS. > I don't think this follows. ALPS and half-RTT data happen at the same round-trip. If the frontend is able to forward half-RTT data, it has clearly decided on which backend to use by the time it's assembling the ServerHello flight. It can as easily pick a backend-specific ALPS value as it can pick backend-specific half-RTT data. Beyond that, it's a question of what exactly your frontend/backend split looks like. I gather you're worried about a deployment scenario where your frontend is a TLS terminator, which has a boring pipe to the HTTP backend, without any out-of-band signaling. (As opposed to having an HTTP frontend.) In that case, the argument is that, since half-RTT data is just bytes, that can be transparently forwarded over the pipe, whereas an ALPS signal wouldn't. Is that right? It's unlikely half-RTT data would work for that scenario. The frontend most likely waits for the handshake to actually finish, before enabling the pipe. Indeed, the security properties of the half-RTT point are kind of subtle (particularly with client certs). Forwarding data then without appropriate signaling is dangerous. Such a frontend/backend split would also likely be unable to manage the recommendations in RFC8470, the remembered settings vs. 0-RTT interactions, the guarantee of half-RTT data being sent early enough, or the delimiting information necessary to make a half-RTT settings work. For that matter, it already needs some out-of-band signaling to communicate the ALPN protocol. ALPS probably even helps this kind of deployment, by at least making it possible to statically configure the settings. Static configuration risks the footguns you mention below, but when all you've got is a boring pipe, there aren't many options. This is not an unreasonable design choice given the other constraints > you've mentioned, but it is a limitation, and potentially a footgun (e.g. > if someone forgets to revert the ALPS config change before rolling back t= he > HTTP server config change). > Again, this depends on where your frontend/backend split is, and what is the communication between them. Note also that this hypothetical deployment model already has a similar footgun around ALPN. David --000000000000e7064105a9e08464 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 7, 2020 at 4:38 PM Ben Schwar= tz <bemasc@google.com> wrote= :

On Tue, Jul 7, 2020 at 3:14 PM David Benjamin <<= a href=3D"mailto:davidben@chromium.org" target=3D"_blank">davidben@chromium= .org> wrote:
Any solution here involves a TLS change, even for serv= ers which currently send half-RTT settings. ...
=
I think a new ALPN protocol ID ("h2-but-with-settings-f= rom-the-server-asap-for-real") would suffice.

That doesn't suffice. Please see my reply to = Martin. This would be one possible spelling of the indicator, but it would = not provide the other components=C2=A0necessary for half-RTT data to work.<= /div>
=C2=A0
It=E2=80=99s also not the case that non-un= iform backends must disable 0-RTT. That is what 0-RTT rejection logic is fo= r. ...

I would be impressed if there = is any TLS load balancer architecture that supports 0-RTT rejection by the = backend.=C2=A0 This would require an interesting new metadata layer, quite = different from the usual "decrypt and forward" approach.=C2=A0 (O= f course, I assume that most load balancers simply won't implement 0-RT= T at all.)

HTTP/3 0-RTT= =C2=A0already=C2=A0requires such an interaction. In fact, it require= s an even more complex version than ALPS. The link was lost in the quoted r= eply, so I'll include it again:
This is fundamentally unavoidable if you want 0-RTT to be able = to use negotiated parameters. Any negotiated parameter available to 0-RTT <= i>must=C2=A0be available predictively. Because it is predictive, mispre= dictions may occur.

RFC8470 likewise contains reco= mmendations which also require=C2=A0more=C2=A0than a "decrypt and forw= ard" approach.
=C2=A0
The simpler that TLS/H= TTP interaction, the looser the coupling we can manage, and checking opaque= bytes for equality is the simplest possible option here.

I'm not sure what equality check you're propos= ing; I don't see it in the draft.

>=C2=A0 =C2=A0For appli= cation protocols that support 0-RTT data, both the client
>=C2=A0 =C2= =A0and the server have to remember the settings provided by the both
>= ;=C2=A0 =C2=A0sides during the original connection.=C2=A0 If the client sen= ds 0-RTT data
>=C2=A0 =C2=A0and the server accepts it, the ALPS value= s SHALL be the same values
>=C2=A0 =C2=A0as were during the original = connection.=C2=A0 In all other cases
>=C2=A0 =C2=A0(including session= resumption that does not result in server
>=C2=A0 =C2=A0accepting ea= rly data), new ALPS values SHALL be negotiated.
>
>=C2=A0 =C2= =A0If the client wishes to send different client settings for the 0-RTT
= >=C2=A0 =C2=A0session, it MUST NOT offer 0-RTT.=C2=A0 Conversely, if the= server would
>=C2=A0 =C2=A0send different server settings, it MUST r= eject 0-RTT.=C2=A0 Note that the
>=C2=A0 =C2=A0ALPN itself is similar= ly required to match the one in the original
>=C2=A0 =C2=A0connection= , thus the settings only need to be remembered or checked
>=C2=A0 =C2= =A0for a single application protocol.
=C2=A0
However, I agree with your conclusion: if the TLS server manages = the settings-state, it can easily invalidate resumption across a settings c= hange.

Ultimately, I think I'm saying somethin= g obvious: if the TLS server represents multiple backends without distincti= on, it can't represent a property that those backends do not share.=C2= =A0 This is true of ALPN, and would be true of ALPS too.=C2=A0 This is fine= ; the ALPS just has to represent the intersection of backend capabilities.= =C2=A0 All currently defined HTTP/2 Settings appear to support intersection= in a reasonable way,=C2=A0although I'm not sure this is guaranteed in = general.=C2=A0 However, SETTINGS at 0.5-RTT would not have this problem; he= terogeneous backends could each report their own SETTINGS.

I don't think this follows. ALPS and = half-RTT data happen at the same round-trip. If the frontend is able to for= ward half-RTT data, it has clearly decided on which backend to use by the t= ime it's assembling the ServerHello flight. It can as easily pick a bac= kend-specific ALPS value as it can pick backend-specific half-RTT data.

Beyond that, it's a question of what exactly your= frontend/backend split looks like. I gather you're worried about a=C2= =A0deployment scenario where your frontend is a TLS terminator, which has a= boring pipe to the HTTP backend, without any out-of-band signaling. (As op= posed to having an HTTP frontend.) In that case, the argument is that, sinc= e half-RTT data is just bytes, that can be transparently forwarded over the= pipe, whereas an ALPS signal wouldn't. Is that right?

It's unlikely half-RTT data would work for that scenario. The = frontend most likely waits for the handshake to actually finish, before ena= bling the pipe. Indeed, the security properties of the half-RTT point are k= ind of subtle (particularly with client certs). Forwarding data then withou= t appropriate signaling is dangerous.

Such a front= end/backend split would also likely be unable to manage the recommendations= in RFC8470, the remembered settings vs. 0-RTT interactions, the guarantee = of half-RTT data being sent early enough, or the delimiting information nec= essary to make a half-RTT settings work. For that matter, it already needs = some out-of-band signaling to communicate the ALPN protocol.

=
ALPS probably even helps this kind of deployment, by at least ma= king it possible to statically configure the settings. Static configuration= risks the footguns you mention below, but when all you've got is a bor= ing pipe, there aren't many options.

This is not an unreasonable design choice given the other constra= ints you've mentioned, but it is a limitation, and potentially a footgu= n (e.g. if someone forgets to revert the ALPS config change before rolling = back the HTTP server config change).
Again, this depends on where your frontend/backend split is, an= d what is the communication between them. Note also that this hypothetical = deployment model already has a similar footgun around ALPN.

<= /div>
David
--000000000000e7064105a9e08464-- From nobody Tue Jul 7 18:28: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 8F51A3A0CF9 for ; Tue, 7 Jul 2020 18:28:36 -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_H4=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=BiHLoTJA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bKfB7yUu 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 0Q4fwj2aWtlu for ; Tue, 7 Jul 2020 18:28:34 -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 51C053A0CF8 for ; Tue, 7 Jul 2020 18:28:34 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 965C25C0158; Tue, 7 Jul 2020 21:28:33 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 07 Jul 2020 21:28:33 -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:content-transfer-encoding; s=fm2; bh=U+bVV qL4pk7Qw5A3wMDyQpu3TXdtSHeljKa0jRigg+k=; b=BiHLoTJAy9VvkU6Ednidw roqKWnuRB/WR1nrAEL5mn0ACHb2wLhOb2pjkE12UcRGmXiWVMC7bscyRSgEpfECT 909BiiZS0RoDn6m1NwM4GyZ9HmmwA0UiqUTe1yu3xBltEQwSv4w+Q3UnqqLY+UV8 5youxUrZLaGj7B3GHXcP66FtLkv0JoxP7hOEBceqKMoDF9AHc9CzUrXkI6YMXCN7 vXMUV+/nTSML5k2GOKKVB88RdNwew4BAysnz1YgHGDdq2xFg1AkkCY8YQjrAdILh /V1zRQwCmNIcbzMeZHSkvR5IMqGuQvuaYHv9wpLSxj70raR9KfYaMFkO9ZUCiWWD g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=U+bVVqL4pk7Qw5A3wMDyQpu3TXdtSHeljKa0jRigg +k=; b=bKfB7yUuPx0KRW1I0vyN05YRYQzHOTYnx+uRWk6yi3xgTyh8y9Azmt8Fy J6PXupYZSlGlgGXCPUN2y8TiCI6aQkZUewSLS5nqPg2BkfvZ6VLni9U64/0GYI3r +FmGkmHh4C8ofQOn13wxPkfly1a3SA3bIfRwVI32L72gcn+ByR0vzkCUTckGLXxD o+pBLnkBm9hrGxn2xVGSK7FgImU/+eHn/MagqtN1vF7eAMKxy5LjuAX5iFoiJ+pb xMwRl5/ZNFmQ+SBfupbkZVabZVHfsou4N/JyoOiRxGQBAss2/6S+uVSI8QSDUuIu NMMBcKrd2OrzLuCfOUakTAsADld4A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeigdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhephfdvieehveehkeehteethedthfelkedvtdetjeelgeegjedujeeg ueffleejgfevnecuffhomhgrihhnpehhthhtphdvrdhimhdpihgvthhfrdhorhhgpdiffe drohhrghdphhhtthhpohhrrghtlhhsqdhlvghvvghlvghnughofhhhrghlfhdqrhhtthgu rghtrgguvghlihhmihhtvghrrdhnohifpdhgihhthhhusgdrtghomhdphhhtthhpfehthh hishhhrghsshhomhgvihhntghrvghmvghnthgrlhgvfhhfvggtthgsvgihohhnughthhgr thdrihhnpdhhthhtphhsvghtthhinhhgshhfrhgrmhgvihhnthhothhhvghtlhhshhgrnh gushhhrghkvgdrhhgvrhgvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1C6E8E00E3; Tue, 7 Jul 2020 21:28:33 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> Date: Wed, 08 Jul 2020 11:28:13 +1000 From: "Martin Thomson" To: ietf-http-wg@w3.org, tls@ietf.org, "David Benjamin" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 01:28:37 -0000 Hi David, I think that there is an important difference between something that is = hard to realize in practice (as many aspects of this clearly are) and us= ing that to say that the fundamental protocol definition is wrong. I appreciate - at least superficially - the complexities involved here. = Having implemented them, and having worked around many of the problems = you have identified, it was not trivial to implement 0-RTT or 0.5-RTT (t= he latter was pretty-much trivial for much the same reason that false st= art works, but I'll concede that I probably didn't fully explore all of = the potential problems). But as much as recognizing implementation complexity is important, that = doesn't necessarily translate into a requirement to change the protocol.= Let's take an example of a feature you are trying to negotiate in HTTP (= /2 or /3). I don't think that it is unreasonable to say to a client tha= t it cannot attempt anything that depends on this feature until it recei= ves SETTINGS. You can then require servers that support this extension = to send SETTINGS in 0.5-RTT so that the client is only blocked on the ex= tra bytes and not additional round trips. All of which implies that you= need TLS 1.3 for the feature. The drawback there is that the client that wants to use the feature migh= t not receive the SETTINGS in time and they don't get a clear indication= that this is not happening. Ben's suggestion to use a new version if y= ou care about avoiding that case is entirely appropriate. It depends on= what sort of extensions are being contemplated here to determine whethe= r this is indeed necessary. I tend to think a h2_tls13 ALPN that mandat= ed use of 0.5-RTT for SETTINGS would put a big dent in this negotiation = problem. Either way, your stack might require new changes to support the writing = of some fixed amount of data on all new connections. This might turn in= to a requirement on TLS terminators to have per-backend configuration to= support this new information. But these don't necessarily turn into ne= w protocol mechanisms. Indeed, these changes are far less disruptive ov= erall than a completely new TLS extension, particularly if the TLS exten= sion involves all of the same coordination. I concede that saying that SETTINGS is sufficient isn't free, and that t= here is some additional cost on implementations. On the other hand, the= "cost" is that implementations improve some aspects of an existing prot= ocol that provide other benefits to those implementations. On the other hand, new mechanisms like this require the same amount of c= oordination, more work at the TLS layer, and all the delays imposed by s= tandardization. On Wed, Jul 8, 2020, at 05:11, David Benjamin wrote: > Hi Martin, >=20 > You=E2=80=99re right that this is closely related to half-RTT data. Ho= wever, I=20 > don=E2=80=99t think this is a no-op for HTTP/2. >=20 > I=E2=80=99m not aware of HTTP/2 clients that wait for the SETTINGS fra= me today.=20 > Doing so costs a round-trip with servers that don=E2=80=99t send SETTI= NGS in=20 > half-RTT, and there's no indicator for whether the server will send it= .=20 > I=E2=80=99ll see about testing some sites here and will report back, b= ut I=20 > expect most do not. We (correctly) designed TLS 1.3 as a drop-in=20 > replacement for TLS 1.2, which means that we don't get to key new I/O=20= > patterns on it. Half-RTT data is a very weird state and wouldn=E2=80=99= t get=20 > used by default. This is the problem with =E2=80=9Cno standards change= is=20 > required=E2=80=9D style of thinking around simply changing I/O pattern= s. A=20 > protocol is more than its wire image. Changing the I/O patterns is a=20= > protocol change. >=20 > This means we cannot get efficient and reliable feature negotiation=20= > today. Moreover, HTTP/2 servers today may send ServerHello..Finished=20= > without application data in their first flight, so we need *some*=20 > change to the TLS flight, be it ALPS or just some indicator. >=20 > Let=E2=80=99s look at what it=E2=80=99d take to make half-RTT SETTINGS= work. We need=20 > some =E2=80=9CI will send half-RTT data, so you can safely wait for it= =E2=80=9D=20 > indicator. Then the client needs to know when it is done waiting. We=20= > could say it=E2=80=99s one SETTINGS frame, but that only allows intege= r values.=20 > (Related: EXTENDED_SETTINGS=20 > and discussion .) Those currently need separate frames, and one can= not wait for the absence of a frame. Maybe we need an HTTP-level SETTING= S_WILL_SEND_HALF_RTT_XYZ_FRAME indicator to keep the delimiter in HTTP, = or a TLS-level =E2=80=9Cend of half-RTT data=E2=80=9D delimiter. (Now co= nsider how that works in QUIC...) >=20 > Next we need to tackle 0-RTT. Waiting for half-RTT data costs a=20 > round-trip in 0-RTT, so we need something to persist across the=20 > session, with semantics around mismatch and whatnot. (Another=20 > TLS-visible change.) Anything persisted in the session must have=20 > bounded size, and be delivered in something ordered with=20 > NewSessionTicket. >=20 > If we place those bytes inside the handshake, we=E2=80=99ve reinvented= ALPS. If=20 > we place them outside, the NewSessionTicket ordering becomes complex,=20= > especially in QUIC=20 > . To your question about the server repeating its configuration vs. = the client remembering it, I believe the issue was exactly that ordering= mishap. ALPS avoids this because EncryptedExtensions and NewSessionTick= et are ordered. >=20 > On top of this, the half-RTT point in a non-0-RTT connection is a weir= d=20 > state. Not all connection properties (e.g. client certs) have been=20 > established yet, and writes out of turn are tricky. This message=20 > discusses some of the challenges here. I would argue something like A= LPS is the settings design we should have had all along. >=20 > David >=20 > On Tue, Jul 7, 2020 at 1:10 AM Martin Thomson wrot= e: > > Hi Victor, > >=20 > > For HTTP/2, this is essentially a noop, as endpoints are required t= o send SETTINGS immediately. Whether these bytes appear before Finished = or not only affects endpoints that aren't inclined to wait for SETTINGS.= This is somewhat complicated by the way that TLS 1.2 and TLS 1.3 differ= , but if we assume TLS 1.3 here, any uncertainty is easily avoided. > >=20 > > The main justification here appears to be based on the lack of 0.5-= RTT send capability at some servers. I don't know how to assess whether = the cost of greater integration with the TLS stack is preferable to fixi= ng the 0.5-RTT send problem. > >=20 > > For HTTP/3, this has some incremental effect beyond that. In effect= , this deliberately introduces head-of-line blocking for settings. You c= an already do that in HTTP/3 if you are not prepared to deal with settin= gs being in an ambiguous state. There's a little more determinism here i= n terms of where you look for the data that unblocks progress, but with = retransmissions, this is not a difference worth worrying about. > >=20 > > What this head-of-line blocking might allow is the development of n= ew extensions that are unable to deal with uncertainty regarding SETTING= S. But isn't it also possible to address that problem by saying "if you = implement extension X, then you MUST NOT send requests prior to receivin= g SETTINGS?" > >=20 > > In QUIC, we decided that having the server repeat its configuration= after 0-RTT was preferable to remembering it. This was after a non-triv= ial number of questions about that part of the specification. You seem t= o have taken the opposite approach. Is that deliberate? If so, why? > >=20 > > On Tue, Jul 7, 2020, at 05:12, Victor Vasiliev wrote: > > > Hello TLS and HTTP working groups, > > >=20 > > > (QUIC WG bcc'd as this has been discussed there before) > > >=20 > > > Currently, we use SETTINGS frames as an extensibility mechanism i= n=20 > > > HTTP/2 and HTTP/3. The SETTINGS frame is sent at the very beginni= ng of=20 > > > TLS application data; this approach, while simple, has some drawb= acks.=20 > > > The most notable one is that when SETTINGS are used to negotiate=20= > > > extensions, there is an entire round-trip where the client can se= nd=20 > > > requests, but doesn't know yet about any server extensions, thus = making=20 > > > any extension-dependant requests take an extra RTT. > > >=20 > > > The proposed solution to this problem is to move HTTP SETTINGS fr= ame=20 > > > into the TLS handshake. Here are some issues where this has been=20= > > > discussed before: > > > * https://github.com/quicwg/base-drafts/issues/3086 > > > * https://github.com/quicwg/base-drafts/issues/3622 > > > * https://github.com/WICG/client-hints-infrastructure/pull/30 > > > I wrote up a draft for the TLS extension that would solve this pr= oblem:=20 > > > https://tools.ietf.org/html/draft-vvv-tls-alps-00 > > >=20 > > > I also wrote up a draft that explains how to use that extension w= ith=20 > > > HTTP, and defines some settings (the ones discussed here=20 > > > ) that would n= ot be=20 > > > possible without it:=20 > > > https://tools.ietf.org/html/draft-vvv-httpbis-alps-00 > > >=20 > > > I would appreciate feedback on those drafts. > > >=20 > > > Thanks, > > > Victor. > > > _______________________________________________ > > > TLS mailing list > > > TLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/tls > > > > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 8 01:03: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 D94C93A0C35; Wed, 8 Jul 2020 01:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, 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 YjMbl23CSNtP; Wed, 8 Jul 2020 01:03:27 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140087.outbound.protection.outlook.com [40.107.14.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 258BE3A0C33; Wed, 8 Jul 2020 01:03:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Omq5l+FSrc1h0BlE1FoMVz5UzMFuVV4S1AZ1mCarENpJAWoJn0Qjch7VOA1ZttfUoKFVSfaqEhsh3DDSgiR9LHCzBajc11dReXyEZ3YgdJSlIoq+yHh+R9GOkGz7RqBfkaFn8KaIPu9WsefSyxqD8qKMyvmdmf1ltDezOBu180FYCHMuPUs4rKsQe0y89765MkYohvJqcHRyhMet88CNlEMzHKf1wMetTQY1kKV08fepnV852J49e/s3Im+wu0qNoFDaKgeiFSkyIQeEXjahngi/LEg/7EvY8Rbtoh+DA3vq9RubiXMcJaKaIdrAWD+yBETQqE782HA+xOx2ByrjSg== 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=dVOI6pb55yhax8bd4GDbyhgZtbpw8G2X5XSmTrgOz4o=; b=IbxpIV5g6mi6CsLDq5oBCLTRx4TXWertQLTIK7PpHyO8eSnou0HXmj2xQa1ydSEBn/70FAd0cAIhjGCU3hsYQzNylYAvvsHRYcKzYjISv3yXHiX01pt/2+RYQZNbKXSbBykBnFTr0TlEoiScbIsrK/rsy9FsD3EI3TjNKcH3ksEDpYgDmwKJMvva8+fwp9A/SDGlm2NU3/T1tQFUfCeRXCQk4825l0dtCoShUnr1kFDw6yjNUqcX9P/odokiSi1/wvZ0uMTtpjm31CQUnUHYinq+UCfpUWtg8ksi+YnnY3oQL0elVCrd1XYmdR6NAhPyVGWMwB+gyIQabiDI5HZWpg== 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=dVOI6pb55yhax8bd4GDbyhgZtbpw8G2X5XSmTrgOz4o=; b=CosF5Q8p3UrKW3a/h09Lgpo4PUtt9VBCALk1VN94Q0g81OQgOgnjGwjx6JgCd9KILNmqKxw++Lm06bkqdB7Xj3jKEPZm7e7GCmkxQYoW9fr/wBd2zI7rbqyuSzCetoJYIuvubXC7ATos0g2OGLutZQv3nYbcZVydQBLXe3DetBc= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR07MB3273.eurprd07.prod.outlook.com (2603:10a6:7:2b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.16; Wed, 8 Jul 2020 08:03:24 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::d6e:6298:19a7:7c99]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::d6e:6298:19a7:7c99%5]) with mapi id 15.20.3174.020; Wed, 8 Jul 2020 08:03:24 +0000 From: Mohit Sethi M To: Jim Schaad , Mohit Sethi M , "draft-ietf-tls-external-psk-guidance@ietf.org" CC: "tls@ietf.org" Thread-Topic: [TLS] Review of draft-ietf-tls-external-psk-guidance-00 Thread-Index: AQHWU32mq0e1idfoLE2Dgf3tNNTFWaj6t/aAgAKdj4A= Date: Wed, 8 Jul 2020 08:03:24 +0000 Message-ID: <4f52e8f0-eb0b-d6c6-e8bd-3f6fc0b3541e@ericsson.com> References: <045601d64fea$e0d7f800$a287e800$@augustcellars.com> <006401d653af$7b029f80$7107de80$@augustcellars.com> In-Reply-To: <006401d653af$7b029f80$7107de80$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:140:10de:c8af:53f7:f0d6:ed49] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0b5074c9-a673-4189-58e0-08d8231563c8 x-ms-traffictypediagnostic: HE1PR07MB3273: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TJGBxJg4mq4O3qI3lX7KPwd4W2j+ArDNBCEb8c3XHDoS4Cl5jgM1lyk6/PWvJtQp3/XXgDH7eMpBM66f/sGRYlwVcShnOwgn1+xbf52TeEe2V1g9A0UP4JNOXxGv6GQylDBdCgXVBWgMXltDZG+nY65GusNU91MNfB6JhOe3jhODauH4jJAFzYfqd8Ff7UJHB1EHUzV69R1muh68C+QZv1AAEqw2ZV9Y9TqJzKSC2dEPZWn4goHvqD+LqwH4aDNOWp/sjmEt0U8hboWZPswUFdH+kUUbiGkPCKISdnKpSdWQlh7gWEI52LHtfv6ZPdIQ5pjwEZ5G1NsXm8wPaYb6zIVARbXbnDAl7nWH9r3z8sfulpQ2/fr0j11wgJ77+YxZwSvDueI/HQ6T9bjy1+h6/6sDe8gqt69Wgpt7pYegpAQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(346002)(39860400002)(136003)(366004)(478600001)(6486002)(966005)(4326008)(31686004)(83380400001)(166002)(8676002)(2906002)(8936002)(110136005)(316002)(66446008)(6512007)(76116006)(71200400001)(31696002)(36756003)(6506007)(53546011)(2616005)(186003)(66476007)(66946007)(66556008)(5660300002)(64756008)(86362001)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: jM93Tlr3E2A+hfBAH+Dwfv1MRUhpABMSS6JIIo2C99n/hCiUcYgOZxHIjrZ43fCekZcHhaAmZkEGXV+NueER11cVjcP3HNNKdbQVAQ62jfZlQCUzdCMt1BJM/yS/6pVzderVMt8miuEpSiPwYerZ39lgR0jPI5zLqjCcGhUlIxhVncVLbcyc6ZNenxZd7cfSRxMCkmMF21cuzS0keLS/vEuwCJHrP5bYf/MKNjVE+ry5qhfW63iYsk859Tw2rqIyqx8mFMVqFt3/zbXiNoAxJr+uVT13dYbjZhxW190K7OH6+o3C/gxjEv3IskoapN+Fr4bsJsJ2eZGDCTAWrizGFe/hlt3R+7aDdcFHHI0Ww/u90Z+TsdGr/ukT1I9Bapw7vkISYasKsRpkW8APoYEoSbFRFWI8BYNxpC2pJuBZiKSktqjORJCWYzWLkCL7eZHOCbV6Lpm1DYe021tLXkPj97Wnvu+ykglt7lJ56xMnKXVxwRuIp5hcujIXcr1f4wwoph0+DIy9oW3TTAinwwiPUQE87BAegIHl9LaQfytvK2FcGIaP6rqeiwLlt5uTU4ui Content-Type: multipart/alternative; boundary="_000_4f52e8f0eb0bd6c6e8bd3f6fc0b3541eericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3386.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0b5074c9-a673-4189-58e0-08d8231563c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2020 08:03:24.6875 (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: pfgcua81EmSzDUV0rjyE5+4h9Jgq+594GOWuxV7dmxbzlCDxOJM6pPRBjLV6KyTFa5yapQlf/w/aL/dkwdfedp4sZJWGyBIw0/8XvI5/BHo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3273 Archived-At: Subject: Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00 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 Jul 2020 08:03:30 -0000 --_000_4f52e8f0eb0bd6c6e8bd3f6fc0b3541eericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmltLA0KDQpPbiA3LzYvMjAgNzowNiBQTSwgSmltIFNjaGFhZCB3cm90ZToNCg0KDQoNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTW9oaXQgU2V0aGkgTSA8bW9oaXQu bS5zZXRoaUBlcmljc3Nvbi5jb20+PG1haWx0bzptb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbT4N ClNlbnQ6IE1vbmRheSwgSnVseSA2LCAyMDIwIDM6MTAgQU0NClRvOiBKaW0gU2NoYWFkIDxpZXRm QGF1Z3VzdGNlbGxhcnMuY29tPjxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47IGRyYWZ0 LWlldGYtdGxzLWV4dGVybmFsLXBzay0NCmd1aWRhbmNlQGlldGYub3JnPG1haWx0bzpndWlkYW5j ZUBpZXRmLm9yZz4NCkNjOiB0bHNAaWV0Zi5vcmc8bWFpbHRvOnRsc0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBSZXZpZXcgb2YgZHJhZnQtaWV0Zi10bHMtZXh0ZXJuYWwtcHNrLWd1aWRhbmNlLTAw DQoNCkhpIEppbSwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBBIGNsYXJpZnlpbmcgcXVlc3Rp b24gaW4tbGluZS4NCg0KT24gNy8yLzIwIDEyOjAyIEFNLCBKaW0gU2NoYWFkIHdyb3RlOg0KDQoN CiogSW4gc2VjdGlvbiA0IHRoZXJlIGlzIGEgc3RhdGVtZW50IHRoYXQgc3dpdGNoaW5nIHRoZSBy b2xlcyBvZg0Kc2VydmVycyB3aGljaCB1c2UgUFNLcyB3aWxsIGxlYWQgdG8gd2Vha2VuaW5nIG9m IHNlY3VyaXR5IHByb3BlcnRpZXMuDQpBcyB0aGlzIGlzIGEgY29tbW9uIHNjZW5hcmlvIHRvZGF5 IGluIHNpdHVhdGlvbnMgd2hlcmUgeW91IGFyZSBkb2luZw0Kc2VydmVyLXRvLXNlcnZlciBjb21t dW5pY2F0aW9uLCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gZGlzY3VzcyBqdXN0IGhvdw0KYW5kIGhv dyBtdWNoIHRoaXMgd2Vha2VuaW5nIG9jY3Vycy4gIFRoaXMgd2FzIGEgY29tcGxldGUgc3VycHJp c2UgdG8NCm1lIGFuZCBJIGRvbid0IGtub3cgaWYgaXQgd2FzIHN1cHBvc2VkIHRvIGJlIG9uZS4g IEFyZSB0aGVyZSBtaXRpZ2F0aW9ucyB0aGF0DQoNCg0KY2FuIGJlIG1hZGU/DQoNCg0KDQoqIElu IHNlY3Rpb24gNywgVGhlIGZpcnN0IHNlbnRlbmNlIGRvZXMgbm90IHJlYWQsIGFsc28gSXQgc2Vl bXMgYSBiaXQNCmRpZmZpY3VsdCB0byBoYXZlIGEgTVVTVCBpbiB0aGVyZSB3aGVuIG1vc3Qgb2Yg dGhlIGl0ZW1zIGJlbG93IGFyZSBTSE9VTERzLg0KVGhhdCBzZWVtcyB0byBiZSBhIGRpc3NvbmFu Y2UuDQoNCiogU2VjdGlvbiA3LjEuMSAtIFRoZSBpZGVhIG9mIGhhdmluZyBkb21haW4gbmFtZSBz dWZmaXhlcyBvbiBQU0tzDQpzZWVtcyB0byBtZSB0byBiZSBhIGJhZCBpZGVhIGFzIHRoaXMgd291 bGQgc2VlbSB0byBsb3dlciBwcml2YWN5IGxldmVscy4NCg0KDQoNCkkgdGhpbmsgeW91IGFyZSBy ZWZlcnJpbmcgdG8gdGhlIFBTSyBpZGVudGl0eSBhbmQgbm90IHRvIHRoZSBQU0suDQoNCkFzIHlv dSBrbm93LCB0aGUgTmV0d29yayBBY2Nlc3MgSWRlbnRpZmllcnMgKE5BSXMpIHVzZWQgaW4gRUFQ IHR5cGljYWxseSBuZWVkDQp0aGUgZG9tYWluIG5hbWUgc3VmZml4IGZvciByb2FtaW5nLCBmZWRl cmF0aW9uLCBldGMuDQoNCg0KDQpUaGlzIGlzIHRydWUsIGl0IGlzIGFsc28gdHJ1ZSB0aGF0IEVB UCBpcyB2ZXJ5IHN0cm9uZyBvbiBzYXlpbmcgdGhhdCBpZiB5b3UgaGF2ZSBhIGNob2ljZSwgYWx3 YXlzIHNlbmQgYW4gYW5vbnltb3VzIHZlcnNpb24gb2YgdGhlIE5BSSBpZiB5b3UgaGF2ZSB0byBk byBpdCBpbiB0aGUgY2xlYXIuICBUaGlzIG1lYW5zIHRoYXQgdGhlIGRvbWFpbiBjYW4gYmUgdXNl ZCBmb3IgY29ycmVsYXRpb24sIGJ1dCB5b3UgZG8gbm90IGhhdmUgdGhlIGZ1bGwgaWRlbnRpdHkg Zm9yIHRoYXQgcHVycG9zZS4NCg0KSSB0aGluayB0aGF0IHRoZSBFTVUgZ3JvdXAgaXMgZ29pbmcg dG8gbmVlZCB0byBsb29rIGF0IHdoYXQgbGV2ZWwgb2YgcHJpdmFjeSBwcm90ZWN0aW9uIGl0IGlz IGdvaW5nIHRvIGRlc2lyZSB3aGVuIHVzaW5nIGEgUFNLLCBidXQgaW4gdGhhdCBjYXNlIHRoZXJl IGlzIG5vIG5lZWQgZm9yIGhhdmluZyAgYSBkb21haW4gc3VmZml4IGFzIHRoYXQgaW5mb3JtYXRp b24gaXMgcHJvdmlkZWQgZWxzZXdoZXJlLiAgIFRoaXMgbWlnaHQgcmVxdWlyZSBrZWVwaW5nIHRo ZSBUTFMgdHVubmVsaW5nIGFzIGFuIG9wdGlvbiB0byBkZWFsIHdpdGggcGFzc2l2ZSBhdHRhY2tz Lg0KDQpZb3UgYXJlIGFic29sdXRlbHkgcmlnaHQgYWJvdXQgdGhlIHByZWZlcmVuY2UgZm9yIHVz aW5nIGFub255bW91cyBpZGVudGl0aWVzLiBkcmFmdC1pZXRmLWVtdS1lYXAtdGxzMTMgY3VycmVu dGx5IHNheXMgdGhlIGZvbGxvd2luZyBhYm91dCByZXN1bXB0aW9uOg0KDQogICBJdCBpcyBSRUNP TU1FTkRFRCB0byB1c2UgYSBOQUlzIHdpdGggdGhlIHNhbWUgcmVhbG0gaW4gdGhlIHJlc3VtcHRp b24NCiAgIGFuZCB0aGUgb3JpZ2luYWwgZnVsbCBhdXRoZW50aWNhdGlvbi4gIFRoaXMgcmVxdWly ZW1lbnQgYWxsb3dzIEVBUA0KICAgcGFja2V0cyB0byBiZSByb3V0YWJsZSB0byB0aGUgc2FtZSBk ZXN0aW5hdGlvbiBhcyB0aGUgb3JpZ2luYWwgZnVsbA0KICAgYXV0aGVudGljYXRpb24uICBJZiB0 aGlzIHJlY29tbWVuZGF0aW9uIGlzIG5vdCBmb2xsb3dlZCwgcmVzdW1wdGlvbg0KICAgaXMgbGlr ZWx5IHRvIGJlIGltcG9zc2libGUuICBXaGVuIE5BSSByZXVzZSBjYW4gYmUgZG9uZSB3aXRob3V0 DQogICBwcml2YWN5IGltcGxpY2F0aW9ucywgaXQgaXMgUkVDT01NRU5ERUQgdG8gdXNlIHRoZSBz YW1lIGFub255bW91cyBOQUkNCiAgIGluIHRoZSByZXN1bXB0aW9uLCBhcyB3YXMgdXNlZCBpbiB0 aGUgb3JpZ2luYWwgZnVsbCBhdXRoZW50aWNhdGlvbi4NCiAgIEUuZy4gdGhlIE5BSSBAcmVhbG0g Y2FuIHNhZmVseSBiZSByZXVzZWQsIHdoaWxlIHRoZSBOQUkNCiAgIFpteGxlRzg9QHJlYWxtIGNh bm5vdC4NCg0KVGhpcyBkb2N1bWVudCBhbmQgdGhlIGVuc3VpbmcgZGlzY3Vzc2lvbiBwZXJ0YWlu cyBvbmx5IHRvIGV4dGVybmFsIFBTS3MgYW5kIGV4dGVybmFsIFBTSyBpZGVudGl0aWVzLiBJIHRo aW5rIEkgaW5jb3JyZWN0bHkgdXNlZCB0aGUgd29yZCAiaXNzdWUiIGluIG15IHByZXZpb3VzIGVt YWlsIGFzIGEgbW9yZSBjb3JyZWN0IGNob2ljZSB3b3VsZCBoYXZlIGJlZW4gImFncmVlL2VzdGFi bGlzaCIgKGkuZS4gdGhlIHNlcnZlciBhbmQgY2xpZW50IGFncmVlIG9uIGFuIGV4dGVybmFsIFBT SyBhbmQgYW4gZXh0ZXJuYWwgUFNLIGlkZW50aXR5KS4gUkZDIDg0NDYgZG9lc24ndCBwbGFjZSBh bnkgcmVzdHJpY3Rpb25zIG9uIGV4dGVybmFsIFBTSyBpZGVudGl0aWVzIChvdGhlciB0aGFuIHRo ZSBmYWN0IHRoYXQgdGhleSBhcmUgYXQgbGVhc3QgMSBieXRlKS4gSWYgd2UgYXJlIGdvaW5nIHRv IGRpc2NvdXJhZ2UgdGhlIHVzZSBvZiBkb21haW4gbmFtZXMgaW4gZXh0ZXJuYWwgUFNLIGlkZW50 aXRpZXMsIHdvdWxkIHRoYXQgYmUgc3VmZmljaWVudD8gV2hhdCBwcmV2ZW50cyBtZSBmcm9tIHVz aW5nIGFuIGV4dGVybmFsIFBTSyBpZGVudGl0eSBvZiB0aGUgdHlwZTogbXlfc3Ryb25nX3NlY3Jl dF9wc2tfd2l0aF9hbWF6b25fc2VydmVyPw0KDQpJIGFtIG5vdCBzdXJlIGlmIHdlIHNob3VsZCBy ZWNvbW1lbmQgcmFuZG9taXplZCBleHRlcm5hbCBQU0sgaWRlbnRpdGllcyBvZiBhIGNlcnRhaW4g bWluaW11bSBsZW5ndGguIFBlcmhhcHMgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIGFkZCBhIGRpc2Ns YWltZXIgYWJvdXQgdGhlIHByaXZhY3kgbG9zcyBmcm9tIGNhcmVsZXNzbHkgY2hvc2VuIGV4dGVy bmFsIFBTSyBpZGVudGl0aWVzPw0KDQotLU1vaGl0DQoNCg0KDQoNCg0KDQoNCg0KDQpJIHdvdWxk IGxpa2UgdG8gdW5kZXJzdGFuZCB0aGUgbmF0dXJlIG9mIHRoZSByZXN1bHRpbmcgcHJpdmFjeSBs b3NzLiBJcyBpdCB0aGF0IGENCnBhc3NpdmUgYXR0YWNrZXIgY2FuIG5vdyBlYXNpbHkgZGV0ZXJt aW5lIHRoZSBzZXJ2ZXIgd2hpY2ggaXNzdWVkIHRoZSBQU0sNCmlkZW50aXR5IChhbmQgdGhlIHNl cnZlciB3aGVyZSBpdCB3aWxsIGV2ZW50dWFsbHkgYmUgdXNlZCk/DQoNCg0KDQpXaGlsZSBpdCBJ IHRydWUgdGhhdCBhdCBsZWFzdCBzb21lIG9mIHRoZSBwcml2YWN5IGluZm9ybWF0aW9uIGhhcyBh bHJlYWR5IGJlZW4gbGVha2VkIGluIHRoZSBQU0sgY2FzZSwgeW91IGtub3cgdGhlIGFkZHJlc3Mg dGhhdCBpcyBiZWluZyB0YWxrZWQgdG8gYW5kIHRoZSBQU0sgaWRlbnRpdHkgdGhhdCBpcyBwYXNz ZWQuICBJZiB5b3UgbG9vayBhdCB1c2luZyB0aGlncyBsaWtlIEVTTkksIGRvaW5nIHRoaXMgd291 bGQgYXBwZWFyIHRvIHBvdGVudGlhbGx5IGdpdmUgYXdheSB0aGUgdmVyeSBpbmZvcm1hdGlvbiB0 aGF0IGlzIGJlaW5nIGhpZGRlbiBpbiB0aGF0IGNhc2UuDQoNClRoZSBvdGhlciBwcm9ibGVtIHdp dGggaGF2aW5nIGRvbWFpbiBiYXNlZCBLSURzIGlzIHRoYXQgeW91IGNvdWxkIGVhc2lseSBnZXQg c29tZSBhbW91bnQgb2YgY29ycmVsYXRpb24gYmV0d2VlbiB0aGUgS0lEcyB0aGF0IGFyZSBhc3Np Z25lZCBpbiBkaWZmZXJlbnQgZG9tYWlucy4gIFlvdSBjb3VsZCBlbmQgdXAgd2l0aCBtb2hpdC5p ZXRmIGFuZCBtb2hpdC5hbWF6b24gYW5kIGl0IHdvdWxkIGJlIHF1aXRlIHJlYXNvbmFibGUgdG8g YXNzdW1lIHRoYXQgYm90aCBvZiB0aG9zZSBpZGVudGl0aWVzIGFyZSBnb2luZyB0byBiZSBmb3Ig dGhlIHNhbWUgZW50aXR5LCBqdXN0IGluIGRpZmZlcmVudCBkb21haW5zLg0KDQpKaW0NCg0KDQoN Cg0KDQotLU1vaGl0DQoNCg0KDQoNCiogU2VjdGlvbiA3LjEuMiAtIFRoZXJlIHNlZW0gdG8gbWUg dG8gYmUgdGhyZWUgZGlmZmVyZW50IHBsYWNlcyB3aGVyZQ0KY29sbGlzaW9ucyB3aWxsIG9jY3Vy LiAgVGhlIGltcG9ydGVyIGZ1bmN0aW9uIGNvdWxkIGdldCBhIGNvbGxpc2lvbiwNCnRoZXJlIGNv dWxkIGJlIGNvbGxpc2lvbnMgd2l0aCBwcmUtVExTIDEuMiBleHRlcm5hbCBpZGVudGlmaWVycyBh bmQNCnRoZXJlIGNvdWxkIGJlIGNvbGxpc2lvbiB3aXRoIHJlc3VtcHRpb24ga2V5cy4gIFRoZXJl IGhhcyBiZWVuIGEgaHVnZQ0KZGlzY3Vzc2lvbiBhYm91dCB0aGlzIGluIHRoZSBFTVUgZ3JvdXAg YW5kIEkgZG9uJ3QgZmluZCB0aGUgdGV4dCBoZXJlDQp0byBiZSBzZW5zaWJsZSBpbiB0ZXJtIG9m IHdoZXRoZXIgdGhpcyBpcyBvciBpcyBub3QgYSBwcm9ibGVtLg0KDQoqIFNlY3Rpb24gNy4xLjIg LSBPbmUgb2YgdGhlIHRoaW5ncyB0aGF0IEkga2VwdCBtZWFuaW5nIHRvIGdldCB0byBhbmQNCmp1 c3QgaGF2ZW4ndCBkb25lIHNvIHlldCwgaXMgZGVhbGluZyB3aXRoIHRoZSBxdWVzdGlvbiBvZiBj YW4gdGhlIFRMUw0KS2V5IGJpbmRlcnMgaW4gdGhlIGhhbmRzaGFrZSB0byBkaXN0aW5ndWlzaCBi ZXR3ZWVuIG11bHRpcGxlIGtleXMgdGhhdA0KaGFwcGVuIHRvIGhhdmUgdGhlIHNhbWUgaWRlbnRp dHkuICBQZXJoYXBzIHlvdSBzaG91bGQgbG9vayB0byBzZWUgaWYNCnRoaXMgZG9lcyB3b3JrIGFu ZCBpZiBpdCBpcyBzYWZlLg0KDQpKaW0NCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3Jn PG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3Rscw0KDQo= --_000_4f52e8f0eb0bd6c6e8bd3f6fc0b3541eericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <9EB885C7875C28408DCF37E167965A90@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHA+SGkgSmltLDwv cD4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gNy82LzIwIDc6MDYgUE0sIEppbSBT Y2hhYWQgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJt aWQ6MDA2NDAxZDY1M2FmJDdiMDI5ZjgwJDcxMDdkZTgwJEBhdWd1c3RjZWxsYXJzLmNvbSI+DQo8 cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPg0KDQo8L3ByZT4NCjxibG9ja3F1b3Rl IHR5cGU9ImNpdGUiPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTW9oaXQgU2V0aGkgTSA8YSBjbGFzcz0ibW96LXR4 dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20i PiZsdDttb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbSZndDs8L2E+DQpTZW50OiBNb25kYXksIEp1 bHkgNiwgMjAyMCAzOjEwIEFNDQpUbzogSmltIFNjaGFhZCA8YSBjbGFzcz0ibW96LXR4dC1saW5r LXJmYzIzOTZFIiBocmVmPSJtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSI+Jmx0O2lldGZA YXVndXN0Y2VsbGFycy5jb20mZ3Q7PC9hPjsgZHJhZnQtaWV0Zi10bHMtZXh0ZXJuYWwtcHNrLQ0K PGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmd1aWRhbmNl QGlldGYub3JnIj5ndWlkYW5jZUBpZXRmLm9yZzwvYT4NCkNjOiA8YSBjbGFzcz0ibW96LXR4dC1s aW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86dGxzQGlldGYub3JnIj50bHNAaWV0Zi5vcmc8 L2E+DQpTdWJqZWN0OiBSZTogUmV2aWV3IG9mIGRyYWZ0LWlldGYtdGxzLWV4dGVybmFsLXBzay1n dWlkYW5jZS0wMA0KDQpIaSBKaW0sDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldy4gQSBjbGFyaWZ5 aW5nIHF1ZXN0aW9uIGluLWxpbmUuDQoNCk9uIDcvMi8yMCAxMjowMiBBTSwgSmltIFNjaGFhZCB3 cm90ZToNCjwvcHJlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8cHJlIGNsYXNzPSJtb3ot cXVvdGUtcHJlIiB3cmFwPSIiPiogSW4gc2VjdGlvbiA0IHRoZXJlIGlzIGEgc3RhdGVtZW50IHRo YXQgc3dpdGNoaW5nIHRoZSByb2xlcyBvZg0Kc2VydmVycyB3aGljaCB1c2UgUFNLcyB3aWxsIGxl YWQgdG8gd2Vha2VuaW5nIG9mIHNlY3VyaXR5IHByb3BlcnRpZXMuDQpBcyB0aGlzIGlzIGEgY29t bW9uIHNjZW5hcmlvIHRvZGF5IGluIHNpdHVhdGlvbnMgd2hlcmUgeW91IGFyZSBkb2luZw0Kc2Vy dmVyLXRvLXNlcnZlciBjb21tdW5pY2F0aW9uLCBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gZGlzY3Vz cyBqdXN0IGhvdw0KYW5kIGhvdyBtdWNoIHRoaXMgd2Vha2VuaW5nIG9jY3Vycy4gIFRoaXMgd2Fz IGEgY29tcGxldGUgc3VycHJpc2UgdG8NCm1lIGFuZCBJIGRvbid0IGtub3cgaWYgaXQgd2FzIHN1 cHBvc2VkIHRvIGJlIG9uZS4gIEFyZSB0aGVyZSBtaXRpZ2F0aW9ucyB0aGF0DQo8L3ByZT4NCjwv YmxvY2txdW90ZT4NCjxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+Y2FuIGJlIG1h ZGU/DQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPHByZSBjbGFzcz0ibW96LXF1 b3RlLXByZSIgd3JhcD0iIj4NCiogSW4gc2VjdGlvbiA3LCBUaGUgZmlyc3Qgc2VudGVuY2UgZG9l cyBub3QgcmVhZCwgYWxzbyBJdCBzZWVtcyBhIGJpdA0KZGlmZmljdWx0IHRvIGhhdmUgYSBNVVNU IGluIHRoZXJlIHdoZW4gbW9zdCBvZiB0aGUgaXRlbXMgYmVsb3cgYXJlIFNIT1VMRHMuDQpUaGF0 IHNlZW1zIHRvIGJlIGEgZGlzc29uYW5jZS4NCg0KKiBTZWN0aW9uIDcuMS4xIC0gVGhlIGlkZWEg b2YgaGF2aW5nIGRvbWFpbiBuYW1lIHN1ZmZpeGVzIG9uIFBTS3MNCnNlZW1zIHRvIG1lIHRvIGJl IGEgYmFkIGlkZWEgYXMgdGhpcyB3b3VsZCBzZWVtIHRvIGxvd2VyIHByaXZhY3kgbGV2ZWxzLg0K PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIi Pg0KSSB0aGluayB5b3UgYXJlIHJlZmVycmluZyB0byB0aGUgUFNLIGlkZW50aXR5IGFuZCBub3Qg dG8gdGhlIFBTSy4NCg0KQXMgeW91IGtub3csIHRoZSBOZXR3b3JrIEFjY2VzcyBJZGVudGlmaWVy cyAoTkFJcykgdXNlZCBpbiBFQVAgdHlwaWNhbGx5IG5lZWQNCnRoZSBkb21haW4gbmFtZSBzdWZm aXggZm9yIHJvYW1pbmcsIGZlZGVyYXRpb24sIGV0Yy4NCjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0K PHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3JhcD0iIj4NClRoaXMgaXMgdHJ1ZSwgaXQgaXMg YWxzbyB0cnVlIHRoYXQgRUFQIGlzIHZlcnkgc3Ryb25nIG9uIHNheWluZyB0aGF0IGlmIHlvdSBo YXZlIGEgY2hvaWNlLCBhbHdheXMgc2VuZCBhbiBhbm9ueW1vdXMgdmVyc2lvbiBvZiB0aGUgTkFJ IGlmIHlvdSBoYXZlIHRvIGRvIGl0IGluIHRoZSBjbGVhci4gIFRoaXMgbWVhbnMgdGhhdCB0aGUg ZG9tYWluIGNhbiBiZSB1c2VkIGZvciBjb3JyZWxhdGlvbiwgYnV0IHlvdSBkbyBub3QgaGF2ZSB0 aGUgZnVsbCBpZGVudGl0eSBmb3IgdGhhdCBwdXJwb3NlLg0KDQpJIHRoaW5rIHRoYXQgdGhlIEVN VSBncm91cCBpcyBnb2luZyB0byBuZWVkIHRvIGxvb2sgYXQgd2hhdCBsZXZlbCBvZiBwcml2YWN5 IHByb3RlY3Rpb24gaXQgaXMgZ29pbmcgdG8gZGVzaXJlIHdoZW4gdXNpbmcgYSBQU0ssIGJ1dCBp biB0aGF0IGNhc2UgdGhlcmUgaXMgbm8gbmVlZCBmb3IgaGF2aW5nICBhIGRvbWFpbiBzdWZmaXgg YXMgdGhhdCBpbmZvcm1hdGlvbiBpcyBwcm92aWRlZCBlbHNld2hlcmUuICAgVGhpcyBtaWdodCBy ZXF1aXJlIGtlZXBpbmcgdGhlIFRMUyB0dW5uZWxpbmcgYXMgYW4gb3B0aW9uIHRvIGRlYWwgd2l0 aCBwYXNzaXZlIGF0dGFja3MuPC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD5Zb3UgYXJlIGFic29s dXRlbHkgcmlnaHQgYWJvdXQgdGhlIHByZWZlcmVuY2UgZm9yIHVzaW5nIGFub255bW91cyBpZGVu dGl0aWVzLiBkcmFmdC1pZXRmLWVtdS1lYXAtdGxzMTMgY3VycmVudGx5IHNheXMgdGhlIGZvbGxv d2luZyBhYm91dCByZXN1bXB0aW9uOg0KPC9wPg0KPHA+PC9wPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQo8cHJlIGNsYXNzPSJuZXdwYWdlIj4gICBJdCBpcyBSRUNPTU1FTkRFRCB0byB1c2Ug YSBOQUlzIHdpdGggdGhlIHNhbWUgcmVhbG0gaW4gdGhlIHJlc3VtcHRpb24NCiAgIGFuZCB0aGUg b3JpZ2luYWwgZnVsbCBhdXRoZW50aWNhdGlvbi4gIFRoaXMgcmVxdWlyZW1lbnQgYWxsb3dzIEVB UA0KICAgcGFja2V0cyB0byBiZSByb3V0YWJsZSB0byB0aGUgc2FtZSBkZXN0aW5hdGlvbiBhcyB0 aGUgb3JpZ2luYWwgZnVsbA0KICAgYXV0aGVudGljYXRpb24uICBJZiB0aGlzIHJlY29tbWVuZGF0 aW9uIGlzIG5vdCBmb2xsb3dlZCwgcmVzdW1wdGlvbg0KICAgaXMgbGlrZWx5IHRvIGJlIGltcG9z c2libGUuICBXaGVuIE5BSSByZXVzZSBjYW4gYmUgZG9uZSB3aXRob3V0DQogICBwcml2YWN5IGlt cGxpY2F0aW9ucywgaXQgaXMgUkVDT01NRU5ERUQgdG8gdXNlIHRoZSBzYW1lIGFub255bW91cyBO QUkNCiAgIGluIHRoZSByZXN1bXB0aW9uLCBhcyB3YXMgdXNlZCBpbiB0aGUgb3JpZ2luYWwgZnVs bCBhdXRoZW50aWNhdGlvbi4NCiAgIEUuZy4gdGhlIE5BSSBAcmVhbG0gY2FuIHNhZmVseSBiZSBy ZXVzZWQsIHdoaWxlIHRoZSBOQUkNCiAgIFpteGxlRzg9QHJlYWxtIGNhbm5vdC4gPC9wcmU+DQo8 L2Jsb2NrcXVvdGU+DQpUaGlzIGRvY3VtZW50IGFuZCB0aGUgZW5zdWluZyBkaXNjdXNzaW9uIHBl cnRhaW5zIG9ubHkgdG8gZXh0ZXJuYWwgUFNLcyBhbmQgZXh0ZXJuYWwgUFNLIGlkZW50aXRpZXMu IEkgdGhpbmsgSSBpbmNvcnJlY3RseSB1c2VkIHRoZSB3b3JkICZxdW90O2lzc3VlJnF1b3Q7IGlu IG15IHByZXZpb3VzIGVtYWlsIGFzIGEgbW9yZSBjb3JyZWN0IGNob2ljZSB3b3VsZCBoYXZlIGJl ZW4gJnF1b3Q7YWdyZWUvZXN0YWJsaXNoJnF1b3Q7IChpLmUuIHRoZSBzZXJ2ZXIgYW5kIGNsaWVu dCBhZ3JlZQ0KIG9uIGFuIGV4dGVybmFsIFBTSyBhbmQgYW4gZXh0ZXJuYWwgUFNLIGlkZW50aXR5 KS4gUkZDIDg0NDYgZG9lc24ndCBwbGFjZSBhbnkgcmVzdHJpY3Rpb25zIG9uIGV4dGVybmFsIFBT SyBpZGVudGl0aWVzIChvdGhlciB0aGFuIHRoZSBmYWN0IHRoYXQgdGhleSBhcmUgYXQgbGVhc3Qg MSBieXRlKS4gSWYgd2UgYXJlIGdvaW5nIHRvIGRpc2NvdXJhZ2UgdGhlIHVzZSBvZiBkb21haW4g bmFtZXMgaW4gZXh0ZXJuYWwgUFNLIGlkZW50aXRpZXMsIHdvdWxkDQogdGhhdCBiZSBzdWZmaWNp ZW50PyBXaGF0IHByZXZlbnRzIG1lIGZyb20gdXNpbmcgYW4gZXh0ZXJuYWwgUFNLIGlkZW50aXR5 IG9mIHRoZSB0eXBlOiBteV9zdHJvbmdfc2VjcmV0X3Bza193aXRoX2FtYXpvbl9zZXJ2ZXI/DQo8 YnI+DQo8cD48L3A+DQo8cD5JIGFtIG5vdCBzdXJlIGlmIHdlIHNob3VsZCByZWNvbW1lbmQgcmFu ZG9taXplZCBleHRlcm5hbCBQU0sgaWRlbnRpdGllcyBvZiBhIGNlcnRhaW4gbWluaW11bSBsZW5n dGguIFBlcmhhcHMgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIGFkZCBhIGRpc2NsYWltZXIgYWJvdXQg dGhlIHByaXZhY3kgbG9zcyBmcm9tIGNhcmVsZXNzbHkgY2hvc2VuIGV4dGVybmFsIFBTSyBpZGVu dGl0aWVzPw0KPGJyPg0KPC9wPg0KPHA+LS1Nb2hpdDxicj4NCjwvcD4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNpdGU9Im1pZDowMDY0MDFkNjUzYWYkN2IwMjlmODAkNzEwN2RlODAkQGF1Z3Vz dGNlbGxhcnMuY29tIj4NCjxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+DQo8L3By ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDowMDY0 MDFkNjUzYWYkN2IwMjlmODAkNzEwN2RlODAkQGF1Z3VzdGNlbGxhcnMuY29tIj4NCjxwcmUgY2xh c3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+DQoNCjwvcHJlPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPg0KSSB3b3VsZCBsaWtl IHRvIHVuZGVyc3RhbmQgdGhlIG5hdHVyZSBvZiB0aGUgcmVzdWx0aW5nIHByaXZhY3kgbG9zcy4g SXMgaXQgdGhhdCBhDQpwYXNzaXZlIGF0dGFja2VyIGNhbiBub3cgZWFzaWx5IGRldGVybWluZSB0 aGUgc2VydmVyIHdoaWNoIGlzc3VlZCB0aGUgUFNLDQppZGVudGl0eSAoYW5kIHRoZSBzZXJ2ZXIg d2hlcmUgaXQgd2lsbCBldmVudHVhbGx5IGJlIHVzZWQpPw0KPC9wcmU+DQo8L2Jsb2NrcXVvdGU+ DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPg0KV2hpbGUgaXQgSSB0cnVlIHRo YXQgYXQgbGVhc3Qgc29tZSBvZiB0aGUgcHJpdmFjeSBpbmZvcm1hdGlvbiBoYXMgYWxyZWFkeSBi ZWVuIGxlYWtlZCBpbiB0aGUgUFNLIGNhc2UsIHlvdSBrbm93IHRoZSBhZGRyZXNzIHRoYXQgaXMg YmVpbmcgdGFsa2VkIHRvIGFuZCB0aGUgUFNLIGlkZW50aXR5IHRoYXQgaXMgcGFzc2VkLiAgSWYg eW91IGxvb2sgYXQgdXNpbmcgdGhpZ3MgbGlrZSBFU05JLCBkb2luZyB0aGlzIHdvdWxkIGFwcGVh ciB0byBwb3RlbnRpYWxseSBnaXZlIGF3YXkgdGhlIHZlcnkgaW5mb3JtYXRpb24gdGhhdCBpcyBi ZWluZyBoaWRkZW4gaW4gdGhhdCBjYXNlLiAgDQoNClRoZSBvdGhlciBwcm9ibGVtIHdpdGggaGF2 aW5nIGRvbWFpbiBiYXNlZCBLSURzIGlzIHRoYXQgeW91IGNvdWxkIGVhc2lseSBnZXQgc29tZSBh bW91bnQgb2YgY29ycmVsYXRpb24gYmV0d2VlbiB0aGUgS0lEcyB0aGF0IGFyZSBhc3NpZ25lZCBp biBkaWZmZXJlbnQgZG9tYWlucy4gIFlvdSBjb3VsZCBlbmQgdXAgd2l0aCBtb2hpdC5pZXRmIGFu ZCBtb2hpdC5hbWF6b24gYW5kIGl0IHdvdWxkIGJlIHF1aXRlIHJlYXNvbmFibGUgdG8gYXNzdW1l IHRoYXQgYm90aCBvZiB0aG9zZSBpZGVudGl0aWVzIGFyZSBnb2luZyB0byBiZSBmb3IgdGhlIHNh bWUgZW50aXR5LCBqdXN0IGluIGRpZmZlcmVudCBkb21haW5zLg0KDQpKaW0NCg0KDQo8L3ByZT4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIgd3Jh cD0iIj4NCi0tTW9oaXQNCg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxwcmUg Y2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+DQoqIFNlY3Rpb24gNy4xLjIgLSBUaGVyZSBz ZWVtIHRvIG1lIHRvIGJlIHRocmVlIGRpZmZlcmVudCBwbGFjZXMgd2hlcmUNCmNvbGxpc2lvbnMg d2lsbCBvY2N1ci4gIFRoZSBpbXBvcnRlciBmdW5jdGlvbiBjb3VsZCBnZXQgYSBjb2xsaXNpb24s DQp0aGVyZSBjb3VsZCBiZSBjb2xsaXNpb25zIHdpdGggcHJlLVRMUyAxLjIgZXh0ZXJuYWwgaWRl bnRpZmllcnMgYW5kDQp0aGVyZSBjb3VsZCBiZSBjb2xsaXNpb24gd2l0aCByZXN1bXB0aW9uIGtl eXMuICBUaGVyZSBoYXMgYmVlbiBhIGh1Z2UNCmRpc2N1c3Npb24gYWJvdXQgdGhpcyBpbiB0aGUg RU1VIGdyb3VwIGFuZCBJIGRvbid0IGZpbmQgdGhlIHRleHQgaGVyZQ0KdG8gYmUgc2Vuc2libGUg aW4gdGVybSBvZiB3aGV0aGVyIHRoaXMgaXMgb3IgaXMgbm90IGEgcHJvYmxlbS4NCg0KKiBTZWN0 aW9uIDcuMS4yIC0gT25lIG9mIHRoZSB0aGluZ3MgdGhhdCBJIGtlcHQgbWVhbmluZyB0byBnZXQg dG8gYW5kDQpqdXN0IGhhdmVuJ3QgZG9uZSBzbyB5ZXQsIGlzIGRlYWxpbmcgd2l0aCB0aGUgcXVl c3Rpb24gb2YgY2FuIHRoZSBUTFMNCktleSBiaW5kZXJzIGluIHRoZSBoYW5kc2hha2UgdG8gZGlz dGluZ3Vpc2ggYmV0d2VlbiBtdWx0aXBsZSBrZXlzIHRoYXQNCmhhcHBlbiB0byBoYXZlIHRoZSBz YW1lIGlkZW50aXR5LiAgUGVyaGFwcyB5b3Ugc2hvdWxkIGxvb2sgdG8gc2VlIGlmDQp0aGlzIGRv ZXMgd29yayBhbmQgaWYgaXQgaXMgc2FmZS4NCg0KSmltDQoNCg0KPC9wcmU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWls aW5nIGxpc3QNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0 bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT4NCjxhIGNsYXNzPSJtb3otdHh0LWxpbmst ZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxz Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT4NCjwvcHJlPg0K PC9ibG9ja3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4f52e8f0eb0bd6c6e8bd3f6fc0b3541eericssoncom_-- From nobody Wed Jul 8 03:58: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 558F13A07E5 for ; Wed, 8 Jul 2020 03:58: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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 F5d4FFdkzasV for ; Wed, 8 Jul 2020 03:58:46 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (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 053EB3A07E3 for ; Wed, 8 Jul 2020 03:58:45 -0700 (PDT) Received: from pps.filterd (m0050098.ppops.net [127.0.0.1]) by m0050098.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 068Avjww021327 for ; Wed, 8 Jul 2020 11:57:45 +0100 Received: from pps.reinject (localhost [127.0.0.1]) by m0050098.ppops.net-00190b01. with ESMTP id 3255gt88ds-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 08 Jul 2020 11:57:45 +0100 Received: from pps.reinject (m0050098.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 068AvgST021305 for ; Wed, 8 Jul 2020 11:57:44 +0100 Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 322he8kdus-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 08 Jul 2020 05:22:26 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06846QvY013001 for ; Wed, 8 Jul 2020 00:22:25 -0400 Received: from prod-mail-relay18.dfw02.corp.akamai.com ([172.27.165.172]) by prod-mail-ppoint4.akamai.com with ESMTP id 322n3y03bg-1 for ; Wed, 08 Jul 2020 00:22:25 -0400 Received: from akamai.com (unknown [172.19.16.134]) by prod-mail-relay18.dfw02.corp.akamai.com (Postfix) with ESMTP id 20C36346 for ; Wed, 8 Jul 2020 04:22:24 +0000 (GMT) Date: Tue, 7 Jul 2020 21:22:24 -0700 From: Benjamin Kaduk To: tls@ietf.org Message-ID: <20200708042223.GB20623@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-08_01:2020-07-08, 2020-07-08 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=17 suspectscore=1 bulkscore=0 spamscore=17 mlxlogscore=69 phishscore=0 malwarescore=0 adultscore=0 mlxscore=17 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007080024 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-08_01:2020-07-08, 2020-07-08 signatures=0 X-Proofpoint-Spam-Details: rule=spam policy=default score=53 priorityscore=1501 mlxlogscore=-4 impostorscore=0 lowpriorityscore=0 suspectscore=1 phishscore=0 spamscore=53 clxscore=1015 bulkscore=0 malwarescore=0 adultscore=0 cotscore=-2147483648 mlxscore=53 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2007080027 Archived-At: Subject: [TLS] invariant or not: one TLS connection per TCP connection? 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 Jul 2020 10:58:47 -0000 Hi all, There's an interesting note in draft-ietf-nfsv4-rpc-tls-08 (currently in IESG Evaluation): The protocol convention specified in the current document assumes there can be no more than one concurrent TLS session per TCP connection. This is true of current generations of TLS, but might be different in a future version of TLS. Can we envision wanting to do such a thing (e.g., with connection IDs for non-D TLS)? If not, I can give them guidance that this type of statement is not needed. Thanks, Ben From nobody Wed Jul 8 05:46: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 9C4B43A09A9 for ; Wed, 8 Jul 2020 05:46:05 -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 Ve5HXniZ96y5 for ; Wed, 8 Jul 2020 05:46:02 -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 52CD53A09C0 for ; Wed, 8 Jul 2020 05:46:01 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id m26so26799506lfo.13 for ; Wed, 08 Jul 2020 05:46:01 -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=eoTFVriAqEkQJhR5oNwH4oshzdJlUtiwUporw3I4QdA=; b=kJ+KrvSvxXxXdoxOEWPskp5dWKRGdiIdU/ZwyFLm/DWoYKntZ4l+8pc31ur5Eg7xeP 5kP2AY2odLMgEPXrp0tHk3GM5wn2g5gLLShv9+eXUfrW03idA7qjFgkUV759q45uIbDm r/nfi96HeKbIW1Q6+myiA8bIh/5rkJTHUb/TBTEMuYn1xeiBusDJ63Ycus7MWUMDmxRm v89IecwyR6KEq7S1nA6ub05COOkqpYwOGJCarkekOtdnJTowGNiuyXD9jhEtvmjPL69u b1y9l/iXjmoTjugdFaNpphRsK+6qiZgCTRl8sH2zZaS0rZB6VrOlEzKZagoRq0G2Q5pj Catg== 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=eoTFVriAqEkQJhR5oNwH4oshzdJlUtiwUporw3I4QdA=; b=lagrKRt7r9OxYGlQbNaeYG1aqXI+p8LYssm4pzUcidIRWx3DVNOGc76fpKvovmWD3L q0HDXaSyUsUxNy+9bycwU14Tg9Gu1DKEiZ0xbT8Xs9wKJ+5XbxM1EBefUN6/2ikmklRM 4nzuv6XRNYRfjxAIJYt2zZ0USsn1fTVxKdmPs4YxRb4mmTRZezjq9reRoOL5Wbm67ond +KTM3D94bm7RGPxDZLl3NotFQKCY5VkPB6d42b//K11qGC8CfAfEHpLRCIZVqQ+W9GR+ 7C59Vk4Ttf5Mtu5dw9LsyQiRP/bThaDO5WnHJtYahCNz13q+t5zLGLnB/EV9/VFzY9Pl ap8A== X-Gm-Message-State: AOAM531KbnLLzniyavSTtgjRsJp6qlgOBBUliGw3irEH6rulo5+9j/0p 4DzNhri2n+hI0dwJ7sTHAwRMOEAELAtDIclYEslBliJz2Cc= X-Google-Smtp-Source: ABdhPJyl1IIUUHfQOYA34HI+7A4ffLmep14/e6NFlBnHtXvf0KlPro35qMhbyAwm7eGiEwcL40YO2upfffXaVW829Fk= X-Received: by 2002:ac2:4158:: with SMTP id c24mr36404427lfi.109.1594212359421; Wed, 08 Jul 2020 05:45:59 -0700 (PDT) MIME-Version: 1.0 References: <20200708042223.GB20623@akamai.com> In-Reply-To: <20200708042223.GB20623@akamai.com> From: Eric Rescorla Date: Wed, 8 Jul 2020 05:45:23 -0700 Message-ID: To: Benjamin Kaduk Cc: "" Content-Type: multipart/alternative; boundary="00000000000061513c05a9ed7ddb" Archived-At: Subject: Re: [TLS] invariant or not: one TLS connection per TCP connection? 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 Jul 2020 12:46:06 -0000 --00000000000061513c05a9ed7ddb Content-Type: text/plain; charset="UTF-8" On Wed, Jul 8, 2020 at 3:59 AM Benjamin Kaduk wrote: > Hi all, > > There's an interesting note in draft-ietf-nfsv4-rpc-tls-08 (currently > in IESG Evaluation): > > The protocol convention specified in the current document assumes > there can be no more than one concurrent TLS session per TCP > connection. This is true of current generations of TLS, but might be > different in a future version of TLS. > > Can we envision wanting to do such a thing (e.g., with connection IDs for > non-D TLS)? If not, I can give them guidance that this type of statement > is not needed. > This may turn out to be permissible with cTLS, so I think we should not remove it. -Ekr > Thanks, > > Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000061513c05a9ed7ddb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 8, 2020 at 3:59 AM Benjam= in Kaduk <bkaduk=3D40akam= ai.com@dmarc.ietf.org> wrote:
Hi all,

There's an interesting note in draft-ietf-nfsv4-rpc-tls-08 (currently in IESG Evaluation):

=C2=A0 =C2=A0The protocol convention specified in the current document assu= mes
=C2=A0 =C2=A0there can be no more than one concurrent TLS session per TCP =C2=A0 =C2=A0connection.=C2=A0 This is true of current generations of TLS, = but might be
=C2=A0 =C2=A0different in a future version of TLS.

Can we envision wanting to do such a thing (e.g., with connection IDs for non-D TLS)?=C2=A0 If not, I can give them guidance that this type of statem= ent
is not needed.

This may turn out to be = permissible with cTLS, so I think we should not remove it.

-Ekr


Thanks,

Ben

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000061513c05a9ed7ddb-- From nobody Wed Jul 8 07:14: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 36F033A0C25 for ; Wed, 8 Jul 2020 07:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 R1Pxa8VC6urZ for ; Wed, 8 Jul 2020 07:14:04 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 D82403A0D40 for ; Wed, 8 Jul 2020 07:13:46 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id d17so39707658ljl.3 for ; Wed, 08 Jul 2020 07:13:46 -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 :cc; bh=TU4UMVr0Ynz0M30ckEzLTexnFvpQNqdYCpSNEglwxE0=; b=uc0AJ1g0w80aBl4oy7X7TsmqFEPmJsYCnwjKw/jZwXVPPXxPmavX5UC2hH5HNzv8Sp hQWua8bsm1FulKAIltP+hHbJbUrGpCgO3Ro8s4hDbgY6MdjGnzOx8+Pgmticvv7j99tA XYEaQF1/7VXZjcHBHXxhVLC2pW6coRQs5kkzb32VWwem+tAmbvOHKUbIR11IiovUm1Uv e4auDqzC4LJseuaYpmk4gpkkpfKoxGwqr9G7TXVoD+njVsM2nN3o6Qsg94tYPek9hdIb DfxL0zvvqO5sT2BEOFNcyjcn5Hsa6WB34wtJFydZvcXY4KMjBfj2eiBF9Fi+jS1WTBh7 S+Tg== 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=TU4UMVr0Ynz0M30ckEzLTexnFvpQNqdYCpSNEglwxE0=; b=Y1DfOCVAzE8H+1SlGeDEL/bydZhfCow9QdmUbmTWqMaxRV1Bm82a5sIbJkXEmeuvWO Jvb7/DjMk3rHHUghIXLrjfWcpIkQWgfpN3yDsm9sVQSyL9CU4iaj/3exujX6K9JJs14T 7Xi9IGTM9wgDO2jGDluIsmnpwej/uS+z5NS66jk3KgQHKXLcj/qLSM1djnNgQjnaSbtp USIE3zqYbEyr20c+mudmvg2i+hd4knAt9kwlmuQOPW1x1O8flRkfoISxLZ+Y+gf2PlV4 VWFiVN/5mU0MqhpFjIC2DDSDzumuBuk99/S2oxjoJ4sdO+dbboGf+C+CZyCcDgEcIJYN 9gjw== X-Gm-Message-State: AOAM531KXHC4tdxuoSrvl3VxiFhbN543z/V9kL7uQ5/Y+90CjlpJhOHx JDieQGqyMnwNHR1qJz+up+NH3ydRzg41pLiwLJ65FyRUu1A= X-Google-Smtp-Source: ABdhPJwn8sfvSaO6o9dMXo+wureQu0oSo3VwuyHv0vC2sYmxsb+3DRRPmMzGXqn4iFC8DIr+xv7i4KtWek+AQUdTQWs= X-Received: by 2002:a2e:81c4:: with SMTP id s4mr31638206ljg.284.1594217624597; Wed, 08 Jul 2020 07:13:44 -0700 (PDT) MIME-Version: 1.0 References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> In-Reply-To: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> From: Victor Vasiliev Date: Wed, 8 Jul 2020 10:13:33 -0400 Message-ID: To: Martin Thomson Cc: "tls@ietf.org" , HTTP Working Group Content-Type: multipart/alternative; boundary="00000000000035fcd205a9eeb739" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 14:14:07 -0000 --00000000000035fcd205a9eeb739 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 7, 2020 at 1:10 AM Martin Thomson wrote: > Hi Victor, > > For HTTP/2, this is essentially a noop, as endpoints are required to send > SETTINGS immediately. Whether these bytes appear before Finished or not > only affects endpoints that aren't inclined to wait for SETTINGS. This is > somewhat complicated by the way that TLS 1.2 and TLS 1.3 differ, but if we > assume TLS 1.3 here, any uncertainty is easily avoided. > > The main justification here appears to be based on the lack of 0.5-RTT > send capability at some servers. I don't know how to assess whether the > cost of greater integration with the TLS stack is preferable to fixing the > 0.5-RTT send problem. > It's both about solving the "lack of 0.5-RTT send capability" problem, and about making the client aware that it will in fact get the settings in 0.5-RTT without having to risk waiting for an entire RTT. I don't think you can avoid putting a "I will correctly send and receive 0.5-RTT data" signal into any location other than the TLS handshake, so this is less of a question of *should*, and more of *how*. For what it's worth, I don't think we should define a new ALPN token for that; using ALPN tokens for flags will eventually lead to combinatorial explosion (e.g. "if we define h2_half_rtt, we have to define h2c_half_rtt", etc), and can also lead to some really unpleasant situations with Alt-Svc. Also, as far as I am aware, SETTINGS are currently not carried over for HTTP/2 0-RTT in any form, meaning that it's currently impossible to, for example, send a WebSocket CONNECT request in HTTP/2 0-RTT. The proposed draft fixes that. > For HTTP/3, this has some incremental effect beyond that. In effect, this > deliberately introduces head-of-line blocking for settings. You can > already do that in HTTP/3 if you are not prepared to deal with settings > being in an ambiguous state. There's a little more determinism here in > terms of where you look for the data that unblocks progress, but with > retransmissions, this is not a difference worth worrying about. > > What this head-of-line blocking might allow is the development of new > extensions that are unable to deal with uncertainty regarding SETTINGS. > But isn't it also possible to address that problem by saying "if you > implement extension X, then you MUST NOT send requests prior to receiving > SETTINGS?" > This probably works for 1-RTT, but I am not quite sure it would work with 0-RTT as currently defined in HTTP/3. > In QUIC, we decided that having the server repeat its configuration after > 0-RTT was preferable to remembering it. This was after a non-trivial > number of questions about that part of the specification. You seem to have > taken the opposite approach. Is that deliberate? If so, why? > HTTP/3 approach to 0-RTT settings is based around the idea that things work just fine with default settings (which is true if you don't have extensions you care about), whereas ALPS aims to provide "actual settings are always there" guarantee. If you define extensions that require blocking on settings, then not remembering settings makes 0-RTT useless anyways, so this is kind of moot. That said, we could add an "upgrade to compatible settings" mechanism similar to QUIC if people believe it's useful. Also, from what I recall, the approach we chose for HTTP/3 was partially motivated by the ordering ambiguity between SETTINGS and NewSessionTicket, which the proposed draft removes. > > On Tue, Jul 7, 2020, at 05:12, Victor Vasiliev wrote: > > Hello TLS and HTTP working groups, > > > > (QUIC WG bcc'd as this has been discussed there before) > > > > Currently, we use SETTINGS frames as an extensibility mechanism in > > HTTP/2 and HTTP/3. The SETTINGS frame is sent at the very beginning of > > TLS application data; this approach, while simple, has some drawbacks. > > The most notable one is that when SETTINGS are used to negotiate > > extensions, there is an entire round-trip where the client can send > > requests, but doesn't know yet about any server extensions, thus making > > any extension-dependant requests take an extra RTT. > > > > The proposed solution to this problem is to move HTTP SETTINGS frame > > into the TLS handshake. Here are some issues where this has been > > discussed before: > > * https://github.com/quicwg/base-drafts/issues/3086 > > * https://github.com/quicwg/base-drafts/issues/3622 > > * https://github.com/WICG/client-hints-infrastructure/pull/30 > > I wrote up a draft for the TLS extension that would solve this problem: > > https://tools.ietf.org/html/draft-vvv-tls-alps-00 > > > > I also wrote up a draft that explains how to use that extension with > > HTTP, and defines some settings (the ones discussed here > > ) that would not be > > possible without it: > > https://tools.ietf.org/html/draft-vvv-httpbis-alps-00 > > > > I would appreciate feedback on those drafts. > > > > Thanks, > > Victor. > > _______________________________________________ > > 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 > --00000000000035fcd205a9eeb739 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 7, 2020 at 1:10 AM Martin Tho= mson <mt@lowentro= py.net> wrote:
Hi Victor,

For HTTP/2, this is essentially a noop, as endpoints are required to send S= ETTINGS immediately.=C2=A0 Whether these bytes appear before Finished or no= t only affects endpoints that aren't inclined to wait for SETTINGS.=C2= =A0 This is somewhat complicated by the way that TLS 1.2 and TLS 1.3 differ= , but if we assume TLS 1.3 here, any uncertainty is easily avoided.

The main justification here appears to be based on the lack of 0.5-RTT send= capability at some servers.=C2=A0 I don't know how to assess whether t= he cost of greater integration with the TLS stack is preferable to fixing t= he 0.5-RTT send problem.

It's both = about solving the "lack of 0.5-RTT send capability" problem, and = about=C2=A0making the client aware that it will in fact get the settings in= 0.5-RTT without having to risk waiting for an entire RTT.=C2=A0 I don'= t think you can avoid putting a "I will correctly send and receive 0.5= -RTT data" signal into any location other than=C2=A0the TLS handshake,= so this is less of a question of should, and more of how.

For what it's worth, I don't think we should= define a new ALPN token for that; using ALPN tokens for flags will eventua= lly lead to combinatorial explosion (e.g. "if we define h2_half_rtt, w= e have to define h2c_half_rtt", etc), and can also lead to some really= unpleasant situations=C2=A0with Alt-Svc.

Also, as far as I am aware, SETTINGS are currently not carried over for = HTTP/2 0-RTT in any form, meaning that it's currently impossible to, fo= r example, send a WebSocket CONNECT request in HTTP/2 0-RTT.=C2=A0 The prop= osed draft fixes that.
=C2=A0
For HTTP/3, this has some incremental effect beyond that.=C2=A0 In effect, = this deliberately introduces head-of-line blocking for settings.=C2=A0 You = can already do that in HTTP/3 if you are not prepared to deal with settings= being in an ambiguous state.=C2=A0 There's a little more determinism h= ere in terms of where you look for the data that unblocks progress, but wit= h retransmissions, this is not a difference worth worrying about.

What this head-of-line blocking might allow is the development of new exten= sions that are unable to deal with uncertainty regarding SETTINGS.=C2=A0 Bu= t isn't it also possible to address that problem by saying "if you= implement extension X, then you MUST NOT send requests prior to receiving = SETTINGS?"

This probably works for= 1-RTT, but I am not quite sure it would work with 0-RTT as currently defin= ed in HTTP/3.
=C2=A0
In QUIC, we decided that having the server repeat its configuration after 0= -RTT was preferable to remembering it.=C2=A0 This was after a non-trivial n= umber of questions about that part of the specification.=C2=A0 You seem to = have taken the opposite approach.=C2=A0 Is that deliberate?=C2=A0 If so, wh= y?

HTTP/3 approach to 0-RTT settings is= based around the idea that things work just fine with default settings (wh= ich is true if you don't have extensions you care about), whereas ALPS = aims to provide "actual settings are always there" guarantee.=C2= =A0 If you define extensions that require blocking on settings, then not re= membering settings makes 0-RTT useless anyways, so this is kind of moot.=C2= =A0 That said, we could add an "upgrade to compatible settings" m= echanism similar to QUIC=C2=A0if people believe it's useful.
=
Also, from what I recall, the approach we chose for HTTP/3= =C2=A0was partially motivated by the=C2=A0ordering ambiguity between SETTIN= GS and NewSessionTicket, which the proposed draft removes.
=C2=A0=

On Tue, Jul 7, 2020, at 05:12, Victor Vasiliev wrote:
> Hello TLS and HTTP working groups,
>
> (QUIC WG bcc'd as this has been discussed there before)
>
> Currently, we use SETTINGS frames as an extensibility mechanism in > HTTP/2 and HTTP/3. The SETTINGS frame is sent at the very beginning of=
> TLS application data; this approach, while simple, has some drawbacks.=
> The most notable one is that when SETTINGS are used to negotiate
> extensions, there is an entire round-trip where the client can send > requests, but doesn't know yet about any server extensions, thus m= aking
> any extension-dependant requests take an extra RTT.
>
> The proposed solution to this problem is to move HTTP SETTINGS frame <= br> > into the TLS handshake. Here are some issues where this has been
> discussed before:
>=C2=A0 * https://github.com/quicwg/base-drafts/= issues/3086
>=C2=A0 * https://github.com/quicwg/base-drafts/= issues/3622
>=C2=A0 * https://github.com/WICG/clie= nt-hints-infrastructure/pull/30
> I wrote up a draft for the TLS extension that would solve this problem= :
> https://tools.ietf.org/html/draft-vvv-tls-alps= -00
>
> I also wrote up a draft that explains how to use that extension with <= br> > HTTP, and defines some settings (the ones discussed here
> <https://github.com/quicwg/base-drafts/iss= ues/3622>) that would not be
> possible without it:
> https://tools.ietf.org/html/draft-vvv-htt= pbis-alps-00
>
> I would appreciate feedback on those drafts.
>
> Thanks,
>=C2=A0 Victor.
> _______________________________________________
> 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
--00000000000035fcd205a9eeb739-- From nobody Wed Jul 8 07:45: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 ADEA13A0D0F; Wed, 8 Jul 2020 07:45:27 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 VT1qWoNOrKWz; Wed, 8 Jul 2020 07:45:25 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4AC3A0CC3; Wed, 8 Jul 2020 07:45:22 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 8 Jul 2020 07:45:15 -0700 From: Jim Schaad To: 'Mohit Sethi M' , CC: References: <045601d64fea$e0d7f800$a287e800$@augustcellars.com> <006401d653af$7b029f80$7107de80$@augustcellars.com> <4f52e8f0-eb0b-d6c6-e8bd-3f6fc0b3541e@ericsson.com> In-Reply-To: <4f52e8f0-eb0b-d6c6-e8bd-3f6fc0b3541e@ericsson.com> Date: Wed, 8 Jul 2020 07:45:13 -0700 Message-ID: <010201d65536$6554f5b0$2ffee110$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0103_01D654FB.B8F84090" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJKcycXoPg67pLJAT3vSEDhcRD9xgI5SobMAloYa9wBpZZNm6fjvKJA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00 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 Jul 2020 14:45:34 -0000 ------=_NextPart_000_0103_01D654FB.B8F84090 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Mohit Sethi M =20 Sent: Wednesday, July 8, 2020 1:03 AM To: Jim Schaad ; Mohit Sethi M = ; = draft-ietf-tls-external-psk-guidance@ietf.org Cc: tls@ietf.org Subject: Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00 =20 Hi Jim, On 7/6/20 7:06 PM, Jim Schaad wrote: =20 =20 -----Original Message----- From: Mohit Sethi M = Sent: Monday, July 6, 2020 3:10 AM To: Jim Schaad = ; draft-ietf-tls-external-psk- guidance@ietf.org =20 Cc: tls@ietf.org =20 Subject: Re: Review of draft-ietf-tls-external-psk-guidance-00 =20 Hi Jim, =20 Thanks for the review. A clarifying question in-line. =20 On 7/2/20 12:02 AM, Jim Schaad wrote: * In section 4 there is a statement that switching the roles of servers which use PSKs will lead to weakening of security properties. As this is a common scenario today in situations where you are doing server-to-server communication, it would be useful to discuss just how and how much this weakening occurs. This was a complete surprise to me and I don't know if it was supposed to be one. Are there mitigations = that can be made? =20 * In section 7, The first sentence does not read, also It seems a bit difficult to have a MUST in there when most of the items below are = SHOULDs. That seems to be a dissonance. =20 * Section 7.1.1 - The idea of having domain name suffixes on PSKs seems to me to be a bad idea as this would seem to lower privacy levels. =20 I think you are referring to the PSK identity and not to the PSK. =20 As you know, the Network Access Identifiers (NAIs) used in EAP typically = need the domain name suffix for roaming, federation, etc. =20 This is true, it is also true that EAP is very strong on saying that if = you have a choice, always send an anonymous version of the NAI if you = have to do it in the clear. This means that the domain can be used for = correlation, but you do not have the full identity for that purpose. =20 I think that the EMU group is going to need to look at what level of = privacy protection it is going to desire when using a PSK, but in that = case there is no need for having a domain suffix as that information is = provided elsewhere. This might require keeping the TLS tunneling as an = option to deal with passive attacks. You are absolutely right about the preference for using anonymous = identities. draft-ietf-emu-eap-tls13 currently says the following about = resumption:=20 It is RECOMMENDED to use a NAIs with the same realm in the resumption and the original full authentication. This requirement allows EAP packets to be routable to the same destination as the original full authentication. If this recommendation is not followed, resumption is likely to be impossible. When NAI reuse can be done without privacy implications, it is RECOMMENDED to use the same anonymous NAI in the resumption, as was used in the original full authentication. E.g. the NAI @realm can safely be reused, while the NAI ZmxleG8=3D@realm cannot.=20 This document and the ensuing discussion pertains only to external PSKs = and external PSK identities. I think I incorrectly used the word "issue" = in my previous email as a more correct choice would have been = "agree/establish" (i.e. the server and client agree on an external PSK = and an external PSK identity). RFC 8446 doesn't place any restrictions = on external PSK identities (other than the fact that they are at least 1 = byte). If we are going to discourage the use of domain names in external = PSK identities, would that be sufficient? What prevents me from using an = external PSK identity of the type: = my_strong_secret_psk_with_amazon_server?=20 I am not sure if we should recommend randomized external PSK identities = of a certain minimum length. Perhaps it might be better to add a = disclaimer about the privacy loss from carelessly chosen external PSK = identities?=20 [JLS] There are going to be three different cases for external PSK = identities: The identity if factory provisioned and carried in a file to = the server, the identity is factory provisioned and read by the user = from the device, and it is hand chosen. The first two cases can = definitely be randomized. I don=E2=80=99t know that having a minimum = length makes any difference. This is not exactly a cryptographic = property. Another thing that might be done would be analogous to the = PSK importer document and apply a one way hash from the typed in value = to the value that is sent over the wire so on the wire it is just a = random set of bytes. Jim =20 --Mohit =20 =20 =20 =20 I would like to understand the nature of the resulting privacy loss. Is = it that a passive attacker can now easily determine the server which issued the = PSK identity (and the server where it will eventually be used)? =20 While it I true that at least some of the privacy information has = already been leaked in the PSK case, you know the address that is being = talked to and the PSK identity that is passed. If you look at using = thigs like ESNI, doing this would appear to potentially give away the = very information that is being hidden in that case. =20 =20 The other problem with having domain based KIDs is that you could easily = get some amount of correlation between the KIDs that are assigned in = different domains. You could end up with mohit.ietf and mohit.amazon = and it would be quite reasonable to assume that both of those identities = are going to be for the same entity, just in different domains. =20 Jim =20 =20 =20 --Mohit =20 =20 * Section 7.1.2 - There seem to me to be three different places where collisions will occur. The importer function could get a collision, there could be collisions with pre-TLS 1.2 external identifiers and there could be collision with resumption keys. There has been a huge discussion about this in the EMU group and I don't find the text here to be sensible in term of whether this is or is not a problem. =20 * Section 7.1.2 - One of the things that I kept meaning to get to and just haven't done so yet, is dealing with the question of can the TLS Key binders in the handshake to distinguish between multiple keys that happen to have the same identity. Perhaps you should look to see if this does work and if it is safe. =20 Jim =20 =20 =20 _______________________________________________ TLS mailing list TLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_0103_01D654FB.B8F84090 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From: Mohit = Sethi M <mohit.m.sethi@ericsson.com>
Sent: Wednesday, = July 8, 2020 1:03 AM
To: Jim Schaad = <ietf@augustcellars.com>; Mohit Sethi M = <mohit.m.sethi@ericsson.com>; = draft-ietf-tls-external-psk-guidance@ietf.org
Cc: = tls@ietf.org
Subject: Re: [TLS] Review of = draft-ietf-tls-external-psk-guidance-00

 

Hi Jim,

On 7/6/20 7:06 PM, Jim Schaad = wrote:

 
 
-----Original =
Message-----
From: Mohit Sethi M <mohit.m.sethi@ericsson.com=
>
Sent: Monday, July 6, 2020 3:10 =
AM
To: Jim Schaad <ietf@augustcellars.com>=
; draft-ietf-tls-external-psk-
guidance@ietf.org
<=
pre>Cc: tls@ietf.org
Subjec=
t: Re: Review of =
draft-ietf-tls-external-psk-guidance-00
 <=
/o:p>
Hi =
Jim,
 
Thanks for the =
review. A clarifying question =
in-line.
 
On 7/2/20 =
12:02 AM, Jim Schaad wrote:
* In section 4 there =
is a statement that switching the roles of
servers =
which use PSKs will lead to weakening of security =
properties.
As this is a common scenario today in =
situations where you are doing
server-to-server =
communication, it would be useful to discuss just =
how
and how much this weakening occurs.=C2=A0 This =
was a complete surprise to
me and I don't know if =
it was supposed to be one.=C2=A0 Are there mitigations =
that
can be =
made?
 
* In section 7, The first sentence does not read, also It seems a =
bit
difficult to have a MUST in there when most of =
the items below are SHOULDs.
That seems to be a =
dissonance.
 
* Section =
7.1.1 - The idea of having domain name suffixes on =
PSKs
seems to me to be a bad idea as this would =
seem to lower privacy =
levels.
 
I =
think you are referring to the PSK identity and not to the =
PSK.
 
As you know, the =
Network Access Identifiers (NAIs) used in EAP typically =
need
the domain name suffix for roaming, =
federation, =
etc.
 
This =
is true, it is also true that EAP is very strong on saying that if you =
have a choice, always send an anonymous version of the NAI if you have =
to do it in the clear.=C2=A0 This means that the domain can be used for =
correlation, but you do not have the full identity for that =
purpose.
 
I think that =
the EMU group is going to need to look at what level of privacy =
protection it is going to desire when using a PSK, but in that case =
there is no need for having=C2=A0 a domain suffix as that information is =
provided elsewhere.=C2=A0=C2=A0 This might require keeping the TLS =
tunneling as an option to deal with passive =
attacks.

You are absolutely right about = the preference for using anonymous identities. draft-ietf-emu-eap-tls13 = currently says the following about resumption: = 

=C2=A0=C2=A0=C2=A0It =
is RECOMMENDED to use a NAIs with the same realm in the =
resumption
=C2=A0=C2=A0 and the original full =
authentication.=C2=A0 This requirement allows =
EAP
=C2=A0=C2=A0 packets to be routable to the same =
destination as the original full
=C2=A0=C2=A0 =
authentication.=C2=A0 If this recommendation is not followed, =
resumption
=C2=A0=C2=A0 is likely to be =
impossible.=C2=A0 When NAI reuse can be done =
without
=C2=A0=C2=A0 privacy implications, it is =
RECOMMENDED to use the same anonymous =
NAI
=C2=A0=C2=A0 in the resumption, as was used in =
the original full authentication.
=C2=A0=C2=A0 E.g. =
the NAI @realm can safely be reused, while the =
NAI
=C2=A0=C2=A0 ZmxleG8=3D@realm cannot. =

This document and the = ensuing discussion pertains only to external PSKs and external PSK = identities. I think I incorrectly used the word "issue" in my = previous email as a more correct choice would have been = "agree/establish" (i.e. the server and client agree on an = external PSK and an external PSK identity). RFC 8446 doesn't place any = restrictions on external PSK identities (other than the fact that they = are at least 1 byte). If we are going to discourage the use of domain = names in external PSK identities, would that be sufficient? What = prevents me from using an external PSK identity of the type: = my_strong_secret_psk_with_amazon_server?

I am not sure = if we should recommend randomized external PSK identities of a certain = minimum length. Perhaps it might be better to add a disclaimer about the = privacy loss from carelessly chosen external PSK identities? =

[JLS] There are going to be three different cases for = external PSK identities: The identity if factory provisioned and carried = in a file to the server,=C2=A0 the identity is factory provisioned and = read by the user from the device, and it is hand chosen.=C2=A0 The first = two cases can definitely be randomized.=C2=A0 I don=E2=80=99t know that = having a minimum length makes any difference.=C2=A0 This is not exactly = a cryptographic property.=C2=A0 Another thing that might be done would = be analogous to the PSK importer document and apply a one way hash from = the typed in value to the value that is sent over the wire so on the = wire it is just a random set of = bytes.

Jim

 

--Mo= hit

 
 
 
 
I would like to understand the nature of the resulting privacy =
loss. Is it that a
passive attacker can now easily =
determine the server which issued the PSK
identity =
(and the server where it will eventually be =
used)?
 
Whil=
e it I true that at least some of the privacy information has already =
been leaked in the PSK case, you know the address that is being talked =
to and the PSK identity that is passed.=C2=A0 If you look at using thigs =
like ESNI, doing this would appear to potentially give away the very =
information that is being hidden in that case.=C2=A0 =

 
The other problem with =
having domain based KIDs is that you could easily get some amount of =
correlation between the KIDs that are assigned in different =
domains.=C2=A0 You could end up with mohit.ietf and mohit.amazon and it =
would be quite reasonable to assume that both of those identities are =
going to be for the same entity, just in different =
domains.
 
Jim<=
/pre>
 
 
 
--Mohit
 
 
* Section 7.1.2 - There seem to me to be three different places =
where
collisions will occur.=C2=A0 The importer =
function could get a collision,
there could be =
collisions with pre-TLS 1.2 external identifiers =
and
there could be collision with resumption =
keys.=C2=A0 There has been a huge
discussion about =
this in the EMU group and I don't find the text =
here
to be sensible in term of whether this is or =
is not a problem.
 
* =
Section 7.1.2 - One of the things that I kept meaning to get to =
and
just haven't done so yet, is dealing with the =
question of can the TLS
Key binders in the =
handshake to distinguish between multiple keys =
that
happen to have the same identity.=C2=A0 =
Perhaps you should look to see if
this does work =
and if it is =
safe.
 
Jim
 
 
 
_____________________________=
__________________
TLS mailing =
list
TLS@ietf.org
https://www.ietf.org/m=
ailman/listinfo/tls
<= /html> ------=_NextPart_000_0103_01D654FB.B8F84090-- From nobody Wed Jul 8 08:08: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 DDE7F3A0D75 for ; Wed, 8 Jul 2020 08:08:09 -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, RCVD_IN_MSPIKE_H2=-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=cryptonector.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 vRwq26byTuAz for ; Wed, 8 Jul 2020 08:08:08 -0700 (PDT) Received: from cat.oak.relay.mailchannels.net (cat.oak.relay.mailchannels.net [23.83.215.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 A97963A0D77 for ; Wed, 8 Jul 2020 08:08:05 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 8F8A4540365; Wed, 8 Jul 2020 15:08:03 +0000 (UTC) Received: from pdx1-sub0-mail-a38.g.dreamhost.com (100-96-9-37.trex.outbound.svc.cluster.local [100.96.9.37]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 75C66541392; Wed, 8 Jul 2020 15:08:02 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a38.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Wed, 08 Jul 2020 15:08:03 +0000 X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Arch-Callous: 69237eb240f5ae49_1594220883339_4260049303 X-MC-Loop-Signature: 1594220883339:202351607 X-MC-Ingress-Time: 1594220883339 Received: from pdx1-sub0-mail-a38.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a38.g.dreamhost.com (Postfix) with ESMTP id 917F6B4157; Wed, 8 Jul 2020 08:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=4Lw5B368TSQmPb FpeLnBYoRPXgU=; b=EaRcawUyrVYNBzx1ZJoQZeKl1wD1P4eWIEyhwKmmReuFBN F75jt92YqJ9zNZKXjPeeOmj0rPmydJvETKaF5fR2T3t651H6X+D3b/NaCmChRGr6 T0gxtO0bRvw9WZdEiAlOt/VRVwysrLcTAeEOQVcnYX4D//Ybf6wmhy6VYq+YA= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a38.g.dreamhost.com (Postfix) with ESMTPSA id BF88BB4156; Wed, 8 Jul 2020 08:07:58 -0700 (PDT) Date: Wed, 8 Jul 2020 10:07:53 -0500 X-DH-BACKEND: pdx1-sub0-mail-a38 From: Nico Williams To: Benjamin Kaduk Cc: tls@ietf.org Message-ID: <20200708150752.GL3100@localhost> References: <20200708042223.GB20623@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200708042223.GB20623@akamai.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduiedrudejgdekhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm Archived-At: Subject: Re: [TLS] invariant or not: one TLS connection per TCP connection? 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 Jul 2020 15:08:10 -0000 On Tue, Jul 07, 2020 at 09:22:24PM -0700, Benjamin Kaduk wrote: > There's an interesting note in draft-ietf-nfsv4-rpc-tls-08 (currently > in IESG Evaluation): > > The protocol convention specified in the current document assumes > there can be no more than one concurrent TLS session per TCP > connection. This is true of current generations of TLS, but might be > different in a future version of TLS. > > Can we envision wanting to do such a thing (e.g., with connection IDs for > non-D TLS)? If not, I can give them guidance that this type of statement > is not needed. I can see an application that starts TLS in a TCP connection, ends TLS without also ending the TCP connection, then starts TLS again. But multiple concurrent TLS connections in one TCP connection? I don't see that happening. Maybe with DTLS, but they are using TLS. I would just remove the above paragraph. Nico -- From nobody Wed Jul 8 17:16: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 F0E823A0A14 for ; Wed, 8 Jul 2020 17:16:45 -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=Q39Km79d; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gEeAKRji 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 bAXRlnMCbh9k for ; Wed, 8 Jul 2020 17:16:44 -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 7985A3A0A0E for ; Wed, 8 Jul 2020 17:16:44 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 7A3295C0100; Wed, 8 Jul 2020 20:16:43 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 08 Jul 2020 20:16:43 -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=6sAvQFelyyPu3jRZ+Vnk9CZxdZ8q F6iY44RSIahhgQY=; b=Q39Km79deEbMBKrbnepywp2d73unE5mfcOf8BUppr+0/ heR9gCRa3SEVcTVTQ08+/ffiaRHpb65gf9qkHANsevNfPp1+Y7yu6ITNXVuPwx8+ pr9T95vZFfxn9ureWom296lfZAB7QNEwV4bjpG9UfBTHtqEln+8NC98OkBDp0OMI MOjfhySUX7AcVD72ENpcQklr8kXCQD87OXVcE3sO5j1BjNS3OxaU3LT2yprJ4ZPx 1VbnEjSMaRT/v/ko50vFQTooxFPft1Er7Ae/2jh5gWHUMZ6hzp2Gdo1QQlYRuOBc aWNck+X278jpch9muw4eWf0ye2IAGaBdzP4wd62bTw== 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=fm3; bh=6sAvQF elyyPu3jRZ+Vnk9CZxdZ8qF6iY44RSIahhgQY=; b=gEeAKRji9B8lh2WmWYkZbj Im80jGae6QMzHpcqL6SBwAaxqm0T8Qa70XccN2AzSezkYBWz6wwDTP0ue184OZ/2 arRcNriq3LGyRvTaQepFqhmekqM4dxIcGBPRpRA8t370vnNOc+sw2axurMC8xDKx ke/k6tGx9oWMOZ1wZ5EywpmPYvHYEBc0UgxfSi3itJ2HAG8rdcqY/H9gSskqJeG5 a64b7KpMAeVuCKPd86GTSNKKJOo7KeyxSkLxSHFCXCfEOMFFEIIdv9gJzalMKu7o oKARCSSWBm8jlQoIwOyzCq/fVfpY/qJsj5GxTAlG4Bb8nvTMGy8fVlTFK486mrVA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudekgdefgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtf frrghtthgvrhhnpeekteeuieektdekleefkeevhfekffevvdevgfekgfeluefgvdejjeeg ffeigedtjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0278EE00B3; Wed, 8 Jul 2020 20:16:43 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-601-g4bf46fa-fm-20200708.001-g4bf46fa8 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> Date: Thu, 09 Jul 2020 10:16:24 +1000 From: "Martin Thomson" To: "Victor Vasiliev" Cc: "tls@ietf.org" , "HTTP Working Group" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 00:16:47 -0000 On Thu, Jul 9, 2020, at 00:13, Victor Vasiliev wrote: > For what it's worth, I don't think we should define a new ALPN token > for that; using ALPN tokens for flags will eventually lead to > combinatorial explosion (e.g. "if we define h2_half_rtt, we have to > define h2c_half_rtt", etc), and can also lead to some really unpleasant > situations with Alt-Svc. I'm not so firm on that. h2 was defined before 0-RTT, so there is no provision for carrying settings over into 0-RTT anyway, which is what would be required for thewebsocketprotocol CONNECT to work. You propose defining extensions to TLS to address this shortcoming in addition to the synchronization issue, but what that really is is a new version of h2 - one where SETTINGS does not appear in application data (mostly, I assume that updates are OK). This was discussed during the design of HTTP/2. But 0-RTT was too new to decide anything at that point and the view was that anything could be negotiated in one of two ways: SETTINGS (which takes time) or a new protocol version. It might seem a little early to be even contemplating a new version, but that wasn't the thinking at the time. h2c is dead, so we don't need to worry about that. From nobody Thu Jul 9 03:08: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 F253F3A07E0 for ; Thu, 9 Jul 2020 03:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, 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 CCBroRns1jCe for ; Thu, 9 Jul 2020 03:08:41 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60057.outbound.protection.outlook.com [40.107.6.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 BD83D3A07D0 for ; Thu, 9 Jul 2020 03:08:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D4AP17QSjso4gxhGPMwcUaKhMkijCEksWS7kX+++sDO0SXCedaiC5/e1A1KH9S0nx7xl8bAVOdGll05+vrbNJ6PT59kOLC1SKaEvlKUz9TOo3i/4BMXvdr16j5HPs+g5oF1nXDA+4evVOIOA2Zt4b49PYaXvLDQfkDxM7/WEbpJ+bAE7LFFCvlauTmonIjNJewKZhZgUkZJvnhshpXMu6Xf57FzebzEQmW5mPJSJ/xEIWDRvm5xmA528LQ2cnGZN8oz02A9qLdv5WECcUbzq5HhgXYSU5HsdBqTh0sricnxZLzJaInRDg1gTRZTvIxq8Yh+a+yOppkXIw3/IpzDLLw== 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=QNWjDtk+Q/qE+pCHcvXujE0MrnCKch5dXdOU3F8VEyU=; b=i89pzNG6GOYWkA9Ae9t6DNJUucAOWyGTYaIzydr9AdUBfe8xgHlI/POzlZvXMLJ4rqNWJ04wARVEQFMZASW/5f2lSpEm75EcjxQusf2VSaUB8RhdsHQ4Z7eoEXgpWDz7Zxj+MNRUObdpKnAjk9BBzBPs8RBcIWD6LHMOQugJWniNSqyChSlY/EgQVM55Q0TMJ52hbhOWzwYQ5GsRkD19vcEPzJcuP/OA1awV13kILEIWEkUJTRGT1rFBbbxmMmZR2dNWup1K131dEh3L5HxgYElJAvMATq+iQLf2L1sPBu+CKWbT85m22hXdMmKR11s3WwEn/FtWf/EO4zj1jqLUag== 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=QNWjDtk+Q/qE+pCHcvXujE0MrnCKch5dXdOU3F8VEyU=; b=knOSS5Bqb573J5/bVrFe7FEBWtrIqbZKRz2x0fZmkv3kFIZgSfGnWyhHoS31zK2gD67biSi6aVQi8M34uCJmITi74uMVYnxJiufa3tLR1y77RDfhqA7k3IPtONOAqDWbGx0k+rhbvQ7dq8kIcAeZSYB8lH5NOmQgpbttcgXQw/c= Received: from HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) by HE1PR0701MB2444.eurprd07.prod.outlook.com (2603:10a6:3:74::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.9; Thu, 9 Jul 2020 10:08:37 +0000 Received: from HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::d6e:6298:19a7:7c99]) by HE1PR07MB3386.eurprd07.prod.outlook.com ([fe80::d6e:6298:19a7:7c99%5]) with mapi id 15.20.3174.022; Thu, 9 Jul 2020 10:08:37 +0000 From: Mohit Sethi M To: Jim Schaad CC: "tls@ietf.org" Thread-Topic: [TLS] Review of draft-ietf-tls-external-psk-guidance-00 Thread-Index: AQHWU32mq0e1idfoLE2Dgf3tNNTFWaj6t/aAgAKdj4CAAHBFgIABRQkA Date: Thu, 9 Jul 2020 10:08:36 +0000 Message-ID: References: <045601d64fea$e0d7f800$a287e800$@augustcellars.com> <006401d653af$7b029f80$7107de80$@augustcellars.com> <4f52e8f0-eb0b-d6c6-e8bd-3f6fc0b3541e@ericsson.com> <010201d65536$6554f5b0$2ffee110$@augustcellars.com> In-Reply-To: <010201d65536$6554f5b0$2ffee110$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [2001:14bb:180:32e0:4410:998:b5bb:a856] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b7c5b294-e6a4-4e60-e575-08d823f00bd8 x-ms-traffictypediagnostic: HE1PR0701MB2444: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oKwUUkIOIMKioOTEyLTzosixOWpuyJ6yKkt/uMBAx197XIR/yXrd69DPksrqceYaP3j6eIh2cCHE3WOaZdXqG9QbQqzog93zOzELyH48ZVUXsi1wHN4+ePM8Ire61Q5p3ORUblzXfLlb4XRttZR+nqQBWeQTnm6NKCpaOfQXZ7ys1FkIWT9VRA0+n0b/mMUPseNptuCNGxLSoBzHRU+USQ+jNHnD+euVWT1QJbrzZ/nCgcx/hhGd8jLOrE9zwalHBYDMS1p0E04TSA1OigUOgn4NA4AYHuvxFBvNxX9SLRdNt9esXHLoCX/8td5/o6DmMTM9cO4/dtlrB4DieVsjSGxW/cXirfYtBfblnxMMzh3Yvwwmxt/0DTy7E3CnNPM60ruFRYNYHwxrgaZZV9P+XxHuecCgtQUbD+D7oudeN6/DwWwEzKZlkMtLEiT2oyD/k2ASP10mAgrm/bqTeQ83yg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR07MB3386.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(39860400002)(376002)(366004)(396003)(53546011)(2906002)(186003)(8936002)(6916009)(6506007)(6486002)(36756003)(316002)(71200400001)(166002)(86362001)(4326008)(8676002)(2616005)(478600001)(966005)(64756008)(66556008)(6512007)(76116006)(66476007)(66446008)(66946007)(5660300002)(31686004)(31696002)(83380400001)(43740500002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: UaayDKdDCzaVc3pelKw2j2u5/s26lqMw8V1Q6hoL5szEJrp7LCNWzjo8EoATYble13GwkUdSjQc2nDbNwT9JFXIB6PyKJlEkAOKlsPY44JQIDseXL/YvnP/VnmX/4K3zsmOu5sCx1Rr205n9b58xk0n0erb6XEJ5IYdEIqMCR8KENordRoiAV+1usTvf1nJJbjdYagrVkZdLFPFU1ViZ4E9HG6+RQ4ntPuugj49Qq9MSKMlM0hzzPtpzchUZkh1LAOEfMHqk7Cxy6tBscuR2w5Rq4/oDYaLAIHStd4mYZrSEOtu6XCP7yxUhQt2CI9ereyXfMqaSBoS/bm8oTVPHdeaeBByBTQEWgpAzluaio1UQzWPXgTsaG/0SbN6BqE19Zw9q3+nP3QGUKODqAAT6BSSPryNQ2CHv/3+xWNrjbfNJFOUx+iO/ZVcEXUnCXLZ/562t9h4BUPcLr8nBn8u3fSv/Fcnu82i7NTGs0Sa4ErYKSLPRpEF2a3ET7hwY0DEgL+wWqN4ZJ33Bie/J00gglaG1p6GU4yjqNNWILtU9Yw0= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_c3d2ff8c762a399b40c259ddbfe387aeericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR07MB3386.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b7c5b294-e6a4-4e60-e575-08d823f00bd8 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2020 10:08:36.5925 (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: z+qL/IDB9muzh2ErnLluvgo/Usn5oxY0Gu3hUGtoVjQlxdK1PkC7rBlLJv4pLp7gj4I/WXKeqWGLfIMYv9tta/03SK+ROtodZQuedch/8dQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2444 Archived-At: Subject: Re: [TLS] Review of draft-ietf-tls-external-psk-guidance-00 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 Jul 2020 10:08:43 -0000 --_000_c3d2ff8c762a399b40c259ddbfe387aeericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG9wIHBvc3Rpbmcgc28gdGhhdCBvdGhlcnMgb24gdGhlIGxpc3QgY2FuIGNoaW1lIGluLg0KDQpX aGlsZSBkaXNjdXNzaW5nIHRoZSBwcml2YWN5IGltcGxpY2F0aW9ucyBvZiBleHRlcm5hbCBQU0sg aWRlbnRpdGllcywgSmltIFNjaGFhZCBpbiBoaXMgZW1haWwgYmVsb3cgcmVjb21tZW5kcyB0aGF0 IHdlIGNvdWxkIGRlc2NyaWJlIHRlY2huaXF1ZXMgZm9yIGltcG9ydGluZyBleHRlcm5hbCBQU0sg aWRlbnRpdGllcyAodGhhdCBtYXkgYmUgdHlwZWQgaW4gYnkgdGhlIHVzZXIpLiBIZSBzdWdnZXN0 cyB0aGF0IHdlIGNvdWxkIGNvbnNpZGVyIHVzaW5nIGEgY29uc3RydWN0IGJhc2VkIG9uIG9uZSB3 YXkgaGFzaCBmdW5jdGlvbnMgc28gdGhhdCB0aGUgdHlwZWQtaW4gZXh0ZXJuYWwgUFNLIGlkZW50 aXR5IChwcmVzdW1hYmx5IHdpdGggbm90IHNvIGdvb2QgcHJpdmFjeSBwcm9wZXJ0aWVzKSBhcmUg bmV2ZXIgc2VudCBvbiB0aGUgd2lyZS4NCg0KLS1Nb2hpdA0KDQpPbiA3LzgvMjAgNTo0NSBQTSwg SmltIFNjaGFhZCB3cm90ZToNCg0KDQpGcm9tOiBNb2hpdCBTZXRoaSBNIDxtb2hpdC5tLnNldGhp QGVyaWNzc29uLmNvbT48bWFpbHRvOm1vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tPg0KU2VudDog V2VkbmVzZGF5LCBKdWx5IDgsIDIwMjAgMTowMyBBTQ0KVG86IEppbSBTY2hhYWQgPGlldGZAYXVn dXN0Y2VsbGFycy5jb20+PG1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tPjsgTW9oaXQgU2V0 aGkgTSA8bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20+PG1haWx0bzptb2hpdC5tLnNldGhpQGVy aWNzc29uLmNvbT47IGRyYWZ0LWlldGYtdGxzLWV4dGVybmFsLXBzay1ndWlkYW5jZUBpZXRmLm9y ZzxtYWlsdG86ZHJhZnQtaWV0Zi10bHMtZXh0ZXJuYWwtcHNrLWd1aWRhbmNlQGlldGYub3JnPg0K Q2M6IHRsc0BpZXRmLm9yZzxtYWlsdG86dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNd IFJldmlldyBvZiBkcmFmdC1pZXRmLXRscy1leHRlcm5hbC1wc2stZ3VpZGFuY2UtMDANCg0KDQpI aSBKaW0sDQpPbiA3LzYvMjAgNzowNiBQTSwgSmltIFNjaGFhZCB3cm90ZToNCg0KDQoNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBNb2hpdCBTZXRoaSBNIDxtb2hpdC5t LnNldGhpQGVyaWNzc29uLmNvbT48bWFpbHRvOm1vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tPg0K DQpTZW50OiBNb25kYXksIEp1bHkgNiwgMjAyMCAzOjEwIEFNDQoNClRvOiBKaW0gU2NoYWFkIDxp ZXRmQGF1Z3VzdGNlbGxhcnMuY29tPjxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47IGRy YWZ0LWlldGYtdGxzLWV4dGVybmFsLXBzay0NCg0KZ3VpZGFuY2VAaWV0Zi5vcmc8bWFpbHRvOmd1 aWRhbmNlQGlldGYub3JnPg0KDQpDYzogdGxzQGlldGYub3JnPG1haWx0bzp0bHNAaWV0Zi5vcmc+ DQoNClN1YmplY3Q6IFJlOiBSZXZpZXcgb2YgZHJhZnQtaWV0Zi10bHMtZXh0ZXJuYWwtcHNrLWd1 aWRhbmNlLTAwDQoNCg0KDQpIaSBKaW0sDQoNCg0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuIEEg Y2xhcmlmeWluZyBxdWVzdGlvbiBpbi1saW5lLg0KDQoNCg0KT24gNy8yLzIwIDEyOjAyIEFNLCBK aW0gU2NoYWFkIHdyb3RlOg0KDQoqIEluIHNlY3Rpb24gNCB0aGVyZSBpcyBhIHN0YXRlbWVudCB0 aGF0IHN3aXRjaGluZyB0aGUgcm9sZXMgb2YNCg0Kc2VydmVycyB3aGljaCB1c2UgUFNLcyB3aWxs IGxlYWQgdG8gd2Vha2VuaW5nIG9mIHNlY3VyaXR5IHByb3BlcnRpZXMuDQoNCkFzIHRoaXMgaXMg YSBjb21tb24gc2NlbmFyaW8gdG9kYXkgaW4gc2l0dWF0aW9ucyB3aGVyZSB5b3UgYXJlIGRvaW5n DQoNCnNlcnZlci10by1zZXJ2ZXIgY29tbXVuaWNhdGlvbiwgaXQgd291bGQgYmUgdXNlZnVsIHRv IGRpc2N1c3MganVzdCBob3cNCg0KYW5kIGhvdyBtdWNoIHRoaXMgd2Vha2VuaW5nIG9jY3Vycy4g IFRoaXMgd2FzIGEgY29tcGxldGUgc3VycHJpc2UgdG8NCg0KbWUgYW5kIEkgZG9uJ3Qga25vdyBp ZiBpdCB3YXMgc3VwcG9zZWQgdG8gYmUgb25lLiAgQXJlIHRoZXJlIG1pdGlnYXRpb25zIHRoYXQN Cg0KY2FuIGJlIG1hZGU/DQoNCg0KDQoqIEluIHNlY3Rpb24gNywgVGhlIGZpcnN0IHNlbnRlbmNl IGRvZXMgbm90IHJlYWQsIGFsc28gSXQgc2VlbXMgYSBiaXQNCg0KZGlmZmljdWx0IHRvIGhhdmUg YSBNVVNUIGluIHRoZXJlIHdoZW4gbW9zdCBvZiB0aGUgaXRlbXMgYmVsb3cgYXJlIFNIT1VMRHMu DQoNClRoYXQgc2VlbXMgdG8gYmUgYSBkaXNzb25hbmNlLg0KDQoNCg0KKiBTZWN0aW9uIDcuMS4x IC0gVGhlIGlkZWEgb2YgaGF2aW5nIGRvbWFpbiBuYW1lIHN1ZmZpeGVzIG9uIFBTS3MNCg0Kc2Vl bXMgdG8gbWUgdG8gYmUgYSBiYWQgaWRlYSBhcyB0aGlzIHdvdWxkIHNlZW0gdG8gbG93ZXIgcHJp dmFjeSBsZXZlbHMuDQoNCg0KDQpJIHRoaW5rIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBQU0sg aWRlbnRpdHkgYW5kIG5vdCB0byB0aGUgUFNLLg0KDQoNCg0KQXMgeW91IGtub3csIHRoZSBOZXR3 b3JrIEFjY2VzcyBJZGVudGlmaWVycyAoTkFJcykgdXNlZCBpbiBFQVAgdHlwaWNhbGx5IG5lZWQN Cg0KdGhlIGRvbWFpbiBuYW1lIHN1ZmZpeCBmb3Igcm9hbWluZywgZmVkZXJhdGlvbiwgZXRjLg0K DQoNCg0KVGhpcyBpcyB0cnVlLCBpdCBpcyBhbHNvIHRydWUgdGhhdCBFQVAgaXMgdmVyeSBzdHJv bmcgb24gc2F5aW5nIHRoYXQgaWYgeW91IGhhdmUgYSBjaG9pY2UsIGFsd2F5cyBzZW5kIGFuIGFu b255bW91cyB2ZXJzaW9uIG9mIHRoZSBOQUkgaWYgeW91IGhhdmUgdG8gZG8gaXQgaW4gdGhlIGNs ZWFyLiAgVGhpcyBtZWFucyB0aGF0IHRoZSBkb21haW4gY2FuIGJlIHVzZWQgZm9yIGNvcnJlbGF0 aW9uLCBidXQgeW91IGRvIG5vdCBoYXZlIHRoZSBmdWxsIGlkZW50aXR5IGZvciB0aGF0IHB1cnBv c2UuDQoNCg0KDQpJIHRoaW5rIHRoYXQgdGhlIEVNVSBncm91cCBpcyBnb2luZyB0byBuZWVkIHRv IGxvb2sgYXQgd2hhdCBsZXZlbCBvZiBwcml2YWN5IHByb3RlY3Rpb24gaXQgaXMgZ29pbmcgdG8g ZGVzaXJlIHdoZW4gdXNpbmcgYSBQU0ssIGJ1dCBpbiB0aGF0IGNhc2UgdGhlcmUgaXMgbm8gbmVl ZCBmb3IgaGF2aW5nICBhIGRvbWFpbiBzdWZmaXggYXMgdGhhdCBpbmZvcm1hdGlvbiBpcyBwcm92 aWRlZCBlbHNld2hlcmUuICAgVGhpcyBtaWdodCByZXF1aXJlIGtlZXBpbmcgdGhlIFRMUyB0dW5u ZWxpbmcgYXMgYW4gb3B0aW9uIHRvIGRlYWwgd2l0aCBwYXNzaXZlIGF0dGFja3MuDQoNCllvdSBh cmUgYWJzb2x1dGVseSByaWdodCBhYm91dCB0aGUgcHJlZmVyZW5jZSBmb3IgdXNpbmcgYW5vbnlt b3VzIGlkZW50aXRpZXMuIGRyYWZ0LWlldGYtZW11LWVhcC10bHMxMyBjdXJyZW50bHkgc2F5cyB0 aGUgZm9sbG93aW5nIGFib3V0IHJlc3VtcHRpb246DQoNCiAgIEl0IGlzIFJFQ09NTUVOREVEIHRv IHVzZSBhIE5BSXMgd2l0aCB0aGUgc2FtZSByZWFsbSBpbiB0aGUgcmVzdW1wdGlvbg0KDQogICBh bmQgdGhlIG9yaWdpbmFsIGZ1bGwgYXV0aGVudGljYXRpb24uICBUaGlzIHJlcXVpcmVtZW50IGFs bG93cyBFQVANCg0KICAgcGFja2V0cyB0byBiZSByb3V0YWJsZSB0byB0aGUgc2FtZSBkZXN0aW5h dGlvbiBhcyB0aGUgb3JpZ2luYWwgZnVsbA0KDQogICBhdXRoZW50aWNhdGlvbi4gIElmIHRoaXMg cmVjb21tZW5kYXRpb24gaXMgbm90IGZvbGxvd2VkLCByZXN1bXB0aW9uDQoNCiAgIGlzIGxpa2Vs eSB0byBiZSBpbXBvc3NpYmxlLiAgV2hlbiBOQUkgcmV1c2UgY2FuIGJlIGRvbmUgd2l0aG91dA0K DQogICBwcml2YWN5IGltcGxpY2F0aW9ucywgaXQgaXMgUkVDT01NRU5ERUQgdG8gdXNlIHRoZSBz YW1lIGFub255bW91cyBOQUkNCg0KICAgaW4gdGhlIHJlc3VtcHRpb24sIGFzIHdhcyB1c2VkIGlu IHRoZSBvcmlnaW5hbCBmdWxsIGF1dGhlbnRpY2F0aW9uLg0KDQogICBFLmcuIHRoZSBOQUkgQHJl YWxtIGNhbiBzYWZlbHkgYmUgcmV1c2VkLCB3aGlsZSB0aGUgTkFJDQoNCiAgIFpteGxlRzg9QHJl YWxtIGNhbm5vdC4NClRoaXMgZG9jdW1lbnQgYW5kIHRoZSBlbnN1aW5nIGRpc2N1c3Npb24gcGVy dGFpbnMgb25seSB0byBleHRlcm5hbCBQU0tzIGFuZCBleHRlcm5hbCBQU0sgaWRlbnRpdGllcy4g SSB0aGluayBJIGluY29ycmVjdGx5IHVzZWQgdGhlIHdvcmQgImlzc3VlIiBpbiBteSBwcmV2aW91 cyBlbWFpbCBhcyBhIG1vcmUgY29ycmVjdCBjaG9pY2Ugd291bGQgaGF2ZSBiZWVuICJhZ3JlZS9l c3RhYmxpc2giIChpLmUuIHRoZSBzZXJ2ZXIgYW5kIGNsaWVudCBhZ3JlZSBvbiBhbiBleHRlcm5h bCBQU0sgYW5kIGFuIGV4dGVybmFsIFBTSyBpZGVudGl0eSkuIFJGQyA4NDQ2IGRvZXNuJ3QgcGxh Y2UgYW55IHJlc3RyaWN0aW9ucyBvbiBleHRlcm5hbCBQU0sgaWRlbnRpdGllcyAob3RoZXIgdGhh biB0aGUgZmFjdCB0aGF0IHRoZXkgYXJlIGF0IGxlYXN0IDEgYnl0ZSkuIElmIHdlIGFyZSBnb2lu ZyB0byBkaXNjb3VyYWdlIHRoZSB1c2Ugb2YgZG9tYWluIG5hbWVzIGluIGV4dGVybmFsIFBTSyBp ZGVudGl0aWVzLCB3b3VsZCB0aGF0IGJlIHN1ZmZpY2llbnQ/IFdoYXQgcHJldmVudHMgbWUgZnJv bSB1c2luZyBhbiBleHRlcm5hbCBQU0sgaWRlbnRpdHkgb2YgdGhlIHR5cGU6IG15X3N0cm9uZ19z ZWNyZXRfcHNrX3dpdGhfYW1hem9uX3NlcnZlcj8NCg0KSSBhbSBub3Qgc3VyZSBpZiB3ZSBzaG91 bGQgcmVjb21tZW5kIHJhbmRvbWl6ZWQgZXh0ZXJuYWwgUFNLIGlkZW50aXRpZXMgb2YgYSBjZXJ0 YWluIG1pbmltdW0gbGVuZ3RoLiBQZXJoYXBzIGl0IG1pZ2h0IGJlIGJldHRlciB0byBhZGQgYSBk aXNjbGFpbWVyIGFib3V0IHRoZSBwcml2YWN5IGxvc3MgZnJvbSBjYXJlbGVzc2x5IGNob3NlbiBl eHRlcm5hbCBQU0sgaWRlbnRpdGllcz8NCg0KW0pMU10gVGhlcmUgYXJlIGdvaW5nIHRvIGJlIHRo cmVlIGRpZmZlcmVudCBjYXNlcyBmb3IgZXh0ZXJuYWwgUFNLIGlkZW50aXRpZXM6IFRoZSBpZGVu dGl0eSBpZiBmYWN0b3J5IHByb3Zpc2lvbmVkIGFuZCBjYXJyaWVkIGluIGEgZmlsZSB0byB0aGUg c2VydmVyLCAgdGhlIGlkZW50aXR5IGlzIGZhY3RvcnkgcHJvdmlzaW9uZWQgYW5kIHJlYWQgYnkg dGhlIHVzZXIgZnJvbSB0aGUgZGV2aWNlLCBhbmQgaXQgaXMgaGFuZCBjaG9zZW4uICBUaGUgZmly c3QgdHdvIGNhc2VzIGNhbiBkZWZpbml0ZWx5IGJlIHJhbmRvbWl6ZWQuICBJIGRvbuKAmXQga25v dyB0aGF0IGhhdmluZyBhIG1pbmltdW0gbGVuZ3RoIG1ha2VzIGFueSBkaWZmZXJlbmNlLiAgVGhp cyBpcyBub3QgZXhhY3RseSBhIGNyeXB0b2dyYXBoaWMgcHJvcGVydHkuICBBbm90aGVyIHRoaW5n IHRoYXQgbWlnaHQgYmUgZG9uZSB3b3VsZCBiZSBhbmFsb2dvdXMgdG8gdGhlIFBTSyBpbXBvcnRl ciBkb2N1bWVudCBhbmQgYXBwbHkgYSBvbmUgd2F5IGhhc2ggZnJvbSB0aGUgdHlwZWQgaW4gdmFs dWUgdG8gdGhlIHZhbHVlIHRoYXQgaXMgc2VudCBvdmVyIHRoZSB3aXJlIHNvIG9uIHRoZSB3aXJl IGl0IGlzIGp1c3QgYSByYW5kb20gc2V0IG9mIGJ5dGVzLg0KDQpKaW0NCg0KDQoNCi0tTW9oaXQN Cg0KDQoNCg0KDQoNCg0KDQoNCkkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHRoZSBuYXR1cmUg b2YgdGhlIHJlc3VsdGluZyBwcml2YWN5IGxvc3MuIElzIGl0IHRoYXQgYQ0KDQpwYXNzaXZlIGF0 dGFja2VyIGNhbiBub3cgZWFzaWx5IGRldGVybWluZSB0aGUgc2VydmVyIHdoaWNoIGlzc3VlZCB0 aGUgUFNLDQoNCmlkZW50aXR5IChhbmQgdGhlIHNlcnZlciB3aGVyZSBpdCB3aWxsIGV2ZW50dWFs bHkgYmUgdXNlZCk/DQoNCg0KDQpXaGlsZSBpdCBJIHRydWUgdGhhdCBhdCBsZWFzdCBzb21lIG9m IHRoZSBwcml2YWN5IGluZm9ybWF0aW9uIGhhcyBhbHJlYWR5IGJlZW4gbGVha2VkIGluIHRoZSBQ U0sgY2FzZSwgeW91IGtub3cgdGhlIGFkZHJlc3MgdGhhdCBpcyBiZWluZyB0YWxrZWQgdG8gYW5k IHRoZSBQU0sgaWRlbnRpdHkgdGhhdCBpcyBwYXNzZWQuICBJZiB5b3UgbG9vayBhdCB1c2luZyB0 aGlncyBsaWtlIEVTTkksIGRvaW5nIHRoaXMgd291bGQgYXBwZWFyIHRvIHBvdGVudGlhbGx5IGdp dmUgYXdheSB0aGUgdmVyeSBpbmZvcm1hdGlvbiB0aGF0IGlzIGJlaW5nIGhpZGRlbiBpbiB0aGF0 IGNhc2UuDQoNCg0KDQpUaGUgb3RoZXIgcHJvYmxlbSB3aXRoIGhhdmluZyBkb21haW4gYmFzZWQg S0lEcyBpcyB0aGF0IHlvdSBjb3VsZCBlYXNpbHkgZ2V0IHNvbWUgYW1vdW50IG9mIGNvcnJlbGF0 aW9uIGJldHdlZW4gdGhlIEtJRHMgdGhhdCBhcmUgYXNzaWduZWQgaW4gZGlmZmVyZW50IGRvbWFp bnMuICBZb3UgY291bGQgZW5kIHVwIHdpdGggbW9oaXQuaWV0ZiBhbmQgbW9oaXQuYW1hem9uIGFu ZCBpdCB3b3VsZCBiZSBxdWl0ZSByZWFzb25hYmxlIHRvIGFzc3VtZSB0aGF0IGJvdGggb2YgdGhv c2UgaWRlbnRpdGllcyBhcmUgZ29pbmcgdG8gYmUgZm9yIHRoZSBzYW1lIGVudGl0eSwganVzdCBp biBkaWZmZXJlbnQgZG9tYWlucy4NCg0KDQoNCkppbQ0KDQoNCg0KDQoNCg0KDQotLU1vaGl0DQoN Cg0KDQoNCg0KKiBTZWN0aW9uIDcuMS4yIC0gVGhlcmUgc2VlbSB0byBtZSB0byBiZSB0aHJlZSBk aWZmZXJlbnQgcGxhY2VzIHdoZXJlDQoNCmNvbGxpc2lvbnMgd2lsbCBvY2N1ci4gIFRoZSBpbXBv cnRlciBmdW5jdGlvbiBjb3VsZCBnZXQgYSBjb2xsaXNpb24sDQoNCnRoZXJlIGNvdWxkIGJlIGNv bGxpc2lvbnMgd2l0aCBwcmUtVExTIDEuMiBleHRlcm5hbCBpZGVudGlmaWVycyBhbmQNCg0KdGhl cmUgY291bGQgYmUgY29sbGlzaW9uIHdpdGggcmVzdW1wdGlvbiBrZXlzLiAgVGhlcmUgaGFzIGJl ZW4gYSBodWdlDQoNCmRpc2N1c3Npb24gYWJvdXQgdGhpcyBpbiB0aGUgRU1VIGdyb3VwIGFuZCBJ IGRvbid0IGZpbmQgdGhlIHRleHQgaGVyZQ0KDQp0byBiZSBzZW5zaWJsZSBpbiB0ZXJtIG9mIHdo ZXRoZXIgdGhpcyBpcyBvciBpcyBub3QgYSBwcm9ibGVtLg0KDQoNCg0KKiBTZWN0aW9uIDcuMS4y IC0gT25lIG9mIHRoZSB0aGluZ3MgdGhhdCBJIGtlcHQgbWVhbmluZyB0byBnZXQgdG8gYW5kDQoN Cmp1c3QgaGF2ZW4ndCBkb25lIHNvIHlldCwgaXMgZGVhbGluZyB3aXRoIHRoZSBxdWVzdGlvbiBv ZiBjYW4gdGhlIFRMUw0KDQpLZXkgYmluZGVycyBpbiB0aGUgaGFuZHNoYWtlIHRvIGRpc3Rpbmd1 aXNoIGJldHdlZW4gbXVsdGlwbGUga2V5cyB0aGF0DQoNCmhhcHBlbiB0byBoYXZlIHRoZSBzYW1l IGlkZW50aXR5LiAgUGVyaGFwcyB5b3Ugc2hvdWxkIGxvb2sgdG8gc2VlIGlmDQoNCnRoaXMgZG9l cyB3b3JrIGFuZCBpZiBpdCBpcyBzYWZlLg0KDQoNCg0KSmltDQoNCg0KDQoNCg0KDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNClRMUyBtYWlsaW5n IGxpc3QNCg0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYu b3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3Rscw0KDQo= --_000_c3d2ff8c762a399b40c259ddbfe387aeericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHA+VG9wIHBvc3Rp bmcgc28gdGhhdCBvdGhlcnMgb24gdGhlIGxpc3QgY2FuIGNoaW1lIGluLiA8YnI+DQo8L3A+DQo8 cD5XaGlsZSBkaXNjdXNzaW5nIHRoZSBwcml2YWN5IGltcGxpY2F0aW9ucyBvZiBleHRlcm5hbCBQ U0sgaWRlbnRpdGllcywgSmltIFNjaGFhZCBpbiBoaXMgZW1haWwgYmVsb3cgcmVjb21tZW5kcyB0 aGF0IHdlIGNvdWxkIGRlc2NyaWJlIHRlY2huaXF1ZXMgZm9yIGltcG9ydGluZyBleHRlcm5hbCBQ U0sgaWRlbnRpdGllcyAodGhhdCBtYXkgYmUgdHlwZWQgaW4gYnkgdGhlIHVzZXIpLiBIZSBzdWdn ZXN0cyB0aGF0IHdlIGNvdWxkIGNvbnNpZGVyDQogdXNpbmcgYSBjb25zdHJ1Y3QgYmFzZWQgb24g b25lIHdheSBoYXNoIGZ1bmN0aW9ucyBzbyB0aGF0IHRoZSB0eXBlZC1pbiBleHRlcm5hbCBQU0sg aWRlbnRpdHkgKHByZXN1bWFibHkgd2l0aCBub3Qgc28gZ29vZCBwcml2YWN5IHByb3BlcnRpZXMp IGFyZSBuZXZlciBzZW50IG9uIHRoZSB3aXJlLg0KPGJyPg0KPC9wPg0KPHA+LS1Nb2hpdDxicj4N CjwvcD4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gNy84LzIwIDU6NDUgUE0sIEpp bSBTY2hhYWQgd3JvdGU6PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRl PSJtaWQ6MDEwMjAxZDY1NTM2JDY1NTRmNWIwJDJmZmVlMTEwJEBhdWd1c3RjZWxsYXJzLmNvbSI+ DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0 ZXJlZA0KICAgICAgICBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25z ICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNv bGFzO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbg0KICAgICAgICAgIDBpbiAwaW4gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MQ0KICAgICAgICAgICAgICAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBNb2hpdCBTZXRoaSBNIDxhIGNsYXNzPSJtb3ot dHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzptb2hpdC5tLnNldGhpQGVyaWNzc29uLmNv bSI+DQombHQ7bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20mZ3Q7PC9hPiA8YnI+DQo8Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDgsIDIwMjAgMTowMyBBTTxicj4NCjxiPlRvOjwvYj4gSmlt IFNjaGFhZCA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJtYWlsdG86aWV0 ZkBhdWd1c3RjZWxsYXJzLmNvbSI+DQombHQ7aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSZndDs8L2E+ OyBNb2hpdCBTZXRoaSBNIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1h aWx0bzptb2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbSI+DQombHQ7bW9oaXQubS5zZXRoaUBlcmlj c3Nvbi5jb20mZ3Q7PC9hPjsgPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJl Zj0ibWFpbHRvOmRyYWZ0LWlldGYtdGxzLWV4dGVybmFsLXBzay1ndWlkYW5jZUBpZXRmLm9yZyI+ DQpkcmFmdC1pZXRmLXRscy1leHRlcm5hbC1wc2stZ3VpZGFuY2VAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+Q2M6PC9iPiA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWls dG86dGxzQGlldGYub3JnIj50bHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbVExTXSBSZXZpZXcgb2YgZHJhZnQtaWV0Zi10bHMtZXh0ZXJuYWwtcHNrLWd1aWRhbmNlLTAw PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cD5IaSBKaW0sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gNy82LzIwIDc6MDYgUE0sIEppbSBTY2hhYWQgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tPG86cD48L286cD48L3ByZT4NCjxwcmU+RnJvbTogTW9oaXQgU2V0aGkgTSA8YSBocmVmPSJt YWlsdG86bW9oaXQubS5zZXRoaUBlcmljc3Nvbi5jb20iIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+ Jmx0O21vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tJmd0OzwvYT48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT5TZW50OiBNb25kYXksIEp1bHkgNiwgMjAyMCAzOjEwIEFNPG86cD48L286cD48L3ByZT4N CjxwcmU+VG86IEppbSBTY2hhYWQgPGEgaHJlZj0ibWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5j b20iIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+Jmx0O2lldGZAYXVndXN0Y2VsbGFycy5jb20mZ3Q7 PC9hPjsgZHJhZnQtaWV0Zi10bHMtZXh0ZXJuYWwtcHNrLTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PjxhIGhyZWY9Im1haWx0bzpndWlkYW5jZUBpZXRmLm9yZyIgbW96LWRvLW5vdC1zZW5kPSJ0cnVl Ij5ndWlkYW5jZUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5DYzogPGEgaHJl Zj0ibWFpbHRvOnRsc0BpZXRmLm9yZyIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj50bHNAaWV0Zi5v cmc8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3ViamVjdDogUmU6IFJldmlldyBvZiBkcmFm dC1pZXRmLXRscy1leHRlcm5hbC1wc2stZ3VpZGFuY2UtMDA8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5IaSBKaW0sPG86cD48L286cD48L3ByZT4N CjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+VGhhbmtzIGZvciB0aGUgcmV2aWV3 LiBBIGNsYXJpZnlpbmcgcXVlc3Rpb24gaW4tbGluZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5PbiA3LzIvMjAgMTI6MDIgQU0sIEppbSBTY2hh YWQgd3JvdGU6PG86cD48L286cD48L3ByZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT4qIEluIHNlY3Rpb24gNCB0aGVyZSBp cyBhIHN0YXRlbWVudCB0aGF0IHN3aXRjaGluZyB0aGUgcm9sZXMgb2Y8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT5zZXJ2ZXJzIHdoaWNoIHVzZSBQU0tzIHdpbGwgbGVhZCB0byB3ZWFrZW5pbmcgb2Yg c2VjdXJpdHkgcHJvcGVydGllcy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5BcyB0aGlzIGlzIGEg Y29tbW9uIHNjZW5hcmlvIHRvZGF5IGluIHNpdHVhdGlvbnMgd2hlcmUgeW91IGFyZSBkb2luZzxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNlcnZlci10by1zZXJ2ZXIgY29tbXVuaWNhdGlvbiwgaXQg d291bGQgYmUgdXNlZnVsIHRvIGRpc2N1c3MganVzdCBob3c8bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZT5hbmQgaG93IG11Y2ggdGhpcyB3ZWFrZW5pbmcgb2NjdXJzLiZuYnNwOyBUaGlzIHdhcyBhIGNv bXBsZXRlIHN1cnByaXNlIHRvPG86cD48L286cD48L3ByZT4NCjxwcmU+bWUgYW5kIEkgZG9uJ3Qg a25vdyBpZiBpdCB3YXMgc3VwcG9zZWQgdG8gYmUgb25lLiZuYnNwOyBBcmUgdGhlcmUgbWl0aWdh dGlvbnMgdGhhdDxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPmNhbiBiZSBt YWRlPzxvOnA+PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxw cmU+KiBJbiBzZWN0aW9uIDcsIFRoZSBmaXJzdCBzZW50ZW5jZSBkb2VzIG5vdCByZWFkLCBhbHNv IEl0IHNlZW1zIGEgYml0PG86cD48L286cD48L3ByZT4NCjxwcmU+ZGlmZmljdWx0IHRvIGhhdmUg YSBNVVNUIGluIHRoZXJlIHdoZW4gbW9zdCBvZiB0aGUgaXRlbXMgYmVsb3cgYXJlIFNIT1VMRHMu PG86cD48L286cD48L3ByZT4NCjxwcmU+VGhhdCBzZWVtcyB0byBiZSBhIGRpc3NvbmFuY2UuPG86 cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+KiBTZWN0 aW9uIDcuMS4xIC0gVGhlIGlkZWEgb2YgaGF2aW5nIGRvbWFpbiBuYW1lIHN1ZmZpeGVzIG9uIFBT S3M8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5zZWVtcyB0byBtZSB0byBiZSBhIGJhZCBpZGVhIGFz IHRoaXMgd291bGQgc2VlbSB0byBsb3dlciBwcml2YWN5IGxldmVscy48bzpwPjwvbzpwPjwvcHJl Pg0KPC9ibG9ja3F1b3RlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5JIHRo aW5rIHlvdSBhcmUgcmVmZXJyaW5nIHRvIHRoZSBQU0sgaWRlbnRpdHkgYW5kIG5vdCB0byB0aGUg UFNLLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJl PkFzIHlvdSBrbm93LCB0aGUgTmV0d29yayBBY2Nlc3MgSWRlbnRpZmllcnMgKE5BSXMpIHVzZWQg aW4gRUFQIHR5cGljYWxseSBuZWVkPG86cD48L286cD48L3ByZT4NCjxwcmU+dGhlIGRvbWFpbiBu YW1lIHN1ZmZpeCBmb3Igcm9hbWluZywgZmVkZXJhdGlvbiwgZXRjLjxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoaXMg aXMgdHJ1ZSwgaXQgaXMgYWxzbyB0cnVlIHRoYXQgRUFQIGlzIHZlcnkgc3Ryb25nIG9uIHNheWlu ZyB0aGF0IGlmIHlvdSBoYXZlIGEgY2hvaWNlLCBhbHdheXMgc2VuZCBhbiBhbm9ueW1vdXMgdmVy c2lvbiBvZiB0aGUgTkFJIGlmIHlvdSBoYXZlIHRvIGRvIGl0IGluIHRoZSBjbGVhci4mbmJzcDsg VGhpcyBtZWFucyB0aGF0IHRoZSBkb21haW4gY2FuIGJlIHVzZWQgZm9yIGNvcnJlbGF0aW9uLCBi dXQgeW91IGRvIG5vdCBoYXZlIHRoZSBmdWxsIGlkZW50aXR5IGZvciB0aGF0IHB1cnBvc2UuPG86 cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSB0aGlu ayB0aGF0IHRoZSBFTVUgZ3JvdXAgaXMgZ29pbmcgdG8gbmVlZCB0byBsb29rIGF0IHdoYXQgbGV2 ZWwgb2YgcHJpdmFjeSBwcm90ZWN0aW9uIGl0IGlzIGdvaW5nIHRvIGRlc2lyZSB3aGVuIHVzaW5n IGEgUFNLLCBidXQgaW4gdGhhdCBjYXNlIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGhhdmluZyZuYnNw OyBhIGRvbWFpbiBzdWZmaXggYXMgdGhhdCBpbmZvcm1hdGlvbiBpcyBwcm92aWRlZCBlbHNld2hl cmUuJm5ic3A7Jm5ic3A7IFRoaXMgbWlnaHQgcmVxdWlyZSBrZWVwaW5nIHRoZSBUTFMgdHVubmVs aW5nIGFzIGFuIG9wdGlvbiB0byBkZWFsIHdpdGggcGFzc2l2ZSBhdHRhY2tzLjxvOnA+PC9vOnA+ PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cD5Zb3UgYXJlIGFic29sdXRlbHkgcmlnaHQgYWJvdXQg dGhlIHByZWZlcmVuY2UgZm9yIHVzaW5nIGFub255bW91cyBpZGVudGl0aWVzLiBkcmFmdC1pZXRm LWVtdS1lYXAtdGxzMTMgY3VycmVudGx5IHNheXMgdGhlIGZvbGxvd2luZyBhYm91dCByZXN1bXB0 aW9uOg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+Jm5ic3A7Jm5ic3A7Jm5ic3A7SXQgaXMgUkVD T01NRU5ERUQgdG8gdXNlIGEgTkFJcyB3aXRoIHRoZSBzYW1lIHJlYWxtIGluIHRoZSByZXN1bXB0 aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGFuZCB0aGUgb3JpZ2luYWwg ZnVsbCBhdXRoZW50aWNhdGlvbi4mbmJzcDsgVGhpcyByZXF1aXJlbWVudCBhbGxvd3MgRUFQPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHBhY2tldHMgdG8gYmUgcm91dGFibGUg dG8gdGhlIHNhbWUgZGVzdGluYXRpb24gYXMgdGhlIG9yaWdpbmFsIGZ1bGw8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgYXV0aGVudGljYXRpb24uJm5ic3A7IElmIHRoaXMgcmVj b21tZW5kYXRpb24gaXMgbm90IGZvbGxvd2VkLCByZXN1bXB0aW9uPG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IGlzIGxpa2VseSB0byBiZSBpbXBvc3NpYmxlLiZuYnNwOyBXaGVu IE5BSSByZXVzZSBjYW4gYmUgZG9uZSB3aXRob3V0PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7IHByaXZhY3kgaW1wbGljYXRpb25zLCBpdCBpcyBSRUNPTU1FTkRFRCB0byB1c2Ug dGhlIHNhbWUgYW5vbnltb3VzIE5BSTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBpbiB0aGUgcmVzdW1wdGlvbiwgYXMgd2FzIHVzZWQgaW4gdGhlIG9yaWdpbmFsIGZ1bGwgYXV0 aGVudGljYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IEUuZy4gdGhl IE5BSSBAcmVhbG0gY2FuIHNhZmVseSBiZSByZXVzZWQsIHdoaWxlIHRoZSBOQUk8bzpwPjwvbzpw PjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgWm14bGVHOD1AcmVhbG0gY2Fubm90LiA8bzpwPjwv bzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBkb2N1 bWVudCBhbmQgdGhlIGVuc3VpbmcgZGlzY3Vzc2lvbiBwZXJ0YWlucyBvbmx5IHRvIGV4dGVybmFs IFBTS3MgYW5kIGV4dGVybmFsIFBTSyBpZGVudGl0aWVzLiBJIHRoaW5rIEkgaW5jb3JyZWN0bHkg dXNlZCB0aGUgd29yZCAmcXVvdDtpc3N1ZSZxdW90OyBpbiBteSBwcmV2aW91cyBlbWFpbCBhcyBh IG1vcmUgY29ycmVjdCBjaG9pY2Ugd291bGQgaGF2ZSBiZWVuICZxdW90O2FncmVlL2VzdGFibGlz aCZxdW90OyAoaS5lLiB0aGUgc2VydmVyDQogYW5kIGNsaWVudCBhZ3JlZSBvbiBhbiBleHRlcm5h bCBQU0sgYW5kIGFuIGV4dGVybmFsIFBTSyBpZGVudGl0eSkuIFJGQyA4NDQ2IGRvZXNuJ3QgcGxh Y2UgYW55IHJlc3RyaWN0aW9ucyBvbiBleHRlcm5hbCBQU0sgaWRlbnRpdGllcyAob3RoZXIgdGhh biB0aGUgZmFjdCB0aGF0IHRoZXkgYXJlIGF0IGxlYXN0IDEgYnl0ZSkuIElmIHdlIGFyZSBnb2lu ZyB0byBkaXNjb3VyYWdlIHRoZSB1c2Ugb2YgZG9tYWluIG5hbWVzIGluIGV4dGVybmFsIFBTSw0K IGlkZW50aXRpZXMsIHdvdWxkIHRoYXQgYmUgc3VmZmljaWVudD8gV2hhdCBwcmV2ZW50cyBtZSBm cm9tIHVzaW5nIGFuIGV4dGVybmFsIFBTSyBpZGVudGl0eSBvZiB0aGUgdHlwZTogbXlfc3Ryb25n X3NlY3JldF9wc2tfd2l0aF9hbWF6b25fc2VydmVyPw0KPG86cD48L286cD48L3A+DQo8cD5JIGFt IG5vdCBzdXJlIGlmIHdlIHNob3VsZCByZWNvbW1lbmQgcmFuZG9taXplZCBleHRlcm5hbCBQU0sg aWRlbnRpdGllcyBvZiBhIGNlcnRhaW4gbWluaW11bSBsZW5ndGguIFBlcmhhcHMgaXQgbWlnaHQg YmUgYmV0dGVyIHRvIGFkZCBhIGRpc2NsYWltZXIgYWJvdXQgdGhlIHByaXZhY3kgbG9zcyBmcm9t IGNhcmVsZXNzbHkgY2hvc2VuIGV4dGVybmFsIFBTSyBpZGVudGl0aWVzPw0KPG86cD48L286cD48 L3A+DQo8cD5bSkxTXSBUaGVyZSBhcmUgZ29pbmcgdG8gYmUgdGhyZWUgZGlmZmVyZW50IGNhc2Vz IGZvciBleHRlcm5hbCBQU0sgaWRlbnRpdGllczogVGhlIGlkZW50aXR5IGlmIGZhY3RvcnkgcHJv dmlzaW9uZWQgYW5kIGNhcnJpZWQgaW4gYSBmaWxlIHRvIHRoZSBzZXJ2ZXIsJm5ic3A7IHRoZSBp ZGVudGl0eSBpcyBmYWN0b3J5IHByb3Zpc2lvbmVkIGFuZCByZWFkIGJ5IHRoZSB1c2VyIGZyb20g dGhlIGRldmljZSwgYW5kIGl0IGlzIGhhbmQgY2hvc2VuLiZuYnNwOyBUaGUNCiBmaXJzdCB0d28g Y2FzZXMgY2FuIGRlZmluaXRlbHkgYmUgcmFuZG9taXplZC4mbmJzcDsgSSBkb27igJl0IGtub3cg dGhhdCBoYXZpbmcgYSBtaW5pbXVtIGxlbmd0aCBtYWtlcyBhbnkgZGlmZmVyZW5jZS4mbmJzcDsg VGhpcyBpcyBub3QgZXhhY3RseSBhIGNyeXB0b2dyYXBoaWMgcHJvcGVydHkuJm5ic3A7IEFub3Ro ZXIgdGhpbmcgdGhhdCBtaWdodCBiZSBkb25lIHdvdWxkIGJlIGFuYWxvZ291cyB0byB0aGUgUFNL IGltcG9ydGVyIGRvY3VtZW50IGFuZCBhcHBseSBhIG9uZQ0KIHdheSBoYXNoIGZyb20gdGhlIHR5 cGVkIGluIHZhbHVlIHRvIHRoZSB2YWx1ZSB0aGF0IGlzIHNlbnQgb3ZlciB0aGUgd2lyZSBzbyBv biB0aGUgd2lyZSBpdCBpcyBqdXN0IGEgcmFuZG9tIHNldCBvZiBieXRlcy48bzpwPjwvbzpwPjwv cD4NCjxwPkppbTxvOnA+PC9vOnA+PC9wPg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD4t LU1vaGl0PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZu YnNwOzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkkg d291bGQgbGlrZSB0byB1bmRlcnN0YW5kIHRoZSBuYXR1cmUgb2YgdGhlIHJlc3VsdGluZyBwcml2 YWN5IGxvc3MuIElzIGl0IHRoYXQgYTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnBhc3NpdmUgYXR0 YWNrZXIgY2FuIG5vdyBlYXNpbHkgZGV0ZXJtaW5lIHRoZSBzZXJ2ZXIgd2hpY2ggaXNzdWVkIHRo ZSBQU0s8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5pZGVudGl0eSAoYW5kIHRoZSBzZXJ2ZXIgd2hl cmUgaXQgd2lsbCBldmVudHVhbGx5IGJlIHVzZWQpPzxvOnA+PC9vOnA+PC9wcmU+DQo8L2Jsb2Nr cXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPldoaWxlIGl0IEkgdHJ1 ZSB0aGF0IGF0IGxlYXN0IHNvbWUgb2YgdGhlIHByaXZhY3kgaW5mb3JtYXRpb24gaGFzIGFscmVh ZHkgYmVlbiBsZWFrZWQgaW4gdGhlIFBTSyBjYXNlLCB5b3Uga25vdyB0aGUgYWRkcmVzcyB0aGF0 IGlzIGJlaW5nIHRhbGtlZCB0byBhbmQgdGhlIFBTSyBpZGVudGl0eSB0aGF0IGlzIHBhc3NlZC4m bmJzcDsgSWYgeW91IGxvb2sgYXQgdXNpbmcgdGhpZ3MgbGlrZSBFU05JLCBkb2luZyB0aGlzIHdv dWxkIGFwcGVhciB0byBwb3RlbnRpYWxseSBnaXZlIGF3YXkgdGhlIHZlcnkgaW5mb3JtYXRpb24g dGhhdCBpcyBiZWluZyBoaWRkZW4gaW4gdGhhdCBjYXNlLiZuYnNwOyA8bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgb3RoZXIgcHJvYmxlbSB3 aXRoIGhhdmluZyBkb21haW4gYmFzZWQgS0lEcyBpcyB0aGF0IHlvdSBjb3VsZCBlYXNpbHkgZ2V0 IHNvbWUgYW1vdW50IG9mIGNvcnJlbGF0aW9uIGJldHdlZW4gdGhlIEtJRHMgdGhhdCBhcmUgYXNz aWduZWQgaW4gZGlmZmVyZW50IGRvbWFpbnMuJm5ic3A7IFlvdSBjb3VsZCBlbmQgdXAgd2l0aCBt b2hpdC5pZXRmIGFuZCBtb2hpdC5hbWF6b24gYW5kIGl0IHdvdWxkIGJlIHF1aXRlIHJlYXNvbmFi bGUgdG8gYXNzdW1lIHRoYXQgYm90aCBvZiB0aG9zZSBpZGVudGl0aWVzIGFyZSBnb2luZyB0byBi ZSBmb3IgdGhlIHNhbWUgZW50aXR5LCBqdXN0IGluIGRpZmZlcmVudCBkb21haW5zLjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkppbTxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+LS1Nb2hp dDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+ PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+KiBTZWN0aW9uIDcuMS4yIC0gVGhlcmUgc2Vl bSB0byBtZSB0byBiZSB0aHJlZSBkaWZmZXJlbnQgcGxhY2VzIHdoZXJlPG86cD48L286cD48L3By ZT4NCjxwcmU+Y29sbGlzaW9ucyB3aWxsIG9jY3VyLiZuYnNwOyBUaGUgaW1wb3J0ZXIgZnVuY3Rp b24gY291bGQgZ2V0IGEgY29sbGlzaW9uLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZXJlIGNv dWxkIGJlIGNvbGxpc2lvbnMgd2l0aCBwcmUtVExTIDEuMiBleHRlcm5hbCBpZGVudGlmaWVycyBh bmQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGVyZSBjb3VsZCBiZSBjb2xsaXNpb24gd2l0aCBy ZXN1bXB0aW9uIGtleXMuJm5ic3A7IFRoZXJlIGhhcyBiZWVuIGEgaHVnZTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPmRpc2N1c3Npb24gYWJvdXQgdGhpcyBpbiB0aGUgRU1VIGdyb3VwIGFuZCBJIGRv bid0IGZpbmQgdGhlIHRleHQgaGVyZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRvIGJlIHNlbnNp YmxlIGluIHRlcm0gb2Ygd2hldGhlciB0aGlzIGlzIG9yIGlzIG5vdCBhIHByb2JsZW0uPG86cD48 L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+KiBTZWN0aW9u IDcuMS4yIC0gT25lIG9mIHRoZSB0aGluZ3MgdGhhdCBJIGtlcHQgbWVhbmluZyB0byBnZXQgdG8g YW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+anVzdCBoYXZlbid0IGRvbmUgc28geWV0LCBpcyBk ZWFsaW5nIHdpdGggdGhlIHF1ZXN0aW9uIG9mIGNhbiB0aGUgVExTPG86cD48L286cD48L3ByZT4N CjxwcmU+S2V5IGJpbmRlcnMgaW4gdGhlIGhhbmRzaGFrZSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVu IG11bHRpcGxlIGtleXMgdGhhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmhhcHBlbiB0byBoYXZl IHRoZSBzYW1lIGlkZW50aXR5LiZuYnNwOyBQZXJoYXBzIHlvdSBzaG91bGQgbG9vayB0byBzZWUg aWY8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGlzIGRvZXMgd29yayBhbmQgaWYgaXQgaXMgc2Fm ZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5K aW08bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48 bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHBy ZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRMUyBtYWlsaW5n IGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86VExTQGlldGYub3Jn IiBtb3otZG8tbm90LXNlbmQ9InRydWUiPlRMU0BpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJl Pg0KPHByZT48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rs cyIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3RsczwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjxicj4NCjxmaWVsZHNldCBjbGFzcz0ibWltZUF0dGFjaG1lbnRIZWFkZXIiPjwvZmll bGRzZXQ+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUtcHJlIiB3cmFwPSIiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQo8YSBj bGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVmPSJtYWlsdG86VExTQGlldGYub3Jn Ij5UTFNAaWV0Zi5vcmc8L2E+DQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVm PSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+DQo8L3ByZT4NCjwvYmxvY2txdW90ZT4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_c3d2ff8c762a399b40c259ddbfe387aeericssoncom_-- From nobody Thu Jul 9 22:09: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 341473A0D06 for ; Thu, 9 Jul 2020 22:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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=icloud.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 qzeTxQymg9Mg for ; Thu, 9 Jul 2020 22:09:12 -0700 (PDT) Received: from mr85p00im-zteg06011501.me.com (mr85p00im-zteg06011501.me.com [17.58.23.182]) (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 05FEB3A0D05 for ; Thu, 9 Jul 2020 22:09:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1594357750; bh=yp13kDpCFJGvMbqlZDTPwumo/TpkBiE5OKHDwJEjgyM=; h=From:Content-Type:Subject:Message-Id:Date:To; b=k8JT77/rv62URDMQ+HqhA/oxTxHDlZeUn7kEVqySx7XOiosyV0bNxNmGSNkxRm+8I DhQ0KN3KDik4gLIzbDJhRXjYrgfR0s9dtpBULMxcy1pigrr8cyBojpg4myOafsGslc x/X768C6vtpMro5RCSp52ymd7G2eK1gfZzYjYYTusf7tYWPw9/+v2fOJzT/uyrCIkM hC1hZd3PSUQjEWlYjOwAK/qkrgKEmDj1aUnMd8E4bhjB3gMhrOQ+85Ca2zO7PbLv8w DNMeHAZe8iDpCdjMg+ZqBeFkkuMXAsPoy+4QyKTGlQSx6Gvb/kTT7vDZdxWp++n0B4 FSTRobdwyI1kQ== Received: from [17.234.78.251] (unknown [17.234.78.251]) by mr85p00im-zteg06011501.me.com (Postfix) with ESMTPSA id 89EBD2A06D3 for ; Fri, 10 Jul 2020 05:09:10 +0000 (UTC) From: Carrick Bartle Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3622.0.7\)) Message-Id: <3359D367-16E3-4C30-B434-A8043B1F253A@icloud.com> Date: Thu, 9 Jul 2020 22:09:09 -0700 To: TLS List X-Mailer: Apple Mail (2.3622.0.7) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-10_01:2020-07-09, 2020-07-10 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=736 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2007100034 Archived-At: Subject: [TLS] Review of draft-ietf-tls-external-psk-guidance-00 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, 10 Jul 2020 05:09:13 -0000 Hi everyone, A few thoughts on draft-ietf-tls-external-psk-guidance-00: Isn=E2=80=99t the rerouting attack described in Section 4 not possible = if "A" uses the SNI extension and "C" aborts the connection on mismatch? = If so, it might be worth mentioning that as a potential mitigation (as = the Selfie paper does). > "C" has completed the handshake, ostensibly with "A". "C" did in fact complete the handshake with "A." (Without mistaking it = for some other endpoint or something.) > Low entropy keys are only secure against active attack if a PAKE is = used with TLS. Maybe cite a document that contains a recommended way of using PAKEs = with TLS (e.g. draft-sullivan-tls-opaque-00)? > Applications should take precautions when using external PSKs to = mitigate these risks. What sort of precautions should they take? > Preventing this type of linkability is out of scope, as PSKs are = explicitly designed to support mutual authentication. Isn't mutual authentication, in general, orthogonal to linkability? = Certificates, for example, are encrypted in TLS 1.3, and so cannot be = linked across connections. > Below, we list some example use-cases where pair-wise external PSKs = with TLS have been used for authentication. I assume "pair-wise" here means a PSK is shared between only one server = and one client, but this the term "pair-wise" hasn't been associated = with that concept in this document, it's not completely clear. Since = "pair-wise" is used twice in the document, maybe define it when the = concept is first introduced. > primarily for the purposes of supporting TLS connections with fast = open (0-RTT data) I've only ever heard "fast open" used in the context of TFO, which is = distinct from (albeit similar to) 0-RTT. Using "fast open" to refer to = 0-RTT sounds like it's conflating terms. Shouldn't "early data" be used = here instead of "fast open"? > In this use-case, resource-constrained IoT devices act as TLS clients = and share the same PSK. The devices use this PSK for quickly = establishing connections with a central server. Such a scheme ensures = that the client IoT devices are legitimate members of the system. If the IoT devices only talk to a central server and not each other, why = do they all need the same PSK? > To perform rare system specific operations that require a higher = security level, the central server can request resource-intensive client = authentication with the usage of a certificate after successfully = establishing the connection with a PSK. If you're going to authenticate with a cert, why bother preceding that = with an authentication with a PSK? > 6.1. Provisioning Examples This section contains a list of ways to provision PSKs, but mostly = without any commentary or discussion. Are these methods good? Bad? Are = there any pitfalls? If so, how can one guard against them? > Moreover, PSK production lacks guidance unlike user passwords. Isn't that precisely the point of this draft? Seems unnecessary to = mention. (Or it might be better to move this point to the intro as a = motivating factor of this document.) > PSK provisioning systems are often constrained in application-specific = ways. For example, although one goal of provisioning is to ensure that = each pair of nodes has a unique key pair, some systems do not want to = distribute pair-wise shared keys to achieve this. Why not? What application-specific constraint would warrant that? > some systems require the provisioning process to embed = application-specific information in either PSKs or their identities. Is it really a good idea to embed data in the PSK itself? Does that not = diminish the entropy of the PSK? Why is it not sufficient to put that = sort of information in the identity? > Identities may sometimes need to be routable, as is currently under = discussion for EAP-TLS-PSK. What does it mean for an identity to be "routable"? Also, EAP-TLS-PSK = needs a citation link. I'm not sure which document it's referring to. > Applications MUST use external PSKs that adhere to the following = requirements: I think you mean "If an application uses external PSKs, the PSKs MUST = adhere to the following requirements." Otherwise it sounds like you're = saying every application must use an external PSK. > Each PSK SHOULD be derived from at least 128 bits of entropy Recommend a particular method for doing that? > Note that these mechanisms do not necessarily follow the same = architecture as the ordinary process for incorporating EPSKs described = in this draft. Where was the ordinary process for incorporating EPSKs described? Is = "incorporating" a PSK the same as "provisioning" one? If so, several = ways were described. What's the problem with these mechanisms (e.g. = PAKE) having a different architecture from these ordinary processes? Are = they not compatible? > 3. Nodes SHOULD use external PSK importers = [I-D.ietf-tls-external-psk-importer] when configuring PSKs for a pair of = TLS client and server. Why? > OpenSSL and BoringSSL: Applications specify support for external PSKs = via distinct ciphersuites. This is not true of BoringSSL for TLS 1.3. Although the paragraph goes = on to mention "new callback functions added specifically to OpenSSL for = TLS 1.3 [RFC8446] PSK support," this doesn't preclude 1.3 PSK support in = BoringSSL. > PSK identities MAY have a domain name suffix for roaming and = federation. What do roaming and federation mean here? Is there a source that = discusses this? > Deployments should take care that the length of the PSK identity is = sufficient to avoid obvious collisions. What's the difference between a "collision" and an "obvious collision"? > This means that if a PSK identity collision occurs, the application = will be given precedence over how to handle the PSK. How should the application handle the collision? I'm happy to make the suggested changes in a PR if they look ok. Carrick From nobody Sun Jul 12 00:26: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 990C83A0E8C for ; Sun, 12 Jul 2020 00:25: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, 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 Us_rAygjhRBt for ; Sun, 12 Jul 2020 00:25:58 -0700 (PDT) Received: from mail-vk1-xa2b.google.com (mail-vk1-xa2b.google.com [IPv6:2607:f8b0:4864:20::a2b]) (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 53B893A0E8A for ; Sun, 12 Jul 2020 00:25:58 -0700 (PDT) Received: by mail-vk1-xa2b.google.com with SMTP id r7so2124711vkf.0 for ; Sun, 12 Jul 2020 00:25:58 -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; bh=EXBJt5w9LQV6Fo8nleJj+8OyHOQL9BfaFFW/sazu4DA=; b=nU/XdmCER0QHPSMJ8JHVCuQ8JUGYyijEdab7wWcTXbWPY5jnkw+As10kPnf55Bh7xR VE6pD8KmPhYDGG0zJPhgfg8S4gYwmHDoIjTJsZs2QKxwCz0ZNnSeFd1JjNMEE0mHUCFg h7v+P3dd6NK8VfCgGJXbXvMjoYMvam9Qa7067HqFozKeJ1HZ7pQeUbFOnzGuQqPwPsot oZzD9LbD57g2dsM0EovnrfQ1v0bnc/PUVVbkTLMFbqV9LRnzsD8+QOJqvUBd0IMiMq5j CnlwMtjZd458v88dvQZp5D1hPdLdeRtVm5KsqwAzQaqvYd3BAOQlRSfdylRLvdLqruxo ubEg== 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=EXBJt5w9LQV6Fo8nleJj+8OyHOQL9BfaFFW/sazu4DA=; b=F1fs3sdzuGHkxapsTQOcmGyWD2E4eHcWoqQL3N4N48SMIqU1LyOn0y6covaYB+IFoU NQ8GaMzsh7Vaf5lk5SBcqx+StwmcI4Uo1V5pB555LOdMXz1NE07kwfbDC/j/TSGYjRMV N/lW+lpzsPAV0AgsIOwPYOqWsaX6MyDSoT7F9rMYLoYid56Lh5WJI9lS7wrQ4KT0o8Ee zoxdVIaczBurGv159kRNPRwyNSlju6PiVHW81GEB6taxWx7DqiqLo/nV3lVdMXLh5V6w ToJ8KrGHhcKKEs4oO/PviTmw6h1VXyBLJadghYoPBMHs+y5IrHoCTvQm9hQFL2aEjtSh b8og== X-Gm-Message-State: AOAM53268Zi9XxAsi+NCk8YDBNKdsKlD2UEsGOMnqfwcFmrnPNnZUiF+ KhP1dQocvbEhZ8c6mMwXj5KW+yIj7ETf5yGARwvxHLYtHWY= X-Google-Smtp-Source: ABdhPJwSfLWcYouBTSURVL818pufHPtZaLWoxT+js3Dh2dr1BkMsqVTdHUa/0MGH6n0R9vlzpmt7m+T7RjOJivBsWPA= X-Received: by 2002:a1f:acc2:: with SMTP id v185mr242396vke.18.1594538756945; Sun, 12 Jul 2020 00:25:56 -0700 (PDT) MIME-Version: 1.0 From: Pascal Urien Date: Sun, 12 Jul 2020 09:25:45 +0200 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary="000000000000303a3005aa397cfc" Archived-At: Subject: [TLS] draft-urien-tls-im-02.txt & test 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 Jul 2020 07:26:00 -0000 --000000000000303a3005aa397cfc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear All I tested the identity module for tls1.3, whose features and code for javacard 3.04, are described in draft-urien-tls-im-02, with the WolfSSL TLS13 stack. As many stacks, pre-shared key is available thanks to a callback that returns the psk value in clear form. I believe this is a bad practice from a security point of view. The main idea of draft-urien-tls-im-02 is to avoid psk exposure. In order to prevent hijacking, psk is only used thanks to dedicated HDSK procedures, based on psk value. >From a sofware point of view the identiy module requires a dedicated callback at several points in the TLS13 stack. Given this pre-requisite the draft-urien-tls-im-02 works and protects the preshared key. In the WolfSSL TLS13 stack there is a callback to compute asymmetric signature when certificates are used. The identity module can perform this operation (as described in draft and code) and so avoid the private key hijacking. This seems to be the common TLS13 mistake: private key is protected from eavesdropping but not psk. It should be great to test identity module at next IETF hackatons=E2=80=A6i= t is easy to make an identity module with a commercial javacard..i can provided UART interface devices for embedded platform Rgs Pascal --000000000000303a3005aa397cfc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All
I tested the identity module for tls1.3, whose= features and code for javacard 3.04, are described in draft-urien-tls-im-0= 2, with the WolfSSL TLS13 stack.
As many stacks, pre-shared key is avail= able thanks to a callback that returns the psk value in clear form. I belie= ve this is a bad practice from a security point of view.
The main idea o= f draft-urien-tls-im-02 is to avoid psk exposure. In order to prevent hijac= king, psk is only used thanks to dedicated HDSK procedures, based on psk va= lue.
From a sofware point of view the identiy module requires a dedicate= d callback at several points in the TLS13 stack. Given this pre-requisite t= he draft-urien-tls-im-02 works and protects the preshared key.
In the Wo= lfSSL TLS13 stack there is a callback to compute asymmetric signature when = certificates are used.=C2=A0 The identity module can perform this operation= (as described in draft and code) and so avoid the private key hijacking.This seems to be the common TLS13 mistake: private key is protected from = eavesdropping but not psk.
It should be great to test identity module at= next IETF hackatons=E2=80=A6it is easy to make an identity module with a c= ommercial javacard..i can provided UART interface devices for embedded plat= form

Rgs
Pascal
--000000000000303a3005aa397cfc-- From nobody Sun Jul 12 00:32: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 6804B3A0EA9 for ; Sun, 12 Jul 2020 00:32: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, 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=NIZTCwjI; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rTuCG2rr 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 noVfspTsImTF for ; Sun, 12 Jul 2020 00:32:15 -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 7FBCB3A0E98 for ; Sun, 12 Jul 2020 00:32:15 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D76995C0086 for ; Sun, 12 Jul 2020 03:32:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 12 Jul 2020 03:32:14 -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= fm3; bh=UI6YG3kR0WQ6r/n+QrhnId8ocqGBUQfwKO2RM+Emtjg=; b=NIZTCwjI 7fm7rrWuSbQa08iHBY0obf+A5K4oxU/klQN8mCnAgLXJ6OnwKkzEJKzfj4GTpPhl 8ZVlKt4bC+1LY9tkIQWks7XU/0/SMzCzauLM0EYbPJwNtf09jtof415Qzz8yUT3l DsvzNaWx3z/nxyXsBbbeBnrujT6iZ2vRbsVOCq7Q2l8ZBFXYNA/w4r78Irn+OU5a Plh8oZUxCDuJFtnJ99uLb93+NknmRCJU19N7eSn5UuyZ/QCLqQqGjymW/xr0b2g4 Qx2xtoBJwecmYo6Im7PomuR3kIocJkd/jqGiZGKAHlBwzgE7hve3zrM1Jl+R5O0V nOPbEIJWk0hg/w== 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=fm3; bh=UI6YG3kR0WQ6r/n+QrhnId8ocqGBU QfwKO2RM+Emtjg=; b=rTuCG2rr3tNC26/rUOEnI0RNMrj17PWxW8X9ygHQJNV63 /vurWDO5ZwQd2c6Fyp/ALaCaJeKsd+bGy9B1X/zb2RICxsO4gG50dokbDIDlLA+e 8Hd/xFo8oETldjndBbsJ7fTWuzqEJ0/+ikD6pT4h9xx1MIQFtjw9Ander7DQh+Wy rKVaw3AV6p+xGlXfvleRc8XNSBrY4nIHf4UcT514nZ+MECzNXZHoySFR/mc+OsDQ DNBZvWKhRX1AMMfkushMvEcn5fmW2i2yfU2y07O4RU827TJps568cVwGb89zdXVk k+nIlRpSgpd6/kum/J6qUPTm9026wMuc+1Sc8D9Yw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvdehgddvhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtthgvrh hnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudeiteen ucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrkeekrddufeegrdegke enucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgp nhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az86.internal.cloudapp.net (unknown [40.88.134.48]) by mail.messagingengine.com (Postfix) with ESMTPA id A6C7C306005F for ; Sun, 12 Jul 2020 03:32:14 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============1880521447309974807==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: tls@ietf.org Message-Id: <20200712073214.A6C7C306005F@mailuser.nyi.internal> Date: Sun, 12 Jul 2020 03:32:14 -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 Jul 2020 07:32:20 -0000 --===============1880521447309974807== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Pull requests ------------- * tlswg/tls-subcerts (+1/-0/=F0=9F=92=AC0) 1 pull requests submitted: - Add in test vectors (by wbl) https://github.com/tlswg/tls-subcerts/pull/77=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 --===============1880521447309974807== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (TLS Working Group Drafts)

Sunday July 12, 2020

Pull requests

tlswg/tls-subcerts (+1/-0/=F0=9F=92=AC0)

1 pull requests submitted:

Repositories tracked by this digest:

--===============1880521447309974807==-- From nobody Sun Jul 12 14:23: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 E1DED3A090F for ; Sun, 12 Jul 2020 14:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5rOvtju83TLW for ; Sun, 12 Jul 2020 14:23:20 -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 B01363A07C4 for ; Sun, 12 Jul 2020 14:23:19 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id q4so13369451lji.2 for ; Sun, 12 Jul 2020 14:23:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=w+TjI0qPacvWCICrg8gdliExyu8llqy9Qc8EaMliTpw=; b=vJQJ3YoZ9sAqxEFqCHPppaTWzCf42u/QCPUJ3NNmT6D74/GZ8WiH6wt9hOMQAHZhTl AY043nU8+T8gI91h1SfB5KEQDt/1TGGkdUO0G2sfQiegG7lM4jVePF0iZoAOOV43O1Bh 5vX/rlEYnSSyBe74IQe7OFlExTkgy2fV3qEYsL2v5rEm5eVFadtYwFcr+7HJLTp3Rbp9 Vhpf/LMyaJYqWXlUcLPt0jEZ8f8CiFDCQq1ht1Y/9KqO+3wKEgWyyPUtybzlhy+NguAB CrpDl373emGhgLwmS3EX7ikHMMLmAeGex++R+1EorOi5YjRme5UiQHDOrMJ1Hmd1sF01 qT+Q== 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=w+TjI0qPacvWCICrg8gdliExyu8llqy9Qc8EaMliTpw=; b=Svs/6V2fjhBkDil3dvK+FdxeYY+oxnmyPczeaCZiP8wA3FmSPoLGjYesPx8y+qCCQZ 4+AxIH80Oz06Ke95YzACCht/oyeU7b71R3h7nXGgwquoC83KVDjFNrU1R612P9j+UN0o kA0RdazsQzsk9ISjcxNepPhjVYaOXPeNVCOBR5AvyxOYrYOEbbPjQgO78zVQfjg/YCaK SPdXlc3XqU4BOOf/30BY6lqgXQ4hincWroO8gniG49SffiUU5mwVKSiNOfiE7I/wJmfv fUUQi3YdM+4Nt5tfDqdaC5lZB0deWbzmJWj4z8swKtR9BVWMpE9zOAYBlXE6Yr+G5aaU j4UQ== X-Gm-Message-State: AOAM532++VjzQMVqwoiECBwLxjylHB2e06+NFnZ180K8GigB0Viy0XnI MiLje5qxPINDRfQ93ueCEEvf/Rm4UcT5g4uIhJm0QWPOXPI= X-Google-Smtp-Source: ABdhPJxR0j7buluhQ+1Elv5jNmZH8tpseUwuyDqe9yNYLE9NAXrbTUb0LwBpt3TWptazLFlYEj+yX1Xs0wxAlh7f6Fg= X-Received: by 2002:a2e:80cc:: with SMTP id r12mr42775120ljg.344.1594588997072; Sun, 12 Jul 2020 14:23:17 -0700 (PDT) MIME-Version: 1.0 From: Victor Vasiliev Date: Sun, 12 Jul 2020 17:23:06 -0400 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bd575005aa452e91" Archived-At: Subject: [TLS] TLS Cross-SNI Resumption 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 Jul 2020 21:23:25 -0000 --000000000000bd575005aa452e91 Content-Type: text/plain; charset="UTF-8" Hello everyone, As some of you might remember, we've had multiple discussions in the past about letting the clients do session resumption in cases when the SNI value changes, but the original certificate is also valid for the new SNI. Originally we talked about this during TLS 1.3 standardization; the conclusion back then was that resumption across domains is fine in principle, but the extension used to opt into it should be shipped in a separate document. One such document was proposed back in Prague: https://tools.ietf.org/html/draft-sy-tls-resumption-group-00. That draft unfortunately hasn't progressed since; I've tried contacting the author back in March, but got no response. I wrote a draft that does a similar thing: https://tools.ietf.org/html/draft-vvv-tls-cross-sni-resumption-00. This introduces a NewSessionTicket extension, which was the original approach proposed back in PR#777 (draft-sy-tls-resumption-group used CH/SH extension). What do people think about this? Cheers, Victor. --000000000000bd575005aa452e91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

As some of you might re= member, we've had multiple discussions in the past about letting the cl= ients do session resumption in cases when the SNI value changes, but the or= iginal certificate is also=C2=A0valid for the new SNI.=C2=A0 Originally we = talked about this= during TLS 1.3 standardization; the conclusion back then was that resu= mption across domains is fine in principle, but the extension used=C2=A0to = opt into it should be shipped in a separate document.

<= div>One such document was proposed back in=C2=A0Prague:=C2=A0https://tools.ie= tf.org/html/draft-sy-tls-resumption-group-00.=C2=A0 That draft unfortun= ately=C2=A0hasn't progressed since;=C2=A0 I've tried contacting the= author back in March, but got no response.

I wrot= e a draft that does a=C2=A0similar thing:=C2=A0https://tools.ietf.org/ht= ml/draft-vvv-tls-cross-sni-resumption-00.=C2=A0 This introduces a NewSe= ssionTicket extension, which was the original approach proposed back in=C2= =A0PR#777 (dra= ft-sy-tls-resumption-group used CH/SH extension).

= What do people think about this?

Cheers,
=C2=A0 Victor.
--000000000000bd575005aa452e91-- From nobody Mon Jul 13 18:21: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 E00CC3A0D6C for ; Mon, 13 Jul 2020 18:21:49 -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=lowentropy.net header.b=lBgcX0Lx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FbL1w9Nx 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 8xDB6ARy53To for ; Mon, 13 Jul 2020 18:21:45 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF6CB3A0D27 for ; Mon, 13 Jul 2020 18:21:45 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 50E895C01B1 for ; Mon, 13 Jul 2020 21:21:44 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 13 Jul 2020 21:21:44 -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; s= fm2; bh=rymbT1oz2eXAf3cuxzz7vmyITPslJRxmcERl03DO148=; b=lBgcX0Lx CrPAXmAT/voki2K/ZUKF9apzg3Cf++i3wBdbSICbu8o3OhvgmEUoaJNAtuYA9jz7 pA3U83dkZEuGuteL1OYD3SpYPiIgSNzpwvNnt8SMMJtF0KR4OG6XfNLZiGQfWCG7 LKQg3pxnWiKXmoo9EYvt0no8QMg3mDjIGwvVxOvBgRZNt+fO6NoJo+UwyuIO5VLJ WgXyERVxgEWTNZf3bgqGELcVoLTjqZ5gHStmeoAn7pXKDw8uQJDf30tvr+Uh06P7 m47wRHPQem/5IM+E1rGQNTMkuSrmrlUWUCsCfM9DA6ajDg9Rge9qsF6W3ztFvzO6 8VnwUodDOAbqEg== 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=fm3; bh=rymbT1oz2eXAf3cuxzz7vmyITPslJ RxmcERl03DO148=; b=FbL1w9Nxg5eGEA6Nweu3zqZpK/lidTR82gpx/Uk+kZRVW GJnnzHrZBVxk+kFY4uCBvLkeaG4JfRV9taITKSb0rOnlRT/6p2ZVN06hJHbf/IBS c+PeD64UNszCTXb6KsgNIN3EAswwFQftmTUuWttk2zlEIlf34N8S7hjUbrAfI4S/ Y4JXC99Bo6audQ282K3GX/0wjE3Ysc8DzmUBlMP9s8h6c2dNd2hgRmeD5SXBCInl kJNTi4Okf7BElv5tzi3BaoOk44lDAta88JXwwBKfcReqYBe3wUPBPwkn+4oV6sHg z0c/87omUqd+etfbpQkGcS/PFbx3fH2bn2805xW1w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrvdelgdegfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmdenuc fjughrpefofgggkfffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhhtihhn ucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtffrrg htthgvrhhnpeffgeegfeeutdegleehgfdtieffieefteevheelieeliedtgeeuleevuedt teduvdenucffohhmrghinhepihgvthhfrdhorhhgpdhgihhthhhusgdrihhonecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghn thhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id F22BAE00CE; Mon, 13 Jul 2020 21:21:43 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e Mime-Version: 1.0 Message-Id: <60bc7458-c054-4715-aba2-8c4c9393f74d@www.fastmail.com> Date: Tue, 14 Jul 2020 11:21:24 +1000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: [TLS] Authenticating incompatible protocols 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 Jul 2020 01:21:50 -0000 The work in DNSOP on the SVCB record raised a few awkward questions about the potential for downgrade attacks. Where protocols aren't compatible -- that is, A is not compatible with B if you can't attempt A and negotiate B -- you don't get downgrade protection. ALPN only really protects against downgrades with compatible protocols. With QUIC, and increasing diversity of protocol usage across TLS and DTLS, there are more opportunities for incompatible protocols to be used. I've done a quick writeup of something that might work: https://datatracker.ietf.org/doc/draft-thomson-tls-snip/ https://martinthomson.github.io/snip/draft-thomson-tls-snip.html Thoughts would be appreciated. As a footnote: this makes some assumptions about the way that ALPN is used. That is, this relies on the same ALPN not being used in incompatible protocols. The ALPN registry already lists one counterexample in stun.turn [RFC7443] which can be used over both DTLS and TLS. I personally think that was a mistake, but I know that others disagree. From nobody Tue Jul 14 05:42: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 EDA393A0B80 for ; Tue, 14 Jul 2020 05:42:00 -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, RCVD_IN_MSPIKE_H2=-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 C6hTb9ZbfR4N for ; Tue, 14 Jul 2020 05:41:59 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 2BB203A0BE7 for ; Tue, 14 Jul 2020 05:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1594730515; bh=2+QU6iVRvylsvdsVbX279bIJrsYySBV25BLOkgBSqjA=; h=X-UI-Sender-Class:To:From:Subject:Date; b=G7XEqgsB/q/E2tRZauthAIWjyR1kLIjJeBD92h8fQnHAvJHLvvHwX2N/ECNQqwrIf oqPP5JSuPl7vKrujW1X+doud88Vf7f2aNn3PI75bpHH+U2G7ZJhyfurJG2m8DRuZQ/ k914JhWBbFVizW8ThtEFYBIZ6cmscG/I57tSJnso= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([94.216.255.61]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mr9Fs-1kh1c43Epy-00oFCG for ; Tue, 14 Jul 2020 14:41:54 +0200 To: "tls@ietf.org" From: Achim Kraus Message-ID: <5713df9d-b693-ab67-0875-ea8f27bd41b7@gmx.net> Date: Tue, 14 Jul 2020 14:41:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:IXUTkmY32NnXoY6cE0vBiC+nAh92Y1urErFumZlctIhLGhgXRSi Fa5MkVJLYLsTnTqK0OhGaNLh5Gk7ZJQtVpDR1n01++wDccGVqIRr/rvke951t/tv+Ao4yYN amRJpyui5YV1VaTkZo2nfauvZG5kUEADx2/uoDtKonIuRsRyM+eLmBdGs7/9RV6Z7MueRDa o9yT4jcQ2DcuCLg3HTuCw== X-UI-Out-Filterresults: notjunk:1;V03:K0:QH/nOzabz4I=:7+Z3ZgJgnvHf7l2ytdBC7i 3RvNj5mV06WGiQdE7kstULaUHioXUtL8JZfpAeXkwK9iYnUwudmTuJ8qfLSeJBzwxTNG8JhrK Vaizu778+PUUiaV2LHe04mKo+PPT9mmyM/+LP25s5u9+mo/OW4fEO0enjmhrv2Zj1haTXZrB5 +xyipd0ZeDM79QEBNYIQTXokT6Z+U7oM2li4bE8+SPVtmcvxi3IdEqIXVVrJbnb2tGGX7RN0y 1RDZ+lVgN6x54i+vWL3Y83NwB0EvtPvcfQCWHCxz67nT8Om8ylskw44w2Z+G5lpGPUTcMimYj AxBfYtAcKyn56Te9cVbRV0hGj5JWIBDvZAlMqbrwKVGhgly8rNaISPExyI9IWu1p/OWdl+m59 t5hgxf8Qnawlbk71ZmIIs58KFKHIAR6JF2knanESis6c/00IrjliJOuMXj21Vqlli/2C9J6Vv E+vzPwISWfIboZj1OcTKfG2b3H8mdp9jTrG7Qg5F2ojqGn4qrLjcQlrTsFYJ/iP2iaKFkLscA lkF4ZBjUAFIIMeqZTA36gMYH3F3V5JsaX2jK5mIEYjKA/T+CzlRXR6k1jk8+JRTYXFLzJSAyH x0DRf4Lo9WM6sbBRyUMsmO1Dve4E4E9tItGuuDaAssLyB/RGYNGkiR+pRZolA8wB1D/2i+ayo uAq13ITQGO+ZL3N3K8RQ1v0ll1LxKQoP+VEho2ShNSgM6ZotcOm2tusmFDHkDdLb2NQkhTFJ6 z6DiiwNecpjnaWn/8wXc3zhhGNCrTO1/zpyM+nBSIFaNm0KWwWtZn2m3I5vPM6nTn2DENVLET 09sdB+e38Ybwj+hWzh7H5JfAnmzSW8TFNKLy4dMhig4W5WCn6XS9HTpHlWWs7IHNNgwwwKikV qNoU6dNEOvu17PD2PT1qblYPQd8abb2MFg3q0us0Ty/yYhF4L/ffz5xUpTsNooRiqtz1Btupc DzwUTYbE5AbVLl+0bLN16bXEaV76IpOahuILaexfIF/b2G2yFpCKRCjnff9VId/YUh4zrHDNg RvTjxAPb9ED36TBgtPc7irFbveEFv+IrlkChssUqfenzXcyViLIlj1vuxQH2SqZ1xWP38wZoM VJtm628ZLjcsXso50CDsWsl0fe2t/b7SRisgnIJahYs8Y60vGNKLArfMDsYQaf4rePBgDTz0W v0540S+eoQqri4dwsYI3qrMaGywnYSvKgIfq188/3k7wKeRImnUIt80CEsESnVV7QGTxxcOHQ arf1JCihD9RYu8EINR7kyqLMOz5g70PRKlu8RUw== Archived-At: Subject: [TLS] =?utf-8?q?RFC_8449_=E2=80=93_DTLS_1=2E2_considerations?= 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 Jul 2020 12:42:01 -0000 Hello list, implementing a first experimental version of RFC 8449 for DTLS 1.2 in the Eclipse Open Source Project "Californium", I got some doubts about statements, which seems for me to be only applicable, if a API for chunked read/write operations is available. RFC 8449, Section 3, page 4 =E2=80=9CConstraints on record size are often receiver constraints. In comparison, an implementation might be able to send data incrementally. Encryption does not have the same atomicity requirement. Some ciphers can be encrypted and sent progressively. Thus, an endpoint might be willing to send records larger than the limit it advertises for records that it receives.=E2=80=9D That matches pretty well the TCP APIs, which supports a chunked usage (by the cost of resources in the TCP stack itself). I=E2=80=99m not sure, = how this could be applied to UDP. I=E2=80=99m not aware of a =E2=80=9Cchunked= =E2=80=9D API for UDP. A web search also didn=E2=80=99t fill that gap, others seems also to fail = as well. https://stackoverflow.com/questions/15446887/udp-read-data-from-the-queue-= in-chunks So, should that be applicable for UDP? If so, would it be possible to provide some information about the API to be used for that? RFC 8449, Section 4, page 6 =E2=80=9CPMTU governs the size of UDP datagrams, which limits the size of records, but does not prevent records from being smaller. An endpoint that sends small records is still able to send multiple records in a single UDP datagram.=E2=80=9D I would agree, if UDP offers a =E2=80=9Cchunked API=E2=80=9D. Without, all= records must be assembled before passing them to the UDP stack. That would end up in supporting a =E2=80=9Cnegotiated, limited crypto buffer=E2=80=9D and a =E2= =80=9Cnot-negotiated, larger message buffer=E2=80=9D. For me it seems, that an agreement about this message buffer size is still missing. That may be a simple agreement for minimum message buffer size (e.g. 1472 bytes), or a estimated size from this record size limit (but that would cause a conflict with the page 6 and additionally with, RFC 8449, Section 4, page 4, =E2=80=9CUnprotected messages are not subject to this l= imit.=E2=80=9D). So, how do other DTLS implementations deal with that message buffer size? Best regards Achim Kraus From nobody Tue Jul 14 10:42: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 B41ED3A0C5E for ; Tue, 14 Jul 2020 10:42:27 -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 (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 DdXqgPI1AthJ for ; Tue, 14 Jul 2020 10:42:26 -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 68B783A0C55 for ; Tue, 14 Jul 2020 10:42:25 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06EHSb0e009104 for ; Tue, 14 Jul 2020 18:42:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=K8AfqjTiqhulZXjsnnTewvoKdxGEzXdrFU6TiiGpjyw=; b=cNwkwuMdG4FJci3x9txr4Z/cLvt4lHHmZkZCVo8ROB5F7ruPbarSjBN87vYC37Exw334 f9u1VdHxZSYq3V6qXdfZhxx3C/X+RxFNIlWu/n1YFAxgudoUud2KfT3kNL2GzKzJe++x xaoKS5T5ay0bQHdUcV5m/0wknWMxOSm86H/rN+8H8+qyk07jQ/StLK/u6ttj0jMNJZ4/ IDosOKft+JY16G+jmzTLX0z8V7nPg1l7cczcSxRx8pvDteBfA89n7nxf9M1BjR6VJY3J PYZvvTSNrp9g8RD+Ki0MmfyjsX84W8dx3tuAzAVnpVVxNZh16CgSo+7KGpuCujJvBpOm 4w== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 327anen43m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 14 Jul 2020 18:42:24 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06EHZ7SS012879 for ; Tue, 14 Jul 2020 13:42:21 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.116]) by prod-mail-ppoint7.akamai.com with ESMTP id 3278rxqsy1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Tue, 14 Jul 2020 13:42:21 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.165.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 14 Jul 2020 12:42:20 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Tue, 14 Jul 2020 12:42:20 -0500 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: comments on draft-subcerts Thread-Index: AQHWWgYf7lURQ0CEx0qsqH38k+s1qA== Date: Tue, 14 Jul 2020 17:42:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.133] Content-Type: multipart/alternative; boundary="_000_A2E098AE6ACE4999ADF25C1211E70CCBakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-14_06:2020-07-14, 2020-07-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=444 mlxscore=0 suspectscore=0 malwarescore=0 spamscore=0 adultscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007140127 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-14_07:2020-07-14, 2020-07-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 bulkscore=0 adultscore=0 mlxscore=0 spamscore=0 suspectscore=0 clxscore=1015 lowpriorityscore=0 phishscore=0 mlxlogscore=397 priorityscore=1501 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007140128 Archived-At: Subject: [TLS] comments on draft-subcerts 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 Jul 2020 17:42:28 -0000 --_000_A2E098AE6ACE4999ADF25C1211E70CCBakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gbm8gcGFydGljdWxhciBvcmRlci4gTW9zdGx5IG5pdHMuDQoNClNlYyAzLjIsIEkgdW5kZXJz dGFuZCB0aGUgY29uY2VybiBvZiBBQ01FIGJlaW5nIGEgdGhpcmQtcGFydHkgZGVwZW5kZW5jeSwg d2hpbGUgdGhlIG9yaWdpbiBpcyBub3QgcmVhbGx5LiAgUGVyaGFwcyBhIHNlbnRlbmNlIG9mIGV4 cGxhbmF0aW9uIHdoeSBpdCBpcywgd291bGQgaGVscC4gIE9yIG1heWJlIGp1c3Qgc2F5IOKAnHdp dGggYW4gQUNNRSBzZXJ2ZXLigJ0gIEFuZCB0aGVuIG1lbnRpb24gQUNNRSBpbiB0aGUgb3JpZ2lu Pw0KDQpTZWMgNCwgdGhlIOKAnHZhbGlkX3RpbWXigJ0gc2F5cyBNVVNUIE5PVCBleGNlZWQgc2V2 ZW4gZGF5cy4gIFRoYXTigJlzIHJlbGF0aXZlIHRvIGNsaWVudCBhbmQgc2VydmVyIGNvbmNlcHQg b2Yg4oCcbm93LOKAnSByaWdodD8gIFNlZSBub3RlIGJlbG93Lg0KDQpTZWMgNC4xLjEgc2hvdWxk IHNheSB0aGF0IFNpZ25hdHVyZVNjaGVtZUxpc3QgaXMgdGhlIHNhbWUgYXMgdGhlIG9uZSBpbiBS RkMgODQ0Ni4gIEnigJlkIHByZWZlciB0byBzZWUgdGhlIGR1cGxpY2F0aW9uIHJlbW92ZWQuDQoN ClNlYyA0LjIgZG9lc27igJl0IHNlZW0gdG8gYWdyZWUgd2l0aCB0aGUgY29tcGxldGUgQVNOMSBp biBBcHBlbmRpeCBBLiAgVGhlIGxhdHRlciBoYXMgRGVsZWdhdGVkQ3JlZGVudGlhbEV4dG4gd2hp Y2ggaXMgbWVudGlvbmVkIGluIHByb3NlIGFuZCBhIFRCRCBpbiA0LjIgIFBlcmhhcHMgYSBjb21t ZW50IG9yIHNvbWUgb3RoZXIgd29yZHMgdG8gdGllIHRoZW0gdG9nZXRoZXI/ICBPciBkb2VzIHRo YXQgaXNzdWUganVzdCBnbyBhd2F5IHdoZW4gSUFOQSBkb2VzIHRoZSByZWdpc3RyYXRpb24/DQoN ClNlYyA3LjUsIEkgd291bGQgcHV0IHRoZSBpbmNvZ25pdG8gbW9kZSBpbiBhIHNlcGFyYXRlIHBh cmFncmFwaCB0byBjYWxsIGl0IG91dCBtb3JlIGNsZWFybHkuDQoNCk5vdGUgYmVsb3c6DQpJdCBj b3VsZCBiZSBwb3NzaWJsZSBmb3IgdGhlIHNlcnZlciB0byBwcmUtZ2VuZXJhdGUgZGVsZWdhdGVk IGNyZWRlbnRpYWxzIGFuZCBlaXRoZXIgaG9sZCB0aGVtIG9yIGRpc3RyaWJ1dGUgdGhlbS4gSSB0 aGluayB0aGF0IGlzIHdvcnRoIG1lbnRpb25pbmcsIHdpdGggdGhlIGNhdmVhdCB0aGF0IHRoZXkg Y2Fubm90IGJlIHVzZWQgdW50aWwgd2l0aGluIHNldmVuIGRheXMgb2Yg4oCcbm934oCdDQoNClRu eC4NCg0KICAgICAgICAgICAgICAgIC9yJA0K --_000_A2E098AE6ACE4999ADF25C1211E70CCBakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTIuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+SW4gbm8gcGFydGljdWxhciBvcmRlci4gTW9zdGx5IG5pdHMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TZWMgMy4yLCBJIHVuZGVyc3RhbmQg dGhlIGNvbmNlcm4gb2YgQUNNRSBiZWluZyBhIHRoaXJkLXBhcnR5IGRlcGVuZGVuY3ksIHdoaWxl IHRoZSBvcmlnaW4gaXMgbm90IHJlYWxseS4mbmJzcDsgUGVyaGFwcyBhIHNlbnRlbmNlIG9mIGV4 cGxhbmF0aW9uIHdoeSBpdCBpcywgd291bGQgaGVscC4mbmJzcDsgT3IgbWF5YmUganVzdCBzYXkg 4oCcd2l0aCBhbiBBQ01FIHNlcnZlcuKAnSZuYnNwOw0KIEFuZCB0aGVuIG1lbnRpb24gQUNNRSBp biB0aGUgb3JpZ2luPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ U2VjIDQsIHRoZSDigJx2YWxpZF90aW1l4oCdIHNheXMgTVVTVCBOT1QgZXhjZWVkIHNldmVuIGRh eXMuJm5ic3A7IFRoYXTigJlzIHJlbGF0aXZlIHRvIGNsaWVudCBhbmQgc2VydmVyIGNvbmNlcHQg b2Yg4oCcbm93LOKAnSByaWdodD8mbmJzcDsgU2VlIG5vdGUgYmVsb3cuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5TZWMgNC4xLjEgc2hvdWxkIHNheSB0aGF0IFNp Z25hdHVyZVNjaGVtZUxpc3QgaXMgdGhlIHNhbWUgYXMgdGhlIG9uZSBpbiBSRkMgODQ0Ni4mbmJz cDsgSeKAmWQgcHJlZmVyIHRvIHNlZSB0aGUgZHVwbGljYXRpb24gcmVtb3ZlZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNlYyA0LjIgZG9lc27igJl0IHNlZW0g dG8gYWdyZWUgd2l0aCB0aGUgY29tcGxldGUgQVNOMSBpbiBBcHBlbmRpeCBBLiZuYnNwOyBUaGUg bGF0dGVyIGhhcyBEZWxlZ2F0ZWRDcmVkZW50aWFsRXh0biB3aGljaCBpcyBtZW50aW9uZWQgaW4g cHJvc2UgYW5kIGEgVEJEIGluIDQuMiZuYnNwOyBQZXJoYXBzIGEgY29tbWVudCBvciBzb21lIG90 aGVyIHdvcmRzIHRvIHRpZSB0aGVtIHRvZ2V0aGVyPyZuYnNwOw0KIE9yIGRvZXMgdGhhdCBpc3N1 ZSBqdXN0IGdvIGF3YXkgd2hlbiBJQU5BIGRvZXMgdGhlIHJlZ2lzdHJhdGlvbj88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlNlYyA3LjUsIEkgd291bGQgcHV0IHRo ZSBpbmNvZ25pdG8gbW9kZSBpbiBhIHNlcGFyYXRlIHBhcmFncmFwaCB0byBjYWxsIGl0IG91dCBt b3JlIGNsZWFybHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5O b3RlIGJlbG93OiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SXQgY291bGQgYmUgcG9zc2libGUgZm9yIHRo ZSBzZXJ2ZXIgdG8gcHJlLWdlbmVyYXRlIGRlbGVnYXRlZCBjcmVkZW50aWFscyBhbmQgZWl0aGVy IGhvbGQgdGhlbSBvciBkaXN0cmlidXRlIHRoZW0uIEkgdGhpbmsgdGhhdCBpcyB3b3J0aCBtZW50 aW9uaW5nLCB3aXRoIHRoZSBjYXZlYXQgdGhhdCB0aGV5IGNhbm5vdCBiZSB1c2VkIHVudGlsIHdp dGhpbiBzZXZlbg0KIGRheXMgb2Yg4oCcbm934oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij5UbnguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgL3IkPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A2E098AE6ACE4999ADF25C1211E70CCBakamaicom_-- From nobody Tue Jul 14 11:51: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 E436D3A08A9 for ; Tue, 14 Jul 2020 11:51:17 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 TQSGQbnlM8x7 for ; Tue, 14 Jul 2020 11:51:15 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3763A09D6 for ; Tue, 14 Jul 2020 11:51:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A4CA7300B79 for ; Tue, 14 Jul 2020 14:51:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id k92nKFof-xVU for ; Tue, 14 Jul 2020 14:51:10 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 72BA6300AA6; Tue, 14 Jul 2020 14:51:10 -0400 (EDT) From: Russ Housley Message-Id: <0E6AD5FA-69AB-4BB0-ABE3-F1BAEE9DA1C7@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_94D38963-EFE0-4FFB-8247-AA1190908139" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Tue, 14 Jul 2020 14:51:11 -0400 In-Reply-To: Cc: IETF TLS To: "Salz, Rich" References: X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [TLS] comments on draft-subcerts 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 Jul 2020 18:51:23 -0000 --Apple-Mail=_94D38963-EFE0-4FFB-8247-AA1190908139 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Rich: > Sec 4.2 doesn=E2=80=99t seem to agree with the complete ASN1 in = Appendix A. The latter has DelegatedCredentialExtn which is mentioned = in prose and a TBD in 4.2 Perhaps a comment or some other words to tie = them together? Or does that issue just go away when IANA does the = registration? I do not see a problem. =20 DelegatedCredentialExtn is the name of the module, and the OID that goes = with it will be assigned by IANA in the future. id-ce-delegationUsage is the OID that defines the X.909 certificate = extension. in Section 4.2 and Appendix A, this is assigned under the = Cloudflare PEN arc as { 1 3 6 1 4 1 44363 44 }. Russ --Apple-Mail=_94D38963-EFE0-4FFB-8247-AA1190908139 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Rich:

Sec 4.2 doesn=E2=80=99t seem to agree with the = complete ASN1 in Appendix A.  The latter has = DelegatedCredentialExtn which is mentioned in prose and a TBD in = 4.2  Perhaps a comment or some other words to tie them = together?  Or does that issue just go away when IANA does the = registration?

I do not see a problem.  

DelegatedCredentialExtn is the name of the module, = and the OID that goes with it will be assigned by IANA in the = future.

id-ce-delegationUsage is the = OID that defines the X.909 certificate extension.  in Section 4.2 = and Appendix A, this is assigned under the Cloudflare PEN arc as { 1 3 6 = 1 4 1 44363 44 }.

Russ


= --Apple-Mail=_94D38963-EFE0-4FFB-8247-AA1190908139-- From nobody Tue Jul 14 12:38: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 F0A133A09D8; Tue, 14 Jul 2020 12:38:01 -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 (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 f-FHjTK0CNWB; Tue, 14 Jul 2020 12:38:00 -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 82C003A09D3; Tue, 14 Jul 2020 12:38:00 -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 06EJb2kg014201; Tue, 14 Jul 2020 20:37:59 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=J3QfzzYNDYhSKbQJBlLaPsLJAWzIr4dc3hSud5fZc6o=; b=G90WTw3M3lpVQ1mbqjkleUpfCMIqft8Ojlk7M51sLs0JG63akNu3wfeJWlspQpNhgN2i Roi6+6rInnd/jF0Vnkp8qCLr9adMfIWkygFSNcshewaa3E2CxbPt//L1qShd4qd56GmW V3vcLycTOCtiw2iMFi1pxCu5NpkAISuZO11j5yWuGkHqj8CzLDbflDRUJMgnwxTs9LgY sGX7Wa5sOz3C7WJZTUZKLSPWNtssfRjhrTkBPHUaPduholjm+4L4MhmvvfRvhqBNe/ld HF5nJ/jTqfb7iazGawKhwb48Lb/NUYhPFCV8sYLEIUoTlseWqlDc4LB3wTBlufoMGSHx sA== Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 327a6jbcqb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Jul 2020 20:37:59 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06EJ5200012263; Tue, 14 Jul 2020 15:37:58 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.112]) by prod-mail-ppoint4.akamai.com with ESMTP id 3278ry093h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 14 Jul 2020 15:37:58 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.165.123) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 14 Jul 2020 14:37:58 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.006; Tue, 14 Jul 2020 14:37:57 -0500 From: "Salz, Rich" To: "Salz, Rich" , "tls@ietf.org" Thread-Topic: [TLS] comments on draft-subcerts Thread-Index: AQHWWhZG7lURQ0CEx0qsqH38k+s1qA== Date: Tue, 14 Jul 2020 19:37:57 +0000 Message-ID: <881F2E57-A39D-42B6-8BC1-61D3917AA993@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.133] Content-Type: multipart/alternative; boundary="_000_881F2E57A39D42B68BC161D3917AA993akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-14_08:2020-07-14, 2020-07-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 malwarescore=0 adultscore=0 mlxlogscore=724 spamscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007140134 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-14_08:2020-07-14, 2020-07-14 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 malwarescore=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 spamscore=0 suspectscore=0 mlxlogscore=685 adultscore=0 impostorscore=0 clxscore=1015 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007140138 Archived-At: Subject: Re: [TLS] comments on draft-subcerts 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 Jul 2020 19:38:02 -0000 --_000_881F2E57A39D42B68BC161D3917AA993akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBsb3ZlIHRvIHNlZSBhIHNhbXBsZSBjZXJ0IGFuZCBwcml2YXRlIGtleSBpbiDigJxQ RU0gZm9ybWF04oCdIGFuZCBzYW1wbGVzIG9mIHRoZSBUTFMgZXh0ZW5zaW9ucyBlbmNvZGVkLCBv ciBldmVuIGEgc2ltcGxpZmllZCBoYW5kc2hha2UgZHVtcC4NCg== --_000_881F2E57A39D42B68BC161D3917AA993akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPkkgd291bGQgbG92ZSB0byBzZWUgYSBzYW1wbGUgY2VydCBhbmQgcHJpdmF0ZSBr ZXkgaW4g4oCcUEVNIGZvcm1hdOKAnSBhbmQgc2FtcGxlcyBvZiB0aGUgVExTIGV4dGVuc2lvbnMg ZW5jb2RlZCwgb3IgZXZlbiBhIHNpbXBsaWZpZWQgaGFuZHNoYWtlIGR1bXAuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_881F2E57A39D42B68BC161D3917AA993akamaicom_-- From nobody Tue Jul 14 12:51: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 66E943A0A85 for ; Tue, 14 Jul 2020 12:51: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, DKIMWL_WL_HIGH=-0.001, 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=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 u8k7IqioEPAt for ; Tue, 14 Jul 2020 12:51:36 -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 08FAA3A0A7B for ; Tue, 14 Jul 2020 12:51:35 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id o38so13833355qtf.6 for ; Tue, 14 Jul 2020 12:51:35 -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:content-transfer-encoding; bh=b/GQAW9i3bP/BgL/MvBtDwjEXCJa0G9eLorO4IJ9BYY=; b=J88bFIiPZNL9ch3GKPQiWUJzQWezgQei6UxVJefDMFI/g1znJ+hXkr7dus5zXXopEG OhfeAqI9zf9zkuPaHg3oZUy76/sMkX5JfE18AR5zYQdD28GrQXUpGWQ712wY1NezGXQ+ qbylvqtUrcB5YwM8m9EF1kd95vaPk6dwyF3Nk= 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=b/GQAW9i3bP/BgL/MvBtDwjEXCJa0G9eLorO4IJ9BYY=; b=KWEHpMI850DUgoS6ewVUrucXvXw6wIx2YgxBxlR1Mjl2KvE9Z2LQy93EoZuXE72do1 L7XbrpPD+DoShrg5/6N7djfAILU1UXbJk3xRPE/aJABrSuPbDUcpNpYH39cxC8ctzpHD CCs7aAvRqF2/yZgcy4sD2zfBnGnaEvKXzu/4Qsi77qOU1x/pUsymg6WmWmtShV+lL1Oc UsQAvQUmR6FZt4rrgJKyVje1jVPnWNGTlVO8Dd0k65uujmpq5v5i/0YWnJSFAFTk6JPM gBxZqXDne+jFRgz1OPhkDTgoRtvwXv1m4NIPK+cPfyIxTRAevCvoFtL7gEyzlzMWaUTx WqxQ== X-Gm-Message-State: AOAM531YUi7/4mWG/pxsFXSSS4fJppBPqWYyYa2h730P0dzAEDNebais GZo0ya9JeV+Vn+uQM1/660h3xwYrCUrRV5KNeCIy/g== X-Google-Smtp-Source: ABdhPJyQFvLNbjevQR2wZpsxANXrbLrYkD0ePt3sq1Dn6n48K0RcVAQqAwqmDtCBj8q60MiND3EID1ezC5mDUM9FIX0= X-Received: by 2002:aed:3fac:: with SMTP id s41mr6410516qth.86.1594756294936; Tue, 14 Jul 2020 12:51:34 -0700 (PDT) MIME-Version: 1.0 References: <881F2E57-A39D-42B6-8BC1-61D3917AA993@akamai.com> In-Reply-To: <881F2E57-A39D-42B6-8BC1-61D3917AA993@akamai.com> From: Watson Ladd Date: Tue, 14 Jul 2020 15:51:24 -0400 Message-ID: To: "Salz, Rich" Cc: "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] comments on draft-subcerts 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 Jul 2020 19:51:37 -0000 On Tue, Jul 14, 2020 at 3:38 PM Salz, Rich wrote: > > I would love to see a sample cert and private key in =E2=80=9CPEM format= =E2=80=9D and samples of the TLS extensions encoded, or even a simplified h= andshake dump. https://github.com/tlswg/tls-subcerts/pull/77 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jul 14 14:05: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 9A9743A09C0 for ; Tue, 14 Jul 2020 14:05: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, NICE_REPLY_A=-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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=wizmail.org header.b=JFWNMY1r; dkim=pass (2048-bit key) header.d=wizmail.org header.b=keqWKrHT 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 hDvKYJ2BQlLM for ; Tue, 14 Jul 2020 14:05:30 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (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 A3E243A09A4 for ; Tue, 14 Jul 2020 14:05:30 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org; s=e202001; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:Autocrypt:From:References:To:Subject :From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type :Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=EuocDoNWA0C+nbF/rUZaiLbIh6XwEO3eW/Y93aaN0lY=; b=JFWNMY1rpRVqgHCf/8fJFJHmMe M5yH6iNcVwqbUxZfIYqyCZvhCOv4HjQ9XDXdFkv/cSZwfv8RprYSXAD5/jDQ==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r202001; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:Autocrypt:From:References:To:Subject:From:Sender :Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive:Autocrypt; bh=EuocDoNWA0C+nbF/rUZaiLbIh6XwEO3eW/Y93aaN0lY=; b=keqWKrHTFuBzY4IRMVmtchEk+g W9yijKCyaGetudRu1HqeD+Hdjq6rEpG+Z0aF7d1SnbgPF7UXbK77jH0D7eacXqPZSnh7UKqpEzTWw yd7K9r9dSIBhQUPh1vYMV5jpRcP7cU5d6IyiyugShcVQW7v35iXvyiqFVMKgtiHzE1qLBaDefuE/s 118WvThRhgLbramShXjqz5Ou1ELbDWV35n4TXJGvlOkqJwJ1snGfUeNK+rlmorww3uO6dlfbuFXnT d1yTDV2uYXUtm2WF1Z99xKaS08NGEEwNBdh/SNYfPOYGvoQa07Ps3rO2RiOhr+gEXVqXg6UflBzYA rrNJUM0Q==; Authentication-Results: wizmail.org; iprev=pass (vgate18.wizint.net) smtp.remote-ip=2a00:1940:107::1:2f:0; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) by wizmail.org (Exim 4.94.102) (TLS1.3) tls TLS_AES_128_GCM_SHA256 with esmtpsa id 1jvS7C-00ARrI-AK for tls@ietf.org (return-path ); Tue, 14 Jul 2020 21:05:26 +0000 To: tls@ietf.org References: <20200708042223.GB20623@akamai.com> <20200708150752.GL3100@localhost> From: Jeremy Harris Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= mQENBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAG0JkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+iQFOBBMBCAA4FiEE qYbzpr1jd9hzCVjevOWMjOQfMt8FAl4WMuMCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQvOWMjOQfMt946ggAvqDr2jvVnGIN2Njnjl2iiKyw4dYdFzNhZgjTaryiV90BftUDxRsB uTVFUC6XU+B13MEgSK0zRDyI5NpEH+JTW539gWlmz2k2WTTmoBsm/js1ELoAjGr/i32SByqm 0fo3JPctn/lc7oTo0muGYvB5xWhTHRlcT9zGTRUb/6ucabVLiJUrcGhS1OqDGq7nvYQpFZdf Dj7hyyrCKrq6YUPRvoq3aWw/o6aPUN8gmJj+h4pB5dMbbNKm7umz4O3RHWceO9JCGYxfC4uh 0k85bgIVb4wtaljBW90YZRU/5zIjD6r2b6rluY55rLulsyT7xAqe14eE1AlRB1og/s4rUtRf 8LkBDQRVgAbEAQgA6YSx2ik6EbkfxO0x3qwYgow2rcAmhEzijk2Ns0QUKWkN9qfxdlyBi0vA nNu/oK2UikOmV9GTeOzvgBchRxfAx/dCF2RaSUd0W/M4F0/I5y19PAzN9XhAmR50cxYRpTpq ulgFJagdxigj1AmNnOHk0V8qFy7Xk8a1wmKI+Ocv2Jr5Wa5aJwTYzwQMh4jvyzc/le32bTbD ezf1xq5y23HTXzXfkg9RDZmyyfEb8spsYLk8gf5GvSXYxxyKEBCei9eugd4YXwh6bfIgtBj2 ZLYvSDJdDaCdNvYyZtyatahHHhAZ+R+UDBp+hauuIl8E7DtUzDVMKVsfKY71e8FSMYyPGQAR AQABiQEfBBgBAgAJBQJVgAbEAhsMAAoJELzljIzkHzLfTegH/Aktgk6zEBXYZBhLQV5i+Inw /FBxZAUQRpjPGS9n1lAU2V0/Jq3UTDiurXD5ylmgr1ryq9JJ7fe9I/w8gIBZh/IYDot8nLYo BXnFQ444pQHgiTKt/LNbWCmIiw2wXR1rXZAPbh2cKt5X3d0MXBBDt0GpkBfnTu4fIADl5Rvq aPOx5vhNMM+LMCAfPkt+yc68fbrtC0hQ3yQkyvkyChmuVJ/C8T8cqvVp5zQ4e9syuwYkYnZP 7ONCnDaHfNzTOB5/7Gxn8i2vLEtBdzBNEvqHEjDorv2RxzosKS2DW8Eye7LWcRrK4Llnk/T/ mpsWwP2JSveS3nbLcLzflnB2e3fvgK65AQ0EXiRPygEIAMP9Z2LRciWF8OoKUbcnA50W0U60 zTBvb7IMm0Rfaeb+s5vk0bX6Hel8i7dxmQvy0yUBrQq/9NYa90MOcm54b9oETtKHcoe63U3i iZc62ERe5dRIr9EG1DAN3SW5fRc5H234mskCdl06ftOJCsXLL1enbunWF8WYQpn8hzsoQqzs klloqd24z8c/+3C5cPjI26hyGFR0W5Q1T8xBMqxgc5W0smyyqDdDs/H1VXrxfQdculDXkM3B EUkeZMsyT7Q8jr8qHv13T1dPCyObP4wXkaOSEtOcBAeF2B1TUVUEhqPzXbG6+oZWgVUKWB8o oHReboJUCkQC8jAIZrr9xpgCMPMAEQEAAYkBPAQYAQgAJhYhBKmG86a9Y3fYcwlY3rzljIzk HzLfBQJeJE/KAhsMBQkB4TOAAAoJELzljIzkHzLfjg4IAM2GxIUaXLfO22z2JWS3byFvfRNS eXLZx2cDokn8AGpzTY+k5mcCkOQVUUz9MuxM50VnrRuBaeH++LfzSghKRWLx2PdJlKzThyFi y23NagSwx4i/R2J8xiPtajZm5SS3slEg1pt3NhgDkkrTQUTHYcf4F0O3YgdoqGKR7m10jqXz gzwQE65Pb0QUX5clxy55oV1pXoq1qjELIYVH9aS8bpI0RE86axHwpOvG4cQrMWZ0tg1txwZ/ DSstczlx7/Ptxfdd+A0x27UhS7ijUuqXx/z8Vh7U/oj/lsVERXyxuUgojD5kkagRLURuYBef CxJ/k6RTKs8juRsbVGfJMmNdfyK4OAReJFQPEgorBgEEAZdVAQUBAQdAPr/8EgFM8AkB/CZz +BGJIezPAdpTYFLvRhsem2GoBicDAQgHiQE8BBgBCAAmFiEEqYbzpr1jd9hzCVjevOWMjOQf Mt8FAl4kVA8CGwwFCQPCZwAACgkQvOWMjOQfMt99PAgApNBPoJog4UKuiP4YP4vvntA4etz8 z7WzVU4uI2ep7++qEaZOafHlSaUILaGag4CSh7KmxrTUjtoJNeX2qx5AQ4pdlNIjMy/V/Z+z 8gJ5vQ3tXglN4P7S6ud6mYKzpGHCvNF2CdzSRa2DRizCy6+sHOrDiH5V7veKE+9LjF+aB9lw PYLeF6Dh4idnxIa3aVwQjAAn3NBYAuhymnqgLgWcrPNaiSP6VIrsu4aCCoeIuc7bCFks6hrR x805g1J6uxixrMu2bW+AbPpRObi5B0pTJhDaLBW1xQgOiwYIAdyu0H2YNMrCBsA0w40UWEIz xrAkJFP/CS+qkjMI47FKq1EzbQ== Message-ID: Date: Tue, 14 Jul 2020 22:05:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200708150752.GL3100@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: vgate18.wizint.net ([2a00:1940:107::1:2f:0] helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [TLS] invariant or not: one TLS connection per TCP connection? 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 Jul 2020 21:05:33 -0000 On 08/07/2020 16:07, Nico Williams wrote: > On Tue, Jul 07, 2020 at 09:22:24PM -0700, Benjamin Kaduk wrote: >> There's an interesting note in draft-ietf-nfsv4-rpc-tls-08 (currently >> in IESG Evaluation): >> >> The protocol convention specified in the current document assumes >> there can be no more than one concurrent TLS session per TCP >> connection. This is true of current generations of TLS, but might be >> different in a future version of TLS. >> >> Can we envision wanting to do such a thing (e.g., with connection IDs for >> non-D TLS)? If not, I can give them guidance that this type of statement >> is not needed. > > I can see an application that starts TLS in a TCP connection, ends TLS > without also ending the TCP connection, then starts TLS again. But > multiple concurrent TLS connections in one TCP connection? I don't see > that happening. Maybe with DTLS, but they are using TLS. I would just > remove the above paragraph. Devil's advocate: It would let one overlap the command phase of a second smtp message transfer while the previous was committing the end of data-phase - and still get congestion-control fate-sharing and TCP buffer sharing. Without either complexifying SMTP-level pipelining, invoking TCP-CC state copying, or use of SCTP/QUIC. Mind, I'd not want to implement it. Or any of them. -- Cheers, Jeremy From nobody Tue Jul 14 14:56: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 415C73A07D1 for ; Tue, 14 Jul 2020 14:56:28 -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 Ml_VXg9eQUl8 for ; Tue, 14 Jul 2020 14:56:26 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81CC3A07D0 for ; Tue, 14 Jul 2020 14:56:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 58450300B5B for ; Tue, 14 Jul 2020 17:56:24 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id D97ODSsVQG9D for ; Tue, 14 Jul 2020 17:56:23 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id E35303005C6; Tue, 14 Jul 2020 17:56:22 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Russ Housley In-Reply-To: Date: Tue, 14 Jul 2020 17:56:24 -0400 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: References: <881F2E57-A39D-42B6-8BC1-61D3917AA993@akamai.com> To: Watson Ladd X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [TLS] comments on draft-subcerts 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 Jul 2020 21:56:28 -0000 Watson: This does not look right to me. The extensions in the certificate are: extensions=3DExtensions: Extension: extnID=3D2.5.29.15 critical=3DTrue extnValue=3D0x03020780 Extension: extnID=3D2.5.29.37 critical=3DFalse extnValue=3D0x300a06082b06010505070301 Extension: extnID=3D2.5.29.19 critical=3DTrue extnValue=3D0x3000 Extension: extnID=3D2.5.29.17 critical=3DFalse extnValue=3D0x300687047f000001 Extension: extnID=3D1.3.6.1.4.1.44363.44 critical=3DFalse extnValue=3D The last one should have a value of 0x0500. Russ > On Jul 14, 2020, at 3:51 PM, Watson Ladd = wrote: >=20 > On Tue, Jul 14, 2020 at 3:38 PM Salz, Rich > wrote: >>=20 >> I would love to see a sample cert and private key in =E2=80=9CPEM = format=E2=80=9D and samples of the TLS extensions encoded, or even a = simplified handshake dump. >=20 > https://github.com/tlswg/tls-subcerts/pull/77 From nobody Tue Jul 14 15:53: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 405583A09AD for ; Tue, 14 Jul 2020 15:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, RCVD_IN_DNSWL_BLOCKED=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 D4OjseHAy_OV for ; Tue, 14 Jul 2020 15:53:54 -0700 (PDT) Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450: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 C97A73A09AC for ; Tue, 14 Jul 2020 15:53:53 -0700 (PDT) Received: by mail-wm1-x332.google.com with SMTP id 17so1542134wmo.1 for ; Tue, 14 Jul 2020 15:53:53 -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 :cc; bh=/VrXbUgWZd6sRHoC9CDFQQ4yK6kaIe7p1PMRCT8Z5Dg=; b=LTuyNUG+8h3mSNMuNl3dS0GqROozgjlOPZUnYWmhsjD+Jjyn/7o2LSgGlzPzFF9I6O 1q79lteejH7bThjW6HtkHv07OSMl2d4FzuHIKaUTwj2Fn9PHvHkRVoFoeU0CCjgIsB1b cZV8ha2nYMd7B/V1UbxNQBCFrZwb8+2l/iOqrSza9iE6ak9i8m7/3il9xZpcqvD8hPF1 LsySqf3twdZ0rSocqqUraOLSVYnQthKqsRHqiGQ1jfwUmhIHfbuUa1ke5VqiTZ2SzHqS GpsAf2TJ7KZN4jrIyl6ILZ3ZA4HH5IQzyzaj63GxrIm+peRTSaI7xUsty5tLcMd2mA1O ii0A== 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=/VrXbUgWZd6sRHoC9CDFQQ4yK6kaIe7p1PMRCT8Z5Dg=; b=ggB+cjxwKAmwpv8DSJDJXxCGa3zgJctghZtXVY2+LCxaLAJpwBNhsRZ175mtuqGsOF Qf+2KeqEXE7cuj6TB9Y4cjStW6OoDTgxAPW/rx/ToWjNdoaOjNcg+NiJarYE62JBnZcB Em2tNtRAmXH29yQE8N+ShhyQtc6vrCh8ISHMXQIctC/uYGaluO1ESXJeRpPQG4PnNQPe ERzWNMShpk/9TY9gEL+2uJkQlldHsFAt2syvaLhCy2BIsInvNTZZdijo2isJpafNjQF4 VQ093LeQJPN7M8RAps0HlC5G1TzCmy7G74DftYfo5wIUFrDl+kmymeZETE7DzTyj/Nyb K27w== X-Gm-Message-State: AOAM531jOoe4YDZDxqVBg9NEsRWd5UUH+NsVeo0wv4GTej5eifuyG6S4 kvUTiAeagl58aSx4macS69SzYvIQCdQ20kPoHcrbjJqF X-Google-Smtp-Source: ABdhPJxyllz3cGIOmEct0sjc+S0tpb7z80BjYpAD+RkmhI4yhHRnP6t0VOvh+Sny3oy0teBmBoAu/X4SeBFJ3hgOm0g= X-Received: by 2002:a1c:6246:: with SMTP id w67mr5715410wmb.42.1594767231919; Tue, 14 Jul 2020 15:53:51 -0700 (PDT) MIME-Version: 1.0 References: <60bc7458-c054-4715-aba2-8c4c9393f74d@www.fastmail.com> In-Reply-To: <60bc7458-c054-4715-aba2-8c4c9393f74d@www.fastmail.com> From: Ben Schwartz Date: Tue, 14 Jul 2020 18:53:40 -0400 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000006300c305aa6eaecb" Archived-At: Subject: Re: [TLS] Authenticating incompatible protocols 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 Jul 2020 22:53:56 -0000 --0000000000006300c305aa6eaecb Content-Type: multipart/alternative; boundary="0000000000005c169f05aa6eaec4" --0000000000005c169f05aa6eaec4 Content-Type: text/plain; charset="UTF-8" I am supportive of this draft. I don't think it's needed now, but eventually I would like to live in a world where we don't have to tolerate these kinds of downgrades, and I don't think it's too early to be drawing up the mechanism to prevent them. For ease of deployment, I wonder whether the concept of a "scope" needs to be pinned down a bit more precisely. In 00 here, the scope is entirely implicit; servers are required to know how users might have found them, and what other servers they also might have found at the same time. That seems like it could be a management headache, especially if clients reach your server in more than one way. Could the scope be made more explicit instead? For example, it might be helpful if the server could say "this IP (and port number?) can also do FOO and BAR, and the whole SVCB pool can do FOO (but I don't know if they can all do BAR)". On Mon, Jul 13, 2020 at 9:22 PM Martin Thomson wrote: > The work in DNSOP on the SVCB record raised a few awkward questions about > the potential for downgrade attacks. Where protocols aren't compatible -- > that is, A is not compatible with B if you can't attempt A and negotiate B > -- you don't get downgrade protection. ALPN only really protects against > downgrades with compatible protocols. > > With QUIC, and increasing diversity of protocol usage across TLS and DTLS, > there are more opportunities for incompatible protocols to be used. > > I've done a quick writeup of something that might work: > > https://datatracker.ietf.org/doc/draft-thomson-tls-snip/ > https://martinthomson.github.io/snip/draft-thomson-tls-snip.html > > Thoughts would be appreciated. > > As a footnote: this makes some assumptions about the way that ALPN is > used. That is, this relies on the same ALPN not being used in incompatible > protocols. The ALPN registry already lists one counterexample in stun.turn > [RFC7443] which can be used over both DTLS and TLS. I personally think > that was a mistake, but I know that others disagree. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000005c169f05aa6eaec4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am supportive of this draft.=C2=A0 I don't think it&= #39;s needed now, but eventually I would like to live in a world where we d= on't have to tolerate these kinds of downgrades, and I don't think = it's too early to be drawing up the mechanism to prevent them.

=
For ease of deployment, I wonder whether the concept of a "= scope" needs to be pinned down a bit more precisely.=C2=A0 In 00 here,= the scope is entirely implicit; servers are required to know how users mig= ht have found them, and what other servers they also might have found at th= e same time.=C2=A0 That seems like it could be a management headache, espec= ially if clients reach your server in more than one way.=C2=A0 Could the sc= ope be made more explicit instead? For example, it might be helpful if the = server could say "this IP (and port number?) can also do FOO and BAR, = and the whole SVCB=C2=A0pool can do FOO (but I don't know if they can a= ll do BAR)".

On Mon, Jul 13, 2020 at 9:22 PM Martin Thomson <<= a href=3D"mailto:mt@lowentropy.net" target=3D"_blank">mt@lowentropy.net= > wrote:
The = work in DNSOP on the SVCB record raised a few awkward questions about the p= otential for downgrade attacks.=C2=A0 Where protocols aren't compatible= -- that is, A is not compatible with B if you can't attempt A and nego= tiate B -- you don't get downgrade protection.=C2=A0 ALPN only really p= rotects against downgrades with compatible protocols.

With QUIC, and increasing diversity of protocol usage across TLS and DTLS, = there are more opportunities for incompatible protocols to be used.

I've done a quick writeup of something that might work:

https://datatracker.ietf.org/doc/draft-thoms= on-tls-snip/
https://martinthomson.github.io/snip= /draft-thomson-tls-snip.html

Thoughts would be appreciated.

As a footnote: this makes some assumptions about the way that ALPN is used.= =C2=A0 That is, this relies on the same ALPN not being used in incompatible= protocols.=C2=A0 The ALPN registry already lists one counterexample in stu= n.turn [RFC7443] which can be used over both DTLS and TLS.=C2=A0 I personal= ly think that was a mistake, but I know that others disagree.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000005c169f05aa6eaec4-- --0000000000006300c305aa6eaecb Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAH8qNflD4Mi9yKttXfRdHcwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDA2MDUwODIyMjhaFw0yMDEyMDIwODIyMjhaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kbyV9S0YLplF3kV 6t3GgD7IyHe8L29pJ7l+UR0Sj31uPgXOFdSSdTVwhPfQvxmB2OUDXWDgDtZdL2xu4DgHhrDyyOXT 8uDJqUCPw004ZSuUfUor1vz5u6+oYNfx2OTPTb81vtsQO2/khni3iAeQlKgO/rUI1c9+zvT6k3mR SZUypAlk/rCyG6NV7NMJMmOaU20/kPBXG297iP8+/F9w4xs+lyb3IkcSfoSUr3fVz7mYqESFato5 JnjRQGT2/f/ehxkc09jATqVGj9nyQMoD2GNPjiNnYyTVBwK5Ol/s9+E2VSL4TSLrgS2R07kY9zPi VOM3lhDDRnceboNSaqnfMwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUwJS1fB3cBxoLgZFatdIO9Vp5wOcwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQCC91PBn9rMxo8kSo1zNY2mxkTQDTVc0oyYk8s3y72y21IEp/d/+h1H VTCD2FR30aFUv8hTJkebJ5Z1/zue2L7sx/lLEOIHm9uYxyTkTWbKup3+XrE1vhODTHVx+ktMuOTY z447/fwjy4praSaFrQsOjTPbAoU6xuC8S2j2K2Yg6XQsctcKHKeAJjN6evZYChDaTBLmtYq9LTSH KVv3Et795vNK3gWKjhEkJtaBu4FfKLoopb1PENJ/zK6p/3edCLFgCRMSlbQ0SGtdVESSJcgezSwW WK2VB1Zcj2kyVzcL1pmV8m1xQuz2aBgUMn7peoVxKxYKP12gMtzeMvkzltYBMYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhAB/KjX5Q+DIvcirbV30XR3MA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCCIPxe8U3vlecM0EF1Jkv1eM/QwnCH/9VQf2ECBknpxEzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3MTQyMjUzNTJaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAFxED6e9QuwUO6af/hhUqIQu2GEIvGumMJwxvR/pLS9yYGrvaK7paouObIoW0gbsl04qVKj4g 2g7Gxtm5ip/udtmsE7HF50Sb8+jhPNitcrCvKl2qcebW5rfaQeHQ9IVW5ODB+F/ClpakakI2RvGI ZLomSiY/u5qmoTbdLuAus+tc7w5Ar0IJxkWFKgfK0IltkCkMd5MievMCyzo/MfjEBq0jGGIugpsT nuODf7D/044Sjr54MwawC9ZoVFl7uaq7/+9JjoPHrnWBX33IDUE/lQaAr4WDAcrwYPJrPyh/qun0 /UA2jpTEQXmeKHgYpXWLKGZbBU6Y5lKj1qxqdOBt2w== --0000000000006300c305aa6eaecb-- From nobody Tue Jul 14 23:25: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 A76A73A0978 for ; Tue, 14 Jul 2020 23:25:30 -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=lowentropy.net header.b=LqYbeHKj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cenhDYki 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 t7DhEboGYIVj for ; Tue, 14 Jul 2020 23:25:29 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 618043A0972 for ; Tue, 14 Jul 2020 23:25:29 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id AAF4D5C0190; Wed, 15 Jul 2020 02:25:28 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 15 Jul 2020 02:25:28 -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=Ew5GkAluwEa/YXjm/m+AHtdRRgjq R9cvyky41080XoQ=; b=LqYbeHKjfwtMh3YrTzOg3RaiiFuhFlkBuANcPjX3sN/N D8IwMCLsIlsXJvIi0wb0O1gw16/UTbbuL6Gi6DArG5LhDLhTVV5iO1F6qXd5gegs zvaj/jl28NwZIfm7eLg7WB/wPWJHmt293No3mk/kkMYT4lxQlIfDEVsNILqsp4UM sqaYbR08+q/afZxPJRSZgdGcm7OiwifCoU2XNwtbQpdKeVv3/+497wYDDA0MQNUV zJxhzyq1CpvjnzQPUHp41nI0UyUBV1F2BlHh5GvAjV8S4SA0mRGVf2uknQXri3jE LH5YEnJEx8TJcgxKuHns01YpDF0JpsBoacwyxNagSA== 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=fm3; bh=Ew5GkA luwEa/YXjm/m+AHtdRRgjqR9cvyky41080XoQ=; b=cenhDYkinJUi+z3D23Fnm6 klUmgy/wZ9UjiQzxcFDL6NmTssmGwZCBWi9yCcE4mReKaju99WvzCSXz2Cr1Y2Uu GXidZKIn5ImqDSN3303Ims5mR3FaGNjgwoAXG3p/MfpDP6LLHBpwA1UsYdLHXNLL 8IBTMJYzGVnjDFHYsQrCbScju3j/JFgHnLI+RxdHtcy4jopN1wP7Pvo91CD7yc61 rHWpdutQc4xweZm6lhx9wWBlkj/z/xH41xQ53iAkro36C0EgqbFUdLiudNWWk6yR nugMYJrMvxvCy4uyXtqeKgRrcSFqEEOOwGqonchB9O8b71DrCDKpf8chIGO86tiA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfedugddutdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 617DCE00C1; Wed, 15 Jul 2020 02:25:28 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e Mime-Version: 1.0 Message-Id: In-Reply-To: References: <60bc7458-c054-4715-aba2-8c4c9393f74d@www.fastmail.com> Date: Wed, 15 Jul 2020 16:25:08 +1000 From: "Martin Thomson" To: "Ben Schwartz" Cc: "" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Authenticating incompatible protocols 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, 15 Jul 2020 06:25:31 -0000 On Wed, Jul 15, 2020, at 08:53, Ben Schwartz wrote: > For ease of deployment, I wonder whether the concept of a "scope" needs > to be pinned down a bit more precisely. In 00 here, the scope is > entirely implicit; servers are required to know how users might have > found them, and what other servers they also might have found at the > same time. I don't think that it is that bad. It is more that server operators need to understand that the ways in which they advertise the availability of their service interacts with what is deployed. That is, you need to configure discovery methods and your TLS stacks with the same information (though your TLS configuration can be more conservative in terms of advertising a subset of what can be discovered, so that deployments can be staged). Right now, that means that if you use SVCB, you should configure your TLS stack to authenticate that. This might eventually include QUIC versions as well - once that is sorted out - but that won't require the same sort of coordination. The problem with more detailed indications is that it requires far more configuration. The TLS stack doesn't just need to know that FOO is available, it needs to know where. As that is usually the business of the DNS provisioning more than the TLS configuration, I'm concerned that you would get out of sync too easily. From nobody Tue Jul 14 23:41: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 3A2223A0B0E for ; Tue, 14 Jul 2020 23:41:32 -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=lowentropy.net header.b=mz898L8r; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Z5kFTaTH 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 ZUh30iKebf4b for ; Tue, 14 Jul 2020 23:41:31 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDF23A0B03 for ; Tue, 14 Jul 2020 23:41:30 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 4E8415C00E8 for ; Wed, 15 Jul 2020 02:41:30 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 15 Jul 2020 02:41: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 :subject:content-type; s=fm2; bh=Enc2t9aSX48mgOgNe/1l6J0m4X1g0/b x2JblkZuXdfY=; b=mz898L8rRaJy9OGp1aUaPRNH1IZ/yyfsK9pgEIxaQkgG14w 1l0W4sm23NEUhHgUa02YRcXZjc3lU5dYRRePvcB+A4W/+MyPSmtnB9BplYoNkqkx nECWIGgyuEtHUuey1fG+7dxsVhUITMO0Gg5sY+4+7sxCtiZFYksVlZwazE2p8cC7 aiLWGGcD2yEiQWQxDEWIthxae2QH7XvJ3HW95JLMX+/F2gmLCVQgluayYsH8cLw1 BdYwiqhp6HqEV/BtE8IAXmzJ+xzOpj5tBzgn7N4nM5orSvt+seNc7YH1WfptO06i 7bRp1Nfn/igreZ8kxHP2Htje2E2HrRyQds9vIbA== 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=fm3; bh=Enc2t9 aSX48mgOgNe/1l6J0m4X1g0/bx2JblkZuXdfY=; b=Z5kFTaTHSdzY5Pl5A3P88w FRaylLivsgUyD42tkpjmPy6XEmoPiQViptvnmidQKiMXgXZGjsybLNIWsBYJUzfr 3ifjQk3OI/SLENX0lBlEjEJRfUrh15cqZRYHqrM5xWAxkgR143e7V0zQXQetmsWX p33vm0u/oV0D550SiHfR1Lgj5OVADLFylVSF149yQShkuq+aCphM2McHEmie8ffW Ep7NvgzCqpZ5xxUBQi/sSYCLO0nqC3vayzMhpTeiLhBAmsaCz97LsshrKuc3Nh92 oX2VBvBi1HjwS4UZqzzr7swuKoCf2Ac2AaWxzpAer1bAOhOL5LknVs+BtQPtMZyA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfedugdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeehfeetudduudehtdekhf dvhfetleffudejgeejffehffevkeduiefgueevkeefleenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D4CFCE00C1; Wed, 15 Jul 2020 02:41:29 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e Mime-Version: 1.0 Message-Id: In-Reply-To: <5713df9d-b693-ab67-0875-ea8f27bd41b7@gmx.net> References: <5713df9d-b693-ab67-0875-ea8f27bd41b7@gmx.net> Date: Wed, 15 Jul 2020 16:41:09 +1000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] =?utf-8?q?RFC_8449_=E2=80=93_DTLS_1=2E2_considerations?= 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, 15 Jul 2020 06:41:32 -0000 On Tue, Jul 14, 2020, at 22:41, Achim Kraus wrote: > For me it seems, that an agreement about this message buffer size is > still missing. This is a question we dealt with in QUIC by limiting UDP datagram size rather than the record size (or packet size in QUIC terminology). In this case, the spec doesn't really say the most helpful thing about UDP datagram size in DTLS. Indeed, you might say that pointing to the ability to include multiple records per datagrams is an invitation to do bad things. After all, a receiver that receives a datagram that is too large for it likely has to drop it or only process part of it. The partial processing is possible if there are small records, but it does lead to lots of losses. The way I would approach this is to send one record per datagram in DTLS, no matter what the spec says. (NSS implements this spec, but does not assume any limits, it only respects a limit set by a peer. For DTLS it sends one record per datagram, outside of the handshake.) Assuming that you do have a constrained implementation that can't receive large datagrams, then we probably need different signaling. But there are workarounds. If you start receiving large UDP datagrams, then it is possible to drop those and hope that your peer has some sort of PMTU discovery (NSS has something, but it is crude). At that point, the size of datagrams is limited as though it were a path limitation. That likely gets you down to the minimum MTU for the IP version you are using. For IPv6, that's not so different from the 1400-odd that you describe, but IPv4 - and therefore some implementations - might go as low as the IPv4 minimum MTU. (FWIW, NSS will go as low as a 228 byte MTU, which is pretty extreme. And it takes a lot of failed retransmissions to get that low. I wouldn't expect that small an MTU from other implementations.) All that said, if you have a size constraint smaller than a typical UDP MTU, then you have a very constrained implementation. Not being able to spare ~1k but expecting to do TLS is something I struggle to comprehend. From nobody Tue Jul 14 23:42: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 6C7923A0B12 for ; Tue, 14 Jul 2020 23:42:33 -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=lowentropy.net header.b=DcUilCji; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nbirXyjI 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 saAadTOC0_dk for ; Tue, 14 Jul 2020 23:42:32 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD1F3A0B0E for ; Tue, 14 Jul 2020 23:42:32 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 53DCD5C00E9 for ; Wed, 15 Jul 2020 02:42:31 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 15 Jul 2020 02:42: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=fm2; bh=qT1wQ1EMYbX3dHQo9sjks44b4WmiDtv U2pqJK9lSGnU=; b=DcUilCjiTbBtbeNCm8yoRzSVY/JHUjCzqw0omcNI0ItzsIv xIrwpMnwA5xpAL9aVE20RxhrrhLqwegwo32r5JRidSDWQAE4AKHWNgBmDlYJDYx3 RZi5XBY/OtwLmwxiJMMKg+RzuReuU5twflfErY5YyngA7+I6sFi7KL8m6/myYn6w uW/aQatpJz+OAFcT9wEI39NSydxt7a+D3cKIpUA/0PwTTiU9ZoXOiM1hZK/Ycehf xhrhGf7w7cBUhj8xUYsaNTDxPr0EErYuB43G0SfF8hBjasSHP7leUEWYPKeGwVzy y1aCFktP0jLkUo79hhvGus6O6rq6A7Hp1bUJqaw== 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=fm3; bh=qT1wQ1 EMYbX3dHQo9sjks44b4WmiDtvU2pqJK9lSGnU=; b=nbirXyjI/XPsNQiJ7idEA+ EgoP1aEW9L0rtYBcBQ4tOhhhcFdHw/8SXhn5dfMXvSK5tAAo6t/SPNhZzMTTxKYS 6nhtWU+/hHLSWE2g4O/VZhf4rL/yTv5BhRjHlCVO11dzzQhcZNmp9UDlw1NFc6Lx wOEjx9BL4B/cv13kItii95C8f/Z75CHtjDc/8F61LmMUQYG+B2oSy51bpGvFXkLS AeYsnOGt4OLlJUqE66IeBaRHRVB8N308iBJJst7Kuad4K6Ekykf4I8w7KCJA9c3J 64K2AtJijsK5++rkqWhATWOetg1rLiuFHWg6AjBlJexbxb9SJR7DQNFuGX3bn9IQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrfedugdduuddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 187DEE00C8; Wed, 15 Jul 2020 02:42:31 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-613-g8a73ad6-fm-20200709.001-g8a73ad6e Mime-Version: 1.0 Message-Id: In-Reply-To: <20200708042223.GB20623@akamai.com> References: <20200708042223.GB20623@akamai.com> Date: Wed, 15 Jul 2020 16:42:10 +1000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] invariant or not: one TLS connection per TCP connection? 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, 15 Jul 2020 06:42:33 -0000 On Wed, Jul 8, 2020, at 14:22, Benjamin Kaduk wrote: > Hi all, > > There's an interesting note in draft-ietf-nfsv4-rpc-tls-08 (currently > in IESG Evaluation): > > The protocol convention specified in the current document assumes > there can be no more than one concurrent TLS session per TCP > connection. This is true of current generations of TLS, but might be > different in a future version of TLS. > > Can we envision wanting to do such a thing (e.g., with connection IDs for > non-D TLS)? If not, I can give them guidance that this type of statement > is not needed. Are we forgetting HTTP CONNECT in HTTP/2? From nobody Wed Jul 15 13:52: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 24A9D3A0820 for ; Wed, 15 Jul 2020 13:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BMlDrhh9SEuz for ; Wed, 15 Jul 2020 13:52:49 -0700 (PDT) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 7F7AC3A0805 for ; Wed, 15 Jul 2020 13:52:49 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id f18so7502211wml.3 for ; Wed, 15 Jul 2020 13:52:49 -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 :cc; bh=cxyZ+Juimui8Ik3E5v5kU/0Otwd3NGrChq/AJAycb7Q=; b=h9n51cDNu71bZ5AVBjoJ4smrE8v53bRsuUhdi5uhFHPCjswXfrgHY3Oj1Par42cX/Q NKjWMDb51PzbUXkbYGqb0EyL8hi/im1lMa8Ui1Hswc3XjzOswsc4/EPQehQHgHnzA92+ GwQMpm+IG5gAgEu7B/zn2UH3NhS4GsubS1JU01KUGVmSYpqoioE10bsY+d8idTRMkyyn 9IJa9tOp1EVB6Xa3RrFoXkqZ52lSxXkjVRbJvf48NnbE/g0syvn1QUaF1iibNvT69RWY N5DnIoyRUIsJYtqp92WYUQfH5nv5UYsb9mCjF1y7u3LgzvTvELY6IgWPOL40JfX7Wlnm k4hQ== 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=cxyZ+Juimui8Ik3E5v5kU/0Otwd3NGrChq/AJAycb7Q=; b=RivwMVHmU3NxzaRVtcSmUmNjKQdTKMYVNyKBJQR9heauXFuEoxkrpYCUJJFcQnRDSQ TN7PXUtj3abVRyVYUW7Mj9Pc3mGJkqOTcS8WNboXNb6Gb2yi33Tu8LCwfELyK11pah0r 6dJlP7HSu7nbNNal8duUzsY5864MLrP3fVeAH/IRWZBrz3Y0ULxL1gBWh/h56qz9S2U9 wPicA9SQ4ecQkJUxo+YUUYzSN6IhWELr+5y4kEGxPg3wr8ArlTO2cIBpzXnAElK7976Q 3MyfOnhhfcIeHqYuESzqGmpgdDNXFBMJJh/s/6CxPC7FZO5pThris2pRa4+jJOa67YO4 IZVg== X-Gm-Message-State: AOAM530C9LaPEFBPsWik788k2TuhgZeNEZslE4vv2JFVTMmsuqE7Q2Bh VnXGbQEne0iFwu1iCsKxMI/Xi1FU4j2xf5oRh/HXv3KS X-Google-Smtp-Source: ABdhPJwOIlU9G62mgNS8255Tz1zZxHA2fume9VzwFdt+vEmlrNbGBSITB7BO37bqtHPbU4hsNQSDaaNNXK/ajmeYe+g= X-Received: by 2002:a7b:c3c7:: with SMTP id t7mr1225263wmj.97.1594846367659; Wed, 15 Jul 2020 13:52:47 -0700 (PDT) MIME-Version: 1.0 References: <60bc7458-c054-4715-aba2-8c4c9393f74d@www.fastmail.com> In-Reply-To: From: Ben Schwartz Date: Wed, 15 Jul 2020 16:52:35 -0400 Message-ID: To: Martin Thomson Cc: "" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000003f38bb05aa811b4f" Archived-At: Subject: Re: [TLS] Authenticating incompatible protocols 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, 15 Jul 2020 20:52:51 -0000 --0000000000003f38bb05aa811b4f Content-Type: multipart/alternative; boundary="00000000000037ab0a05aa811bfc" --00000000000037ab0a05aa811bfc Content-Type: text/plain; charset="UTF-8" On Wed, Jul 15, 2020 at 2:25 AM Martin Thomson wrote: ... > you need to configure discovery methods and your TLS stacks with the same > information (though your TLS configuration can be more conservative in > terms of advertising a subset of what can be discovered, so that > deployments can be staged). If there are multiple ways to reach your server (multiple applicable scopes), you have to be even more conservative: you can only advertise the _intersection_ of supported protocols from all possible scopes. The ClientHello doesn't tell the server which scope the client has. Basically, I think this draft should probably either name the scope or be specific to SVCB, to avoid cases where the scope is ambiguous. Naming the scope, and providing a scope identifier meaning "IP and port number", would often be sufficient for secure QUIC upgrade without SVCB, at the cost of some conceptual complexity. --00000000000037ab0a05aa811bfc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 15, 2020 at 2:25 AM Martin Thomson <mt@lowentropy.net> wrote:
...=C2=A0
you need to configure discovery methods and your T= LS stacks with the same information (though your TLS configuration can be m= ore conservative in terms of advertising a subset of what can be discovered= , so that deployments can be staged).

If th= ere are multiple ways to reach your server (multiple applicable scopes), yo= u have to be even more conservative: you can only advertise the _intersecti= on_ of supported protocols from all possible scopes.=C2=A0 The ClientHello = doesn't tell the server which scope the client has.

Basically, I think this draft should probably either name the scope o= r be specific to SVCB, to avoid cases where the scope is ambiguous.=C2=A0 N= aming the scope, and providing a scope identifier meaning "IP and port= number", would often be sufficient for secure QUIC upgrade without SV= CB, at the cost of some conceptual complexity.
<= div>
--00000000000037ab0a05aa811bfc-- --0000000000003f38bb05aa811b4f Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAH8qNflD4Mi9yKttXfRdHcwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDA2MDUwODIyMjhaFw0yMDEyMDIwODIyMjhaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kbyV9S0YLplF3kV 6t3GgD7IyHe8L29pJ7l+UR0Sj31uPgXOFdSSdTVwhPfQvxmB2OUDXWDgDtZdL2xu4DgHhrDyyOXT 8uDJqUCPw004ZSuUfUor1vz5u6+oYNfx2OTPTb81vtsQO2/khni3iAeQlKgO/rUI1c9+zvT6k3mR SZUypAlk/rCyG6NV7NMJMmOaU20/kPBXG297iP8+/F9w4xs+lyb3IkcSfoSUr3fVz7mYqESFato5 JnjRQGT2/f/ehxkc09jATqVGj9nyQMoD2GNPjiNnYyTVBwK5Ol/s9+E2VSL4TSLrgS2R07kY9zPi VOM3lhDDRnceboNSaqnfMwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUwJS1fB3cBxoLgZFatdIO9Vp5wOcwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQCC91PBn9rMxo8kSo1zNY2mxkTQDTVc0oyYk8s3y72y21IEp/d/+h1H VTCD2FR30aFUv8hTJkebJ5Z1/zue2L7sx/lLEOIHm9uYxyTkTWbKup3+XrE1vhODTHVx+ktMuOTY z447/fwjy4praSaFrQsOjTPbAoU6xuC8S2j2K2Yg6XQsctcKHKeAJjN6evZYChDaTBLmtYq9LTSH KVv3Et795vNK3gWKjhEkJtaBu4FfKLoopb1PENJ/zK6p/3edCLFgCRMSlbQ0SGtdVESSJcgezSwW WK2VB1Zcj2kyVzcL1pmV8m1xQuz2aBgUMn7peoVxKxYKP12gMtzeMvkzltYBMYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhAB/KjX5Q+DIvcirbV30XR3MA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCCRRnvLaGD9jKUqjvK6JoOBtgM8ddDG/n8v7UwphMQ7NjAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3MTUyMDUyNDhaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEABMZ2v0vDN/JHm1UCwQtWXdcI+6mjxTePQIg7LSGmBq1oTwMBTTKQUxTeRLhJz66kLwsjMtEC yq1IZ+x64RyX8fzt13Ng3rXjg7jgTvXkkRaokA1X75R4fzvxEaTkgBSk0bsM+/XsSnjoyUh1cBwa sEKtRUOqZGE2/hofN+rDGDU0uB8kkb0q4uuoKEIBpq8+sHl1bDsL8k6JYkosGvgIUs5Xad6Wfrd4 v+FVBkC7pzgviARfKEn3T4/aaAdVSNpIamUNJ7SqBUDWUrQjgU+tYRAN3Nx/MXpJwQXUjYXChZWK 30gy/R+BWs0c4p2pDTgK85+zoZIoYXJ7F/OORbo+wQ== --0000000000003f38bb05aa811b4f-- From nobody Thu Jul 16 00:28: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 92F773A1028 for ; Thu, 16 Jul 2020 00:28:28 -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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 60PoqDcu5QAR for ; Thu, 16 Jul 2020 00:28:27 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 8CB753A1027 for ; Thu, 16 Jul 2020 00:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1594884501; bh=PnSscWlEiVtvJlUolIBbEvAqKi8FjrhQRcDr+73psrY=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=T7MEAmHCwPj9BqTNHOItw6scJ60dNLtwj7Elm/XNFnCWlcc7d9rJ63f1xgZj+OmGP Ips9hM8pzIWw4mWZdORU+u4vcgewovLSwHBddusbjfDI5lAszZZ4uEg+6p5rxhJxjp QJ5gfzt4WrOjiO8PaxVIqqlOw/rZJ1qYDtPGeo+I= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([88.65.148.93]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MCsPy-1k4o1F1OW8-008v1f; Thu, 16 Jul 2020 09:28:21 +0200 To: Martin Thomson , tls@ietf.org References: <5713df9d-b693-ab67-0875-ea8f27bd41b7@gmx.net> From: Achim Kraus Message-ID: <65876716-f4b2-82c7-24b6-dd759a52dd54@gmx.net> Date: Thu, 16 Jul 2020 09:28:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-AT-frami Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:cel6VvMkGkE8R1yydG0X1HpcqI58+hTv+x6e2FFW1NwshgaQ8tU VYlLic1P6ZjTxtVNTKobY+dGu2VQH4mFRsYOEtgH99sGir82HeSfbtfsO9idIzoSr6cj6OV cFWp71CBB9TudH82wow0YjpGw53+Ouw1rnuGcefrs+g+3i1AOOyyfWuFC80HfqNqVb+qXOC Y1oaklUorsKVRNdI1p9vw== X-UI-Out-Filterresults: notjunk:1;V03:K0:1CVG8mAV0Wg=:Ydw96mRc1nTbJXmlsLC1zx ZMWIqvHtaZmZgJHxRmQSaQUFMiu18MHYR3B6sFPxlXA5gR1vN704tL9B2BS7sftSGdIWwvhyH gdDZ98o9jbsVGkwXEwZgcIbTl55Ggo/QeF0T0wGZHH6ycPZP8kNUG9qsop0CXbd10RzoDx/o4 QXfSJVYtnC1On6zK/UDBOZW3X5fCTCWDQYEU/5rCCYhrMx7pQOtEqIosM+g79mZu0gt5skK/x W3aAIZPkGBHSJcklPIC0z5ADQNfdEpVbHfcQbfhGEVRrIf0eJxLVNtCQaorf2LRdyuN1ykruc O+xWAihGAwAVuDs8bfXDIh8lUexL5FtDQVy8cG9LQr0kHA1c/L69R+JIlGQ/g+d0V+LlD+iSD pP7sjSplkooWwVoa/RVEPB4Zkaxe8mVC+SPyGIJweg2dng6QRMWhGTLxWtH9lJhJHuoynb2w2 uT2W2k1mJxoYvyYprVEJF2R0AGLkzLnJz6r6aRW1dkHlnWrEJD75P9GUCrxJaeQIceb5bP5aX igSmHW/K4wdTopzSfd7CzRz27fYzzv6Wqt61ZgNWuJouTJnYNJMNmNDr0LlrpJjV6l5k7NlTf hn8RbgI6Oyv7zD0bjX+2qBMpSpiaB1AXtrZpbw2iXfP3ZbJ9tSn4DhsmXoCnIxa6/BAdoZS9N T/Syjh8bos3rmRJLU+sy0Wjj2Jh8lMZqhtiUnupqwtJEOR5rnNajC2bWVFt/Mlz0X7MlUIG6u g9MYrKyikvxsNIV6pYsZT0oN/n1LfTA36Z5bOibV3lL8QhcBh5eYA/3pNS/s7jA0hvzKZU2vk c0ZLsVjDq5zzi9w45/wsYrnSr9XswErjxUTTbwIggmfnlGWr1YAbpm0xHidlvH6ci+AWsXstP O1u5IAbklIlrdih9GsVUg9BThVO7yLzL4lzBq83eH3Wir9VHa5uKsQA+7//ivAB1dDnqM46Lm pbZHCs18oDpgj0Y4c/hEJHn0a6gaWLXREmavyrfvWrH887wWMRTzcq/8ruy+JdjJPP4O9GX/a x/9xImXQAMxy1B5WPuB2T7+V70R80+B7TvPI1QFZ/sN/lbEPw3+0o31+8jhvb3RTN0LbFKhEg LJocrpHqE8bIKrXXUADbgsIyXFi4dJuW/62QVuWm3ruLqQHi3ZQz9v4KCKvEeQIIRA0qFXU8r 0cdovo6CFgJL2o5bFot6Rj5Q+s9+5cIxUc6Vj3nJ7S4OGRjyxWRQRkv+y2luN362YpzpKa7rK UWrovaka+dxUh4+p3GEkzhAbp3kWihgYDQKcanQ== Archived-At: Subject: Re: [TLS] =?utf-8?q?RFC_8449_=E2=80=93_DTLS_1=2E2_considerations?= 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, 16 Jul 2020 07:28:29 -0000 Hello Martin, thanks a lot for your answer! That helps very much to overcome my UDP confusion :-). best regards Achim Am 15.07.20 um 08:41 schrieb Martin Thomson: > On Tue, Jul 14, 2020, at 22:41, Achim Kraus wrote: >> For me it seems, that an agreement about this message buffer size is >> still missing. > > This is a question we dealt with in QUIC by limiting UDP datagram size r= ather than the record size (or packet size in QUIC terminology). > > In this case, the spec doesn't really say the most helpful thing about U= DP datagram size in DTLS. Indeed, you might say that pointing to the abil= ity to include multiple records per datagrams is an invitation to do bad t= hings. After all, a receiver that receives a datagram that is too large f= or it likely has to drop it or only process part of it. The partial proce= ssing is possible if there are small records, but it does lead to lots of = losses. > > The way I would approach this is to send one record per datagram in DTLS= , no matter what the spec says. > > (NSS implements this spec, but does not assume any limits, it only respe= cts a limit set by a peer. For DTLS it sends one record per datagram, out= side of the handshake.) > > Assuming that you do have a constrained implementation that can't receiv= e large datagrams, then we probably need different signaling. But there a= re workarounds. > > If you start receiving large UDP datagrams, then it is possible to drop = those and hope that your peer has some sort of PMTU discovery (NSS has som= ething, but it is crude). At that point, the size of datagrams is limited= as though it were a path limitation. That likely gets you down to the mi= nimum MTU for the IP version you are using. For IPv6, that's not so diffe= rent from the 1400-odd that you describe, but IPv4 - and therefore some im= plementations - might go as low as the IPv4 minimum MTU. > > (FWIW, NSS will go as low as a 228 byte MTU, which is pretty extreme. A= nd it takes a lot of failed retransmissions to get that low. I wouldn't e= xpect that small an MTU from other implementations.) > > All that said, if you have a size constraint smaller than a typical UDP = MTU, then you have a very constrained implementation. Not being able to s= pare ~1k but expecting to do TLS is something I struggle to comprehend. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Jul 17 16:31: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 BA80B3A0B44 for ; Fri, 17 Jul 2020 16:31: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 OI_q2FM4uLD2 for ; Fri, 17 Jul 2020 16:31:29 -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 928553A0B43 for ; Fri, 17 Jul 2020 16:31:29 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id g26so153707qka.3 for ; Fri, 17 Jul 2020 16:31:29 -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=RVHPHQz3q5pCH7yExmB14at++1/bJEWHQlC9fX1niYo=; b=LZvc2tZjMluv325N9UZWIg41iguRTOAtDg78EIwla8qxI6WqQHkD24FKLZ7JZDCfAM 9dY7zMIPEdZ4G/d3eDWGjjY0k6LShkyPrW2OH8Y7R9B+VDSSB+gSO4xL19SQEVteC63O sUBii943UyVl2MF4O+P5E/tcXhIXPS7pBe1gk= 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=RVHPHQz3q5pCH7yExmB14at++1/bJEWHQlC9fX1niYo=; b=f0AoNgOv11jxcU8zfpsAoxMj8OuwL2A4dqsEypJThysVbO/NqzTX/y/VNkMYMmrkzC CO3X7Y1lLA5MG6WiuZNhlB+lG5MUTCDemstMgMzAL0lKFxLhadd4wFdKokb5T0qU9uG0 P5J/c8G2KO9sd5lWwTHZfKQewTu+IUY4Iw3uwt93rhG9dhYQZc2HKunHOJ0mgNXMNdhE asrO96rkyfKWDvD4JmnzI2aTcQiPwTC3zOY2sjzNZBaDsDIeQJo7XOY3D66IjximMn65 v3P8J/0MiLZoWht7SHOHfdx6NeoyAFfi8KbsUv+AS7JhOYFzXI6LlcR3xEoB0orLVIr+ xbDw== X-Gm-Message-State: AOAM531iDD8+KVmMmf22GM+YSonhIiS+iJXMZNZ1U/nCuwFt5tOfoPHi izYhhkDZpvMgPCyAqDsUUJgYlx4NsZY= X-Google-Smtp-Source: ABdhPJwxg+WpCBhmvJhBBC4UBRqbV24eQ99GoQfGC5jBb21C+kIqjla7wOuc3+wVDaRGQ2bBvb3+EQ== X-Received: by 2002:a37:4249:: with SMTP id p70mr10947995qka.496.1595028688004; Fri, 17 Jul 2020 16:31:28 -0700 (PDT) Received: from [5.5.33.203] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id j72sm1031568qke.20.2020.07.17.16.31.26 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jul 2020 16:31:26 -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.120.23.2.1\)) Message-Id: <2F330A3C-B80B-4FB4-94DC-B60BBFE2A0C6@sn3rd.com> Date: Fri, 17 Jul 2020 19:31:25 -0400 To: TLS List X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [TLS] TLS@IETF108: Agenda Topics / Mea Culpa 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, 17 Jul 2020 23:31:31 -0000 Apologies for sending this request at this late. It is entirely my fault = for dropping this ball. The TLS WG will be meeting virtual for IETF 108 on Tuesday 2020-07-28 @ = 14:10 UTC for 1 hour and 40 minutes. The chairs would like pull together = an agenda and to help us get a better handle on how to arrange our = session please send in your agenda requests to tls-chairs@ietf.org. = Along with your request please provide an estimate for how much time you = will need. Please note that we will prioritize existing WG items. Sean= From nobody Fri Jul 17 16:54: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 0FB093A0BDD for ; Fri, 17 Jul 2020 16:54: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, 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=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 pWDBYuxQf7b5 for ; Fri, 17 Jul 2020 16:54:41 -0700 (PDT) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 67CC33A0BDA for ; Fri, 17 Jul 2020 16:54:41 -0700 (PDT) Received: by mail-qv1-xf2c.google.com with SMTP id t11so5017569qvk.1 for ; Fri, 17 Jul 2020 16:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:mime-version:subject:message-id:references:to:date; bh=iqQ0qFxRbcg2Olcg+4rUxBTUv/1KNMrMXUC4e1loLrY=; b=JXOWhCxwIj4ruRbwq8bVZmoyfMChzerHDsa69rHcW8k3E2+ZTBTf7eV63Y1JK7I/5D byDw/bTqollgxV5yC2vY3HMsJcFFlnTI5PrlSK5HF7iUnxu/ou5X++8uDSpAYS22poi0 qA/Zi/5CRL9WC5jZ5mrtvTCXTNEhKxDHjbL60= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=iqQ0qFxRbcg2Olcg+4rUxBTUv/1KNMrMXUC4e1loLrY=; b=c6PodQ6Qrw99wNmRZPpnDrhtd2x2mVK0Ins82f5DlvxfUYRhqCNCo8vl0tiE0dHRqq uxsXS0ySVDHnxQla4kdH/h8Gstzafgbev6Onu0z/NFr9vc4MS5aIdGXzpryc4l5D597k sMaKkqLSijrf3YeBKI3cPtvfKP1FGiVlVsaklwnkJAhvc1j4J/02K2ZYSlaWr0a0Swhl dX15OnszeH/iKaSxyuaP8MsWF/lRCdmWAlyCc5HsAQREMunLRcRoGNadT57+uDT3FGo/ lzfssq+hwlNuDrDODLex9i6VM2AIK+InfViI16b7n+qmCGWry6pjCJyGNNoezIo0y5I4 W6Eg== X-Gm-Message-State: AOAM5336m0c64bT/jgX5aLr4wV3kV72/nark+zA3SXk6dIKi5WBY9Zns ea+9KR2/ZEJG6s37bZQIfnVtTMgrW3c= X-Google-Smtp-Source: ABdhPJxLFreql0JlGouwYGfU8b3tHuJ9lkVb6HCzZTWJryTIe130sEF2E+H1rAC+PJ/Y7feRoDCoOw== X-Received: by 2002:ad4:5483:: with SMTP id q3mr10891764qvy.99.1595030079915; Fri, 17 Jul 2020 16:54:39 -0700 (PDT) Received: from [5.5.33.203] ([204.194.23.17]) by smtp.gmail.com with ESMTPSA id f18sm13374265qtc.28.2020.07.17.16.54.38 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Jul 2020 16:54:39 -0700 (PDT) From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_94459FD9-08F1-43E9-85D3-8D1FC0B62D54" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <48365B9B-DCFE-4A47-9C74-9601B067899F@sn3rd.com> References: <437DEDB1-5C00-4ECC-994D-1111021458A8@ietf.org> To: TLS List Date: Fri, 17 Jul 2020 19:54:37 -0400 X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [TLS] Fwd: [108all] Reminder about IETF 108 Online test sessions 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, 17 Jul 2020 23:54:43 -0000 --Apple-Mail=_94459FD9-08F1-43E9-85D3-8D1FC0B62D54 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FYI - some useful info for IETF108. > Begin forwarded message: >=20 > From: Greg Wood > Subject: [108all] Reminder about IETF 108 Online test sessions > Date: July 14, 2020 at 19:11:09 EDT > To: 108all@ietf.org >=20 > Hello, >=20 > Meetecho will be the main conferencing platform for the IETF 108 = Online meeting. >=20 > Test sessions for meeting participants have been scheduled for: >=20 > =E2=80=A2 16 July 2020, 1200 UTC > =E2=80=A2 17 July 2020, 0000 UTC > =E2=80=A2 17 July 2020, 1500 UTC >=20 > Each session is scheduled to last about an hour. Sessions will = include: >=20 > =E2=80=A2 a tour of Meetecho features and controls; > =E2=80=A2 demos of capabilities such as queue management, hums, = and presentation sharing; and > =E2=80=A2 plenty of time for discussion and questions. >=20 > Test sessions will be recorded and shared in advance of IETF 108. >=20 > You are encouraged to review the IETF 108 participant guide, which has = links to the sessions and further details: >=20 > https://www.ietf.org/how/meetings/108/session-participant-guide/ >=20 > Also, Gather.town will be available as a = platform for social interaction during the IETF 108 meeting week. = Details are being finalized and will be shared ahead of the meeting. In = the meantime, a test session has been set up at: >=20 > https://gather.town/iCbv26xgBvGPhlyR/ietftest > with the password: Test108!=20 >=20 > This won=E2=80=99t be covered in the Meetecho sessions, but you are = encouraged to try it out as well. >=20 > Sincerely, >=20 > -Greg >=20 >=20 > -- >=20 > Greg Wood > ghwood@ietf.org > +1-703-625-3917 >=20 > --=20 > 108all mailing list > 108all@ietf.org > https://www.ietf.org/mailman/listinfo/108all --Apple-Mail=_94459FD9-08F1-43E9-85D3-8D1FC0B62D54 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 FYI = - some useful info for IETF108.

Begin = forwarded message:

From: = Greg Wood <ghwood@ietf.org>
Subject: = [108all] Reminder = about IETF 108 Online test sessions
Date: = July 14, 2020 at 19:11:09 = EDT
To: = 108all@ietf.org

Hello,

Meetecho will be the main = conferencing platform for the IETF 108 Online meeting.

Test sessions for meeting participants have been scheduled = for:

=E2=80=A2 16 July 2020, 1200 = UTC
=E2=80=A2 17 July 2020, 0000 = UTC
=E2=80=A2 17 July 2020, 1500 = UTC

Each session is scheduled to last about = an hour. Sessions will include:

=E2=80=A2 = a tour of Meetecho features and controls;
=E2=80=A2 = demos of capabilities such as queue management, hums, and presentation = sharing; and
=E2=80=A2 plenty of time for = discussion and questions.

Test sessions = will be recorded and shared in advance of IETF 108.

You are encouraged to review the IETF 108 participant guide, = which has links to the sessions and further details:

https://www.ietf.org/how/meetings/108/session-participant-guide= /

Also, Gather.town = <https://gather.town> will be available as a platform for social = interaction during the IETF 108 meeting week. Details are being = finalized and will be shared ahead of the meeting. In the meantime, a = test session has been set up at:

https://gather.town/iCbv26xgBvGPhlyR/ietftest
with the password: Test108!

This = won=E2=80=99t be covered in the Meetecho sessions, but you are = encouraged to try it out as well.

Sincerely,

-Greg

--

Greg Wood
ghwood@ietf.org
+1-703-625-3917
--
108all mailing list
108all@ietf.org
https://www.ietf.org/mailman/listinfo/108all

= --Apple-Mail=_94459FD9-08F1-43E9-85D3-8D1FC0B62D54-- From nobody Sun Jul 19 10:35: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 76D303A0400; Sun, 19 Jul 2020 10:35:00 -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 (2048-bit key) header.d=juniper.net header.b=ULby5BBA; dkim=pass (1024-bit key) header.d=juniper.net header.b=j0yv9EEv 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 D3fjbE_Ioipv; Sun, 19 Jul 2020 10:34:59 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 E84C13A03FF; Sun, 19 Jul 2020 10:34:58 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06JHYw9E026684; Sun, 19 Jul 2020 10:34:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=8bDhosOTn4pq34xWQTRMgqjH3vkvTIaMzk162H9cJbI=; b=ULby5BBADUDXA5ryjL33FX/Xl+BChCoBrl5tDNRy9x1in5KGidlixBzZu+zKmDHmJ5yD euJeTn3V0a86Zar5rC16ZZIuUCaeoJz9sMw0opRh3urRFF5mDguetDA0odBv5M+NVlRC duxCP27/ALgEZH/Hhn02LBKIMrgUubTU77rAycCIm53311zWQQCOeXul0ZdYx8zA9bVN 2sacXmAJu1rGIz776ocNNfPvbUYSZpxb2doFRj3YFb3BsceIYn7rdghCLEJlAUYKwilF bcS5iFTLWRbdmLSEi81RpcwsGCEvTFHjQPcm8/TV4HuxnPjzkSyW0svxrUS0V19cv+Bf 0w== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2106.outbound.protection.outlook.com [104.47.70.106]) by mx0b-00273201.pphosted.com with ESMTP id 32c06x187y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 19 Jul 2020 10:34:58 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I1XsW5eGt1Mses6b6JVrfWdHYM1P3fo4ohXDitbxd6ZQlfp+XQUGuG7rDZsnFyIDZVEGdj1CAEbYrot86jH8QBUN2ynbKzUuaax3fPyR3Cx1Aw2ZH1Up6dsbA+YKYq7m5Mf2I/g+BQxXW/4fwuLPuJHhi/PNV+vDwIU3lyyPoX9aeRVeU25o7r8GEZ7eJz4g7+8OkrAdBGg4WWZyMRf8okGY5RR7dI9E3rLssEtHWbmBg09NQGk8b9AHNzNr5XGufQdl9DegZW6clX36TWkCnTEQn2YHZ23cbdp6O5W4ngLtTEPpkW+/qvXLJ1fpDKnJcbpN0o1uo38FvxgR/OqN7Q== 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=8bDhosOTn4pq34xWQTRMgqjH3vkvTIaMzk162H9cJbI=; b=DmAyNK3lpC57KW7zdYbwIlYVXYniZDObVLy+VzAJyCAiBDGZczhIEj307DRewW+D7aCnLG3pLf+EVEymN50WZ+y+YfnZiMT32MGKJzBg0/QKhXw9W3FqQwIEZ9OyqKFCTM5THg2q5sfSB9oQYAOVpYLkvkJvnNVohCNWzpHtl32qV0VWGhs6tYq/rLWXsykgfza76NhID63wd79iZxdKW/zRQnoeKvD066bxzE4/XX9IuyYuiQgwpuA0c5Co6cJw8vVeRmYysaOqg2fBEp4thytFf/Q3th/JhvLBBjg/AKw+DLkQkUBawr8MLIxTA8DXbqSahGRpURQUwQMjJXVNjA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8bDhosOTn4pq34xWQTRMgqjH3vkvTIaMzk162H9cJbI=; b=j0yv9EEvw8My+uGyE5ou+HIQzfAz3/aVNjHK+hdYC5pTCoyBW9WOWuQCSwBGRkFxVWVpkF2H66A1nB79YDH5J9a5lt40iGj2bOXlafQlUQTxE36KKLi/M5XA6OqXRFV6iUlSxq1pGgsEGqVsoWotWIl8fNAt+vWqlioKGuU1coA= Received: from DM6PR05MB6348.namprd05.prod.outlook.com (2603:10b6:5:122::15) by DM6PR05MB7180.namprd05.prod.outlook.com (2603:10b6:5:1df::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.15; Sun, 19 Jul 2020 17:34:54 +0000 Received: from DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::9d38:2336:1379:ce2e]) by DM6PR05MB6348.namprd05.prod.outlook.com ([fe80::9d38:2336:1379:ce2e%7]) with mapi id 15.20.3216.017; Sun, 19 Jul 2020 17:34:54 +0000 From: Ron Bonica To: OPSEC CC: "tls@ietf.org" Thread-Topic: Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AdZd8qs4MVhjKcpfSaSC3eC5PK0rEQ== Date: Sun, 19 Jul 2020 17:34:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2020-07-19T17:34:52Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=6d9a4c40-c774-4c89-93a4-188dc15ebbfd; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 dlp-product: dlpe-windows dlp-version: 11.5.0.60 dlp-reaction: no-action authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 741b5aa4-3a14-4ad5-9b32-08d82c0a0c6e x-ms-traffictypediagnostic: DM6PR05MB7180: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2657; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7ss5rOnpNWP9DCe/uhQl5JfW01fn/OQJuoD6UxnEk5feGOfDnrNObM2CERKKeBoRxqhabiAnHFg3wDWLyNKycHN6gTFEIjlylF/UBVTV718KB6uyZC9fSiUjORICLEvQ52jQt9DLwDqnrxi3ov/Mhh9VfXPDRNWRZI3e1dlxDVsy7gZaKGie9HNuBsRduwHRhMLceeV8N3afawcb/POjcy0GMvogEPL7WfR5frwGoncUeRknLWexrm74niKcwTrZc8Cjzc9DUSoPjnDC0cAEL0vQLiAJdzJVFTxFPjUZO5hqRKCowJe9KOqECBKL8msrFHUl6FVxPqmzSGItpisPhBP/IUt/gkd+iooPV5MrAvmXQF7D9EJpiGnk4YRFfJHWAQn+ls4jkneLb6LB0Ec+6g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR05MB6348.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(136003)(346002)(396003)(39860400002)(6506007)(9686003)(478600001)(52536014)(5660300002)(71200400001)(316002)(4326008)(7696005)(450100002)(166002)(55016002)(66446008)(64756008)(66556008)(66476007)(8676002)(2906002)(8936002)(76116006)(86362001)(66946007)(6916009)(33656002)(186003)(26005)(558084003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: HvwSGM4fTeGflRUDqErWOiXdBxIFLOVnYQd0JN/98YO3HuCYt+lzCCr+Lp8TiB/5KpRThVGiBgNiNsMJT5dfoLR43E3GGUbXtEv0VOpv4QB5CcMOsARDbx4cSqZGGc7M1V24ozAO8yumdPfKgX0ctBUTRv6QkUNfaU9oW7TMcixYyKM6P5gI3cV2Gj2o4xN4nSRPgcbqupTrTV0iA0nba+HaZuemv/kyCxyeMF808Uk8Nl1PnlEpD2SbYoCplsdIMp8nmLdLUn9nD5Kwfsz3rHYl1mfnHURV6BlfWb3+nh9if9wLO5oAAbzm8aR6/oMinUmG5oh51iaubdZ6YhrMiJkJCt4jAEUe2CTdPwrJehnzfq651C/GeFzpayyfHbAh/fLSDtQCpohufZ2M/UNzr9sIsM4/WiX2wQp/txiYqtj6JsvQPEfVXV4+Io+cy4jvrfgLv+CJUKTNdA6jw1WdW9pqEYPGwG8aGPesLAG+DL4= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR05MB634890A51C4AF3CB1A03DA0BAE7A0DM6PR05MB6348namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR05MB6348.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 741b5aa4-3a14-4ad5-9b32-08d82c0a0c6e X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2020 17:34:54.2125 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LCsAbcVldlNlgwEmSNlYZ04DXU4sjgvmeqwWZF37HmSt8xjbwWeyA5F4AmvKBRamrk5YYm//rdRRJPsTqvKOFg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR05MB7180 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-19_03:2020-07-17, 2020-07-19 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 lowpriorityscore=0 suspectscore=0 mlxlogscore=936 adultscore=0 clxscore=1011 spamscore=0 phishscore=0 impostorscore=0 bulkscore=0 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007190136 Archived-At: Subject: [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 17:35:01 -0000 --_000_DM6PR05MB634890A51C4AF3CB1A03DA0BAE7A0DM6PR05MB6348namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp. Please send comments to opsec@ietf.org by August 3, = 2020. Ron Juniper Business Use Only --_000_DM6PR05MB634890A51C4AF3CB1A03DA0BAE7A0DM6PR05MB6348namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp.

 

Please send comments to opsec@ietf.org by August 3, 2020.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;    Ron

 


Juniper Business= Use Only

--_000_DM6PR05MB634890A51C4AF3CB1A03DA0BAE7A0DM6PR05MB6348namp_-- From nobody Mon Jul 20 12:10: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 C9DC73A0E0C for ; Mon, 20 Jul 2020 12:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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 2kt7ic902aGo for ; Mon, 20 Jul 2020 12:10:32 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 1F68F3A0E4A for ; Mon, 20 Jul 2020 12:10:32 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id 184so585236wmb.0 for ; Mon, 20 Jul 2020 12:10:32 -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=++97zvIBZkL7n9HJE9z7TuaAjo0jb6dWgbjarMJUHu0=; b=LuF2jZvmIZ84EPfSHQC3/p49PPx4di5p8FiC371JK8OGF3V3iPLE9NhPbeiynAAnOk 3YyiljJIBhapFJ9RiUdGjN57JHPSR+qAhQUqv9TqKzK3AxhWZBG4T85z6NjHh+3nl1K0 gFCYPQliRdaux2RUyc1F1UM5LD9IY3YSa7B25GvwWlCP/AEIrT7eOS4bbAFnti4Qp0q3 O8IS5i6EAYPCW4M4F45CCbZlAXQculokvHBqJaLg6Zexhhu/TC4ASOJZz/uH227u43Vk AAnYrTx42c3fQVvif+fTU5G9c9auc4pMqZEYDn/U+LIDUf6jgiRkJaM6E3LNNuhw3//I 6Sow== 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=++97zvIBZkL7n9HJE9z7TuaAjo0jb6dWgbjarMJUHu0=; b=joD6QXf9uJz8reNVntTfGCLWEyQqsqJ3CECkvkJ/WZsrwm8fY7iCTFVsZkreQ7Dffi S6xJDCwsxbKDFYsptlg/prK85XTFE1TsJrzS6+O7hZYmzd+xlo6ecRt1LV0GF5LHQ+tD NYnrm8mKc1AodJpohE8ttx3enpX+nk59yD1gkik7tRFvZPZQTcXkOytFTjOaVnDyH07a gYZKuT1a1ms5jwpwrp1pE4jLnfqYEsjrY7rVkmKu9VFCX5OSQUUpv+wLF0Sa4DGEIzjs afxOQu3sKqQS/w+jM9mscG8zbq7+DXCcZdXdGFnOIZT33Bx1H3yxswHDrRg+IBI2HbM9 sMBQ== X-Gm-Message-State: AOAM532Ce8dKNr85qVSoTGZzFsZ6AUmos33AG4T+w2a49e78OO/Th4yb FS/iEZEd55wxQmzMIr2m1NyLAvtMBqNqvn7YAwU= X-Google-Smtp-Source: ABdhPJzOjXJLiWjHS0IhykqP3wPwuEW/m18LfLRcJv6jCEQ2IuLe0t5yRoNaHSor7X33lEG4KcXJ0JE/A4s2Hwm+NPs= X-Received: by 2002:a1c:2dc6:: with SMTP id t189mr746180wmt.26.1595272230599; Mon, 20 Jul 2020 12:10:30 -0700 (PDT) MIME-Version: 1.0 References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> In-Reply-To: From: Lucas Pardue Date: Mon, 20 Jul 2020 20:10:19 +0100 Message-ID: To: Victor Vasiliev Cc: "tls@ietf.org" , HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000a0018b05aae44286" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 19:10:38 -0000 --000000000000a0018b05aae44286 Content-Type: text/plain; charset="UTF-8" Hi Victor, It seems my brain skipped over "ALPS in HTTPS" [1] when you mentioned in your original email. I was reading it in the context of David Benjamin's thread on Client Hint Reliability [2]. There's a couple of things that surprised me when reading both drafts: 1. ALPS in HTTPS actually supports more than just exchanging Settings Parameters, it can actually hold a series of frames. It's just that ALPS only defines SETTINGS to be allowed, and Client Hints Reliability wants to add more in the shape of a new ACCEPT_CH frame. I'm not sure I like the idea of supporting any old frame in the TLS handshake, SETTINGS are at least reasoned about in terms of how they are remembered for the purposes of 0-RTT. 2. ALPS in HTTPS makes it mandatory to support some settings to disable static and Huffman header compression. That seems pretty onerous. If there was interest in prototyping something like ACCEPT_CH-in-handhsake it requires a modification of a QPACK dependency. On the other hand, if you don't make these settings mandatory, then you won't achieve your objective of removing the mandatory parts of HPACK/QPACK. To me this is a signal that ALPN is a better option to negotiate a profile of H2/H3 that modifies mandatory compression behaviour. Cheers Lucas [1] https://tools.ietf.org/html/draft-vvv-httpbis-alps-00 [2] https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0054.html --000000000000a0018b05aae44286 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Victor,

It seems my brain= skipped over "ALPS in HTTPS" [1] when you mentioned in your orig= inal email. I was reading it in the context of David Benjamin's thread = on Client Hint Reliability [2]. There's a couple of things that surpris= ed me when reading both drafts:

1. ALPS in HTT= PS actually supports more than just exchanging Settings Parameters, it can = actually hold a series of frames. It's just that ALPS only defines SETT= INGS to be allowed, and Client Hints Reliability wants to add more in the s= hape of a new ACCEPT_CH frame. I'm not sure I like the idea of supporti= ng any old frame in the TLS handshake, SETTINGS are at least reasoned about= in terms of how they are remembered for the purposes of 0-RTT.
<= div>2. ALPS in HTTPS makes it mandatory to support some settings to disable= static and Huffman header compression. That seems pretty onerous. If there= was interest in prototyping something like ACCEPT_CH-in-handhsake it requi= res a modification of a QPACK dependency. On the other hand, if you don'= ;t make these settings mandatory, then you won't achieve your objective= of removing the mandatory parts of HPACK/QPACK. To me this is a signal tha= t ALPN is a better option to negotiate a profile of H2/H3 that modifies man= datory compression behaviour.

Cheers
Luc= as


=

--000000000000a0018b05aae44286-- From nobody Mon Jul 20 12:33: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 E3B053A0E4B for ; Mon, 20 Jul 2020 12:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 l22WBVoRi7iH for ; Mon, 20 Jul 2020 12:33:35 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 D4CFD3A0E49 for ; Mon, 20 Jul 2020 12:33:34 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id k13so1390028lfo.0 for ; Mon, 20 Jul 2020 12:33:34 -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 :cc; bh=b71hp2jkn2jo28HMWPKufvjTP9PwD+9zkzsQxvLKGes=; b=qmTXC+KcMs5UJ+2M6CzrHQ+/DpYyKFZYQjASR1cG/5vQUlejJof32PhUZBVfKwcn/N ks84YCWAvlGjXwqLrZB06/V+fb1hgh1n/Oux42VrA8vawWM2q8cTHX5PPFMszcIEmS/p biKciPS55igVDKGT+uKu6Ncwz6xxL0icgqsHdybaxMihhXzcRA2agxY5wjjRJFxfL/Au AWN+rlipI4XLyD6O72UKPmjSOsD0LwJ8fHOUmlx5MMBb/NmsdNL7iMygh3n+Vix3xLfe PZikyrASdgsfdNjbfToSJPRNdPLdXPcdhMTkCGGf7SkuEz6h2jgJummxbqCULMfZmXkm 6NQw== 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=b71hp2jkn2jo28HMWPKufvjTP9PwD+9zkzsQxvLKGes=; b=E0zLod8lYqLYNU+pRdzEg3DTdQtlz6jmxKIjstf7R7PowTw8NEuB98MLQbXmHUuxeS JEp3hegNcZ8el6Zhq3kYJ8X+fsZeoGz1TCBiEX0oApr5Jj0ZKrS5aKe2HKZ8OPBtV5cB Tl4DN2NOG/VUBN+1E5yLfl0Ueutvx6iMUnfdx55A7sLnmFxMaBI/VcvVToWETtcbTGSh UFx9ShUcGZvs8nl6bEV1kLxAbRHEseVt2DnfHhdhk3bu51DKBey5EBMk7XXtY33v1HDH dXW3JSfoSQrrBkb8XWv9luKweDKUwifc+R1wwUnCsbXaQzdp6v22/SPKaRCW9niq1W70 4ShA== X-Gm-Message-State: AOAM530VaWhPZ1zw18/mTVC8tIsqrtMqGebsSxLEJzcDvwYFV8hHIX84 R0Es5lsK2cOOWjtQyMQty4/WWy8PmC44qbkSSRcx0g== X-Google-Smtp-Source: ABdhPJxPgl0Zbq9hbHJN1x1Q4mAFgKRfQ23QKmlqVYWw7qrVy8eqOlCWP92+KfEuXhNmOVCchNNz7B00rsZezyUL2UQ= X-Received: by 2002:ac2:5338:: with SMTP id f24mr1185249lfh.5.1595273612577; Mon, 20 Jul 2020 12:33:32 -0700 (PDT) MIME-Version: 1.0 References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> In-Reply-To: From: Victor Vasiliev Date: Mon, 20 Jul 2020 15:33:21 -0400 Message-ID: To: Lucas Pardue Cc: "tls@ietf.org" , HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000000e5705aae495e9" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 19:33:37 -0000 --000000000000000e5705aae495e9 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 20, 2020 at 3:10 PM Lucas Pardue wrote: > Hi Victor, > > It seems my brain skipped over "ALPS in HTTPS" [1] when you mentioned in > your original email. I was reading it in the context of David Benjamin's > thread on Client Hint Reliability [2]. There's a couple of things that > surprised me when reading both drafts: > > 1. ALPS in HTTPS actually supports more than just exchanging Settings > Parameters, it can actually hold a series of frames. It's just that ALPS > only defines SETTINGS to be allowed, and Client Hints Reliability wants to > add more in the shape of a new ACCEPT_CH frame. I'm not sure I like the > idea of supporting any old frame in the TLS handshake, SETTINGS are at > least reasoned about in terms of how they are remembered for the purposes > of 0-RTT. > It explicitly bans all existing frames that are not SETTINGS. The problem here is that SETTINGS only supports integral values, so we'd be limited to those if we make ALPS just SETTINGS. > 2. ALPS in HTTPS makes it mandatory to support some settings to disable > static and Huffman header compression. That seems pretty onerous. If there > was interest in prototyping something like ACCEPT_CH-in-handhsake it > requires a modification of a QPACK dependency. On the other hand, if you > don't make these settings mandatory, then you won't achieve your objective > of removing the mandatory parts of HPACK/QPACK. To me this is a signal that > ALPN is a better option to negotiate a profile of H2/H3 that modifies > mandatory compression behaviour. > That's a fair point. I think I have an idea of how to split those settings into a separate draft without resorting to a new ALPN token. > > Cheers > Lucas > > > [1] https://tools.ietf.org/html/draft-vvv-httpbis-alps-00 > [2] https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0054.html > > --000000000000000e5705aae495e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 20, 2020 at 3:10 PM Lucas Par= due <lucaspardue.24.7@gmai= l.com> wrote:
Hi Victor,

It seems my brain skipped over "ALPS in HTTPS" [1= ] when you mentioned in your original email. I was reading it in the contex= t of David Benjamin's thread on Client Hint Reliability [2]. There'= s a couple of things that surprised me when reading both drafts:
<= div>
1. ALPS in HTTPS actually supports more than just exchan= ging Settings Parameters, it can actually hold a series of frames. It's= just that ALPS only defines SETTINGS to be allowed, and Client Hints Relia= bility wants to add more in the shape of a new ACCEPT_CH frame. I'm not= sure I like the idea of supporting any old frame in the TLS handshake, SET= TINGS are at least reasoned about in terms of how they are remembered for t= he purposes of 0-RTT.

It e= xplicitly bans all existing frames that are not SETTINGS.=C2=A0 The problem= here is that SETTINGS only supports integral values, so we'd be limite= d to those if we make ALPS just SETTINGS.
=C2=A0
2. = ALPS in HTTPS makes it mandatory to support some settings to disable static= and Huffman header compression. That seems pretty onerous. If there was in= terest in prototyping something like ACCEPT_CH-in-handhsake it requires a m= odification of a QPACK dependency. On the other hand, if you don't make= these settings mandatory, then you won't achieve your objective of rem= oving the mandatory parts of HPACK/QPACK. To me this is a signal that ALPN = is a better option to negotiate a profile of H2/H3 that modifies mandatory = compression behaviour.

That'= ;s a fair point.=C2=A0 I think I have an idea of how to split those setting= s into a separate draft without resorting to a new ALPN token.
= =C2=A0

Cheers
Lucas



--000000000000000e5705aae495e9-- From nobody Mon Jul 20 13:38: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 4696D3A0EAB for ; Mon, 20 Jul 2020 13:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.498 X-Spam-Level: X-Spam-Status: No, score=-9.498 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 0FRIT-ISYUqD for ; Mon, 20 Jul 2020 13:38:51 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 BA3543A0EA7 for ; Mon, 20 Jul 2020 13:38:51 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id j19so10854912pgm.11 for ; Mon, 20 Jul 2020 13:38:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=X5+2ARQwyufLKQvrjJ7PfgYRTUTNxwEZF45o7qd7ANI=; b=ifRGIPHhon3AkICIu9h1C25BOOOV6VuogkB104x8fjgP6R8DmW511+t7WwUXKhLRsJ 9MSkWd/xxEn/lsAXVGO/wMEh5q3c7aYwtLjQOS+GcYtfRBVwFySFz0sxusKaFGR2wISG B1LC8hb4L8OrPHbHJCb6aNbK2iti9yylhirzo= 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=X5+2ARQwyufLKQvrjJ7PfgYRTUTNxwEZF45o7qd7ANI=; b=ec8SOAb1AMLc/6mas/R65S5FSjVPDIsCzfG8AiWSsgR+/e6WMYrOeR4SF3LWNh9flY xFuWozJBYcybC46Hh7dYQInjNzX/8Uxwso2r4w4ONwoSRwLURH5l9vapd7hMypteogPx NIUcYLVtUhL4EXnr5QS2fHhfR7cqwZ7L/F4fB6NjzWTU7Snfe4kCebY9fceTEXfnZhpA scHD3eYPt04ovSaBNlgnCAUhFivCILntul9rG24jGlkbz/Ivi5UOJx/erAFcXlmkkBCk D8bivylr/URwEpqJobLzKiGBHx1b6p67m0MX5jdjHlDn+RFfnu/19Mj7zqeqrjJJe/Yj qmgQ== X-Gm-Message-State: AOAM532J6kcmIO9RB+ciQblm7V8ScgKI+/G3DdR9QBrJlxkENlq/hSlD X1wxMlRchJUmzvaGh8HM/JsTdJGQ4922rbTm+fASkR0OAA== X-Google-Smtp-Source: ABdhPJymyhn+iECZwYq2yFw8EtmtxLIJC/IgI7jYE83uYyW447EAFPWIIELFyVM04aHvf+y957LECITrcMmrtV45jhU= X-Received: by 2002:aa7:8507:: with SMTP id v7mr21071118pfn.218.1595277530970; Mon, 20 Jul 2020 13:38:50 -0700 (PDT) MIME-Version: 1.0 References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> In-Reply-To: From: David Benjamin Date: Mon, 20 Jul 2020 16:38:34 -0400 Message-ID: To: Victor Vasiliev Cc: Lucas Pardue , "tls@ietf.org" , HTTP Working Group Content-Type: multipart/alternative; boundary="0000000000008da9ad05aae57e33" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 20:38:53 -0000 --0000000000008da9ad05aae57e33 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 20, 2020 at 3:33 PM Victor Vasiliev wrote: > On Mon, Jul 20, 2020 at 3:10 PM Lucas Pardue > wrote: > >> Hi Victor, >> >> It seems my brain skipped over "ALPS in HTTPS" [1] when you mentioned in >> your original email. I was reading it in the context of David Benjamin's >> thread on Client Hint Reliability [2]. There's a couple of things that >> surprised me when reading both drafts: >> >> 1. ALPS in HTTPS actually supports more than just exchanging Settings >> Parameters, it can actually hold a series of frames. It's just that ALPS >> only defines SETTINGS to be allowed, and Client Hints Reliability wants to >> add more in the shape of a new ACCEPT_CH frame. I'm not sure I like the >> idea of supporting any old frame in the TLS handshake, SETTINGS are at >> least reasoned about in terms of how they are remembered for the purposes >> of 0-RTT. >> > > It explicitly bans all existing frames that are not SETTINGS. The problem > here is that SETTINGS only supports integral values, so we'd be limited to > those if we make ALPS just SETTINGS. > Right, concretely there is an "Allowed in ALPS" column added by Victor's ALPS document, which my document sets for the new frame. Old frames weren't designed with ALPS in mind, so the ALPS document needs to make a decision. New frames can reason about the implications of opting into ALPS and do so. As Victor notes, it's only a new frame because we got SETTINGS values wrong and, per earlier discussion, the extension point we currently have is new frames. If we want something even more restrictive, we could instead revive draft-bishop-httpbis-extended-settings, say only SETTINGS and EXTENDED_SETTINGS are allowed, and close it there. But I think the new column works fine and matches how this sort of thing usually works. > 2. ALPS in HTTPS makes it mandatory to support some settings to disable >> static and Huffman header compression. That seems pretty onerous. If there >> was interest in prototyping something like ACCEPT_CH-in-handhsake it >> requires a modification of a QPACK dependency. On the other hand, if you >> don't make these settings mandatory, then you won't achieve your objective >> of removing the mandatory parts of HPACK/QPACK. To me this is a signal that >> ALPN is a better option to negotiate a profile of H2/H3 that modifies >> mandatory compression behaviour. >> > > That's a fair point. I think I have an idea of how to split those > settings into a separate draft without resorting to a new ALPN token. > > >> >> Cheers >> Lucas >> >> >> [1] https://tools.ietf.org/html/draft-vvv-httpbis-alps-00 >> [2] >> https://lists.w3.org/Archives/Public/ietf-http-wg/2020JulSep/0054.html >> >> _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000008da9ad05aae57e33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 20, 2020 at 3:33 PM Victor Va= siliev <vasilvv=3D40googl= e.com@dmarc.ietf.org> wrote:
On Mon, Jul 20, 2020 at 3:10 PM Lucas Pardue <lucaspardue.24.7@gmail.com&= gt; wrote:
Hi Victor,

=
It seems my brain skipped over "ALPS in HTTPS" [1] when you = mentioned in your original email. I was reading it in the context of David = Benjamin's thread on Client Hint Reliability [2]. There's a couple = of things that surprised me when reading both drafts:

1. ALPS in HTTPS actually supports more than just exchanging Settin= gs Parameters, it can actually hold a series of frames. It's just that = ALPS only defines SETTINGS to be allowed, and Client Hints Reliability want= s to add more in the shape of a new ACCEPT_CH frame. I'm not sure I lik= e the idea of supporting any old frame in the TLS handshake, SETTINGS are a= t least reasoned about in terms of how they are remembered for the purposes= of 0-RTT.

It explicitly b= ans all existing frames that are not SETTINGS.=C2=A0 The problem here is th= at SETTINGS only supports integral values, so we'd be limited to those = if we make ALPS just SETTINGS.

Right, concretely there is an "Allowed in ALPS" column adde= d by Victor's ALPS document, which my document sets for the new frame. = Old frames weren't designed with ALPS in mind, so the ALPS document nee= ds to make a decision. New frames can reason about the implications of opti= ng into ALPS and do so.

As Victor notes, it's = only a new frame because we got SETTINGS values wrong and, per earlier disc= ussion, the extension point we currently have is new frames. If we want som= ething even more restrictive, we could instead revive=C2=A0draft-bishop-htt= pbis-extended-settings, say only SETTINGS and EXTENDED_SETTINGS are allowed= , and close it there.=C2=A0But I think the new column works fine and matche= s how this sort of thing usually works.
=C2=A0=C2=A0
2. ALPS in HTTPS makes it mandatory to support some set= tings to disable static and Huffman header compression. That seems pretty o= nerous. If there was interest in prototyping something like ACCEPT_CH-in-ha= ndhsake it requires a modification of a QPACK dependency. On the other hand= , if you don't make these settings mandatory, then you won't achiev= e your objective of removing the mandatory parts of HPACK/QPACK. To me this= is a signal that ALPN is a better option to negotiate a profile of H2/H3 t= hat modifies mandatory compression behaviour.
=
That's a fair point.=C2=A0 I think I have an idea of how= to split those settings into a separate draft without resorting to a new A= LPN token.
=C2=A0
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000008da9ad05aae57e33-- From nobody Mon Jul 20 14:00: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 882C03A0F90 for ; Mon, 20 Jul 2020 14:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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 WOkmR8KzKNGO for ; Mon, 20 Jul 2020 14:00:56 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 BBBD33A0F8F for ; Mon, 20 Jul 2020 14:00:55 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id f139so810689wmf.5 for ; Mon, 20 Jul 2020 14:00:55 -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=1Sum2hAaARDzUflC3+6o8/CVvM+iqsdqXyL02Ze5PXo=; b=qOqMpzubsQiUgacz/8rb4XU70A9od8ZYkw/bBeQ+O9TSRiMK1aZ35RjkaFN0iEN0yr 5SwHolWvm+3Vwlyz0FKq+oc5LLR+PGPUgtxfkYdqKlG36xU05DzG8RKk0B9wx/ZSczf5 xkfRVd5C3QZVuj3h0KslkFis87Fs61OfUYBEUbIhhRV+hQfu8LuxWJmZ2Pz2JXUr1pgI rZ9YKWtJ2hYEpHunx/rdF7Kp2xbw2GYkitqrift5neZB+8lA4LWWcbKbcoJua7nHXDNQ 9EtRWV1e+Fmuhm/X3zjNo+n3AN6bO+kkJ2B4ZAzGBL0980Bilm/sPtFFzPc8K9YWKrl+ CaOw== 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=1Sum2hAaARDzUflC3+6o8/CVvM+iqsdqXyL02Ze5PXo=; b=pz3usjzNUNuWrbRMYiji29zl76Ugte/+ZTV+1YlZVZK6U83FWLibGvULojEUy5CIKZ 1BH4DLk/UpheKVUCh99h2n5h10FBIXqpQbJMPHcfTSuxtKwkhc3uj01CiULQ8mtm5Anl BtoGmiiN6YAHpVvtufI+ng7iHhTdSZRVdJSmUKfNs+edjnbfUDZYlspUZ4n01hYktrl9 EW8CgetPwf5tb8ANAZ/yGgDwmEOlKE20A0bg5zYw0KrDujGqk5huFFYYg7fMj4cJsV98 HKs8XR+SKhoYcnU5VVeQ3p8EgXJaswzIivkPbZAZ18tAq3MBwWWiojhMnzWuXQ5qlRwA tPIg== X-Gm-Message-State: AOAM530z8ZfRZLiuSAPSL0UB3cefk7sFwPZJO2D/+aKD3A4nTnw/VZ5b 6E7LNXwfdZe98HCxDnYI6e+37azoVc0625debxE= X-Google-Smtp-Source: ABdhPJzfXwHgtiMFS1DSMX5PzFWl6QaK8IhsDOS975V+E1VUie1vUmSJWhQjiC9ihCRnz5cfbYWDpyckg90eQmwMW7c= X-Received: by 2002:a1c:6788:: with SMTP id b130mr1056554wmc.100.1595278854297; Mon, 20 Jul 2020 14:00:54 -0700 (PDT) MIME-Version: 1.0 References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> In-Reply-To: From: Lucas Pardue Date: Mon, 20 Jul 2020 22:00:48 +0100 Message-ID: To: David Benjamin Cc: Victor Vasiliev , "tls@ietf.org" , HTTP Working Group Content-Type: multipart/alternative; boundary="0000000000006d9ace05aae5cd11" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 21:00:58 -0000 --0000000000006d9ace05aae5cd11 Content-Type: text/plain; charset="UTF-8" On Mon, 20 Jul 2020, 21:38 David Benjamin, wrote: > On Mon, Jul 20, 2020 at 3:33 PM Victor Vasiliev 40google.com@dmarc.ietf.org> wrote: > >> On Mon, Jul 20, 2020 at 3:10 PM Lucas Pardue >> wrote: >> >>> Hi Victor, >>> >>> It seems my brain skipped over "ALPS in HTTPS" [1] when you mentioned in >>> your original email. I was reading it in the context of David Benjamin's >>> thread on Client Hint Reliability [2]. There's a couple of things that >>> surprised me when reading both drafts: >>> >>> 1. ALPS in HTTPS actually supports more than just exchanging Settings >>> Parameters, it can actually hold a series of frames. It's just that ALPS >>> only defines SETTINGS to be allowed, and Client Hints Reliability wants to >>> add more in the shape of a new ACCEPT_CH frame. I'm not sure I like the >>> idea of supporting any old frame in the TLS handshake, SETTINGS are at >>> least reasoned about in terms of how they are remembered for the purposes >>> of 0-RTT. >>> >> >> It explicitly bans all existing frames that are not SETTINGS. The >> problem here is that SETTINGS only supports integral values, so we'd be >> limited to those if we make ALPS just SETTINGS. >> > > Right, concretely there is an "Allowed in ALPS" column added by Victor's > ALPS document, which my document sets for the new frame. Old frames weren't > designed with ALPS in mind, so the ALPS document needs to make a decision. > New frames can reason about the implications of opting into ALPS and do so. > > As Victor notes, it's only a new frame because we got SETTINGS values > wrong and, per earlier discussion, the extension point we currently have is > new frames. If we want something even more restrictive, we could instead > revive draft-bishop-httpbis-extended-settings, say only SETTINGS and > EXTENDED_SETTINGS are allowed, and close it there. But I think the new > column works fine and matches how this sort of thing usually works. > That makes sense but I guess I don't see the point in defining a new thing that contains frames that are never sent on streams. That is, if these are connection settings, just send the payload. Unframed extended settings might get you there, if you can find a way to encapsulate conventional settings inside them, then all the better. Cheers Lucas /tls >> > --0000000000006d9ace05aae5cd11 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, 20 Jul 2020, 21:38 David Benjamin, <davidben@chromium.org> wrote:
On Mon, J= ul 20, 2020 at 3:33 PM Victor Vasiliev <vasilvv=3D40google.com@= dmarc.ietf.org> wrote:
= On Mon, Jul 20, 2020 at 3:10 PM Lucas Pardue <lucaspardue.24.7@g= mail.com> wrote:
Hi Victor,

It seems my brain skipped over "ALPS in HTTPS" = [1] when you mentioned in your original email. I was reading it in the cont= ext of David Benjamin's thread on Client Hint Reliability [2]. There= 9;s a couple of things that surprised me when reading both drafts:

1. ALPS in HTTPS actually supports more than just exch= anging Settings Parameters, it can actually hold a series of frames. It'= ;s just that ALPS only defines SETTINGS to be allowed, and Client Hints Rel= iability wants to add more in the shape of a new ACCEPT_CH frame. I'm n= ot sure I like the idea of supporting any old frame in the TLS handshake, S= ETTINGS are at least reasoned about in terms of how they are remembered for= the purposes of 0-RTT.

It= explicitly bans all existing frames that are not SETTINGS.=C2=A0 The probl= em here is that SETTINGS only supports integral values, so we'd be limi= ted to those if we make ALPS just SETTINGS.
<= div>
Right, concretely there is an "Allowed in ALPS"= ; column added by Victor's ALPS document, which my document sets for th= e new frame. Old frames weren't designed with ALPS in mind, so the ALPS= document needs to make a decision. New frames can reason about the implica= tions of opting into ALPS and do so.

As Victor not= es, it's only a new frame because we got SETTINGS values wrong and, per= earlier discussion, the extension point we currently have is new frames. I= f we want something even more restrictive, we could instead revive=C2=A0dra= ft-bishop-httpbis-extended-settings, say only SETTINGS and EXTENDED_SETTING= S are allowed, and close it there.=C2=A0But I think the new column works fi= ne and matches how this sort of thing usually works.

That make= s sense but I guess I don't see the point in defining a new thing that = contains frames that are never sent on streams. That is, if these are conne= ction settings, just send the payload. Unframed extended settings might get= you there, if you can find a way to encapsulate conventional settings insi= de them, then all the better.

Cheers
Lucas

=

--0000000000006d9ace05aae5cd11-- From nobody Mon Jul 20 14:42: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 376C23A0FC8 for ; Mon, 20 Jul 2020 14:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.498 X-Spam-Level: X-Spam-Status: No, score=-9.498 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 XoT13bLd33nX for ; Mon, 20 Jul 2020 14:42:32 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 96D963A0FC1 for ; Mon, 20 Jul 2020 14:42:32 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id o13so10968710pgf.0 for ; Mon, 20 Jul 2020 14:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=u+wwtGwgXZx/pFXzPwOV8MhtTSojkr1XPgZD4LFHDVM=; b=fmQiDQJMtGQ3ifiQ8jCL6LW6hfYRgmp8FOezMcTXjFuWe1WD+JE+bdguJgWNg/IdTz mO+7eg804rSdDYZ+r/A7pYLMKekPrw593jLJzOw1M9Ss87en+U3ayxCyVi8HKMlG12xq g/0doYE5mSeiPMfkXvP6n8FG7F7xX63NkflSE= 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=u+wwtGwgXZx/pFXzPwOV8MhtTSojkr1XPgZD4LFHDVM=; b=GIj9rSWCpnN4KOgkAntzfPfbo62aCqtD82zC/934UuJRyOueboqYdbViLFWDjmvzNf znuxtLyGEHhwSv3DfHLbuhHtSl+JYBT3Z4W9MkAUChs9U2JPpmdeYbciQEg1fyQekB9j /TJrSfVFBfnGhgpQi82JXbwNVkwJ+BVCoMGuoE1UNnoSSREscd8DsN1VnFVGzAqOsfb1 Xx8jzgh2xTOmuOunP1j+0lb9Njpsu77nU/M1byu33pyFyEq17NoNrkHT9bj4TqWqd+Ki gHeYlPCAcSQcs2ojDdvxh+mrNeR8gk5k1pIimKV345pLIejRjmjLMXS2ha7E8b0SD1oQ LyJg== X-Gm-Message-State: AOAM531Q8DFsDgUCaRJ2ddH7KkPCM7/zGRcBCBEu/hfAfJFMNeIvIBBg hV7zZByQLaf7Bx+tm/cV64AqcDYfWLlR7FIAxs4SlpM= X-Google-Smtp-Source: ABdhPJy9rCHMz1vrvwv6nJdOEHjrvb5K5E2yz1VkbLm+3ptsc+un7lPq1s0Mr0JaT8m65bHz5fxiR8ND1xgLOAL3HTI= X-Received: by 2002:a62:7c97:: with SMTP id x145mr22282182pfc.80.1595281351919; Mon, 20 Jul 2020 14:42:31 -0700 (PDT) MIME-Version: 1.0 References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> In-Reply-To: From: David Benjamin Date: Mon, 20 Jul 2020 17:42:15 -0400 Message-ID: To: Lucas Pardue Cc: Victor Vasiliev , "tls@ietf.org" , HTTP Working Group Content-Type: multipart/alternative; boundary="0000000000004cb9c305aae66250" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 21:42:34 -0000 --0000000000004cb9c305aae66250 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue wrote: > On Mon, 20 Jul 2020, 21:38 David Benjamin, wrote: > >> On Mon, Jul 20, 2020 at 3:33 PM Victor Vasiliev > 40google.com@dmarc.ietf.org> wrote: >> >>> On Mon, Jul 20, 2020 at 3:10 PM Lucas Pardue >>> wrote: >>> >>>> Hi Victor, >>>> >>>> It seems my brain skipped over "ALPS in HTTPS" [1] when you mentioned >>>> in your original email. I was reading it in the context of David Benjamin's >>>> thread on Client Hint Reliability [2]. There's a couple of things that >>>> surprised me when reading both drafts: >>>> >>>> 1. ALPS in HTTPS actually supports more than just exchanging Settings >>>> Parameters, it can actually hold a series of frames. It's just that ALPS >>>> only defines SETTINGS to be allowed, and Client Hints Reliability wants to >>>> add more in the shape of a new ACCEPT_CH frame. I'm not sure I like the >>>> idea of supporting any old frame in the TLS handshake, SETTINGS are at >>>> least reasoned about in terms of how they are remembered for the purposes >>>> of 0-RTT. >>>> >>> >>> It explicitly bans all existing frames that are not SETTINGS. The >>> problem here is that SETTINGS only supports integral values, so we'd be >>> limited to those if we make ALPS just SETTINGS. >>> >> >> Right, concretely there is an "Allowed in ALPS" column added by Victor's >> ALPS document, which my document sets for the new frame. Old frames weren't >> designed with ALPS in mind, so the ALPS document needs to make a decision. >> New frames can reason about the implications of opting into ALPS and do so. >> >> As Victor notes, it's only a new frame because we got SETTINGS values >> wrong and, per earlier discussion, the extension point we currently have is >> new frames. If we want something even more restrictive, we could instead >> revive draft-bishop-httpbis-extended-settings, say only SETTINGS and >> EXTENDED_SETTINGS are allowed, and close it there. But I think the new >> column works fine and matches how this sort of thing usually works. >> > > That makes sense but I guess I don't see the point in defining a new thing > that contains frames that are never sent on streams. That is, if these are > connection settings, just send the payload. Unframed extended settings > might get you there, if you can find a way to encapsulate conventional > settings inside them, then all the better. > Could you elaborate on this a bit? I'm probably just failing to parse, but I'm not sure which alternative you're suggesting here. (Ah, the wonders of email.) David --0000000000004cb9c305aae66250 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 20, 2020 at 5:00 PM Lucas Par= due <luc= aspardue.24.7@gmail.com> wrote:
=
On Mon, 20 J= ul 2020, 21:38 David Benjamin, <davidben@chromium.org> wrote:
O= n Mon, Jul 20, 2020 at 3:33 PM Victor Vasiliev <vasilvv=3D40goo= gle.com@dmarc.ietf.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
On Mon, Jul 20, 2020 at 3:10 PM Lucas Pardue <lucaspard= ue.24.7@gmail.com> wrote:
Hi Victor= ,

It seems my brain skipped over "ALPS in HTT= PS" [1] when you mentioned in your original email. I was reading it in= the context of David Benjamin's thread on Client Hint Reliability [2].= There's a couple of things that surprised me when reading both drafts:=

1. ALPS in HTTPS actually supports more than = just exchanging Settings Parameters, it can actually hold a series of frame= s. It's just that ALPS only defines SETTINGS to be allowed, and Client = Hints Reliability wants to add more in the shape of a new ACCEPT_CH frame. = I'm not sure I like the idea of supporting any old frame in the TLS han= dshake, SETTINGS are at least reasoned about in terms of how they are remem= bered for the purposes of 0-RTT.

It explicitly bans all existing frames that are not SETTINGS.=C2=A0 = The problem here is that SETTINGS only supports integral values, so we'= d be limited to those if we make ALPS just SETTINGS.

Right, concretely there is an "Allowed in = ALPS" column added by Victor's ALPS document, which my document se= ts for the new frame. Old frames weren't designed with ALPS in mind, so= the ALPS document needs to make a decision. New frames can reason about th= e implications of opting into ALPS and do so.

As V= ictor notes, it's only a new frame because we got SETTINGS values wrong= and, per earlier discussion, the extension point we currently have is new = frames. If we want something even more restrictive, we could instead revive= =C2=A0draft-bishop-httpbis-extended-settings, say only SETTINGS and EXTENDE= D_SETTINGS are allowed, and close it there.=C2=A0But I think the new column= works fine and matches how this sort of thing usually works.

= That makes sense but I guess I don't see the point in defining a new th= ing that contains frames that are never sent on streams. That is, if these = are connection settings, just send the payload. Unframed extended settings = might get you there, if you can find a way to encapsulate conventional sett= ings inside them, then all the better.

Could you elaborate on this a bit? I'm probably just failing to= parse, but I'm not sure which alternative you're suggesting here. = (Ah, the wonders of email.)

David
--0000000000004cb9c305aae66250-- From nobody Tue Jul 21 05:22: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 A7F4F3A07CB for ; Tue, 21 Jul 2020 05:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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 Q1rs7PxLBFZK for ; Tue, 21 Jul 2020 05:22:15 -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 1F3C13A07CC for ; Tue, 21 Jul 2020 05:22:15 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id s10so20939671wrw.12 for ; Tue, 21 Jul 2020 05:22:14 -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=JUlZLoLzmGps33n98Tn7nSydkScfML1Z1ZSixyrR68g=; b=bSzIAaE/vK1gLm/jFMUpX2p+dFfRToBJUrKI+omvXFRp62BpYydsovjSNccAOZKsDR 76XCc8gJQRrX4livZfL1JRuSBineK8MLjzA2NeJYk+hbcDGI4si0D/NJZU2m6DaFrFm8 uFiAcxTBDxJEfXDL2AMx4s+p4vdMP66TeoSFkaHRiERBJGENr6Q1bhTD3kRHy9OXL5tu vaJONNRfud6yq2DuS9RNyi0x1dJ85XMgFcygkk0oWr/hUzieY2rytL8UTbKfhqyaebDV updmENotIl+jua2fYL5KC5lyfyGs8urldpi1HObWSSnEWMtFTlL6d0BSWWitGYqz1GTF QR4Q== 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=JUlZLoLzmGps33n98Tn7nSydkScfML1Z1ZSixyrR68g=; b=g1hJPcDByjJQkPsUtqs9tD51jviVi8RRemXbWUg9eD3AuM4ZbU315uhcrRJarku5Cv 02WqJspsUqiwv6Kc5/d1Yx9JGVfl0lDdfil1ZLXdfHtLc17IupAu2WYFQxrAqI8HxS85 cPB4le268bE/Bd4Bm6oGrTNgcc/w2VgaGbYHxtdAup4qOYQP1YwlL5qZWm0Ei9dXCW7t N24bKkVoUgLTBGrQ8RimEk2crtREq34m4lB3324cs2RavwznQFjiNEoO+n8037OUcC/7 Atz7taRPCabxcFeStaFs9cfR4mFeQW9ao3PqTGOVaLf5OX9WudRt+YZflWoxQuG5Q/T3 YaiQ== X-Gm-Message-State: AOAM533EoeBIm5hEZzi0m8tocsHfb7GiyXJGdIxhBevf5CG4c4iRjAmX Wswt0417CdyuovfruJSYylwv4EftmWD5LGG/ua0= X-Google-Smtp-Source: ABdhPJzwghNQSVsT9MASbFiAgmlSiEa+G7uX4y2WlOBBQ9QwYH6dZ85ZCm4Ghfrc8K2r/yHM/b9yiU7UKaOYtNnOId4= X-Received: by 2002:adf:dcc9:: with SMTP id x9mr13017986wrm.153.1595334133536; Tue, 21 Jul 2020 05:22:13 -0700 (PDT) MIME-Version: 1.0 References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> In-Reply-To: From: Lucas Pardue Date: Tue, 21 Jul 2020 13:22:02 +0100 Message-ID: To: David Benjamin Cc: Victor Vasiliev , "tls@ietf.org" , HTTP Working Group Content-Type: multipart/alternative; boundary="00000000000053dd0205aaf2acec" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 12:22:17 -0000 --00000000000053dd0205aaf2acec Content-Type: text/plain; charset="UTF-8" On Mon, Jul 20, 2020 at 10:42 PM David Benjamin wrote: > On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue > wrote: > >> >> That makes sense but I guess I don't see the point in defining a new >> thing that contains frames that are never sent on streams. That is, if >> these are connection settings, just send the payload. Unframed extended >> settings might get you there, if you can find a way to encapsulate >> conventional settings inside them, then all the better. >> > > Could you elaborate on this a bit? I'm probably just failing to parse, but > I'm not sure which alternative you're suggesting here. (Ah, the wonders of > email.) > > David > I was trying to accommodate HTTP/2 and HTTP/3 in one breath, which is why my intent was probably unclear. Basically, if ALPS relies on frames for per-protocol settings then it has to accommodate the differences in frame format between HTTP/2 and HTTP/3. In the examples from the ALPS and Client Reliability proposals, the H2 frame needs to populate the frame header and it pick stream 0, which doesn't exist until the connection is actually made, so seems a bit kludgy. In H3, frames don't have the stream ID so you avoid the problem above. So my thought was to basically do away with the notion of protocol-specific frames in ALPS, and instead define the a common payload format that perhaps looks something like bishop-extended-settings [1], a series of Type-Length-Value (but without any frame headers). This would allow you to encode the old and new settings in a single format, rather than needing to delineate things via frames. [1] - https://tools.ietf.org/html/draft-bishop-httpbis-extended-settings-01#section-3.1.1 --00000000000053dd0205aaf2acec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Jul 20, 2020 at 10:42 PM David Be= njamin <davidben@chromium.org> wrote:

That makes sense but I guess I don't see the point in defining a = new thing that contains frames that are never sent on streams. That is, if = these are connection settings, just send the payload. Unframed extended set= tings might get you there, if you can find a way to encapsulate conventiona= l settings inside them, then all the better.
<= br>
Could you elaborate on this a bit? I'm probably just fail= ing to parse, but I'm not sure which alternative you're suggesting = here. (Ah, the wonders of email.)

David

I was trying to accommodate HTTP/2 = and HTTP/3 in one breath, which is why my intent was probably unclear. Basi= cally, if ALPS relies on frames for per-protocol settings then it has to ac= commodate the differences in frame format between HTTP/2 and HTTP/3. In the= examples from the ALPS and Client Reliability proposals, the H2 frame need= s to populate the frame header and it pick stream 0, which doesn't exis= t until the connection is actually made, so seems a bit kludgy. In H3, fram= es don't have the stream ID so you avoid the problem above.
<= div>
So my thought was to basically do away with the notion o= f protocol-specific frames in ALPS, and instead define the a common payload= format that perhaps looks something like bishop-extended-settings [1], a s= eries of Type-Length-Value (but without any frame headers). This would allo= w you to encode the old and new settings in a single format, rather than ne= eding to delineate things via frames.

[1] - htt= ps://tools.ietf.org/html/draft-bishop-httpbis-extended-settings-01#section-= 3.1.1
--00000000000053dd0205aaf2acec-- From nobody Tue Jul 21 08:49: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 8069D3A0B3C for ; Tue, 21 Jul 2020 08:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.498 X-Spam-Level: X-Spam-Status: No, score=-9.498 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 T9d1DO6gni4x for ; Tue, 21 Jul 2020 08:49:12 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 7EAB63A0B3E for ; Tue, 21 Jul 2020 08:49:12 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id o13so12134190pgf.0 for ; Tue, 21 Jul 2020 08:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3IrTFsF/VgHlkYRdM24eK+rpDfHEHknL6yVHTzY0Qq0=; b=oLKX31rsr3HDvWGRYp+1ZMX1G+9HlarGxjKf4GMbllWeIpHQrJA8UVUi5nVSCpIFwd B52+vd7gCt6ZcwDcdhSaFCesepU1LDQnrJyVQS9PEzs/vtFUQ58INa1bHi6chpDDWgBc 0Qv5ds4mh05NALolff09NeE1wzc6ldjsEi9vw= 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=3IrTFsF/VgHlkYRdM24eK+rpDfHEHknL6yVHTzY0Qq0=; b=CAJ0xVlivXDjfNJdvmevdur+yIBTUGyR+QY1LPoqfO2WOCOSRHIVTqFil7m6dI3Icv ZZgvSTH3/na0yZnq7Bdo3Az7w8lR1S1bmdJ5Z+puByE0prlTXdQSa6la6oAaMv2um4eE 5xuZ9SKFO+zQMx3+sKJW8bYdNr02a2/CP4ZetESUuPD4jtv9enZdYMnZS2gdAFWWYOto 51XIHpyBHMVvJGRHj9UMwNOWGUskFYk21SETvtc9lBt5XBQ1/36+L6RZVoBqHlwEb7q+ aPYpHbvsUEz14XydZ0wmbpZV0ngdKfIh9hSWXFHAweCRjvckkPsn/kZS9VjE9TF26ZGa t9bA== X-Gm-Message-State: AOAM532Ppxpz5cgIBftzsAVo8dQQiDrGv/sVbt0T1sn7aeDPJ2Rv+mol A2Rp/CGbTw8ttexCnE+EZU1TgN5yhzA9UE3SBdU7 X-Google-Smtp-Source: ABdhPJyA7KlRU1icX8BjKy50Defz0ftTSQP+gfB2KOI8oGxrh+ZO9FkGA+8VxtME8j/jfUNaC1T95ERQ6/vrFwbeIpA= X-Received: by 2002:a63:6e4c:: with SMTP id j73mr22550723pgc.182.1595346551847; Tue, 21 Jul 2020 08:49:11 -0700 (PDT) MIME-Version: 1.0 References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> In-Reply-To: From: David Benjamin Date: Tue, 21 Jul 2020 11:48:55 -0400 Message-ID: To: Lucas Pardue Cc: Victor Vasiliev , "tls@ietf.org" , HTTP Working Group Content-Type: multipart/alternative; boundary="00000000000084992b05aaf59022" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 15:49:15 -0000 --00000000000084992b05aaf59022 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 21, 2020 at 8:22 AM Lucas Pardue wrote: > > On Mon, Jul 20, 2020 at 10:42 PM David Benjamin > wrote: > >> On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue >> wrote: >> >>> >>> That makes sense but I guess I don't see the point in defining a new >>> thing that contains frames that are never sent on streams. That is, if >>> these are connection settings, just send the payload. Unframed extended >>> settings might get you there, if you can find a way to encapsulate >>> conventional settings inside them, then all the better. >>> >> >> Could you elaborate on this a bit? I'm probably just failing to parse, >> but I'm not sure which alternative you're suggesting here. (Ah, the wonders >> of email.) >> >> David >> > > I was trying to accommodate HTTP/2 and HTTP/3 in one breath, which is why > my intent was probably unclear. Basically, if ALPS relies on frames for > per-protocol settings then it has to accommodate the differences in frame > format between HTTP/2 and HTTP/3. In the examples from the ALPS and Client > Reliability proposals, the H2 frame needs to populate the frame header and > it pick stream 0, which doesn't exist until the connection is actually > made, so seems a bit kludgy. In H3, frames don't have the stream ID so you > avoid the problem above. > > So my thought was to basically do away with the notion of > protocol-specific frames in ALPS, and instead define the a common payload > format that perhaps looks something like bishop-extended-settings [1], a > series of Type-Length-Value (but without any frame headers). This would > allow you to encode the old and new settings in a single format, rather > than needing to delineate things via frames. > > [1] - > https://tools.ietf.org/html/draft-bishop-httpbis-extended-settings-01#section-3.1.1 > Ah, gotcha. The thinking was the settings were ALPN-specific anyway, so we may as well define them however is more idiomatic for the protocol. This means we automatically can make existing H2 and H3 settings more reliable. Settings values can also be updated over the course of the connection, so using frames keeps continuity there. But, yeah, a separate key/value syntax would work too. (A small correction, the current Client Hint Reliability proposal allows ACCEPT_CH to be sent in application data too. Maybe the frontend realizes the origin's ACCEPT_CH preferences have changed and wants to notify existing connections. Though I don't consider this feature important. I doubt most folks, if anyone, will bother with this. Mostly that's how a SETTINGS or EXTENDED_SETTINGS value already would have worked, so I figured the semantics ought to be compatible in case EXTENDED_SETTINGS is revived.) David --00000000000084992b05aaf59022 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 21, 2020 at 8:22 AM Lucas Par= due <luc= aspardue.24.7@gmail.com> wrote:
=

On Mon, Jul 20, 2020 at 10:42 PM David Benjamin <davidben@chromium.org> = wrote:
On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue <= lucaspardue= .24.7@gmail.com> wrote:

= That makes sense but I guess I don't see the point in defining a new th= ing that contains frames that are never sent on streams. That is, if these = are connection settings, just send the payload. Unframed extended settings = might get you there, if you can find a way to encapsulate conventional sett= ings inside them, then all the better.

Could you elaborate on this a bit? I'm probably just failing to= parse, but I'm not sure which alternative you're suggesting here. = (Ah, the wonders of email.)

David

I was trying to accommodate HTTP/2 and HT= TP/3 in one breath, which is why my intent was probably unclear. Basically,= if ALPS relies on frames for per-protocol settings then it has to accommod= ate the differences in frame format between HTTP/2 and HTTP/3. In the examp= les from the ALPS and Client Reliability proposals, the H2 frame needs to p= opulate the frame header and it pick stream 0, which doesn't exist unti= l the connection is actually made, so seems a bit kludgy. In H3, frames don= 't have the stream ID so you avoid the problem above.
So my thought was to basically do away with the notion of prot= ocol-specific frames in ALPS, and instead define the a common payload forma= t that perhaps looks something like bishop-extended-settings [1], a series = of Type-Length-Value (but without any frame headers). This would allow you = to encode the old and new settings in a single format, rather than needing = to delineate things via frames.

[1] - https://tools.ietf.org/html/draft-bishop-httpbis-extended-settings= -01#section-3.1.1

Ah,= gotcha. The thinking was the settings were ALPN-specific anyway, so we may= as well define them however is more idiomatic for the protocol. This means= we automatically can make existing H2 and H3 settings more reliable. Setti= ngs values can also be updated over the course of the connection, so using = frames keeps continuity there. But, yeah, a separate key/value syntax would= work too.

(A small correction, the current Client= Hint Reliability proposal allows ACCEPT_CH to be sent in application data = too. Maybe the frontend realizes the origin's ACCEPT_CH preferences hav= e changed and wants to notify existing connections. Though I don't cons= ider this feature important. I doubt most folks, if anyone, will bother wit= h this. Mostly that's how a SETTINGS or EXTENDED_SETTINGS value already= would have worked, so I figured the semantics ought to be compatible in ca= se EXTENDED_SETTINGS is revived.)

David
--00000000000084992b05aaf59022-- From nobody Tue Jul 21 13:22: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 97AAF3A095F for ; Tue, 21 Jul 2020 13:22:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LB7f_mWku52S for ; Tue, 21 Jul 2020 13:22:44 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 6AD013A0965 for ; Tue, 21 Jul 2020 13:22:44 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id x9so82594ljc.5 for ; Tue, 21 Jul 2020 13:22:44 -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 :cc; bh=Fz4avZOD/H4YZt9nH5xT7BsQX2Y0qIggwkhB+HfeGDA=; b=NWk/U5d1RpUqyskAjxJQhwfmXwNvehV9PMcGDhnI+px09XX9VO2DhzNA9rF021fybT Vt5dW6hfXMKvAQ+84V7UhaumwjOdxFeBSTOMwOp6aoWiTiRPwXL982ORe6cms8V+lzIU dyGJqXnByQ4V8qGYvoCJmqEYlG/tZZBTDZprTuifIgQTh5V2mgIUsHRcBKzarWLYUVhR X53EySwkQAZU9hGUd+ZYhBRAp0XNj9T1rytwD9+/8LK5i3mK6IjE1p62lczRPc1OT0Qp Nwbbl73URv+HzuTE+K+3ZCcgiy+KLRlArDW+bExfSBJQS1S4O0uDOMDtAqq/H5B+re4l UB4g== 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=Fz4avZOD/H4YZt9nH5xT7BsQX2Y0qIggwkhB+HfeGDA=; b=hyUSOF/f2MI2gD8AKoNoPYzaBK2aAjUOyF8qP1Y+pCt590M3HMop3AOLKVpFgf19Am 7kxo16fe65BefC9xIlTnkmxIQAQ6JAe1MZw8DydFJmwfQOmU544WZbU+e2bm5wXf2K+9 uYHc79dTQer6JmaC0YY8BN7tF4SWFqXq2nTflXCNcIkcw9wo6TOV0j/rUA/3d0o16+MP Ju4iYMiPVq+zi9cQNjA+UJ2MWK6DyNggUuOl6WjVByAF+AV7B7K3MYtTznLeJwZavL75 Ek4PzRjDfG8tn+mzwk4rnukXf2B6Fgl/vz1L9Meen8HuJ4dq8xbV2NKZUnFPoCFC4q2H wacg== X-Gm-Message-State: AOAM531ODznU0j82OwOLSckbhAhL4lEk7sozyeuG3FN+8OosjtfVAGNZ V7eFHUz1qBpEmuZmKsikP4H+7z+0GoU0pZ7oMDbYlg== X-Google-Smtp-Source: ABdhPJwvjfV/57Stz/lmQ27lviv1Zr4EmqOMK4j0HWghhlMKvu0xc0j/xCHO/GgUSOBrRc9TosF8bTaJb13AI2Rc1Uk= X-Received: by 2002:a2e:9b87:: with SMTP id z7mr14524797lji.80.1595362962121; Tue, 21 Jul 2020 13:22:42 -0700 (PDT) MIME-Version: 1.0 References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> In-Reply-To: From: Victor Vasiliev Date: Tue, 21 Jul 2020 16:22:30 -0400 Message-ID: To: David Benjamin Cc: Lucas Pardue , "tls@ietf.org" , HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000a5b76c05aaf96275" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 20:22:47 -0000 --000000000000a5b76c05aaf96275 Content-Type: text/plain; charset="UTF-8" How would this work with regular SETTINGS? HTTP/2 and HTTP/3 have disjoint setting number spaces, and it's unclear to me whether there's any significant overlap between those. On Tue, Jul 21, 2020 at 11:49 AM David Benjamin wrote: > On Tue, Jul 21, 2020 at 8:22 AM Lucas Pardue > wrote: > >> >> On Mon, Jul 20, 2020 at 10:42 PM David Benjamin >> wrote: >> >>> On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue < >>> lucaspardue..24.7@gmail.com > wrote: >>> >>>> >>>> That makes sense but I guess I don't see the point in defining a new >>>> thing that contains frames that are never sent on streams. That is, if >>>> these are connection settings, just send the payload. Unframed extended >>>> settings might get you there, if you can find a way to encapsulate >>>> conventional settings inside them, then all the better. >>>> >>> >>> Could you elaborate on this a bit? I'm probably just failing to parse, >>> but I'm not sure which alternative you're suggesting here. (Ah, the wonders >>> of email.) >>> >>> David >>> >> >> I was trying to accommodate HTTP/2 and HTTP/3 in one breath, which is why >> my intent was probably unclear. Basically, if ALPS relies on frames for >> per-protocol settings then it has to accommodate the differences in frame >> format between HTTP/2 and HTTP/3. In the examples from the ALPS and Client >> Reliability proposals, the H2 frame needs to populate the frame header and >> it pick stream 0, which doesn't exist until the connection is actually >> made, so seems a bit kludgy. In H3, frames don't have the stream ID so you >> avoid the problem above. >> >> So my thought was to basically do away with the notion of >> protocol-specific frames in ALPS, and instead define the a common payload >> format that perhaps looks something like bishop-extended-settings [1], a >> series of Type-Length-Value (but without any frame headers). This would >> allow you to encode the old and new settings in a single format, rather >> than needing to delineate things via frames. >> >> [1] - >> https://tools.ietf.org/html/draft-bishop-httpbis-extended-settings-01#section-3.1.1 >> > > Ah, gotcha. The thinking was the settings were ALPN-specific anyway, so we > may as well define them however is more idiomatic for the protocol. This > means we automatically can make existing H2 and H3 settings more reliable. > Settings values can also be updated over the course of the connection, so > using frames keeps continuity there. But, yeah, a separate key/value syntax > would work too. > > (A small correction, the current Client Hint Reliability proposal allows > ACCEPT_CH to be sent in application data too. Maybe the frontend realizes > the origin's ACCEPT_CH preferences have changed and wants to notify > existing connections. Though I don't consider this feature important. I > doubt most folks, if anyone, will bother with this. Mostly that's how a > SETTINGS or EXTENDED_SETTINGS value already would have worked, so I figured > the semantics ought to be compatible in case EXTENDED_SETTINGS is revived.) > > David > --000000000000a5b76c05aaf96275 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
How would this work with regular SETTINGS?=C2=A0 HTTP/2 an= d HTTP/3 have disjoint setting number spaces, and it's unclear to me wh= ether there's any significant overlap between those.

On Tue, Jul 21, 202= 0 at 11:49 AM David Benjamin <d= avidben@chromium.org> wrote:
On Tue, Jul 21, 2020 = at 8:22 AM Lucas Pardue <lucaspardue.24.7@gmail.com> wrote:

On Mon, Jul 20, 2020 at 10:42 PM David Benjam= in <davidben@= chromium.org> wrote:
On Mon, Jul 20, 2020 at 5:00 = PM Lucas Pardue <lucaspardue..24.7@gmail.com> wrote:

That makes sense but I guess I don't see the point= in defining a new thing that contains frames that are never sent on stream= s. That is, if these are connection settings, just send the payload. Unfram= ed extended settings might get you there, if you can find a way to encapsul= ate conventional settings inside them, then all the better.

Could you elaborate on this a bit? I'm pro= bably just failing to parse, but I'm not sure which alternative you'= ;re suggesting here. (Ah, the wonders of email.)

D= avid

I was trying to acco= mmodate HTTP/2 and HTTP/3 in one breath, which is why my intent was probabl= y unclear. Basically, if ALPS relies on frames for per-protocol settings th= en it has to accommodate the differences in frame format between HTTP/2 and= HTTP/3. In the examples from the ALPS and Client Reliability proposals, th= e H2 frame needs to populate the frame header and it pick stream 0, which d= oesn't exist until the connection is actually made, so seems a bit klud= gy. In H3, frames don't have the stream ID so you avoid the problem abo= ve.

So my thought was to basically do away wi= th the notion of protocol-specific frames in ALPS, and instead define the a= common payload format that perhaps looks something like bishop-extended-se= ttings [1], a series of Type-Length-Value (but without any frame headers). = This would allow you to encode the old and new settings in a single format,= rather than needing to delineate things via frames.

[1] - https://tools.ietf.org/html/draft-bishop-ht= tpbis-extended-settings-01#section-3.1.1
=

Ah, gotcha. The thinking was the settings were ALPN-spe= cific anyway, so we may as well define them however is more idiomatic for t= he protocol. This means we automatically can make existing H2 and H3 settin= gs more reliable. Settings values can also be updated over the course of th= e connection, so using frames keeps continuity there. But, yeah, a separate= key/value syntax would work too.

(A small correct= ion, the current Client Hint Reliability proposal allows ACCEPT_CH to be se= nt in application data too. Maybe the frontend realizes the origin's AC= CEPT_CH preferences have changed and wants to notify existing connections. = Though I don't consider this feature important. I doubt most folks, if = anyone, will bother with this. Mostly that's how a SETTINGS or EXTENDED= _SETTINGS value already would have worked, so I figured the semantics ought= to be compatible in case EXTENDED_SETTINGS is revived.)

David
--000000000000a5b76c05aaf96275-- From nobody Tue Jul 21 13:59: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 E925B3A0A6E for ; Tue, 21 Jul 2020 13:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.498 X-Spam-Level: X-Spam-Status: No, score=-9.498 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 P0hot04DcOL4 for ; Tue, 21 Jul 2020 13:59:47 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 750C13A0A6D for ; Tue, 21 Jul 2020 13:59:46 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id b9so10787177plx.6 for ; Tue, 21 Jul 2020 13:59:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M+aMBFQIDIALP6IObYer7Yq/vCX4nsR/hepPJOi5zLI=; b=NGDJIWrpjwxJ6ESYULPuuC4YF6iBqn8heFHOglawcONlk5tou4RhEuSGzfcSNVmMzl 0sj1i2Iy/oXqqoWOKYrWFE3VUTf2r+694x4RAMAoiardXojY6B2bYRsZlpyOXiqADbD2 8SkRwqEDA4W2cQqfR6zVeNnMAF4OFb5GvndQU= 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=M+aMBFQIDIALP6IObYer7Yq/vCX4nsR/hepPJOi5zLI=; b=Lya400bh6SBjEONL2iUP1adFTOPqJSUPvl1PejN4UtxElZY5zTKqO1QkKmhAhEV4TD 8kOFCcqxbe31dKU46IervNng9L1zegudfLFWMLflWEnLUH+vxmmqNPDnUmpQr/tCtU4Z lwIzfbueEY6/XwRe4zuuqLaPfcvLszYqlYN17BT/dIFNNlZP1SbTaW83Y+AxeZ5DPLoQ jGuOQXxlcfJQHoFusjXceO/yqFxPz5g79pp10mm5tVW9RdeHcX3skNZieskWxcwG0xI4 qcmGyHwJ2fi7qPvwzh9hD9cz3UUHwtagIjpUa7SbxkEOmRfaAzXJAIfgQuXP4v9wofok 1QKQ== X-Gm-Message-State: AOAM532TdLybbferkszSHTdRKYP55iFCugyKcQjJIMFbFBF96qfvWme0 /3uawTUD8XiBpqrdAFg4NDkv/96aNaUo+HnW5ayJ X-Google-Smtp-Source: ABdhPJwB6EzNt+5mSYq4Z3c8gJWXRY80r57PqLfwpHPEltySX5Tt8fU6RRB1POX6HXuAwu4Ybd7S7IXhkYum1U72A5Y= X-Received: by 2002:a17:90a:a78b:: with SMTP id f11mr6328601pjq.42.1595365185595; Tue, 21 Jul 2020 13:59:45 -0700 (PDT) MIME-Version: 1.0 References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> In-Reply-To: From: David Benjamin Date: Tue, 21 Jul 2020 16:59:29 -0400 Message-ID: To: Victor Vasiliev Cc: Lucas Pardue , "tls@ietf.org" , HTTP Working Group Content-Type: multipart/alternative; boundary="0000000000002d00cf05aaf9e79c" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 20:59:49 -0000 --0000000000002d00cf05aaf9e79c Content-Type: text/plain; charset="UTF-8" I guess you could have protocol-specific numbers and protocol-independent syntax? Or you could allocate numbers in yet another number space for all the existing settings. The latter seems like a lot of fuss, and the former is kinda weird. At that point you may as well get a protocol-specific blob (as in the draft) so the protocol library can reuse their preferred parsing routines. On Tue, Jul 21, 2020 at 4:22 PM Victor Vasiliev wrote: > How would this work with regular SETTINGS? HTTP/2 and HTTP/3 have > disjoint setting number spaces, and it's unclear to me whether there's any > significant overlap between those. > > On Tue, Jul 21, 2020 at 11:49 AM David Benjamin > wrote: > >> On Tue, Jul 21, 2020 at 8:22 AM Lucas Pardue >> wrote: >> >>> >>> On Mon, Jul 20, 2020 at 10:42 PM David Benjamin >>> wrote: >>> >>>> On Mon, Jul 20, 2020 at 5:00 PM Lucas Pardue < >>>> lucaspardue..24.7@gmail.com > wrote: >>>> >>>>> >>>>> That makes sense but I guess I don't see the point in defining a new >>>>> thing that contains frames that are never sent on streams. That is, if >>>>> these are connection settings, just send the payload. Unframed extended >>>>> settings might get you there, if you can find a way to encapsulate >>>>> conventional settings inside them, then all the better. >>>>> >>>> >>>> Could you elaborate on this a bit? I'm probably just failing to parse, >>>> but I'm not sure which alternative you're suggesting here. (Ah, the wonders >>>> of email.) >>>> >>>> David >>>> >>> >>> I was trying to accommodate HTTP/2 and HTTP/3 in one breath, which is >>> why my intent was probably unclear. Basically, if ALPS relies on frames for >>> per-protocol settings then it has to accommodate the differences in frame >>> format between HTTP/2 and HTTP/3. In the examples from the ALPS and Client >>> Reliability proposals, the H2 frame needs to populate the frame header and >>> it pick stream 0, which doesn't exist until the connection is actually >>> made, so seems a bit kludgy. In H3, frames don't have the stream ID so you >>> avoid the problem above. >>> >>> So my thought was to basically do away with the notion of >>> protocol-specific frames in ALPS, and instead define the a common payload >>> format that perhaps looks something like bishop-extended-settings [1], a >>> series of Type-Length-Value (but without any frame headers). This would >>> allow you to encode the old and new settings in a single format, rather >>> than needing to delineate things via frames. >>> >>> [1] - >>> https://tools.ietf.org/html/draft-bishop-httpbis-extended-settings-01#section-3.1.1 >>> >> >> Ah, gotcha. The thinking was the settings were ALPN-specific anyway, so >> we may as well define them however is more idiomatic for the protocol. This >> means we automatically can make existing H2 and H3 settings more reliable. >> Settings values can also be updated over the course of the connection, so >> using frames keeps continuity there. But, yeah, a separate key/value syntax >> would work too. >> >> (A small correction, the current Client Hint Reliability proposal allows >> ACCEPT_CH to be sent in application data too. Maybe the frontend realizes >> the origin's ACCEPT_CH preferences have changed and wants to notify >> existing connections. Though I don't consider this feature important. I >> doubt most folks, if anyone, will bother with this. Mostly that's how a >> SETTINGS or EXTENDED_SETTINGS value already would have worked, so I figured >> the semantics ought to be compatible in case EXTENDED_SETTINGS is revived.) >> >> David >> > --0000000000002d00cf05aaf9e79c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I guess you could have protocol-specific numbers and proto= col-independent syntax? Or you could allocate numbers in yet another number= space for all the existing settings. The latter seems like a lot of fuss, = and the former is kinda weird. At that point you may as well get a protocol= -specific blob (as in the draft) so the protocol library can reuse their pr= eferred parsing routines.

On Tue, Jul 21, 2020 at 4:22 PM Victor Vasiliev &l= t;vasilvv@google.co= m> wrote:
How would this work with regular SETTINGS?=C2=A0 HTTP/2 a= nd HTTP/3 have disjoint setting number spaces, and it's unclear to me w= hether there's any significant overlap between those.

On Tue, Jul 21, 20= 20 at 11:49 AM David Benjamin <davidben@chromium.org> wrote:
On= Tue, Jul 21, 2020 at 8:22 AM Lucas Pardue <lucaspardue.24.7@gmail.com> wrot= e:

On Mon, Jul 20, 2020 at 10:= 42 PM David Benjamin <davidben@chromium.org> wrote:
On Mon, Jul= 20, 2020 at 5:00 PM Lucas Pardue <lucaspardue..24.7@gmail.com> wrote:

That makes sense but I guess I don&#= 39;t see the point in defining a new thing that contains frames that are ne= ver sent on streams. That is, if these are connection settings, just send t= he payload. Unframed extended settings might get you there, if you can find= a way to encapsulate conventional settings inside them, then all the bette= r.

Could you elaborate on this = a bit? I'm probably just failing to parse, but I'm not sure which a= lternative you're suggesting here. (Ah, the wonders of email.)

David

I = was trying to accommodate HTTP/2 and HTTP/3 in one breath, which is why my = intent was probably unclear. Basically, if ALPS relies on frames for per-pr= otocol settings then it has to accommodate the differences in frame format = between HTTP/2 and HTTP/3. In the examples from the ALPS and Client Reliabi= lity proposals, the H2 frame needs to populate the frame header and it pick= stream 0, which doesn't exist until the connection is actually made, s= o seems a bit kludgy. In H3, frames don't have the stream ID so you avo= id the problem above.

So my thought was to ba= sically do away with the notion of protocol-specific frames in ALPS, and in= stead define the a common payload format that perhaps looks something like = bishop-extended-settings [1], a series of Type-Length-Value (but without an= y frame headers). This would allow you to encode the old and new settings i= n a single format, rather than needing to delineate things via frames.
<= br>[1] - https://tools.ietf.org/html= /draft-bishop-httpbis-extended-settings-01#section-3.1.1

Ah, gotcha. The thinking was the settin= gs were ALPN-specific anyway, so we may as well define them however is more= idiomatic for the protocol. This means we automatically can make existing = H2 and H3 settings more reliable. Settings values can also be updated over = the course of the connection, so using frames keeps continuity there. But, = yeah, a separate key/value syntax would work too.

= (A small correction, the current Client Hint Reliability proposal allows AC= CEPT_CH to be sent in application data too. Maybe the frontend realizes the= origin's ACCEPT_CH preferences have changed and wants to notify existi= ng connections. Though I don't consider this feature important. I doubt= most folks, if anyone, will bother with this. Mostly that's how a SETT= INGS or EXTENDED_SETTINGS value already would have worked, so I figured the= semantics ought to be compatible in case EXTENDED_SETTINGS is revived.)

David
--0000000000002d00cf05aaf9e79c-- From nobody Tue Jul 21 16:44:04 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 056D23A0824 for ; Tue, 21 Jul 2020 16:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 kn0gfv6dWJoL for ; Tue, 21 Jul 2020 16:44:00 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 5C8213A0822 for ; Tue, 21 Jul 2020 16:44:00 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id z2so170040wrp.2 for ; Tue, 21 Jul 2020 16:44:00 -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=dNVQropl5bsAkeJ/JRQEWcp5dDA2i49P8IP/LDOPsCI=; b=FkwvweCwp0lVoY4MqD7R5iXncpwT5oGjRxEeeewzlZHPqRHYsDj22crCc1RiBDER4U KG5+tKHChINyHL9OuswHnGAaBs1xAVhN28qQByj4wITbgU5w09YwsjG7SmtlyiQjMgQJ nbUSjDfgqEsy/sq2v5MDqdudBYwFV8sPDr1LeSSSocmztezMfsvlIKSzrou6xmV7HR91 Sp1jKy+7w++CDcKRkw5/UW4DB+ckA4LfiRw4Hop6CRVkTb229GdNPXAh2oy8qlJQXhlu byj6MWml9rplQSbmn/8tBl04d5FonckIGNvxTjbYyYhJOWRNTMju4zzch/Zh65zcaGHG oyJg== 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=dNVQropl5bsAkeJ/JRQEWcp5dDA2i49P8IP/LDOPsCI=; b=F3lL68Pvxa42grXQbmU4LnwttP2A4KKqgxMCsc+Et59MIohNajlGzt9CY5IceX0oub t6eVqexxMq2C/1CGWETwwsPC/wUEbG+VPrBM4gFh5Y4bWmBN3NJohV4ynXqACOmqou9O qxhG9Fg3IcOAA4ETaFLf4xe69bKIPSG79Ug+KpMkr+HDhjI1iLQgDtw5z7LFrUpj2E6C xQpxZ5NwiD9k1dQkuSdSkKZLqaQ7NX2sjmjVQY6+yipu4R+0glK+XallT9o7RFXSfjkh nZ4BoHVAT/i4oz2lqoOCZeonWPg76r+VGNWkyDR3eFl6gMER+UY6V7PfOfHJjAA0R0Qq j6Fw== X-Gm-Message-State: AOAM530kEvMHTdmBwqVLaR6f+0cHJ47COCEjPQud6qrVibUfUeVWf63k 4Pf9qxloi593ngtPHWnGS4lBAf5VSqnZB+sAfzc= X-Google-Smtp-Source: ABdhPJyKhr96JkHby/e6el51dbF2+ehytlvtFwPicV5rIWm01r+7yqRsozQVxooRTdGDUrxB/m3NnrPPS1w+0uil1iE= X-Received: by 2002:a5d:408f:: with SMTP id o15mr19844354wrp.7.1595375038793; Tue, 21 Jul 2020 16:43:58 -0700 (PDT) MIME-Version: 1.0 References: <374ebd02-c3f6-4124-a1e9-c2f4a17e6c54@www.fastmail.com> In-Reply-To: From: Lucas Pardue Date: Wed, 22 Jul 2020 00:43:46 +0100 Message-ID: To: David Benjamin Cc: Victor Vasiliev , "tls@ietf.org" , HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000788aea05aafc320b" Archived-At: Subject: Re: [TLS] Application-Layer Protocol Settings 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 Jul 2020 23:44:02 -0000 --000000000000788aea05aafc320b Content-Type: text/plain; charset="UTF-8" As I understood things in ALPS, each application protocol has its own settings so I don't see there being too much problem with the disjoint number spaces. It is a bit fussy but it avoids having to rework existing stacks to parse frames that don't belong to any streams. From the stacks that I'm experienced with, frame parsing and stream state are wrapped tightly. Unless you mean that you expect an endpoint to use parsing primitives to parse a frame, which seems like it would duplicate things. Instead just having unframed settings that carry properties of a yet-to-be-fully-instantiated endpoint connection seems something to have less impact. But of course YMMV. Cheers Lucas --000000000000788aea05aafc320b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I understood things in ALPS,= each application protocol has its own settings so I don't see there be= ing too much problem with the disjoint number spaces. It is a bit fussy but= it avoids having to rework existing stacks to parse frames that don't = belong to any streams.=C2=A0 >From the stacks that I'm experienced with, frame parsing and stream state are wrapped tightly. Unless you mean that yo= u expect an endpoint to use parsing primitives to parse a frame, which seem= s like it would duplicate things. Instead just having unframed settings tha= t carry properties of a yet-to-be-fully-instantiated endpoint connection se= ems something to have less impact. But of course YMMV.

Cheers
Lucas
--000000000000788aea05aafc320b-- From nobody Tue Jul 21 18:21: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 F11073A07BB for ; Tue, 21 Jul 2020 18:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-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=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 fIullGyc3QTu for ; Tue, 21 Jul 2020 18:21:12 -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 D5EE43A07BA for ; Tue, 21 Jul 2020 18:21:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A3E62BE2E; Wed, 22 Jul 2020 02:21:09 +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 jq1Xpv8cZNy3; Wed, 22 Jul 2020 02:21:07 +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 9144DBE20; Wed, 22 Jul 2020 02:21:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1595380867; bh=5fUtKArS009fbU1QPtify6GsA/Di9gpYBNTpkibrx0Y=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=0aenv4gKsLdZZs8PemASj66hC1877wp9OKP3HJ6WTnA0F/ypt3bxI1pCG7rgTV+Yx 9DLyeGc0i/obmy5fdaEvGMpatHU6WD88Q1yrLPkx2YbHuGBiqT9JGFSCNkJWRChK5l FN+YOR3rjXqnLuaqHVlBq3T2tf8q/JexO+OW1Vko= From: Stephen Farrell To: Benjamin Kaduk Cc: tls@ietf.org References: <20191111195325.GE32847@kduck.mit.edu> <0390e6c8-dd19-8d5a-45b2-79ac0f1461c5@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: <0cc8af80-811d-f287-eb20-766498a7e08f@cs.tcd.ie> Date: Wed, 22 Jul 2020 02:21:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="goCX3qcNvCAr6RsnXhr82TYStp4w8qz4F" Archived-At: Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 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 Jul 2020 01:21:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --goCX3qcNvCAr6RsnXhr82TYStp4w8qz4F Content-Type: multipart/mixed; boundary="XwtAWHeLu7R79b9Ko73GCquqGTQonkrv4"; protected-headers="v1" From: Stephen Farrell To: Benjamin Kaduk Cc: tls@ietf.org Message-ID: <0cc8af80-811d-f287-eb20-766498a7e08f@cs.tcd.ie> Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 References: <20191111195325.GE32847@kduck.mit.edu> <0390e6c8-dd19-8d5a-45b2-79ac0f1461c5@cs.tcd.ie> In-Reply-To: --XwtAWHeLu7R79b9Ko73GCquqGTQonkrv4 Content-Type: multipart/mixed; boundary="------------0BFE1B78053C3A687EB4C9F6" Content-Language: en-US This is a multi-part message in MIME format. --------------0BFE1B78053C3A687EB4C9F6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, It's now six and a bit months later. It's true those have been very distracting months for us all but when are we hoping to progress this draft? S On 12/05/2020 10:59, Stephen Farrell wrote: >=20 > Hi, >=20 > It's now four and a bit months later. It's true those have > been very distracting months for us all but when are we > hoping to progress this draft? >=20 > Thanks, > S. >=20 > On 06/01/2020 15:16, Stephen Farrell wrote: >> >> Hi all, >> >> I've just submitted -06 that (I think/hope:-) addresses >> the issues in Ben's preliminary AD review. >> >> So the ball's back in Ben's court until he finds more >> stuff that needs fixing or starts IETF LC:-) >> >> Cheers, >> S. >> >> >> _______________________________________________ >> 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 --------------0BFE1B78053C3A687EB4C9F6 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----- --------------0BFE1B78053C3A687EB4C9F6-- --XwtAWHeLu7R79b9Ko73GCquqGTQonkrv4-- --goCX3qcNvCAr6RsnXhr82TYStp4w8qz4F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl8XlIMACgkQWrL68XsX K+oZ4w/+NNpvPaGgFSHq5SsuDXo12kcj8VGu+ArWA+wmGqXK6LDQPQ7C1CFlSBOh 5uyRO20yao/eDbec0faFvvzMeFF+ULkyts90wZt6HqG5mbLGFExUcgPFMKP5sJ+w zu1OEuffHFOUAVeDGzs4QNrSbNsoq0CE88fn7MoNPe9uR5qmp7WkrmQ5CBu+WnfX khSjG6jQ7PzZ0Y7EtK8w728FP7J4ec+5hDpkY+NcUzrFXhOWAnN96LAc27YdUkjO 0QwrS20sUUmmyIiu4hn6G88d4D+pgSAMKvPtICaiCwB9EW4Vtd8rwSPuJsDHTIfU tudLbPb0yuZ5tym7x7aiZ3iNVZ7WVQ//ctnU+LjX4fz9ACCc+qcBuorYnzwqiDkW 7zQ/EPRnou5g+YiS7yow8u9Lf2StWdCbeg4puPgJEdOkVbJv5tUDUhHCfaSt0w9G S1jCJn0ge5f9AnsQ16uIQVtmTc1Hm+VmgDkzyUezHcFoNRevMYF9d1+5KbVnNY2z fVFyt6+RVlioToMKCPl5LkbY0s3SQ6IoDQtQLPbobaBIQjLj4gCNMqKkZkL70SRK mAp7AeXSE98mUDKwZcbA780VYiOMGIoowtfNxs0S2RPrp564G9JvnpRBmwiSrF25 y+Ed/PmYgDDQKzbmGOapZ2nWn3WXr8BIbpeCumyv+TFnXItQTH4= =p0CA -----END PGP SIGNATURE----- --goCX3qcNvCAr6RsnXhr82TYStp4w8qz4F-- From nobody Tue Jul 21 23:53:30 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 13F963A0E70 for ; Tue, 21 Jul 2020 23:53: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, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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 FjqTSTvi-zAC for ; Tue, 21 Jul 2020 23:53:27 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 4D0523A0E6E for ; Tue, 21 Jul 2020 23:53:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1595400802; bh=gwBmAUyYXb6VLHj17tTwdYNHDpIHVYlecPALiDpA2nY=; h=X-UI-Sender-Class:To:From:Subject:Date; b=QKgt6azqVI9229l6JT2loPxu3I0fY+87NfJIyRZifS4v/g99JeHdV5G7Spj6V4pNc pUNHM6jLWFcazXo0xohT10yxdGiNfH6D80KnkbBvYJncjOMrhHUILfebzj2k1VoS7I TbnK3md8HmTtkTzXS3ED0jDqCZJnGICCn+UuE2RA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([94.216.229.78]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MQMuR-1kB0mh0tIP-00MMzb for ; Wed, 22 Jul 2020 08:53:22 +0200 To: "tls@ietf.org" From: Achim Kraus Message-ID: Date: Wed, 22 Jul 2020 08:53:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:0k/V8/sJSVZKMPb5e4OYncMnCFvf5DnWT1U7o4ahfPFAJWGgX4a RMzkhXMh3O0heFSxe4Dujqjh2tX6GnDjuOoBS4ldXQZmNgcMVxnLvDbPMYJbK6Q/0vSfYn9 9CJdvtlhT/jlxqvX8hpwW1zlnE4eMtFRRcqX9K8o9Tv4ANEVJkyQXm/4MnxssC2yQqic45r XS3Ivr5a0LCxSjeZQU6Ig== X-UI-Out-Filterresults: notjunk:1;V03:K0:yboctqr3C00=:ZkFpLvArmzL5Oimxu3i4NW 9OF0+MolWYG32B5c00q7W00xC8Mq/m3/HxBQPj67LmjBzQUcvP5p0tDo6QyhoWPi0skGDJtye ZONWMC2TyeqcIznZuIkW6hF8OVSgHA/kYI2CQDXZeDrBNwCwG4KxjYsciAVqXiu55IC9BrvJJ icrjXHFqZmcNxsaeoTwqGglf7zFkbP11lNGHkxQxoGP6C/tzGxsZ+rEWFnyi1j0pKrW6YlcGL fsdWnNTeeNdiPL/dWtg+sKLAiQdkZmUSVwLxXGLqV1pUKRrTA7/Mjwm1qcQNRx1mLTf3JLRIG ndqxLmGWmpt2FyfpJbUd04Pp2RLUy7b0jgCUYEBQCmnxc4WF/l059CKJlr3a/J3iCU4eSzT5I TGJ+3fS2xtQL0J8HSYE6jtZBVF/qPqAKhbn3h9qT9ArCBa4LsE3kDpxUIkfLYs7w3d88nrHnZ yq/uHd2Pk9mSr6mNFhtg45qvCx0AUbD0q13CFonRDoIg69RMGEi40kqSMGED3loPTcXDAl7XK bHDo6cC28O0ycFe4HF2An4RvzA5ZRrQ2ysulK9WfMFk4k3btGqa4jC27y0yquaaefzmc/V0XK phKwdGLF9fPSpyALbTv3KzaIglscYUMpC5df2DAgIIOpFbJiW4QGHrQcZbt4oyrvAaetBkRsp 6MSBHJNHG9nJDlQfE5rZoFVRcx7jhnpNoQT2DtK7Fc6CFUvQK0qQdQ1HXqJ5aFV0YLrQPX0zT 4KKFAnZk1qPpemS+OuNdjWZubhyzrwrGoD7SKIC8Djs4JSD+K9LCCLAbHlc/kzemTfWWGgfaa yzY2T6SSjY1ow4Rq0a699toXdZRXLc+cmXTI7ToZY8+0OfTE6TRD0YwMxiJpB4DAIboWV1BYX zm+zmOm5J7pTTh2CKCRrENIf4QGM/X1kq7NTyEgtz9F4xgHjRrnTrQ41p8hNiHW4/tEI0i2rV 8vjboraTFZy1mdB24t5Cr2KvCqYyEDcCQmZ3cCon9AxaSLjp8PjmFFK6zGLN7/74ACm7MIOqL hIVVRoGiTShXYTSjy98vx2sNbrbQZ3Err9fG6fKPaZN5/Ly2rlL6qsLnKPEcJaLxXcE34EPKw EiOhhh1Cp6kwih1jsWeLutgjp4+ct5aHgPXA9PvxItVXRX7B+bW+3ndLRMbjeKjC4mARPNM8n cUnA4Dvih2NAkS/hmx3aC/mjKxrJVWaYUTyIeSBIOPY3qhA2WjEbt/vJlbrT+tlAS7lpBxktN IA0cTnYcmYRj9u0mBkR84w2ISj08BEKKcsJVntA== Archived-At: Subject: [TLS] draft-ietf-tls-dtls-connection-id-07 / IANA connection_id 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 Jul 2020 06:53:29 -0000 Dear list, are there any news about the draft-ietf-tls-dtls-connection-id and the IANA registration of the connection_id? According https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id the draft expired on April 23, 2020 and according https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontyp= e-values.xhtml the assigned value expired on 2020-07-02. I still very interested in this extension, it makes coap over dtls 1.2 a very powerful technology for the cloud and NB IoT. Currently two pending threats are discussed, see the PRs in https://github.com/tlswg/dtls-conn-id . One of both is in my opinion a general one using UDP, several countermeasures are discussed, including RRC. Let me add, that in my opinion, it's also about to chose cid for the right use-case, and not generally. That would mostly eliminated the DDoS threat, if the use-case doesn't offer an amplification. The other one requires in my opinion a remark about not using the option of RFC 6347 to generate an alert on invalid MACs, if the cid is used. Potentially, if of any interest at all, an additional remark about AES-CBC, the CID length and "lucky 13" maybe added, though the cid changes the 13. For me this looks much more, that the authors are too busy with other work and not that this draft doesn't make sense anymore. Therefore I would appreciate, if the temporary IANA registration for the connection_id could be extended by an additional year. Best regards Achim Kraus From nobody Wed Jul 22 09:24: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 093B13A0AB3 for ; Wed, 22 Jul 2020 09:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 2f_Td9ls67Vu for ; Wed, 22 Jul 2020 09:24:53 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 398073A0AB0 for ; Wed, 22 Jul 2020 09:24:52 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06MGOkip009580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Jul 2020 12:24:48 -0400 Date: Wed, 22 Jul 2020 09:24:45 -0700 From: Benjamin Kaduk To: Stephen Farrell Cc: tls@ietf.org Message-ID: <20200722162445.GI41010@kduck.mit.edu> References: <20191111195325.GE32847@kduck.mit.edu> <0390e6c8-dd19-8d5a-45b2-79ac0f1461c5@cs.tcd.ie> <0cc8af80-811d-f287-eb20-766498a7e08f@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0cc8af80-811d-f287-eb20-766498a7e08f@cs.tcd.ie> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [TLS] preliminary AD review of draft-ietf-tls-oldversions-deprecate-05 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 Jul 2020 16:24:55 -0000 Hi Stephen, This is currently #2 in my queue; I expect to have a non-preliminary review this week. Thank you for your patience, and the reminder, Ben On Wed, Jul 22, 2020 at 02:21:07AM +0100, Stephen Farrell wrote: > > Hi, > > It's now six and a bit months later. It's true those have > been very distracting months for us all but when are we > hoping to progress this draft? > > S > > > On 12/05/2020 10:59, Stephen Farrell wrote: > > > > Hi, > > > > It's now four and a bit months later. It's true those have > > been very distracting months for us all but when are we > > hoping to progress this draft? > > > > Thanks, > > S. > > > > On 06/01/2020 15:16, Stephen Farrell wrote: > >> > >> Hi all, > >> > >> I've just submitted -06 that (I think/hope:-) addresses > >> the issues in Ben's preliminary AD review. > >> > >> So the ball's back in Ben's court until he finds more > >> stuff that needs fixing or starts IETF LC:-) > >> > >> Cheers, > >> S. > >> > >> > >> _______________________________________________ > >> 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 Jul 22 11: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 7F5503A0882 for ; Wed, 22 Jul 2020 11:55:24 -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 yuiIpilDJH2t for ; Wed, 22 Jul 2020 11:55:23 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 236223A0872 for ; Wed, 22 Jul 2020 11:55:22 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id k18so2604370qtm.10 for ; Wed, 22 Jul 2020 11:55:22 -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=jbl7lKHMO6MSG5cbym98T89V/f5hol5DKf8Tu7VqfwA=; b=DKjQXeG9I0ADTpq7DpDrxDqSV8YEJ9+ze3oHQ+HiArAes3+T2MuFJQF2QQY5pNkTJr XJ3SA4089IMqOVXJXxx+9P4svHDKtOHenAOczHq0yekESQ28koA/pfFzwn3uC06qYFB7 lObgoBHMLd8WlN6u7qEEVem5oTzoXumRHbqwc= 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=jbl7lKHMO6MSG5cbym98T89V/f5hol5DKf8Tu7VqfwA=; b=Woh6l6I/FZpMH1wCWAFH9b5qhO4IQJHRrv+sKQ5UqO2tQnLNs/UNGT3lXS5jPvoVKI NYgIZ97+qNmfn32CA9dHf6qAbWemAifNmktuZTaOqlzV3Knpgxq65Os68wO4rq3TJl80 Yxs9TsKMpIeanoRzoyOOgsA4QipHlTSe4/7itWUX+wB69cw39nk8J3ZCT8XTkRZxDOmJ HF+A3ZHoa8/bR/bFTr3f7yd1BM2CchTyyJlhas1agJv8fELbYek8+02mhZuChn6++sTW 9KbwNIz/9SU144WDghaaPM4u8sfrQl478jc9RcUUEFzOoUYiJ3gY1UPp3dNgXVjUZ5Ec EmDA== X-Gm-Message-State: AOAM532yTNmZ1wfK300CP1mcoJxBJv3+MxUKyMnSHkR87svZFqRVcG7h 0xcqnwlBtwvaElFEMIPaNmLlAmyEYMM= X-Google-Smtp-Source: ABdhPJzGl2zCagM8t5HLmP3WYEr2gZ0E3bQG5eFhJkZb7q3IE49XxDDbOawnP1I/Llt6VmWlFhdWeQ== X-Received: by 2002:ac8:75c4:: with SMTP id z4mr752361qtq.371.1595444121729; Wed, 22 Jul 2020 11:55:21 -0700 (PDT) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id x24sm534895qtj.8.2020.07.22.11.55.20 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jul 2020 11:55:20 -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.120.23.2.1\)) Message-Id: <0A9203D5-C4F3-4AA8-B59E-7D63E4650B3B@sn3rd.com> Date: Wed, 22 Jul 2020 14:55:19 -0400 To: TLS List X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc 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 Jul 2020 18:55:25 -0000 Hi! The authors of "Return Routability Check for DTLS 1.2 and DTLS 1.3" have = asked for adoption of their draft as a WG item. Please state whether = you support adoption of this draft as a WG item by posting a message to = the TLS list by 2359 UTC 06 August 2020. Please include any additional = information that is helpful in understanding your position. NOTE: We discussed this draft at IETF 105 in connection with = draft-ietf-tls-dtls-connection-id [0]. The plan at the time was to = progress draft-tschofenig-tls-dtls-rrc after we progressed = draft-ietf-tls-dtls-connection-id. That time is now. Thanks, Chris, Joe, and Sean [0] = https://datatracker.ietf.org/meeting/105/materials/slides-105-tls-sessb-ci= d-00= From nobody Wed Jul 22 11:55:56 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 B48C53A092D; Wed, 22 Jul 2020 11:55:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159544414868.23556.6501758581253052223@ietfa.amsl.com> Date: Wed, 22 Jul 2020 11:55:48 -0700 Archived-At: Subject: [TLS] The TLS WG has placed draft-tschofenig-tls-dtls-rrc in state "Call For Adoption By WG Issued" 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 Jul 2020 18:55:55 -0000 The TLS WG has placed draft-tschofenig-tls-dtls-rrc in state Call For Adoption By WG Issued (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-tschofenig-tls-dtls-rrc/ From nobody Wed Jul 22 12:07: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 EEC043A088A for ; Wed, 22 Jul 2020 12:07:53 -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, DKIMWL_WL_HIGH=-0.001, 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 C3uoAq1VlrrL for ; Wed, 22 Jul 2020 12:07:53 -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 E02FF3A0878 for ; Wed, 22 Jul 2020 12:07:52 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 06MJ4BhQ009151; Wed, 22 Jul 2020 20:07:51 +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=3wLEWm4nPMrfIR/d1MjWCetqdB/AwxPI89B2RDZkf9M=; b=PRBdTYZIoEEKyCBQ02zNgTFdtSO+0NHtJDY4M8/5BrHqsHtxDv6s/P/pHlXLkhO3E3XA zWPv25ofwMo+dUMJ54aPeIaOCgyC0Mrguce8RPfZ/eqoe77HgsjqjIfqm1C8DXePMmqG +WoS56EBR78EgoHsJpoaYd+4kT2rbcyXdBO0nizWklMPulK4XVn4WEZWT7V2sqMrCwTv OfkA2Fy4cBxhfZxuDiEEYIbgi79AbqkhZAHAKvBClPd+s5fLcfZ0819ruheSZKt8TCwW MWraikvACIVEM1CUqGvrsvsNLnImVPLWhrN8pBuwVu80oiFMq8TRdeOdSNCgNZmKYUWz LQ== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 32cqdnkdcn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Jul 2020 20:07:51 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06MJ4lBf031323; Wed, 22 Jul 2020 15:07:51 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint3.akamai.com with ESMTP id 32djny3906-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 22 Jul 2020 15:07:51 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 22 Jul 2020 15:07:50 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.006; Wed, 22 Jul 2020 15:07:49 -0400 From: "Salz, Rich" To: Sean Turner , TLS List Thread-Topic: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc Thread-Index: AQHWYFmxw3BcUWPc1E6cFfPJvo/b6KkT9hSA Date: Wed, 22 Jul 2020 19:07:49 +0000 Message-ID: References: <0A9203D5-C4F3-4AA8-B59E-7D63E4650B3B@sn3rd.com> In-Reply-To: <0A9203D5-C4F3-4AA8-B59E-7D63E4650B3B@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.187] Content-Type: text/plain; charset="utf-8" Content-ID: <0061E12D57C0FB489A9F0CB1EB3DAA51@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-22_10:2020-07-22, 2020-07-22 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 malwarescore=0 spamscore=0 suspectscore=0 bulkscore=0 adultscore=0 mlxlogscore=741 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007220121 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-22_10:2020-07-22, 2020-07-22 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 clxscore=1015 mlxlogscore=717 lowpriorityscore=0 impostorscore=0 mlxscore=0 suspectscore=0 adultscore=0 phishscore=0 priorityscore=1501 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007220121 Archived-At: Subject: Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc 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 Jul 2020 19:07:54 -0000 Tm90IG11Y2ggb2YgYSBEVExTIHVzZXIsIGJ1dCBJIHJlc3BlY3QgdGhhdCB0aGUgYXV0aG9ycyBh cmUuICBJIHN1cHBvcnQgYWRvcHRpb24gYW5kIHdpbGwgcmV2aWV3IGl0Lg0KIA0KDQo= From nobody Wed Jul 22 17:33: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 6E8B53A0A87 for ; Wed, 22 Jul 2020 17:33:10 -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=lowentropy.net header.b=e+WnPgIR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=A3cvvWPj 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 ZNeBYgzyuBd6 for ; Wed, 22 Jul 2020 17:33:09 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE72B3A0A84 for ; Wed, 22 Jul 2020 17:33:08 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 230A25C00D7 for ; Wed, 22 Jul 2020 20:33:08 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Wed, 22 Jul 2020 20:33: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=INsA/82UKKDN3Oh1F4DZpFUuGo4FwXH CJcGvtcQj1E8=; b=e+WnPgIRkRjrzwi5zv6ZbJSEGuMEUJh11ZFyLAWu7aoitH0 pM0BO8mwzTD3pvEWKmxkFyBg2Wl0+E744FU9G23uzn/duHKnil1uU+COxe4aQWpK W4e6P+oPM5cwHkN7vSvboMO3tsxRS7V667UrESqnS1AUJZG3Nh+9BM2AOQrZk26+ a0Z/HlK2m621rH7xzqavIRWFuNasHjooSTFEcjzakaP4xCRGR7ZrVo5HFlXJLs1o VbF9v7lutoHdh03DCUpwc3nF6H8gvHJAwuT+rJ/p1n2BPVE7Ot++sVcQXUhjSMGG I5gVMTEsj//ph5E3pMwMBHq23ywDlGygwEpwRFg== 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=fm3; bh=INsA/8 2UKKDN3Oh1F4DZpFUuGo4FwXHCJcGvtcQj1E8=; b=A3cvvWPjri6PG6VmYaT1hW 0O6CxG3ZSRGdajWL1QpjW+UKfklPxzE7vHr6eZmztQnYYo2r7u8REMrDChEvIJnB duOI1IK7hwP9/3n0K2uz35Hc2bqO/su7K+NlRs5CXxywOMn+uVbzG/rx126un9iY jpb3okHJ7DwCAp1XK1cvrCjueZJEQU1NTUSAxDRCdY7duP2u3dRLAZZIAObP5RaV Fl8rXQMowmTRzF88E15hkDPL98rvzzpv7uOsk3vqCn2u2ymyPg/6qndZIRueqlPU 1W8PkAtwlohVcW/mp7+SECVgB7+UmQ9Alx61MuXmO2ghzuiqPDWAn/k6qgD40NyQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrhedtgdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhephfeitddtveeihfejjefgve efuedugffgkeevkeehueeggeelveekveektdfhueeinecuffhomhgrihhnpehivghtfhdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B74F6E00A8; Wed, 22 Jul 2020 20:33:07 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-92-g11c785d-fm-20200721.004-g11c785d5 Mime-Version: 1.0 Message-Id: <401eb156-e8de-482a-92c5-aa423e211b5d@www.fastmail.com> In-Reply-To: <0A9203D5-C4F3-4AA8-B59E-7D63E4650B3B@sn3rd.com> References: <0A9203D5-C4F3-4AA8-B59E-7D63E4650B3B@sn3rd.com> Date: Thu, 23 Jul 2020 10:32:48 +1000 From: "Martin Thomson" To: tls@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc 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 Jul 2020 00:33:10 -0000 I'm OK with adoption. That said, I believe that this falls a long way short of addressing the attacks that I'm aware of. But that assumes we share an understanding about what those attacks are. To begin with, we probably need a clearer description of goals. To give an idea, address validation in QUIC is much more complex than is proposed here, for reasons I believe to be good. If this document does less than QUIC, it needs to justify that. On Thu, Jul 23, 2020, at 04:55, Sean Turner wrote: > Hi! > > The authors of "Return Routability Check for DTLS 1.2 and DTLS 1.3" > have asked for adoption of their draft as a WG item. Please state > whether you support adoption of this draft as a WG item by posting a > message to the TLS list by 2359 UTC 06 August 2020. Please include any > additional information that is helpful in understanding your position. > > NOTE: > We discussed this draft at IETF 105 in connection with > draft-ietf-tls-dtls-connection-id [0]. The plan at the time was to > progress draft-tschofenig-tls-dtls-rrc after we progressed > draft-ietf-tls-dtls-connection-id. That time is now. > > Thanks, > Chris, Joe, and Sean > > [0] > https://datatracker.ietf.org/meeting/105/materials/slides-105-tls-sessb-cid-00 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Jul 22 18:30: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 C23473A0AA5; Wed, 22 Jul 2020 18:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 6nhkzGPhARJP; Wed, 22 Jul 2020 18:30:21 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 59D7E3A096B; Wed, 22 Jul 2020 18:30:21 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id o22so3090525qtt.13; Wed, 22 Jul 2020 18:30:21 -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=l2EySzjcrwnACDE6DPuJ03fR/RH2bxTzAOSiY2NZgGs=; b=GCzayiMIEqoX1O/ut53WPjqEXlBqqTko0W/2F635JPDa4duMKmVmFbKwv3YCaRcRd9 cIKxbyFLX6Na4o2CyPbBPNcBXmD5198U7EtI2UbziRGOrlaIP0YEueDx7SvuPVHFrEW2 W5gIwaYIgZIcOValvUqOer3DPiRGe8tOv5UxdFvX7H/3Whv8rRNCoxsl5FOaWGZQl1r+ e7EqSe0+IRMtUYMLNa/VJou8Rdn6q2ISTp/M0E0O2xpxzEBCdktViQFTB8vVOHWH93C6 QLcd6E2Ww+1hu6Ita4QrpBR20CHFTC1PoYygcFHvf0OUoJiehRhqw9xc8pGAU1jHCIZ4 7jgQ== 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=l2EySzjcrwnACDE6DPuJ03fR/RH2bxTzAOSiY2NZgGs=; b=tcgVPEYIKPnNj6PlytS7YXiC/U/rsslaRFZtRejF+lIbQeOLKRN54CzIjLYZMEm3fl im+b1DYf/LkDjV1vm162SzAGmu0BAMUScmKr0nEPoGbnuScAttagmW11Fe2AecoRfXRA QpXiyp19HePQ/byxu3It+ucSpffsPJ7ej4CXHRxFy2wPez1EzzQw+55QnYRjtjXl1UtH f0xSHWC6J3/g67Z1YeQx4LkBOJfmgvjTtcabXybkummLVABpgnDSTmQGr/ZOzGfZzdzI +7/AN5PFFUylnfqcv+GEP7oD3Iy73CcdxGJw8v8s8l/KzPqfxfk8r24Tmyg5hqjdUJ0t aV9A== X-Gm-Message-State: AOAM532ryaxCor7m0lyRO4ok0N3vY+GG1+0BcJUzPn158ZkQBNYfurdB Aox5Hhw11+vN7aUzEN2ccXs61/BC1Zt1h5QuRSqN7E4D X-Google-Smtp-Source: ABdhPJy0yLbuXADaAkf1rqo+gLxGjFBbfD60j2o4OCx1/TgR7DL43xR//T9y29AQlDba6FiMErgpR/ru02d481k7N5Y= X-Received: by 2002:aed:3b0e:: with SMTP id p14mr2152060qte.149.1595467820073; Wed, 22 Jul 2020 18:30:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jen Linkova Date: Thu, 23 Jul 2020 11:30:08 +1000 Message-ID: To: OPSEC , "tls@ietf.org" Cc: OpSec Chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 01:30:23 -0000 One thing to add here: the chairs would like to hear active and explicit support of the adoption. So please speak up if you believe the draft is useful and the WG shall work on getting it published. On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica wrote: > > Folks, > > > > This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp. > > > > Please send comments to opsec@ietf.org by August 3, 2020. > > > > Ron > > > > > Juniper Business Use Only > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec -- SY, Jen Linkova aka Furry From nobody Wed Jul 22 23:18: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 72A2D3A08B7 for ; Wed, 22 Jul 2020 23:18: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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 MOPuHx_hcmQN for ; Wed, 22 Jul 2020 23:18:10 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 9414E3A08B3 for ; Wed, 22 Jul 2020 23:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1595485082; bh=MA4hs0LgUV2apd9QaGCgKrKUJ4X3aBq6TU1EGsKKZS4=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=HW4p0cMgJQ8PdZ0lAdpDZaOr75QTtn/+hAzm0NGdwEva6418e0y1jQfQO/fG56hph 9fN/s7HqrXKuyCWvpGKNvm0/fN2aGpBxLyrJgN2vFasylOxncbI3F5UO8W6rVNSg6F 3xDar5L3Z4yTNoO2cNuXszVFNbmrOJgZf7NGCLjw= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([178.10.250.83]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MpUUw-1kb6Yw1I20-00pwyq; Thu, 23 Jul 2020 08:18:02 +0200 To: tls@ietf.org, Martin Thomson References: <0A9203D5-C4F3-4AA8-B59E-7D63E4650B3B@sn3rd.com> <401eb156-e8de-482a-92c5-aa423e211b5d@www.fastmail.com> From: Achim Kraus Message-ID: Date: Thu, 23 Jul 2020 08:18:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <401eb156-e8de-482a-92c5-aa423e211b5d@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:QG/wSLUjMy8+ynkp42ZjaBqQbFUK9c/YW/F9WVPdYAKvcHnxoWm 03X3zjx9QZlYLj90qmdMggE/U5nbV8WxkpVAp0PR7tdYvXluJygGup9m4plGPUmA8JApYDP 2PKb3pGoe7b4fgm6/zqcqBqIV87TuYNj2V1Qz1wtBRNjAzIH4Dc9b4AscmNa+D9jNp5rRGm vAfAo/4nHuDDVZaJ8S+kg== X-UI-Out-Filterresults: notjunk:1;V03:K0:pKuAfop3H7I=:qjnHJbFpM4FeANEQ6W0C/o s583Rkv388Y29XP3nSIGMEfAKI4dFaxAjO+Izd+Ck+9D24jJ0ZTfoTqFGxAhxkL0M0nJxofHG sE8uCF0tfnCRs94l+ri5l3fC57to2+NrI0zFRKwvrU/mbTP0BA9UrabTTwK/4Cb2PBXIRTF9r vNkytJtuOfTHfCDG1JXgVGaMzmRVNbnX4q4eAStD5JlmjxbNXECHyZC0qVItUfa5UTaCnhuJF 65fUjzfW6hXIKG9SM0+MLo7BJqZLwE6G2N/0TUEK3Bf8n/cHjPTI/DeKNq4G7xtEuERKzEVrs SkRVdYOTKdJHyAGHgT8dxZfp2WWTWxpIxbTVLpKgvdYaKcVv/hnDpvU2UO+SlvpGIJbQLfygY lYuLT3f7CpGPjaj1069z17r+S2vpgusgJBFlbVPG+ejQLOT1nXGSeN6oi2B91j5/VGvq0TxAr EX7pGdqHXiDrqX9dhipJ7/z5TaGu2UfC6lQhaVllFW0s7zMXCu6PlIYYK1/XQKndJA2QKzXBZ mmkbM4k3wS1t8bF7WVbKWhowpR4AhJCUOzvYsz22hKCfjxCSOZ4HDsYGCB2eYC+WOsHYbOr0U ZLwiiwieofP3vnRiPEED7Xw21/Q+HtRkfaBjAacNDvXY7QXLA50c8ENzkLO+bR+1hqsTuoaWO CFwBOZzP2KJXd6pzqdthvBHiMEbumjV+3sH97WYApSeCsaHxqLAuuNp+0kxA7xAwP2VCNxvqP czwGVxmzwr5T5BEIL/WqU2PB+mBzT4W0euLEvGKzNnwMtqokGA+DOQWJdN6bEjyI9IuHLNQHF 6Gq8RO8gYTeX0UilFMRs/ohiZGNrAAd6PPXYnzi3SovFoVkWub9V1aGctc/D6I3DPD6co4dyu 0MDxec1t4zh7eJfIAzVuvCJ3bOn7noMgyhC205p/pTUNbl/tTfBuv13lW8Ms0pjv4BmRY5iLb ar6UmOtq1qQ0Y8PHW48p8MjwN/TTRdJV+LX7iqo8PwnQ5Wr/Zu8h6wx2KuozGbqxu3gEREaEf 6lWRSDJNix9ULlGAfh5LEsgZsIY3crTK8FQqBA5gYq36YRX/ImQYAGh+wcKinFJp6upfpf99n EnWWE5oZtz0USk5QkEscjS3jN77lTfSQVQFifhEQYXqmQ7Sf80zk+CVdQP4mxShWz9NyNYAB+ dfIQQwCDka+KL7Y2S60s1UsxkdhnE88hOaqj9ML42XBYWrv6UYqJqlM/gjL9uLkFHS1EmHltn oXwdqV//jbyHBueANGpKTPH1H52Mo5lntCbNarQ== Archived-At: Subject: Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc 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 Jul 2020 06:18:11 -0000 Hello Martin, Hello list, > That said, I believe that this falls a long way short of addressing the attacks that I'm aware of. But that assumes we share an understanding about what those attacks are. To begin with, we probably need a clearer description of goals. Fully agreed. Unfortunately, that discussion seems to be either not public, or, somehow, stale. https://github.com/tlswg/dtls-conn-id/pull/71 So, if you have any update, please provide the details, where to find it. > To give an idea, address validation in QUIC is much more complex than is proposed here, for reasons I believe to be good. If this document does less than QUIC, it needs to justify that. I disagree. QUIC (as any other technology) sticks to use-cases, and the therefore the definitions there are also depend on the use-case. https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-transpor= t.md#address-validation "Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to a server with spoofed source address information that identifies a victim. If a server generates more or larger packets in response to that packet, the attacker can use the server to send more data toward the victim than it would be able to send on its own. The primary defense against amplification attack is verifying that an endpoint is able to receive packets at the transport address that it claims." In my opinion, the primary defense depends on the use-case. 1. Just don't sent anything back is the very primary defense. That will not work for all use-cases, therefore the secondary defense is 2. Just don't sent back more than received. (Considering DDoS results in a combination of the primary and secondary defense, means only send back responses, limited by size and number.) That again limits also the use-cases, therefore the third defense is then the 3. "primary defense" of QUIC. The difference between QUIC and RRC could analyzed from both ends. The one may justify, why they don't consider something and therefore do less. The others may also justify, why they consider something additionally, and therefore do more. In the end, it's more the question, who is intended to invest the time. best regards Achim Kraus Am 23.07.20 um 02:32 schrieb Martin Thomson: > I'm OK with adoption. > > That said, I believe that this falls a long way short of addressing the = attacks that I'm aware of. But that assumes we share an understanding abo= ut what those attacks are. To begin with, we probably need a clearer desc= ription of goals. > > To give an idea, address validation in QUIC is much more complex than is= proposed here, for reasons I believe to be good. If this document does l= ess than QUIC, it needs to justify that. > > On Thu, Jul 23, 2020, at 04:55, Sean Turner wrote: >> Hi! >> >> The authors of "Return Routability Check for DTLS 1.2 and DTLS 1.3" >> have asked for adoption of their draft as a WG item. Please state >> whether you support adoption of this draft as a WG item by posting a >> message to the TLS list by 2359 UTC 06 August 2020. Please include any >> additional information that is helpful in understanding your position. >> >> NOTE: >> We discussed this draft at IETF 105 in connection with >> draft-ietf-tls-dtls-connection-id [0]. The plan at the time was to >> progress draft-tschofenig-tls-dtls-rrc after we progressed >> draft-ietf-tls-dtls-connection-id. That time is now. >> >> Thanks, >> Chris, Joe, and Sean >> >> [0] >> https://datatracker.ietf.org/meeting/105/materials/slides-105-tls-sessb= -cid-00 >> _______________________________________________ >> 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 Thu Jul 23 09:56: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 5F2F43A0BCD; Thu, 23 Jul 2020 09:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.619 X-Spam-Level: X-Spam-Status: No, score=-14.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=IErpECO3; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=lvDj5Mnm 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 gg84WuVaIb7B; Thu, 23 Jul 2020 09:56:44 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED2D13A0BCA; Thu, 23 Jul 2020 09:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10668; q=dns/txt; s=iport; t=1595523403; x=1596733003; h=from:to:cc:subject:date:message-id:mime-version; bh=ayeI/dRktl8OVhMNu4jlLTwUO020SrLCID4SIZz96Zs=; b=IErpECO39Ws1tnopE/TWkfLpFoRcQtG2QrwHXi7PmfFQeiS9X+i27fvd q9/c6D0lBVZPa3De8IjJHFc1Hu9LtDYYw/zEOUCscGD7p2bogf9GHw8zp 4MOMQmW2SR1lRF+fkRvg/qX+/ewe5PlLwtHuPUXRiHO/qdUotz0QjgNKs E=; X-Files: smime.p7s : 3695 IronPort-PHdr: =?us-ascii?q?9a23=3AYC744hG5XfbmYuvqQqB1gJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401gObUYDS8fkCiufKvebnQ2NTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBrni79zVUGx?= =?us-ascii?q?jjO0xyPOumUoLXht68gua1/ZCbag5UhT27NLV1Khj+rQjYusQMx4V4LaNkwR?= =?us-ascii?q?rSqXwOcONTlm4=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BoBgBlwBlf/5hdJa1gHgEBCxIMgX8?= =?us-ascii?q?LgSMvUQdvDh0tLyyEM4NGA40qJYdYjBuEbIEuFIERA1UEBwEBAQkDAQEjCgI?= =?us-ascii?q?EAQGETCKBegIkNAkOAgMBAQsBAQUBAQECAQYEbYVcDIVxAQIBAxILBhoDAQE?= =?us-ascii?q?3AREBCBEDAQIrAgQwFAkKBAENBQ4UgwQBgksDHw8BDqMQAoE5iGF2gTKDAQE?= =?us-ascii?q?BBYFHQUKCThiCBwcDBoE4gVOBGYYEhAQagUE/gTgMEIJNPoJcAgIBAYEmARI?= =?us-ascii?q?BQQ2CaTOCLZpvigyQYQqCXYQzgliBS5ETAx6Ce4lEkxySDoorlGECBAIEBQI?= =?us-ascii?q?OAQEFgVM6Z3BwFWUBgj5QFwINjh6DcYUUhUJ0AjUCBggBAQMJfI8TAQE?= X-IronPort-AV: E=Sophos;i="5.75,387,1589241600"; d="p7s'?scan'208,217";a="792811130" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jul 2020 16:56:42 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 06NGugHU027697 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Jul 2020 16:56:42 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 23 Jul 2020 11:56:42 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 23 Jul 2020 11:56:42 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 23 Jul 2020 11:56:42 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FKQTDRlX23RJ4Jt4FNy5CFBAMpxCCmcy6Jc3lPItqCKSEPS2ux1xP0r/tJDfRpLBaECYV+RTXMmcEXF4g31Oeae4QofqGgwQEtmphG98gqhX+fOm1Wf8SJpX/aCbBuIv2DmP9SLXb0r4KjrqOhO3IJfMJQ4THwqqO7xJ2pwrtDbWMnMQ3RQIzWDgEzKwKBWfgyFq/XEtlhXy+WqGgSs79p86CfKWZ/dzBPUzovzrECuNPI8Mw9daBU+oRIn32hxVzlIBdTtSV7TXsuZ79ASrA8S9ShDh89p3JIy8SLbwKgzVUAMJFjuU7SecDxNUCssPK8oTapnvL2x/OOfqv5q29Q== 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=RndN2GCcwjMXmNEk4LrMZ6DcGWge48SrUvJj6tvaDho=; b=CcBEZznFdQwo7cn8SlU86Qa3TjrszqQMFZGc1jBVw5RURDrdaUVTz/78ubqfZQ5ZzVpk/bt0u0Uos7mjCWOb21LAHgd5KRq9tMY9IBJAIHgN3rb1paOWRPVOkmm8ezsuDS630g/XgwU+WeCwQRCHQLYu3CIpkgBZn5vWt/4nOILf1E7sMs3aWRt+4GnC4KeKQUMHvw+cAbDLZotzt02a0Aja6eq739fb1cwY8wwldj+w2zRUqSZodPjsOKx0Y88mEi9z6Sb4KQJ4YFdQoJ8WRnqyG0L7/8ISLH++8DKNyuv0XZs+RjMuTIZDyMFi/VL98g4vfrTEWRDBVP/YzigVIg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RndN2GCcwjMXmNEk4LrMZ6DcGWge48SrUvJj6tvaDho=; b=lvDj5Mnm0EwFlXvZdy9mck0yp19p6ewA3fUZiZJSQEFAfRQ73kS9YU2NvdcCdQrmDGn8GPXxro3g16VgaxI7o8UNzWgtNDjlxzCv57DGiJUbtY9gd8h/Hi1B7hY64XZjNdtuLz48SLIbwJzxWYSZTLX/m1uDSqzrVY+oohf7BRk= Received: from DM6PR11MB3691.namprd11.prod.outlook.com (2603:10b6:5:146::33) by DM5PR11MB1819.namprd11.prod.outlook.com (2603:10b6:3:10a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.23; Thu, 23 Jul 2020 16:56:40 +0000 Received: from DM6PR11MB3691.namprd11.prod.outlook.com ([fe80::9c5f:90ad:15d5:615d]) by DM6PR11MB3691.namprd11.prod.outlook.com ([fe80::9c5f:90ad:15d5:615d%3]) with mapi id 15.20.3216.020; Thu, 23 Jul 2020 16:56:40 +0000 From: "Tobias Mayer (tmayer)" To: Ron Bonica , OPSEC CC: "tls@ietf.org" Thread-Topic: [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AQHWYRI8MVhjKcpfSaSC3eC5PK0rEQ== Date: Thu, 23 Jul 2020 16:56:40 +0000 Message-ID: <1EDB061F-C469-4464-B7FA-4BD2DD1C7100@cisco.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2003:c3:3716:2900:21d3:70c:d7a6:c599] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7d1ea8db-c945-440e-00ce-08d82f295eb7 x-ms-traffictypediagnostic: DM5PR11MB1819: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PJz8SEtAqPfIYJHmZIrvUGDvdT/m2CGJjll/IfKgRFbcB7xZrQhO9PWajZyMJD3oFpI2blXnqXQgtp0nN2fohCBA4acZKysgU4v07ovNqxeaBqknqk6W0rxiczFN1ppDo/iIcpVrhQteczGSKiZXAl0LIh1nesePxq2kdnhEZQ52ThzSDrC6ETlcv2C5i7X2Im4SiZ5B254g9A77DIJH32iunXgHFotEf3j1P2ifatHlTkQPTVaAXqPR8myzoiEjcaZ70t0P4edNz8mLHabvxWrMN8UvNNlJTr7LLJBmdGiigKyxrrCcjoDBSeZcNzRZue4MbTv3n77JRHmODbePzar7Jag3TAX5StKV8n1dRiqcMPtRxDsHv1iahS1l+kTOINPHPT6K0iL6HxbXHFiEXQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3691.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(396003)(376002)(136003)(39860400002)(6512007)(110136005)(91956017)(76116006)(66946007)(4326008)(5660300002)(71200400001)(166002)(6506007)(53546011)(2616005)(4744005)(8676002)(6486002)(99936003)(186003)(8936002)(33656002)(86362001)(66616009)(66476007)(66556008)(2906002)(66446008)(64756008)(36756003)(478600001)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: vTkAVko5V7Oq2SKgP5SiX0s3tZaIApvN92phJhkg6QWLrxVrFx/+Glt3iLNMJ58lwqPEHdG0NTEYC0Oq+S6L2aY+AvD/thn20h8Wy9VV30kLl95W8jML4uzl3lhi9ux7NdltHFdpeeOUbExRzdjMisI7WC+YK0sMecDyCqd+JudDKNLJSTliR/RZq3tX9xh+3ofyfRAMqKo2y3TeOh0AtmiV/99IR9Chg3wb2m+TVa43fVDjCIzrFOc3exT37cTsl+ShLCO+SVBPk1XXjdGwTbmev+rjR9YumfPpRGsYKCH5MBKoOLthZhzWMPawQqkWKpSN+HLzW+EuTJGFUbJIgAm33TU4KTeWe9FcR5JlccZA3teefBarTOecoUWhhxluTrQ9pMcfcLOR9e6nn6C3tpJqM+l4bhaFPaWSZUFHDKk7IDGOVCBncejJ5Bgocji5NDI9aRouOv4vt54PmSqGzx/ouYDzF4mE0ZgbuTtHhkKKIgr2JkZNm0sVxdhAB4pdbN6sJgkvvsuZl2CK1Oe6Cog7sgW/cBixGh5PvhCrbDA= x-ms-exchange-transport-forked: True Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3678375399_790696632" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3691.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7d1ea8db-c945-440e-00ce-08d82f295eb7 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2020 16:56:40.0552 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yxqOJR/cOurfEOXwndoSBXcW7WV2G17TIjcEsTvz+FJ6Jg7+IBbXbjwGLKUuci1nJmBMZIb+VAydwjGEGskn0Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB1819 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 16:56:48 -0000 --B_3678375399_790696632 Content-type: multipart/alternative; boundary="B_3678375399_848195937" --B_3678375399_848195937 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit The Draft gives a good baseline on TLS Proxies and what you should consider. I support the adoption. Tobias From: OPSEC on behalf of Ron Bonica Date: Sunday, 19. July 2020 at 19:35 To: OPSEC Cc: "tls@ietf.org" Subject: [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Folks, This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp. Please send comments to opsec@ietf.org by August 3, 2020. Ron Juniper Business Use Only --B_3678375399_848195937 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

The Draft gives a good baseline on TLS Proxies and what you should co= nsider.

I support the adoption.

 <= /o:p>

Tobias

 

Fro= m: OPSEC <opsec-bou= nces@ietf.org> on behalf of Ron Bonica <rbonica=3D40juniper.net@dmarc.ie= tf.org>
Date: Sunday, 19. July 2020 at 19:35
To: OPSE= C <opsec@ietf.org>
Cc: "tls@ietf.org" <tls@ietf= .org>
Subject: [OPSEC] Call For Adoption: draft-wang-opsec-tls-= proxy-bp

 

Folks,

&= nbsp;

This email= begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp.

 

Please send comments to opsec@ietf.org by August 3, 2020.

 

       &= nbsp;            = ;            &nb= sp;            &= nbsp;            &nbs= p;     Ron

 

 

Juniper Bu= siness Use Only

--B_3678375399_848195937-- --B_3678375399_790696632 Content-type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOawYJKoZIhvcNAQcCoIIOXDCCDlgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggxfMIIEojCCA4qgAwIBAgIKAYYYsEe4tre6WDANBgkqhkiG9w0BAQsFADAsMQ4wDAYD VQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lzY28gRW1wbG95ZWUgQ0EwHhcNMTgxMTI4MDg1NjIx WhcNMjAxMTI3MDkwNjIxWjCBlzEeMBwGA1UEAxMVVG9iaWFzIE1heWVyICh0bWF5ZXIpMRQw EgYDVQQLEwtDaXNjbyBVc2VyczESMBAGA1UECxMJRW1wbG95ZWVzMRMwEQYKCZImiZPyLGQB GRMDY29tMRUwEwYKCZImiZPyLGQBGRMFY2lzY28xHzAdBgkqhkiG9w0BCQEMEHRtYXllckBj aXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCNcZhZ1fJ70uMaOSNP nIn1VM14jpK46aDB+xTVmUOgzAkVcRddrQKsSMTAO01C6XIZXI/vC9rndYmC3SwysCQvua0T GkwBBoOdYiITklR7wW2Kv3fMn1D2fz9cwCJsDWnxgt2ztC5YxK7MRayjcg53VhFm3+xr+Y2e lN87MjadxwW+QN9pTb+P4z0qxPrTKsAPidGZT0dltvLfOclRumu5+siy6BIFOL9ro1CayH6c zRpnfU3q/3MSqpxOs1ZNIYNUJcrXSw2F0KgBn9u2P0YQa4vQ8P0GdkydUuB302TuGgZUR+Xr N3BngAOZJ1SrhsEqqV52/AsMjhvh/hcPipQDAgMBAAGjggFYMIIBVDAOBgNVHQ8BAf8EBAMC BPAwDAYDVR0TAQH/BAIwADB6BggrBgEFBQcBAQRuMGwwPAYIKwYBBQUHMAKGMGh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jZXJ0cy9jZWNhLmNlcjAsBggrBgEFBQcwAYYg aHR0cDovL3BraWN2cy5jaXNjby5jb20vcGtpL29jc3AwHwYDVR0jBBgwFoAUn5U2tI5d1UvD CsGnKZNDUQb9iVEwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Npc2NvY2VydHMuY2lzY28u Y29tL2ZpbGUvY2VjYS5jcmwwGwYDVR0RBBQwEoEQdG1heWVyQGNpc2NvLmNvbTAdBgNVHQ4E FgQUVthVuzoCTftjGa1pY6iWs9xEy3YwHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUH AwQwDQYJKoZIhvcNAQELBQADggEBAC+HX94gp7syHiJs/TH8QbueuLuCabMrQkWPcHO9Tqur EdRccELlP5YrzuktYpFoAXHLXel0l37Gj6okaA6mdhyhS7ySLla1vVyp5FW0GU6X+nEPpFlH ErqvP0p7bSEsvAx0KxgL2U8iJJ2NBlwyYjU9apzUue35mIPwsoYeyhCiO16GvAJZILTLRQkd sEM+/fACuTSn6os7hHfJxL39oNekNpXZFBBypWvW7/x2hUQy6KtyClgyfCTCqFC+tcV0WHq8 lf7wvRXNz1ZJdZM5PqmEeKYplWo8gICat9gGLbefjBDFhdjAH53VpNEo4JID+/SNWMPhMNQr cLd+8epmpKYwggRuMIIDVqADAgECAgphEIBtAAAAAAAOMA0GCSqGSIb3DQEBBQUAMDUxFjAU BgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0x NDA0MDQyMDI0MThaFw0yOTA1MTQyMDI1NDJaMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQD ExFDaXNjbyBFbXBsb3llZSBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMrf fhZMUxX7I1bNxrllCgSV5d5MRWeMDMcG4KsfbV83Knvn7aOtgH8RyPOC6+6fUNnJvz2hL7s8 EQc177il2VFO2bD3U6CUgCwskmWtEG+hhmtfQAqZpVBEGpBNz+ZM+0YGjUjjB9fhrWPX1egn ABW/bgeyQ7tlBi999lldmxLFLH2960SwUuHC/B7tnVn3HZOnqzGmQkI5J9OBYsZULCaM2z0U 0KiOFeoopBv+vaw8nk3W1UyvjMv/S58FbA9xgTIkYe0Zq77qcbRojLvI9OSLP3dTon4VnnML 41d0XoPS6JPGzDSRDAKXndcHk3VUtF+DLAIXqLCQZXfZUuTuIncCAwEAAaOCAYcwggGDMBAG CSsGAQQBgjcVAQQDAgEAMB0GA1UdDgQWBBSflTa0jl3VS8MKwacpk0NRBv2JUTAZBgkrBgEE AYI3FAIEDB4KAFMAdQBiAEMAQTALBgNVHQ8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAf BgNVHSMEGDAWgBQn88gVHm6aAgkWrSugiWBf2nsvqjBDBgNVHR8EPDA6MDigNqA0hjJodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY3JsL2NyY2EyMDQ4LmNybDBQBggrBgEF BQcBAQREMEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly93d3cuY2lzY28uY29tL3NlY3VyaXR5L3Br aS9jZXJ0cy9jcmNhMjA0OC5jZXIwXAYDVR0gBFUwUzBRBgorBgEEAQkVARUAMEMwQQYIKwYB BQUHAgEWNWh0dHA6Ly93d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9wb2xpY2llcy9pbmRl eC5odG1sMA0GCSqGSIb3DQEBBQUAA4IBAQA+Tr4jGkYCjV5r24oCNAtjm+UBPCZdjHCyJOtg XuyKhGQuG1kVo2ca4Rbj/eBNfUSaIyjS7bb3oh/nRM3tbeqGIVQorGxhvPvIZVAEQIoqi/yf bhie9cU+paKpHACucaYXu0kyS0pYE5NMNun3Lw3ogOs4XVR5yoVSpKTiVnfTDQchTpwkMgzi vqXDcS1OiDfU8C9WaEZHRWtdUIgl9zoppPGIQa1TflcxhirW4GeH2FOrgaN1d77bIcg6R7Rp J9Xu3/f01nGNunrRcy993c2meJQoZcOJd15C6ugHwhAxeXY6QXYgkY8KQVCCGwkpshEgbwPr C+I/Itb6P7hGq7awMIIDQzCCAiugAwIBAgIQX/h7KCtU3I1CoxW1aMmt/zANBgkqhkiG9w0B AQUFADA1MRYwFAYDVQQKEw1DaXNjbyBTeXN0ZW1zMRswGQYDVQQDExJDaXNjbyBSb290IENB IDIwNDgwHhcNMDQwNTE0MjAxNzEyWhcNMjkwNTE0MjAyNTQyWjA1MRYwFAYDVQQKEw1DaXNj byBTeXN0ZW1zMRswGQYDVQQDExJDaXNjbyBSb290IENBIDIwNDgwggEgMA0GCSqGSIb3DQEB AQUAA4IBDQAwggEIAoIBAQCwmrmrp68Kd6ficba0ZmKUeIhHxmJVhEAyv8CrLqUccda8bnuo qrpu0hWISEWdovyD0My5jOAmaHBKeN8hF570YQXJFcjPFto1YYmUQ6iEqDGYeJu5Tm8sUxJs zR2tKyS7McQr/4NEb7Y9JHcJ6r8qqB9qVvYgDxFUl4F1pyXOWWqCZe+36ufijXWLbvLdT6Ze YpzPEApk0E5tzivMW/VgpSdHjWn0f84bcN5wGyDWbs2mAag8EtKpP6BrXruOIIt6keO1aO6g 58QBdKhTCytKmg9lEg6CTY5j/e/rmxrbU6YTYK/CfdfHbBcl1HP7R2RQgYCUTOG/rksc35Lt LgXfAgEDo1EwTzALBgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUJ/PI FR5umgIJFq0roIlgX9p7L6owEAYJKwYBBAGCNxUBBAMCAQAwDQYJKoZIhvcNAQEFBQADggEB AJ2dhISjQal8dwy3U8pORFBi71R803UXHOjgxkhLtv5MOhmBVrBW7hmWYqpao2TB9k5UM8Z3 /sUcuuVdJcr18JOagxEu5sv4dEX+5wW4q+ffy0vhN4TauYuXcB7w4ovXsNgOnbFp1iqRe6lJ T37mjpXYgyc81WhJDtSd9i7rp77rMKSsH0T8laszBvt9YAretIpjsJyp8qS5UwGH0GikJ3+r /+n6yUA4iGe0OcaEb1fJU9u6ju7AQ7L4CYNu/2bPPu8Xs1gYJQk0XuPL1hS27PKSb3TkL4Eq 1ZKR4OCXPDJoBYVL0fdX4lIdkxpUnwVwwEpxYB5DC2Ae/qPOgRnhCzUxggHQMIIBzAIBATA6 MCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYYsEe4 tre6WDANBglghkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCAzQ2NGzzcQx4UziD2lK5bn 9cOgBarshbqFzU7/ePbxVzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0yMDA3MjMxNjU2MzlaMA0GCSqGSIb3DQEBAQUABIIBAC565xVkaFrltvJd/zumF68e VFtzHzVo3CMG7/gIMS70Me4zoqvVaLTrtVn2R6iHy4mpNW2WpZ0aCVtI5JeaVgqXbo/kidr7 UNeVi/a0Uvkul/8l4ArwXHocbJpTgXMwXXk7DdUku932Vzcz8WuwEQzJzdXLNxeDlYVdiegF VxXEWS3HAy9uVJ8QI6G8C4kngHJplam7W2NoGvpRuv7fOxYv1DZm43vj+cRg9L+Qwvp0wtXL Hwyg7ewPyKat5DldqyNLfQ2soqz+O5+JbMOnHkz0mAnqiARv5/iM6Zab9iCY9O9zvtqlmeeD /qPB60/NnlivSHn7DfeSDlbLdWCJN8g= --B_3678375399_790696632-- From nobody Thu Jul 23 18:26: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 A39C63A07D1 for ; Thu, 23 Jul 2020 18:26:49 -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=lowentropy.net header.b=E4jfQ8SF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RmI52+dt 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 k7oQoNVN46NE for ; Thu, 23 Jul 2020 18:26:47 -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 964BB3A07CE for ; Thu, 23 Jul 2020 18:26:47 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id A12FC5C00E6; Thu, 23 Jul 2020 21:26:46 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Thu, 23 Jul 2020 21:26:46 -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=k5L8z15ICgLPbfCoYRIorraj44Hd Of7RrGJA79Uu8ts=; b=E4jfQ8SFJxkRsUoiJnELgQBOXdHKD4lH9+6EdX1/7Q7H NwE2YzsWumvRymcULavDwMF1UxogkJGprE17zFoqeUVeyx7dpUlfwzMB0POGf43b BI9s7L10dKFMuI+QaT9KJiJxHqIxXZDtjIc21TqaBCLuS0nFfbrWo0gBOcSF9d0N lWtW13xdBdO0yK0YnV19oHXGglKTqYPH3RUnId/SsQtsP8eJKkODv/ikMP4AcPJX zBQFH0GztvovJn4YUnAlRNI1p/Czsm7W2LrUxYwb9NRawwDBeD905kSv22mROcva FRPonCWnG3krr5ksZwQtL2bS7j2cC2VQbTO9xJfc5w== 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=fm3; bh=k5L8z1 5ICgLPbfCoYRIorraj44HdOf7RrGJA79Uu8ts=; b=RmI52+dtugzwE2bf/x5KEw gjakWsIvj5jIHHn+Gbso9aj1GuKKq5dyGA5kAMJFk8aIgq2OXSi4WreEM7x0uf9S SAWoywPB6YVkkkZTRbhzPKnLLpJKnrysWeK+JqP7PqboTQ9IL1xLbfLhXrgXs3E6 r3cc34qHXdNTJt+ICGX6BrLl7izhBCCyrcHJwuIxIsAIz3rP4XKUzWTR8+105nNx RglDEeeKt1rXB3sKYieEqZPedn+LjVjYennbMuMF3ciAmLXg3Z2Heppnueo6Y0JE VDYaOQigBScfYDfp1TdktPqjd/KfW6/T83M3G7nS6/fN+gpRt0O9X23HRtzGaJZg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrhedvgdeggecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnheptdeghfekgeffhfetfeejke evfeetheehleegheehveelfeetfeeikeefgfejvdegnecuffhomhgrihhnpehgihhthhhu sgdrtghomhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 42119E00C9; Thu, 23 Jul 2020 21:26:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-92-g11c785d-fm-20200721.004-g11c785d5 Mime-Version: 1.0 Message-Id: <6278ac6e-d0e6-460f-b9ee-71297b90bf17@www.fastmail.com> In-Reply-To: References: <60bc7458-c054-4715-aba2-8c4c9393f74d@www.fastmail.com> Date: Fri, 24 Jul 2020 11:26:25 +1000 From: "Martin Thomson" To: "Ben Schwartz" Cc: "" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Authenticating incompatible protocols 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 Jul 2020 01:26:50 -0000 On Thu, Jul 16, 2020, at 06:52, Ben Schwartz wrote: > Basically, I think this draft should probably either name the scope or > be specific to SVCB, to avoid cases where the scope is ambiguous. > Naming the scope, and providing a scope identifier meaning "IP and port > number", would often be sufficient for secure QUIC upgrade without > SVCB, at the cost of some conceptual complexity. It took me a while to think this through. tl;dr, I agree with your conclusion. Written up in a longer form as an issue: https://github.com/martinthomson/snip/issues/1 From nobody Fri Jul 24 09:12: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 71C623A0ECF for ; Fri, 24 Jul 2020 09:12:06 -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 Qb1O57i8AwCl for ; Fri, 24 Jul 2020 09:12:04 -0700 (PDT) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 771843A0ECC for ; Fri, 24 Jul 2020 09:12:04 -0700 (PDT) Received: by mail-vs1-xe29.google.com with SMTP id o184so5205139vsc.0 for ; Fri, 24 Jul 2020 09:12:04 -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=6d2J8lpCgIZ5jxjqXOSrx98cTjD12zH9HOhHMgxPmsc=; b=jQt5ef8ocPS1MyX4iKD2XUndRfOXBvMM76jRGtEHj6Klfwo68dBug14Sn7mA1tRdep P5AntQcWGK40hiW7PX7JX2w4lMgI0+ZF1bxj4gnHY7s8oZw4mnMCaWOjj6baHP4NyzGX erOK/2q46Wp8YjFb6XtVITiO4LLXGvEtNKGBbDP3wlYFXMOyM2+BWzo0rNlOMocisCDM Lx0OgpYNkhBvC3VjATwQeM3VkhYgkEEB8CKaweGiSpxMfJnyojMYj6PlB3mNFkOY5R6y hxfMFLP1f7xcRVjVS1H7Fw4kA6kLVzougneiPd548l9GXa05WelgwQUcQGclSHEQj7IT /o8Q== 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=6d2J8lpCgIZ5jxjqXOSrx98cTjD12zH9HOhHMgxPmsc=; b=fEjAWPZt/Z9TsHd9YUnWnS+2u37tYcL2v4KvbbSpNMpse15TGMRq0h5bRoB5AXCnOz Za6e0lA31xfOzGwlEfRD4Cw1ua9WYWOkX0K9GBCNS7jR2dmHw7/9qePeY8QglkVCrCWO ieMJGCb7h0sgvHDu5GcQWEOed7zrBjCs8nOZ7svgdVebx54wImtUpHS3dzKH1tzvcCpf VfqqpDzS8XOpeSpq3QsYMwRTvn6Ez36/jEfVtlE8YkcPy8mlqUYhJUuR3plS2CstE96P jy9YaopTmgVJHHqRvJRXlYjI48LyGQMGfEDKIsQLzN4S9+DeD6shaeSMj58O7MuuJpb2 OmyA== X-Gm-Message-State: AOAM5333ULMuxhn6oVCAyeiHee+qkwVNriJR2vJVCH1SUq6N1fvUoWvo G0MiGZw/8Vcr32qpB1upgamc5y8zYPrDxhmNZgMvVzVr X-Google-Smtp-Source: ABdhPJxQ21Ec0z5gpFJ/EUG8VfaU4du7lPws+uqD9Dz2Bm5CfPuhMxE3r35/mcKz879CUqfatBVmjWI2dZhESOMScUo= X-Received: by 2002:a67:ec54:: with SMTP id z20mr1156629vso.143.1595607123120; Fri, 24 Jul 2020 09:12:03 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Hoyland Date: Fri, 24 Jul 2020 17:11:57 +0100 Message-ID: To: Joseph Salowey Cc: "" Content-Type: multipart/alternative; boundary="000000000000c661b905ab323bfb" Archived-At: Subject: Re: [TLS] 2nd WGLC for Delegated Credentials for TLS 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 Jul 2020 16:12:07 -0000 --000000000000c661b905ab323bfb Content-Type: text/plain; charset="UTF-8" Just as a follow up to this, the proof files are now available here . These results are under the stronger model of a Dolev-Yao attacker with the ability to reveal long term keys (for certificates). Stronger results and write-up are still works-in-progress. Regards, Jonathan On Thu, 2 Jul 2020 at 15:20, Jonathan Hoyland wrote: > Hi All, > > For those interested, I've been working on a formal analysis of DCs the > results of which should appear online in the next few days. > I'll post to the list when it's up. > > In summary I managed to prove a server only version of DCs secure (i.e. > does not violate any of the properties in Appendix E.1) under the Dolev-Yao > model without resumption, and work on a more general result is ongoing. > > Regards, > > Jonathan > > On Mon, 29 Jun 2020 at 16:59, Joseph Salowey wrote: > >> This is the second working group last call for Delegated Credentials for >> TLS. The latest draft can be found here: >> https://tools.ietf.org/html/draft-ietf-tls-subcerts-09. There have been >> 2 revisions since the last review. Draft 8 contains changes that were not >> committed in time for draft 7 and draft 9 contains revisions from the >> previous WGLC. Links to the Diffs between the draft 9 and draft 7 can be >> found at the end of this message. Please focus your review on the changes >> between draft 7 and draft 9. Please send your comments to the list by July >> 13, 2020. >> >> Thanks, >> >> Sean and Joe >> >> [Inline Diff] >> https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tls-subcerts-09.txt&url1=draft-ietf-tls-subcerts-07.txt >> [Side-by-side Diff] >> https://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-09.txt&url1=draft-ietf-tls-subcerts-07.txt >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --000000000000c661b905ab323bfb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just as a follow up to this, the proof files are now = available here.

= These results are under the stronger model of a Dolev-Yao attacker with the= ability to reveal long term keys (for certificates).

<= div>Stronger results and write-up are still works-in-progress.

Regards,

Jonathan

On Th= u, 2 Jul 2020 at 15:20, Jonathan Hoyland <jonathan.hoyland@gmail.com> wrote:
Hi All,

For those interested, I've been working on a form= al analysis of DCs the results of which should appear online in the next fe= w days.
I'll post to the list when it's up.

In summary I managed to prove a server only version of DCs= secure (i.e. does not violate any of the properties in Appendix E.1) under= the Dolev-Yao model without resumption, and work on a more general result = is ongoing.

Regards,

Jonathan

On Mon, 29 Jun 2020 at 16:59, Joseph Salowey <joe@salowey.net> wrote= :
This is the second working group last call for=C2=A0Delegated Crede= ntials for TLS.=C2=A0 The latest draft can be found here:=C2=A0ht= tps://tools.ietf.org/html/draft-ietf-tls-subcerts-09.=C2=A0 There have = been 2 revisions since the last review.=C2=A0 Draft 8 contains changes that= were not committed=C2=A0in time for draft 7 and draft 9 contains revisions= from the previous WGLC.=C2=A0 Links to the Diffs between the draft 9 and d= raft 7 can be found at the end of this message.=C2=A0 =C2=A0Please focus yo= ur review on the changes between draft 7 and draft 9.=C2=A0 Please send you= r comments to the list by July 13, 2020.=C2=A0=C2=A0
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000c661b905ab323bfb-- From nobody Fri Jul 24 20:04: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 2C6C73A1163; Fri, 24 Jul 2020 20:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=cCEyO9ia; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hOyGCSsZ 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 Kug9baIsRJb8; Fri, 24 Jul 2020 20:04:44 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 554CE3A1154; Fri, 24 Jul 2020 20:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1938; q=dns/txt; s=iport; t=1595646254; x=1596855854; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Mb6/2/frl5SyK1YrhW+IMO6Te+IUmGF2ntZEOl4C8oY=; b=cCEyO9iaV4VYL/J1xDB9t4Mbcfg3MpX2PUa6Mxi86JVvVjAuGRMdPLQf 5dzKAT8XxHtLqQNTODa4hyHDPIPuDI+ksyd8vI3wSo+tsXnAhtOheOyn4 a+H/0jNNf/Sal2v0N7BpNtOUUJwTX8oEOeiWIDfkgOOjgu1AiZ4s1LdOV g=; IronPort-PHdr: =?us-ascii?q?9a23=3AbMe6hxIcAD0ZnwmcqdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvKk/g1rAXIGd4PVB2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YkdQEcf6IVbVpy764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BYAQCAoBtf/40NJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgTkEAQELAYFRUQdvWC8sCoQqg0YDjVWKA45dgUKBEQNVCwE?= =?us-ascii?q?BAQwBARgLCgIEAQGETAIXggsCJDcGDgIDAQELAQEFAQEBAgEGBG2FXAyFcgE?= =?us-ascii?q?BBAEBEAsGEQwBASwLAQ8CAQgOCgICJgICAh8GCxQBEAEBBAENBRQOgwQBgks?= =?us-ascii?q?DLgEOo0oCgTmIYXaBMoMBAQEFgkqCZg0Lgg4DBoEOKgGCbINYgjOEBBqCAIE?= =?us-ascii?q?4HIJNPoIaQgEBAoEoARIBgzczgi2SX6I7TgqCXpR4hHUDHoJ7iUaTH5IUjQ2?= =?us-ascii?q?SBwIEAgQFAg4BAQWBaSRncHAVOyoBgj5QFwINjh6DcYUUhUJ0AjUCBgEHAQE?= =?us-ascii?q?DCXyOSgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,392,1589241600"; d="scan'208";a="712447675" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jul 2020 03:04:12 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 06P34CK6018301 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 25 Jul 2020 03:04:12 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Jul 2020 22:04:12 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Jul 2020 23:04:11 -0400 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 24 Jul 2020 22:04:11 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ikdlQbOktIjQTrsCSxSbpyzvgUK6y7SCPF/OXd2SJVSzI5d59X/TSypVip15ip2en/QcqFg3G2NWzIlgC4Sj3SVCw51slij7GCkOQfGUGM8tLJyvNg43kPcUOHJin/pEeKdtVZ+k4riQQKXoIspYUZMC+EnznmjxR8hLozurZoGKVPmbPzBybesjT6XHBG5t3+IvdQtTqq5v5lCFPa2/WFjg95LNjq5m0/67I99Mkyl+MwE9V5558p0abOecAh3un91TdmwVgG/B8vHGgBn/e4wZxICMx2+jKL2ZDfu3o4WX3B2VMqWaqgTBCGK5CJ54Vc363fhKVjI84nzX/1poCQ== 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=Mb6/2/frl5SyK1YrhW+IMO6Te+IUmGF2ntZEOl4C8oY=; b=X+LYY6TYJi31f0Y9itzHhpzvbj3zu5BDlV6H/c9w1HsAgZvdHwL8kWuIzedb1iSANo0tT5lqQFa1YX5cTk1zVqkou+pEYhEGFfIM2ghvrFz+oVEGk3HiGz6wx8gIvp1TFY8n3vD3khzUBfPnJbVyDLSa2XGYYyHY70uO7ke0Dioh7rWbHjt3voSLElwJDoeON+aojoujROgKxsYVq6gcamnHp5+jrIlSYReaHIo/UHxm2uayRzovcFBPrXlSqr4g6hBkWmwsY2mSt+YmzK3QboMf2O4VFgFtbEzjNTC+4IIA1JDm20MA2BflBHl6200hmDPxLUeHbqt3hQ7nx4Db2w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mb6/2/frl5SyK1YrhW+IMO6Te+IUmGF2ntZEOl4C8oY=; b=hOyGCSsZDS/R29KloXDlcoEb2qXp1YxustpIEDtan7fBVIIRXj1qqHlKPwLt2xEvT4zMG1HdcMgAImpdP2JuaI98drK/alTDJnhzLuBHC26+xqYggeDOcL9XCSUsk0hfuIeJh+QWgUBe67miFYOFgve0CdDe5MitzGyOvH+pTps= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BYAPR11MB3334.namprd11.prod.outlook.com (2603:10b6:a03:1c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Sat, 25 Jul 2020 03:04:08 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::e42f:216e:af3e:8ce5]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::e42f:216e:af3e:8ce5%7]) with mapi id 15.20.3216.027; Sat, 25 Jul 2020 03:04:08 +0000 From: "Nancy Cam-Winget (ncamwing)" To: Jen Linkova , OPSEC , "tls@ietf.org" CC: OpSec Chairs Thread-Topic: [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AdZd8qs4MVhjKcpfSaSC3eC5PK0rEQCniF8AAFkyZIA= Date: Sat, 25 Jul 2020 03:04:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.18.200713 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ffcd21a3-4e4d-45cf-7daf-08d830476621 x-ms-traffictypediagnostic: BYAPR11MB3334: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CO0MmfTca+6YM5tDx3TbGgsaYa57JI7aDUk9XEX/VuPXXPGSAjotx+LSKle3K8XIQEeLxXXHZLUW3WI8WOr8swf2RmE13IXNHRoiqD1yK2Bx8k0Y1W6BYDZIAxhEvBZjVDhSTY6Gk+iDqGA7fSEEXVoGYONBob6AO905MYNbRwipuZ6kKfP87ymYWy7A4RLke6+9jTBy7prFuohybqpxADx7Te+hqV70QdN5C5I/MX/VMtgP7jTKb8idiES3TuKCVvZnONaLrVk6lK/QIJqY88RXX/my301dd9nZka77oq5Q8mcHnPxwULTFOI75f4ejqQqNEdNC7PfwpxQiy8ZMpSuOtOKfgYBQWUQWnsqyaOAIMqP+rW5/JI2R6KP/CRpzXdMs+VxODsr1r9L8fBI5yw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(39860400002)(366004)(346002)(396003)(66556008)(86362001)(64756008)(966005)(6486002)(66946007)(66446008)(26005)(33656002)(66476007)(2616005)(76116006)(5660300002)(110136005)(186003)(36756003)(4326008)(2906002)(6512007)(478600001)(6506007)(53546011)(71200400001)(8676002)(8936002)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 7PGwYg0zbhShK6a3By5mpD0P03aSA5lXt4qaOdHSjwiFZR6JQLjK2ucZrH3gGQPQw2BOOtX71C1ecfQqlyDsolkpx6A6xWsji6CMaMWPm4iibzmk2EKmjJN+pESrr9/qFfY9KikntRdW9Kahnb0Q3hEtRkaE62bJ+wjXj7EY2iEymVD68HiYmVTQ6NWz9S4gZLAIdneb8hZ59hFVwEf/UTzEilq26M3g1kDxNgrFIaXAqE0o8rWupmFCo/RpIITOhpymp/SmJzog2RQDnqB37V5y5uHcWKe/Aqemw2SaDgPLVdElSdIW5o3ImGdE7a0P4q/Ow2sa08qnHHkHiAQcD+UyCuUc3/2SUVaN/9FXiYQdFufuAmwKjDywkMtvpmYflnanfodM+q0h7l2FficM4c+IFbOsXTsVGGIm9zQxIUeSFaHl467ri7cjsyOHQ6hLXbA5fpMPc5GHOpK+j4Qx6zo7UqtBRvztjvvCTILWOcRNKLn5PNvXz9izO9gJ5ati x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <858B900874C59742894005932B5CD963@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4070.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ffcd21a3-4e4d-45cf-7daf-08d830476621 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2020 03:04:08.3819 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6Zu3dV4EvBVdtJYoJOu7F5v4XsEz/EdUnerAOPf3XRBuLWRf1xW6a6sohTCrl6Y2GTNZWaQ6RN9jhJ0UkFF0ww== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3334 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 03:04:46 -0000 VGhpcyBkcmFmdCBwcm92aWRlcyBndWlkZWxpbmVzIGZvciBUTFMgcHJveHkgaW1wbGVtZW50YXRp b25zOyBnaXZlbiBjdXJyZW50IGFjdGl2aXRpZXMgdXNpbmcgVExTIHdpdGggcHJveHlpbmcgSSBi ZWxpZXZlIHRoaXMgZG9jdW1lbnQgaXMgdXNlZnVsIGZvciB0aGUgY29tbXVuaXR5IGFuZCBpbXBs ZW1lbnRvcnMuICBJIHN1cHBvcnQgaXRzIGFkb3B0aW9uLg0KDQpXYXJtIHJlZ2FyZHMsIE5hbmN5 DQoNCu+7v09uIDcvMjIvMjAsIDY6MzEgUE0sICJPUFNFQyBvbiBiZWhhbGYgb2YgSmVuIExpbmtv dmEiIDxvcHNlYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBmdXJyeTEzQGdtYWlsLmNv bT4gd3JvdGU6DQoNCiAgICBPbmUgdGhpbmcgdG8gYWRkIGhlcmU6IHRoZSBjaGFpcnMgd291bGQg bGlrZSB0byBoZWFyIGFjdGl2ZSBhbmQNCiAgICBleHBsaWNpdCBzdXBwb3J0IG9mIHRoZSBhZG9w dGlvbi4gU28gcGxlYXNlIHNwZWFrIHVwIGlmIHlvdSBiZWxpZXZlDQogICAgdGhlIGRyYWZ0IGlz IHVzZWZ1bCBhbmQgdGhlIFdHIHNoYWxsIHdvcmsgb24gZ2V0dGluZyBpdCBwdWJsaXNoZWQuDQog ICAgDQogICAgT24gTW9uLCBKdWwgMjAsIDIwMjAgYXQgMzozNSBBTSBSb24gQm9uaWNhDQogICAg PHJib25pY2E9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQogICAgPg0KICAg ID4gRm9sa3MsDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPiBUaGlzIGVtYWlsIGJlZ2lucyBh IENhbGwgRm9yIEFkb3B0aW9uIG9uIGRyYWZ0LXdhbmctb3BzZWMtdGxzLXByb3h5LWJwLg0KICAg ID4NCiAgICA+DQogICAgPg0KICAgID4gUGxlYXNlIHNlbmQgY29tbWVudHMgdG8gb3BzZWNAaWV0 Zi5vcmcgYnkgQXVndXN0IDMsIDIwMjAuDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgUm9uDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4gSnVuaXBlciBCdXNpbmVz cyBVc2UgT25seQ0KICAgID4NCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQogICAgPiBPUFNFQyBtYWlsaW5nIGxpc3QNCiAgICA+IE9QU0VDQGll dGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2Vj DQogICAgDQogICAgDQogICAgDQogICAgLS0NCiAgICBTWSwgSmVuIExpbmtvdmEgYWthIEZ1cnJ5 DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICBPUFNFQyBtYWlsaW5nIGxpc3QNCiAgICBPUFNFQ0BpZXRmLm9yZw0KICAgIGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzZWMNCiAgICANCg0K From nobody Sat Jul 25 07:07: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 8A9B63A1176; Sat, 25 Jul 2020 07:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-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=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 l1Jxk79eydDG; Sat, 25 Jul 2020 07:07:15 -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 C1E7F3A116D; Sat, 25 Jul 2020 07:07:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 92E5CBE2F; Sat, 25 Jul 2020 15:07:12 +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 55bR_Of1c9ll; Sat, 25 Jul 2020 15:07:10 +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 644BEBE20; Sat, 25 Jul 2020 15:07:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1595686030; bh=8kFyMJKKAWydAa4j5D2sauVYRQv8tjbeb8yQUqrfZbM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=YHD3xHNIVPAvA0hczbBVp+li7p1f+HTjn+bbyZGAP9ZMQ1GlQwRm7wP1YLReAQPHz htYvJNbZn1/outDvN6xHyQFBvxfXwHCHfzEJKjjLFQ62Od0owhRHmozfnWmCS7rZ+T QHL6Gz4LUMKzxmgiR5EospI7X96sbG3ivuqcfSFE= To: Jen Linkova , OPSEC , "tls@ietf.org" Cc: OpSec Chairs 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: Sat, 25 Jul 2020 15:07:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FAvIFgt9v20FrpiNfH66umCY9DgaRATDa" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 14:07:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FAvIFgt9v20FrpiNfH66umCY9DgaRATDa Content-Type: multipart/mixed; boundary="ooxA1C7HURYfWxvPydOq9Ot2frNU8BbJk"; protected-headers="v1" From: Stephen Farrell To: Jen Linkova , OPSEC , "tls@ietf.org" Cc: OpSec Chairs Message-ID: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp References: In-Reply-To: --ooxA1C7HURYfWxvPydOq9Ot2frNU8BbJk Content-Type: multipart/mixed; boundary="------------F50784C062484BF407BF9C04" Content-Language: en-US This is a multi-part message in MIME format. --------------F50784C062484BF407BF9C04 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I oppose adoption. While there could be some minor benefit in documenting the uses and abuses seen when mitm'ing tls, I doubt that the effort to ensure a balanced document is at all worthwhile. The current draft is too far from what it'd need to be to be adopted. Send to ISE. S. On 23/07/2020 02:30, Jen Linkova wrote: > One thing to add here: the chairs would like to hear active and > explicit support of the adoption. So please speak up if you believe > the draft is useful and the WG shall work on getting it published. >=20 > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica > wrote: >> >> Folks, >> >> >> >> This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp= =2E >> >> >> >> Please send comments to opsec@ietf.org by August 3, 2020. >> >> >> >> Ron >> >> >> >> >> Juniper Business Use Only >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >=20 >=20 >=20 > -- > SY, Jen Linkova aka Furry >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------F50784C062484BF407BF9C04 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----- --------------F50784C062484BF407BF9C04-- --ooxA1C7HURYfWxvPydOq9Ot2frNU8BbJk-- --FAvIFgt9v20FrpiNfH66umCY9DgaRATDa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl8cPI0ACgkQWrL68XsX K+r3rBAA06ncVV7x6WnOtO/PzLhVrMG8PQeuEieggvOyD/h6qEHDUNNfPc9aiSMi 6B7RfNpoLtqCQ72S3OfaOqN9dpZPJkLefnNNa64hS156Dfx+/0NAssHbUQCeCUAC jJVV1NI8GauCDQ0LsZK6WNJ63g/f0ze/LuUgTMBaq4nTm1qw2ytvHFuqiNpazkF5 DanyVNUGJG3p0i2ZUCh/pRUKTkMOjjQ4Ix14H7+4kqA3EwWu9X4EdNcI3VlAJOR7 LSkCLpscrBj6a31bDjKcbSOdiFMw+NHjuXFS60++27mwEBNfN4ype9oCyjcPSlHz XxwQB2nE+2K36gp0zegSh5R+U0fQLCniHWtNrT/KLwkkMaM7o/38xvQPn/2eTKdW yyWj8rFYOC/J+zXrBSgtIBnBAxirKG0E46/W7tm4sb0i3d2BL1rxyt2yn86odnBS 8eIyt6W9eITsAxSfzKbjOzYAzI+BKqlTkEPv8j656LiJF46w+wmpnVRYEee0q1Eb uC+GpZNUT3E+vhtUQksFCeZwFVfjNVx5RORGerBxPX8GEmcv3Xq1pigqs2ngvQB2 N8oWMhpTaiSjKZ/21ENOCbmDWrBpePyw67AmuV1YX4ZwSH0i9klmL1OQUFIUMj0u iqo20i1Fa3PhoM5uQdbwPj3kcLSmKWcjtUVE3ueHtYNDRpZouMs= =EGXP -----END PGP SIGNATURE----- --FAvIFgt9v20FrpiNfH66umCY9DgaRATDa-- From nobody Sun Jul 26 14:22: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 1911E3A149E; Sun, 26 Jul 2020 14:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, 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 K6JBvVqi27Ua; Sun, 26 Jul 2020 14:22:31 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 0215A3A149D; Sun, 26 Jul 2020 14:22:27 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06QLMNad032641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 26 Jul 2020 17:22:25 -0400 Date: Sun, 26 Jul 2020 14:22:23 -0700 From: Benjamin Kaduk To: draft-ietf-tls-oldversions-deprecate.all@ietf.org Cc: tls@ietf.org Message-ID: <20200726212223.GY41010@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: [TLS] AD review of draft-ietf-tls-oldversions-deprecate-06 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 Jul 2020 21:22:40 -0000 Thanks for putting together the -06 based on my preliminary comments, and my apologies for taking so long to get back to it. It turns out that going through the 80-odd documents we update takes a while! I have a bunch of suggestions that are basically editorial, that I'll make a pull request for (along with suggested changes for several of the following comments). It's up at: https://github.com/tlswg/oldversions-deprecate/pull/3 We mention in the Abstract (but not Introduction!) that this document moves 2246 and 4346 (but not 6347!) to the historic state. Unfortunately, this is slightly problematic from a process perspective, since the current way to make things Historic (https://www.ietf.org/about/groups/iesg/statements/designating-rfcs-historic-2014-07-20) requires a separate "status change document" that gets its own IETF LC, to effectuate the status change. Most references to the status change document can be replaced by this RFC after it's published, but formally the move to historic is *not* done by this document. I've pulled into my pull request the language used in RFC 8429 to describe moves to Historic; please make sure to reproduce that language in the Introduction as well as the Abstract. I found three documents (3656, 4540, 7562) in the list of update targets that are on the ISE (not IETF) stream. I had talked to Adrian during my preliminary review, and in principle it is permissible to make those updates as part of this document, but we will need specific ISE approval to do so. I am supposed to sync up with him during IETF LC, but the document needs to be updated to clarify that the updates of ISE documents are/will be done with permission of the ISE. (Please also try to double-check that the list is complete; I didn't find an authoritative list of "all documents on the ISE stream" to grep against, and I didn't try to have something parse rfc-index.xml to output such a list. I note that in addition to our BCP 195 update (called out in Section 6), we also update 3552, which is BCP 72. This update is quite incidental (compared to our BCP 195 update), so it seems clear that having this document be part of BCP 195 is correct. Section 1.1 I went through all 83 of the references in the big list, that are supposed to be ones that "normatively reference TLS 1.0/1.1 or DTLS 1.0, as well as the shorter list of already-obsoleted documents. I won't bore you with my full notes, but there are some particular things that stood out from the review: - We have a separate list of updates for documents that are already obsolete (but don't say much about why we're going go the extra bother). However, three of the documents in our main list of updates (4743, 4744, and 6460) are already Historic, and presumably should be treated more like the already-obsolete ones. - Several documents (e.g., 8261, 5023) specifically have MUST-level requirements for 1.0 (or 1.1) that disappear or become internally inconsistent with our current update, so we might want to fill that void. - A few documents (6749, 6750, 6739) make an interesting claim about TLS 1.0 being the "most widely deployed version" and providing the "broadest interoperability". - Many documents note specific MTI ciphers (largely just the MTI ciphers from the respective TLS version). Since all ciphers defined for 1.0/1.1 also work in 1.2 (with the exception of the IDEA and DES ciphers from RFC 5469, that it claims "have been removed from TLS version 1.2"), these requirements in theory are still in effect, even though those particular ciphers are not great and the badness of those ciphers is a lot of the justification for deprecating the old protocol versions. I don't really think that a piecemeal effort to identify and update each specific MTI cipher mention is worth the effort, though it may be worth noting that TLS 1.2 has TLS_RSA_WITH_AES_128_CBC_SHA as MTI and that it is preferred over the older MTI ciphers. (Actually, it looks like a few of the specific MTI mentions in the documents we're updating are already TLS_RSA_WITH_AES_128_CBC_SHA, hooray.) - As implied by the previous bullet point, the IDEA and DES ciphers specified by RFC 5469 are now entirely obsolete, which means that that entire document is also obsolete (or maybe historic?). It seems like the right thing to do to effectuate that change via this document. - Similarly, the downgrade protection provided by the SCSV of RFC 7507 seems to be entirely obsolete. Any implementation that is compliant with this document will support only 1.2 or higher. If it only supports one version, no downgrade is possible; if it also supports 1.3 or newer, the new downgrade-detection mechanism defined by TLS 1.3 applies, so the SCSV mechanism is entirely redundant (i.e., obsolete). We could effectuate that status change in this document as well. - We list RFC 8465 as being updated, but it doesn't seem to say anything at all about TLS or reference the relevant RFCs. [RFC6614] has a requirement for TLSv1.1 although only makes an informative reference to [RFC4346]. The text in question seems to be: % * Support for TLS v1.1 [RFC4346] or later (e.g., TLS 1.2 % [RFC5246]) is REQUIRED. [...] And RFC 5246 is a normative reference for it. So we may want to say "has a requirement for TLSv1.1 or later, although only makes an informative reference to [RFC4346]. This requirement is updated to be for TLSv1.2 or later." This document updates DTLS [RFC6347]. I note that in the thread from my preliminary review there was some support for the sentiment that these changes do not formally Update 6347, in that what 6347 says about version negotiation is still true; we just tell you not to do it. (https://mailarchive.ietf.org/arch/msg/tls/YUySQbMVJPv31Fwv68rEpcmBMsM/) But, if we do keep the Updates: relationship, I think we want to say slightly more, e.g., noting that the interoperation with DTLS 1.0 that it describes is now forbidden. Section 2 Specific details on attacks against TLSv1.0 and TLSv1.1 as well as their mitigations are provided in NIST SP800-52r2 [NIST800-52r2], RFC 7457 [RFC7457] and other referenced RFCs. Although the attacks have Are the "other referenced RFCs" referenced from 7457 or from this document. This document references ... quite a few RFCs, so either way we should probably clarify. been mitigated, if support is dropped for future library releases for these versions, it is unlikely attacks found going forward will be mitigated in older library releases. [The wording here is kind of convoluted; I've suggested an alternative in the aforementioned pull request.] NIST for example have provided the following rationale, copied with permission from NIST SP800-52r2 [NIST800-52r2], section 1.2 "History of TLS" (with references changed for RFC formatting). (The version of SP800-52r2 that we reference has been withdrawn. We should probably check that the quotation in question has not changed if we update to reference a current version of the NIST document.) Section 3 The integrity of both TLSv1.0 and TLSv1.1 depends on a running SHA-1 hash of the exchanged messages. This makes it possible to perform a downgrade attack on the handshake by an attacker able to perform 2^77 operations, well below the acceptable modern security margin. The 2^77 number seems to be the pre-shattered.io number. Similarly, the authentication of the handshake depends on signatures made using SHA-1 hash or a not stronger concatenation of MD-5 and SHA-1 hashes, allowing the attacker to impersonate a server when it is able to break the severely weakened SHA-1 hash. Having reviewed the WGLC thread and the papers linked therefrom, I'm suggesting that we change this to "not appreciably stronger" (along with adding the missing article to "using SHA-1 hash"). In particular, https://www.iacr.org/archive/asiacrypt2009/59120136/59120136.pdf suggests that MD5 is particularly weak, and that attacking SHA-1 will continue to be the bulk of the work even as attacks on SHA-1 become more efficient than O(2^58), so that the difference is mostly just the factor of 64 for the Joux multicollision. Section 4 TLSv1.0 MUST NOT be used. Negotiation of TLSv1.0 from any version of TLS MUST NOT be permitted. (editorial) I'm not sure how much precedent there is for a construction that talks about negotiating one version of TLS "from" some other version of TLS. In my head the negotiation is something that's done by or from an implementation, rather than a version. I don't want to insist on anything here, but I probably would have written something more like "negotiation of TLSv1.0 by any implementation of TLS MUST NOT be permitted". (And similarly for the following section.) Any other version of TLS is more secure than TLSv1.0. TLSv1.0 can be configured to prevent interception, though using the highest version available is preferable. This second sentence seems almost like it's undercutting the premise of MUST NOT use. Would it be better to say something like "While TLSv1.0 can be configured to prevent some types of interception, using the highest version available is preferred"? (Similarly for the following section.) Historically, TLS specifications were not clear on what the record layer version number (TLSPlaintext.version) could contain when sending ClientHello. Appendix E of [RFC5246] notes that TLSPlaintext.version could be selected to maximize interoperability, though no definitive value is identified as ideal. That guidance is still applicable; therefore, TLS servers MUST accept any value {03,XX} (including {03,00}) as the record layer version number for ClientHello, but they MUST NOT negotiate TLSv1.0. This "MUST accept any value" seems redundant with Appendix D.2 of RFC 8446, which is also giving guidance in this space (but we don't currently link to). (Similarly for the following section.) Section 5 Should we also wrap the DTLSv1.0 bits in here? (Or have a dedicated section?) We don't currently have specific statements like "DTLSv1.0 MUST NOT be used", "MUST NOT send a ClientHello with ClientHello.client_version set to {254,255}", etc. Thanks, Ben From nobody Sun Jul 26 19:03: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 4C1613A15E7 for ; Sun, 26 Jul 2020 19:02:48 -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 pqJsKpwmXLIy for ; Sun, 26 Jul 2020 19:02:47 -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 241B73A15E8 for ; Sun, 26 Jul 2020 19:02:47 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id x69so14021850qkb.1 for ; Sun, 26 Jul 2020 19:02:47 -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=/hAMweyful58WDEJMSCY0vGUJniiSUOVM9zKgfijI/g=; b=W/XBRB+/msm4ZTOSp7VOTNtcoPzUVH4sFdHi0/mpz6pksHeijMbCdFrysXCI/UtiBA D5pig6oFt4N7MX9tw67tO2CeEo/vAiJOKYItb2BBXRtTgObJu7cttLY/VQuOiwmiSu4t mDj0gMGddNujzWiByGimRl2Ce1a+ZKjCCHEKQ= 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=/hAMweyful58WDEJMSCY0vGUJniiSUOVM9zKgfijI/g=; b=GmePszVyJbjq38+xQnGlJNPn7YbXrubnpEE/vZy5qLkQ2NR58pBazPqGPS85oyQTNK dNNvMKp2xx6jTD6Aq+R8FshmZsc6GPi6gtoO9V+TPY69mwgEoMmKGXZJQDd6qOBlvNHh jcthktqCvvTxXa2Nt9S1v4gY4DUZIBzbeF/P/qBw3M0XIs9/FgbIvL7OHoSoT2EoVkm4 04kzRHbF4wQU8f5cDWAiJZIaz6j9DLwiUEGTroQIRX4r9zl+VQDRykpFlbIc81oYQQl5 RhbT2ZyaZQcVq8KEwRT0SIbNnYMVkFUQvZ/jaGlP3OHjOCQc1D3mz0fpAa9EE8zo87aS 5oMw== X-Gm-Message-State: AOAM531GfvJ6Vq9SxlOOlBn8QkoGxu5xD6NzQkz8ZKHN6EPfzUQbYZ6A 8EoCXGDSos8RV5tQfz753Hl6rSCGNUc= X-Google-Smtp-Source: ABdhPJwt0zB72gkQF8XINfhtaYcY7l4wypP9OC4OZVPjisfiPZ17NU+j8hMeZZLi70CsRpQry4ZH0Q== X-Received: by 2002:a05:620a:22eb:: with SMTP id p11mr5899011qki.413.1595815365864; Sun, 26 Jul 2020 19:02:45 -0700 (PDT) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id w1sm12396155qte.25.2020.07.26.19.02.44 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jul 2020 19:02: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.120.23.2.1\)) Message-Id: Date: Sun, 26 Jul 2020 22:02:40 -0400 To: TLS List X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [TLS] TLS@IETF108: 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: Mon, 27 Jul 2020 02:02:48 -0000 Hi! If you are interested in volunteering to take minutes or be jabber = scribe please let the chairs know (chairs-tls@ietf.org). spt= From nobody Sun Jul 26 20: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 092343A1664 for ; Sun, 26 Jul 2020 20:33:15 -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 0_YvrJdzE0In for ; Sun, 26 Jul 2020 20:33:13 -0700 (PDT) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 5F0A53A1663 for ; Sun, 26 Jul 2020 20:33:13 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id di5so6803758qvb.11 for ; Sun, 26 Jul 2020 20:33:13 -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=aXJu18wQhqpZlIf3ZHIb/IFoVo04gMbleuIxzNS6On8=; b=GSY1E/rE6sg5Kn4q1rxAk+2cEPYEkccuEySnWEime4R1s91kK057PaSQxMnSDLSXuf jOQfYuOPstbx5SlLZR5HC6zG3Dssp1DuSK/MwkVrJv8M71yG0wkvYov1D6wXnchLTGmN A7ayXXdE8Jqx7+s/bIZoTwsaXwFKgiE099ZFo= 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=aXJu18wQhqpZlIf3ZHIb/IFoVo04gMbleuIxzNS6On8=; b=itevVmJDYIEsXEPMXgkryAToG9bPYJXYt5aWPsa2Uo1Oqv7V2JjKimRaOccNOFpusw XhLY/gDw1dDRuiyGrORi6blZgaPiP6k6pQhfKe/qqJN0mr4ZBYv4LTIU9T66h/pgVRhs ifnUiD03Io2VhcwdHgDWZelzhWYqq5zn5BkY9ovINGIsRQB4SXpc146JfemI10blVGFS B837X97O2mHho0bwW2AvH0kfttbUlrA2FYsLBIMU6PTkI2Hb2YOoOaQ4R1+yaBNnXqSj 1H+EuOjAJPbFX1peELP7sIkjOHG5B64RLs9Gt0vZoqINwy++aTi1KCCJTmvRKesm8Avx gQ9Q== X-Gm-Message-State: AOAM530LlnJF7of+0KeD65PDscFDa9dXTIMmoXyecH5Df+Fuua3A2VNJ ZNlSRfC4UnBPJHS/snvmmHFi7vJOBLQ= X-Google-Smtp-Source: ABdhPJy9gdo/I7bjC5qsVoTd8NO662Ni8TpOLOFL7TmfrTZzlpaumJXVe8OiEr9u8ur5c0l5SE4x7A== X-Received: by 2002:ad4:4812:: with SMTP id g18mr20414754qvy.56.1595820791925; Sun, 26 Jul 2020 20:33:11 -0700 (PDT) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id q29sm14185692qtc.10.2020.07.26.20.33.10 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Jul 2020 20:33:10 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: <45290FDC-56AC-46DA-8C20-C21AC55594E7@sn3rd.com> Date: Sun, 26 Jul 2020 23:33:09 -0400 To: TLS List X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [TLS] TLS@IETF108: Meeting Logistics 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 Jul 2020 03:33:15 -0000 The following information can also be found in the agenda: https://www.ietf.org/proceedings/108/agenda/agenda-108-tls-03 # TLS@IETF018 ## Logistics ### Time Tuesday 2020-07-28 14:10 UTC ### Meeting Information Meetecho (a/v and chat): https://gce.conf.meetecho.com/conference/?group=tls&short=&item=1 Audio (only): http://mp3.conf.meetecho.com/ietf/ietf1086.m3u Etherpad (virtual blue sheets and notes): https://codimd.ietf.org/notes-ietf-108-tls# ## Agenda ### Administrivia - Virtual Meeting Tips - Note Well - Virtual Bluesheet - Note Taker - Jabber Scribe - Status ### Drafts TLS Subcerts https://tools.ietf.org/html/draft-ietf-tls-subcerts-09 TLS Flags https://tools.ietf.org/html/draft-ietf-tls-tlsflags-03 TLS 1.3 Extended Key Schedule https://tools.ietf.org/html/draft-jhoyla-tls-extended-key-schedule-01 Cross-SNI Resumption https://tools.ietf.org/html/draft-vvv-tls-cross-sni-resumption-00 ALPS https://tools.ietf.org/html/draft-vvv-tls-alps-00 SNIP https://tools.ietf.org/html/draft-thomson-tls-snip-00 From nobody Sun Jul 26 22:15: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 4C9973A0AAC; Sun, 26 Jul 2020 22:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YEOeoj7X; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iB3295ED 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 qG4VsXNf3acg; Sun, 26 Jul 2020 22:15:00 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19933A0AA7; Sun, 26 Jul 2020 22:14:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24691; q=dns/txt; s=iport; t=1595826899; x=1597036499; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PuzFDiOufT+1M+1wWTx9Cjhl+paKUf4TAn16ApfIfL0=; b=YEOeoj7XUs9H2hGppZA4772G5spB8exyBhmOmK0roiG/xwTWKRVUnrim wDQ00U8Kpp/fISWKfPwEaRyw+AIpkFVxo0wj3HghxCVEMr//ZAMT7m+kY CSIne6oqQqke6kwDLvcA6GQFiZzcfQrHKXaGzHipTyUprRP4Q/4uOCf9S c=; IronPort-PHdr: =?us-ascii?q?9a23=3AopXlHR2R+x7lHMRusmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGuadmlxnVVomd6v8Xw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoOlMTBM3yIVzf8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVDADKYR5f/40NJK1gg3YvUQdvWC8?= =?us-ascii?q?sCoQqg0YDjTCZBoFCgREDVQsBAQEMAQEYAQoKAgQBAYRMAheCCwIkOBMCAwE?= =?us-ascii?q?BCwEBBQEBAQIBBgRthVwMhXICBAEBEAsGHQEBIwkLAQ8CAQg4BwMCAgIlCxQ?= =?us-ascii?q?RAQEEDgUUDoMEAYF+TQMuAQ6hQwKBOYhhdoEygwEBAQWFLRiCDgMGgTiCbYN?= =?us-ascii?q?ZhjcaggCBOAwQgk0+glwBAQIBgScBEgEgGBaCaTOCLY94gis9hlmLUpBjCoJ?= =?us-ascii?q?eiFaRGAMegnuJSJMhnESRFoNWAgQCBAUCDgEBBYFqI2dwcBU7KgGCPj4SFwI?= =?us-ascii?q?Nkg+FFIVCdAI1AgYBBwEBAwl8jgsBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,401,1589241600"; d="scan'208,217";a="529916091" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jul 2020 05:14:58 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 06R5Ewpp007692 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jul 2020 05:14:58 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 00:14:58 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 00:14:58 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 27 Jul 2020 00:14:57 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J794cei53KUN86ge2h3iFf/FEe6ua8tJdRjaJup9Elrd8blqzjtzJC8xr9bUlyJ2R+6uXbap5q6Kv0amGlZnHFrbw5Tzhjfg41uI2s65K7fSIAneBSpfslfguWvzMpnyvcuiA2pPyk7OK732y6W2Z0JclH0BKBbymE5vEy+1ZqLRrx23Uc+5Oby9q1y014lV9D/uLag8UYR8xW9B39gl4T8dt0J4rjXricy9p7iMpMIq7ge7kinmdCcQK/qXkqRcNEzvTNT8H0DoQGZCKp/8x2nNpqCYH7iMCDyTVIjB1WVveZoQrPJl7ePq5kOrnvRrooW/ZB/UMZv+w/n5LGDH9g== 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=PuzFDiOufT+1M+1wWTx9Cjhl+paKUf4TAn16ApfIfL0=; b=b0vs+KACR4FAzfLqLOLKIjlpm1LGWzYljqFkrvxmAsBM04V5lZgHr+WNHmiyqB63smknhTFJyQ18Z1nl2Xyqcl1jqV1wluj7TtarauUYbxfobe4L/FKkXSTE8n4Xlklq1B0WNj87kcn+HClfEwlhw5JXPmityaXhA+ZdWloeEtWCQyGtXyFpkYIf7fBpwZcbqLhDdYcUgXtjp6OwN5Kk/LlEhn65T74NCS/dt754LejyI4RCZARL7DCE68gz7bh1Vn2mf5GmM9ytwFNtBIh6KEHB2RqY3hoo/W2zqiZH55ZsUJgnb1DUe58DqOMCEEzZa3IB1TbrLjORhYeEdHDsoA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PuzFDiOufT+1M+1wWTx9Cjhl+paKUf4TAn16ApfIfL0=; b=iB3295EDWFjlqLg99Oma2oUHcOym4YcWyHj43jjcldf9+BTKNdp/2gD2dXgJQYI3MyjZsDTE1RqV/6BRWitJOxh18bkV54VNZQjvj39bySITz+CWPteLIQLMAi2x7UcT2imlZcIYoXKXKCxv8lc0JWeqGUfnvIasiWNkjdfJej8= Received: from BYAPR11MB2789.namprd11.prod.outlook.com (2603:10b6:a02:cc::11) by BY5PR11MB4037.namprd11.prod.outlook.com (2603:10b6:a03:188::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Mon, 27 Jul 2020 05:14:56 +0000 Received: from BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870]) by BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870%6]) with mapi id 15.20.3216.031; Mon, 27 Jul 2020 05:14:56 +0000 From: "Eric Wang (ejwang)" To: Stephen Farrell CC: Jen Linkova , OPSEC , "tls@ietf.org" , OpSec Chairs Thread-Topic: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AdZd8qs4MVhjKcpfSaSC3eC5PK0rEQCniF8AAH8FdoAAUf6sgA== Date: Mon, 27 Jul 2020 05:14:56 +0000 Message-ID: <4937FCE4-23EF-4585-8675-C07F3B347AC6@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.15) authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=cisco.com; x-originating-ip: [128.107.241.183] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4b86151e-c10b-4409-715d-08d831ec00a0 x-ms-traffictypediagnostic: BY5PR11MB4037: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mCpBLMcyyEkuGq28cuHBA/whvOZoUJA3Eu1zTO+y9hl7JMelia2I3/05bqi24jkDlTZGPS7Rzr6UAbUpIMSKjCqNHPxL9b8FCNlszSOs/1AUP9qcQWUhMpmYd9KgA6qLJBquZidEgLTRHhrJEmR72LgBtX3WayRChsIgpvXmZINCSI8LaR21GYHJXGAr2zE5YPMBrpLz1CkeI1mYJ9oZ0QbqzbKeQfH4EEFLLkhkheyMSINJ+M5IukQ/O2SomZUYSh0/WsR9tQl5Yozrctza4UR/4s6Bwg9mSktOOhxzG80AUlgKYGx5MPZUkZbhlpGUPDiS3BVmltB1IEsEg0yVVFWBLck/hvQ2WHkOysECxkcwT/7DCe2ylC+7d30sMRevRhpbda1AE218eyYGZfwhcA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2789.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(366004)(396003)(376002)(346002)(478600001)(6486002)(5660300002)(166002)(66476007)(71200400001)(76116006)(66556008)(64756008)(66446008)(66946007)(8936002)(2616005)(4326008)(26005)(6506007)(53546011)(6512007)(966005)(186003)(36756003)(86362001)(33656002)(2906002)(316002)(296002)(54906003)(6916009)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Qg5wSSwb/0t7ZRR4jIiV3jajZq4+/b8BPOS70dCKaZ1m3km/neOTo5tQ69sXay0JNrocirczxYhExULSikoeWXd9dUPp7CJK7T2MAah/C4fvFulWzsrzbi7lcwwxO5pMtMrizcwX9kH5WXTbGckcqUB2g7JHs9QeSgqj4eoGEYJWOgd3N2tll/ZTtBRCSk1KX56Od2XGkQ2ueD2q8v44F44JaKN5R0arW4BOtfXozhriLlmXeCIe/LeYGL6s4TUSd6iDvGQP9gdTU6zH9hIZe7cJWzdZTImNYQb0kuDG3CJ2KLLqUNdH/KI1lgsLm4+yrj6hqZZW55zQT0fGjuXvd8gnvbZ9u9Mwfvcp5f7BRoqtrglP7xXWlfemeOVkRlQLt5imJYJCiCzMr76HKKzy0Gmgm08Fa4cHA5Xr2U7vgb9VXhd0EQc0//lEM9UTrm1ZZNmll5NgzwW9Z5xj2f7iz7kXsWblpErgA+KiG0AfCnpxQMgWATw7Y9BuDLT7SWgL Content-Type: multipart/alternative; boundary="_000_4937FCE423EF45858675C07F3B347AC6ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2789.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b86151e-c10b-4409-715d-08d831ec00a0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 05:14:56.3883 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TAq0L7vwPQVd5Pl9R7FA+TzB7EPZ6mOt5HDSgSNs5JlBQ5Qy+X55DIlQBw5m18+vRbIFCaaiu+4WMDGe7RnDzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4037 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 05:15:03 -0000 --_000_4937FCE423EF45858675C07F3B347AC6ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3RlcGhlbiwNCg0KVGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLiAgSeKAmWQgbGlrZSB0byBj bGFyaWZ5LCBnaXZlbiB0aGUgcmVhbGl0eSB0b2RheSB0aGF0IENETi9sb2FkIGJhbGFuY2VycyBh bmQgZW50ZXJwcmlzZXMgZGVwbG95IFRMUyBwcm94eSwgdGhpcyBkcmFmdCBpcyBtZXJlbHkgdG8g bGF5IG91dCBhIGJhc2VsaW5lIGd1aWRhbmNlIHRvIHRoZSBpbXBsZW1lbnRhdGlvbiBhbmQgb3Bl cmF0aW9uWzFdLiAgSXQgaXMgbm90IG1lYW50IHRvIGFuYWx5emUgInVzZSBhbmQgYWJ1c2UiIG9y ICJwcm9zIGFuZCBjb25zIiwgZm9yIHdoaWNoIHRoZXJlIHdlcmUgbWFueSBkaXNjdXNzaW9ucyBh bmQgcHVibGljYXRpb25zIGluIHRoZSBwYXN0IGFuZCB0aGUgZHJhZnQgcmVmZXJlbmNlcyBzb21l IG9mIHRoZW0uDQoNCkdpdmVuIHRoZSBwcm9ncmVzc2lvbiBvZiBUTFMgYW5kIGl0cyB3aWRlIGFk b3B0aW9uLCB0aGUgdXNlIG9mIFRMUyBwcm94eSBpcyBhbHNvIGJlY29taW5nIGEgcHJhY3RpY2Ug YW5kIGlzIGdyb3dpbmcgaW4gZW50ZXJwcmlzZS9DRE4uICBXZSBmZWx0IGl04oCZcyBhIGdvb2Qg dGhpbmcgZm9yIHRoZSBjb21tdW5pdHkgdG8gZGVmaW5lIGEgc2V0IG9mIGJlc3QgcHJhY3RpY2Vz IGZvciBwcmFjdGl0aW9uZXJzIHRvIHJlZmVyZW5jZSB3aGVuIGltcGxlbWVudGluZyBhbmQgb3Bl cmF0aW5nIFRMUyBwcm94eS4gIFdpdGhvdXQgb25lLCBUTFMgZGVwbG95bWVudHMgd291bGQgYmUg bmVnYXRpdmVseSBpbXBhY3RlZC4gIEFsc28sIGdpdmVuIHNvbWUgb2YgdGhlIGltcGxlbWVudGF0 aW9uIGluY29uc2lzdGVuY2llcyBub3RlZCBkdXJpbmcgdGhlIFRMUyAxLjMgZXZvbHV0aW9uLCB3 ZSBmZWx0IGEgYmNwIGd1aWRlIGNvdWxkIGhlbHAgdGhlIGNvbW11bml0eSBtb3ZpbmcgZm9yd2Fy ZC4gIFRoYXTigJlzIHRoZSBwdXJwb3NlIG9mIHRoaXMgZHJhZnQuDQoNCkJlc3QsDQotRXJpYw0K DQpbMV0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhbmctb3BzZWMtdGxzLXBy b3h5LWJwLTAwI3NlY3Rpb24tMQ0KDQoNCk9uIEp1bCAyNSwgMjAyMCwgYXQgNzowNyBBTSwgU3Rl cGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPG1haWx0bzpzdGVwaGVuLmZh cnJlbGxAY3MudGNkLmllPj4gd3JvdGU6DQoNCg0KSSBvcHBvc2UgYWRvcHRpb24uIFdoaWxlIHRo ZXJlIGNvdWxkIGJlIHNvbWUgbWlub3IgYmVuZWZpdA0KaW4gZG9jdW1lbnRpbmcgdGhlIHVzZXMg YW5kIGFidXNlcyBzZWVuIHdoZW4gbWl0bSdpbmcgdGxzLA0KSSBkb3VidCB0aGF0IHRoZSBlZmZv cnQgdG8gZW5zdXJlIGEgYmFsYW5jZWQgZG9jdW1lbnQgaXMgYXQNCmFsbCB3b3J0aHdoaWxlLiBU aGUgY3VycmVudCBkcmFmdCBpcyB0b28gZmFyIGZyb20gd2hhdCBpdCdkDQpuZWVkIHRvIGJlIHRv IGJlIGFkb3B0ZWQuDQoNClNlbmQgdG8gSVNFLg0KDQpTLg0KDQpPbiAyMy8wNy8yMDIwIDAyOjMw LCBKZW4gTGlua292YSB3cm90ZToNCk9uZSB0aGluZyB0byBhZGQgaGVyZTogdGhlIGNoYWlycyB3 b3VsZCBsaWtlIHRvIGhlYXIgYWN0aXZlIGFuZA0KZXhwbGljaXQgc3VwcG9ydCBvZiB0aGUgYWRv cHRpb24uIFNvIHBsZWFzZSBzcGVhayB1cCBpZiB5b3UgYmVsaWV2ZQ0KdGhlIGRyYWZ0IGlzIHVz ZWZ1bCBhbmQgdGhlIFdHIHNoYWxsIHdvcmsgb24gZ2V0dGluZyBpdCBwdWJsaXNoZWQuDQoNCk9u IE1vbiwgSnVsIDIwLCAyMDIwIGF0IDM6MzUgQU0gUm9uIEJvbmljYQ0KPHJib25pY2E9NDBqdW5p cGVyLm5ldEBkbWFyYy5pZXRmLm9yZzxtYWlsdG86cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJj LmlldGYub3JnPj4gd3JvdGU6DQoNCkZvbGtzLA0KDQoNCg0KVGhpcyBlbWFpbCBiZWdpbnMgYSBD YWxsIEZvciBBZG9wdGlvbiBvbiBkcmFmdC13YW5nLW9wc2VjLXRscy1wcm94eS1icC4NCg0KDQoN ClBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIG9wc2VjQGlldGYub3JnPG1haWx0bzpvcHNlY0BpZXRm Lm9yZz4gYnkgQXVndXN0IDMsIDIwMjAuDQoNCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCg0KDQoNCg0KSnVuaXBl ciBCdXNpbmVzcyBVc2UgT25seQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KT1BTRUMgbWFpbGluZyBsaXN0DQpPUFNFQ0BpZXRmLm9yZzxtYWlsdG86 T1BTRUNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29w c2VjDQoNCg0KDQotLQ0KU1ksIEplbiBMaW5rb3ZhIGFrYSBGdXJyeQ0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExT QGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Rscw0KDQo8MHg1QUIyRkFGMTdCMTcyQkVBLmFzYz5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExT QGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Rscw0KDQo= --_000_4937FCE423EF45858675C07F3B347AC6ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkhpIFN0ZXBoZW4sJm5i c3A7PGJyIGNsYXNzPSIiPg0KJm5ic3A7PGJyIGNsYXNzPSIiPg0KVGhhbmtzIGZvciB5b3VyIGZl ZWRiYWNrLiAmbmJzcDtJ4oCZZCBsaWtlIHRvIGNsYXJpZnksIGdpdmVuIHRoZSByZWFsaXR5IHRv ZGF5IHRoYXQgQ0ROL2xvYWQgYmFsYW5jZXJzIGFuZCBlbnRlcnByaXNlcyBkZXBsb3kgVExTIHBy b3h5LCB0aGlzIGRyYWZ0IGlzIG1lcmVseSB0byBsYXkgb3V0IGEgYmFzZWxpbmUgZ3VpZGFuY2Ug dG8gdGhlIGltcGxlbWVudGF0aW9uJm5ic3A7YW5kIG9wZXJhdGlvblsxXS4gJm5ic3A7SXQgaXMg bm90IG1lYW50IHRvIGFuYWx5emUgJnF1b3Q7dXNlIGFuZA0KIGFidXNlJnF1b3Q7IG9yICZxdW90 O3Byb3MgYW5kIGNvbnMmcXVvdDssIGZvciB3aGljaCB0aGVyZSB3ZXJlIG1hbnkgZGlzY3Vzc2lv bnMgYW5kIHB1YmxpY2F0aW9ucyBpbiB0aGUgcGFzdCBhbmQgdGhlIGRyYWZ0IHJlZmVyZW5jZXMg c29tZSBvZiB0aGVtLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkdpdmVuIHRoZSBwcm9n cmVzc2lvbiBvZiBUTFMgYW5kIGl0cyB3aWRlIGFkb3B0aW9uLCB0aGUgdXNlIG9mIFRMUyBwcm94 eSBpcyBhbHNvIGJlY29taW5nIGEgcHJhY3RpY2UgYW5kIGlzIGdyb3dpbmcgaW4gZW50ZXJwcmlz ZS9DRE4uICZuYnNwO1dlIGZlbHQgaXTigJlzIGEgZ29vZCB0aGluZyBmb3IgdGhlIGNvbW11bml0 eSB0byBkZWZpbmUgYSBzZXQgb2YgYmVzdCZuYnNwO3ByYWN0aWNlcyBmb3IgcHJhY3RpdGlvbmVy cyB0byByZWZlcmVuY2Ugd2hlbiBpbXBsZW1lbnRpbmcNCiBhbmQgb3BlcmF0aW5nIFRMUyBwcm94 eS4gJm5ic3A7V2l0aG91dCBvbmUsIFRMUyBkZXBsb3ltZW50cyB3b3VsZCBiZSBuZWdhdGl2ZWx5 IGltcGFjdGVkLiAmbmJzcDtBbHNvLCZuYnNwO2dpdmVuIHNvbWUgb2YgdGhlIGltcGxlbWVudGF0 aW9uIGluY29uc2lzdGVuY2llcyBub3RlZCBkdXJpbmcgdGhlIFRMUyAxLjMgZXZvbHV0aW9uLCB3 ZSBmZWx0IGEgYmNwIGd1aWRlIGNvdWxkIGhlbHAgdGhlIGNvbW11bml0eSBtb3ZpbmcgZm9yd2Fy ZC4gJm5ic3A7VGhhdOKAmXMgdGhlIHB1cnBvc2UNCiBvZiB0aGlzIGRyYWZ0LjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5CZXN0LDwvZGl2Pg0KPGRp diBjbGFzcz0iIj4tRXJpYzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXdhbmctb3BzZWMtdGxzLXByb3h5LWJwLTAwI3NlY3Rpb24tMSIgY2xhc3M9 IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdhbmctb3BzZWMtdGxzLXByb3h5 LWJwLTAwI3NlY3Rpb24tMTwvYT48YnIgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+T24gSnVsIDI1LCAyMDIwLCBhdCA3OjA3IEFNLCBTdGVwaGVuIEZh cnJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllIiBjbGFz cz0iIj5zdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIg Y2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj48YnIgc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBMdWNpZGFTYW5zLVR5 cGV3cml0ZXI7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBMdWNp ZGFTYW5zLVR5cGV3cml0ZXI7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxv YXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SQ0KIG9wcG9z ZSBhZG9wdGlvbi4gV2hpbGUgdGhlcmUgY291bGQgYmUgc29tZSBtaW5vciBiZW5lZml0PC9zcGFu PjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEx1Y2lk YVNhbnMtVHlwZXdyaXRlcjsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IEx1Y2lkYVNhbnMtVHlwZXdyaXRlcjsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5p bg0KIGRvY3VtZW50aW5nIHRoZSB1c2VzIGFuZCBhYnVzZXMgc2VlbiB3aGVuIG1pdG0naW5nIHRs cyw8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogTHVjaWRhU2Fucy1UeXBld3JpdGVyOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogTHVjaWRhU2Fucy1UeXBld3JpdGVyOyBmb250LXNpemU6IDE0cHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNs YXNzPSIiPkkNCiBkb3VidCB0aGF0IHRoZSBlZmZvcnQgdG8gZW5zdXJlIGEgYmFsYW5jZWQgZG9j dW1lbnQgaXMgYXQ8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogTHVjaWRhU2Fucy1UeXBld3JpdGVyOyBmb250LXNpemU6IDE0cHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogTHVjaWRhU2Fucy1UeXBld3JpdGVyOyBmb250LXNpemU6IDE0 cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9y dGFudDsiIGNsYXNzPSIiPmFsbA0KIHdvcnRod2hpbGUuIFRoZSBjdXJyZW50IGRyYWZ0IGlzIHRv byBmYXIgZnJvbSB3aGF0IGl0J2Q8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogTHVjaWRhU2Fucy1UeXBld3JpdGVyOyBmb250LXNpemU6IDE0 cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogTHVjaWRhU2Fucy1UeXBld3JpdGVyOyBmb250 LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxp bmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPm5lZWQNCiB0byBiZSB0byBiZSBhZG9wdGVkLjwvc3Bh bj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBMdWNp ZGFTYW5zLVR5cGV3cml0ZXI7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNs YXNzPSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogTHVjaWRhU2Fucy1UeXBld3JpdGVyOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogTHVjaWRhU2Fucy1UeXBld3JpdGVyOyBmb250LXNpemU6IDE0cHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNs YXNzPSIiPlNlbmQNCiB0byBJU0UuPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IEx1Y2lkYVNhbnMtVHlwZXdyaXRlcjsgZm9udC1zaXplOiAx NHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0 OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsg dGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBMdWNpZGFTYW5zLVR5cGV3cml0ZXI7IGZvbnQt c2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNh cmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBMdWNpZGFTYW5zLVR5cGV3cml0 ZXI7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3Bs YXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+Uy48L3NwYW4+PGJyIHN0eWxlPSJjYXJl dC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogTHVjaWRhU2Fucy1UeXBld3JpdGVy OyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxiciBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEx1Y2lkYVNhbnMtVHlw ZXdyaXRlcjsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEx1Y2lk YVNhbnMtVHlwZXdyaXRlcjsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9h dDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5Pbg0KIDIzLzA3 LzIwMjAgMDI6MzAsIEplbiBMaW5rb3ZhIHdyb3RlOjwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBMdWNpZGFTYW5zLVR5cGV3cml0ZXI7IGZv bnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSIgc3R5bGU9ImZvbnQtZmFtaWx5OiBMdWNpZGFTYW5zLVR5cGV3cml0ZXI7IGZv bnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCk9uZSB0aGlu ZyB0byBhZGQgaGVyZTogdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGhlYXIgYWN0aXZlIGFuZDxi ciBjbGFzcz0iIj4NCmV4cGxpY2l0IHN1cHBvcnQgb2YgdGhlIGFkb3B0aW9uLiBTbyBwbGVhc2Ug c3BlYWsgdXAgaWYgeW91IGJlbGlldmU8YnIgY2xhc3M9IiI+DQp0aGUgZHJhZnQgaXMgdXNlZnVs IGFuZCB0aGUgV0cgc2hhbGwgd29yayBvbiBnZXR0aW5nIGl0IHB1Ymxpc2hlZC48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpPbiBNb24sIEp1bCAyMCwgMjAyMCBhdCAzOjM1IEFNIFJvbiBC b25pY2E8YnIgY2xhc3M9IiI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOnJib25pY2E9NDBqdW5pcGVy Lm5ldEBkbWFyYy5pZXRmLm9yZyIgY2xhc3M9IiI+cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJj LmlldGYub3JnPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KRm9sa3MsPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhpcyBlbWFpbCBiZWdpbnMg YSBDYWxsIEZvciBBZG9wdGlvbiBvbiBkcmFmdC13YW5nLW9wc2VjLXRscy1wcm94eS1icC48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpQ bGVhc2Ugc2VuZCBjb21tZW50cyB0byA8YSBocmVmPSJtYWlsdG86b3BzZWNAaWV0Zi5vcmciIGNs YXNzPSIiPm9wc2VjQGlldGYub3JnPC9hPiBieSBBdWd1c3QgMywgMjAyMC48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtSb248YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpKdW5pcGVyIEJ1 c2luZXNzIFVzZSBPbmx5PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPUFNFQyBt YWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T1BTRUNAaWV0Zi5vcmci IGNsYXNzPSIiPk9QU0VDQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzZWM8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+ DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLTxiciBjbGFz cz0iIj4NClNZLCBKZW4gTGlua292YSBha2EgRnVycnk8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBj bGFzcz0iIj4NClRMUyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86 VExTQGlldGYub3JnIiBjbGFzcz0iIj5UTFNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIGNsYXNzPSIi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxzcGFuIGlkPSJjaWQ6MzU2NDlDMzEt NzJERS00REI3LTkzNEQtNUIxNjY2RkI1Rjg4QG9wZW5kbnMuY29tIj4mbHQ7MHg1QUIyRkFGMTdC MTcyQkVBLmFzYyZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBMdWNpZGFTYW5zLVR5cGV3cml0ZXI7IGZvbnQtc2l6ZTogMTRweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogTHVjaWRhU2Fucy1UeXBld3JpdGVyOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBm b250LWZhbWlseTogTHVjaWRhU2Fucy1UeXBld3JpdGVyOyBmb250LXNpemU6IDE0cHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNs YXNzPSIiPlRMUw0KIG1haWxpbmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBMdWNpZGFTYW5zLVR5cGV3cml0ZXI7IGZvbnQtc2l6 ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOlRM U0BpZXRmLm9yZyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBMdWNpZGFTYW5zLVR5cGV3cml0ZXI7IGZv bnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+VExTQGlldGYub3JnPC9hPjxiciBzdHlsZT0iY2FyZXQt Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEx1Y2lkYVNhbnMtVHlwZXdyaXRlcjsg Zm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyIgc3R5bGU9ImZvbnQtZmFt aWx5OiBMdWNpZGFTYW5zLVR5cGV3cml0ZXI7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zaXplLWFk anVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_4937FCE423EF45858675C07F3B347AC6ciscocom_-- From nobody Mon Jul 27 05:20: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 5E4173A1909; Mon, 27 Jul 2020 05:19:57 -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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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 GQTIfHqAT3bj; Mon, 27 Jul 2020 05:19:54 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (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 339B43A0DD9; Mon, 27 Jul 2020 05:19:53 -0700 (PDT) Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 06RCJjmh005835; Mon, 27 Jul 2020 08:19:45 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Stephen Farrell , Jen Linkova , OPSEC , "tls@ietf.org" CC: OpSec Chairs Thread-Topic: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AdZd8qs4MVhjKcpfSaSC3eC5PK0rEQCv6iMAAH8Fd4AAWHLpgA== Date: Mon, 27 Jul 2020 12:19:44 +0000 Message-ID: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-originating-ip: [172.25.1.84] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3678682784_278884501" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-27_08:2020-07-27, 2020-07-27 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2006250000 definitions=main-2007270091 Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 12:19:59 -0000 --B_3678682784_278884501 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I support Stephen and oppose adoption. IMHO, this is not a technology that = IETF should standardize. =EF=BB=BFOn 7/25/20, 10:07, "TLS on behalf of Stephen Farrell" wrote: I oppose adoption. While there could be some minor benefit in documenting the uses and abuses seen when mitm'ing tls, I doubt that the effort to ensure a balanced document is at all worthwhile. The current draft is too far from what it'd need to be to be adopted. Send to ISE. S. On 23/07/2020 02:30, Jen Linkova wrote: > One thing to add here: the chairs would like to hear active and > explicit support of the adoption. So please speak up if you believe > the draft is useful and the WG shall work on getting it published. >=20 > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica > wrote: >> >> Folks, >> >> >> >> This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-= bp. >> >> >> >> Please send comments to opsec@ietf.org by August 3, 2020. >> >> >> >> Ron >> >> >> >> >> Juniper Business Use Only >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >=20 >=20 >=20 > -- > SY, Jen Linkova aka Furry >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --B_3678682784_278884501 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQAEsOl/1qhyyOFZzgAAAASw6TANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTIwMDIxMjE2NTAyM1oXDTI1MDIx MDE2NTAyM1owYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCmeoHpDu+bGes6qLPIUd2r7EQaBwYt V254WjhvNdMry3tev5DNk7FprxZhspY0dxRoDvIUrfJ3saAcbxrVc9HnzdNTl57rtF2RiRLM Fb7wL6yz4Yis3yY6GpbONzkKX5FajFmSGuktYMMVt8CAPcPbbkUMPZ80QzMxWYolvcYH+C4z eH8Zw/oU7bzunibn0hJISHDZhNJyewLtQEhRxSHf/278CbuAbWq0YHVRwTz7Wd4FpFIvXdxj 6+c4QTMSTtWGvTNPtrYokw8g1SvZhZKYswnWHGOjGC5dr4NBfreyMq3f7y0x8Tp9dpJuDcK9 UMAMY3C0HZrNng3Y+tSc4XrhAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUaBwMva1XkRg3VVpo HkGTEOInxwEwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCjAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACYoq8k4 439LiS2zazVa7DYys6kPXsJaEVjmRmOZYOIeMA0fDV2qoKa27RnGhRvxgER7MYtiNsj95qUx EM3Ov0xnNLZONOsEYRlfdy8oR25TnuEGaVIbxqK38dYGzY0Zy2/2ZjptkXgyH6h3E50s43lr ZSm2KK39qS4o/3ZG7sPjzouWXj8lzMyQar4+2j2U3axuRlY17vXXSCGFYtUNZXWey+JhLWBf DK7EqpS811J3htiJS+eBWtkWMr6ZsnAvMWCdXZY+5Hy7qrpGUxKQA4MdFsATkPYTRE8c8u27 izPeEoZpm40nQGx+IElp1ojJDPekx2EmAbRszcbgGskh8LEwggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAEsOl/1qhyyOFZzgAAAASw6TANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCBrXuSDPsmWHwa5qe40sgkWppJXlXu8WXKbWf1Q fhOaZzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3Mjcx MjE5NDRaMA0GCSqGSIb3DQEBAQUABIIBAA1xJLswDet0hnNxKHFpmG5jdMqOAayBTjxXP4yM J6OY9uyQMZlP9+DjRWe/9QuMBXlmUJlhccCc9NLNQZzI0cZ2oHl6aq13YhingdQ+MoCqQLBc uPr5dqF7ku8iCt5KEg3uGKiU9uTFK2YU2BZ4iJdYRE2MdOp+lEd+dkM3vcIHd5gYEqSp7nyz TjW0o4ivDPWGefjjm8ckcj97ppGQqCx1CyZBhcEvWdT1L6yhCltzUBHmOScYUOVO7ZcIsLkM jYhi/m2dpRn1edWmt59NRMtlsEOsFTJCJIbfBNxAFuEZIDimT4npC9oMJW+rVYCVYl+E2I4a xA3TsPQMKYR4p/U= --B_3678682784_278884501-- From nobody Mon Jul 27 05:27: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 72B413A1927; Mon, 27 Jul 2020 05:27:11 -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 gkJa4n4EYsWF; Mon, 27 Jul 2020 05:27:10 -0700 (PDT) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (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 239753A1923; Mon, 27 Jul 2020 05:27:10 -0700 (PDT) Received: by mail-vk1-xa2c.google.com with SMTP id d21so2474118vke.8; Mon, 27 Jul 2020 05:27:10 -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=4IaS/bPLAAO8GOwimgpTdWjqGZRM7J8xoZAcMyASFac=; b=cL+JAXsAT8fF3BT3WBZytyxGVNnE44GWcQCni026W1OLJyHwqdymUIngOKE2o/117s vjqm64Ph7egf0YBEQq6055LOr/PKojHgr/bhfkBvSg0vhrDrWXmuY7MHOpB7+J1KVuas voZvsV+8ao9lSlweW+Whw4QRKwDQlK4djw/X0P2A6mDgX1wwHURMmQ4eckiq9NHl07/y UtiEc7akAfn6W5/pgQZX/bExYG5vCLK/6GFLrYRnuSw3sQww/0jAl1YZKltSZ5UdEEzu MNGiwrSiAJJmwRvC+q6X5Vp6dMjsKZnKU2TmhVxTj7Lf0jeoDKEwvmWE20Iv85zJwn1s /0bQ== 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=4IaS/bPLAAO8GOwimgpTdWjqGZRM7J8xoZAcMyASFac=; b=ABLUiJ0Z+5K7WfMPZX0LPEAAX4wqhPaxw7Zd2XQafEYgsGTXwWbErusAnR6OscGWSh NUuyueb83QYZC/PkPYAzoi1HvTvupHDE+SlW+inVgSc3M0Op3Rpua1JRF0v/riROFfGO OdoOtO+aRZd1SsvK9RgJh2qNtEIEQCgtlaqza/EUmt0+vR/WwjXFQmiFkYN02v821Zjx lOam1BQ2F53C0YjaitFWPJEIzS4xG8AyhpIGLtss1vzR/WDL0mVEJlegxY4gLCijKIWw g8Vv7ZbAiY8MOhLjQwZLLSRbHv6gbh5Afo4eMn/LN6/JQaEUOpZX3abAlN7hEO6zKEBW YCEw== X-Gm-Message-State: AOAM530c5Pb8IikAlxESdvNPEgkSmX0GNkbCuZYQ7O9lpdBpUym2Q7Lh g7LmliQhnDMpz00DCiJ0jDzfgsk6fxR+tfc+DI3o/g== X-Google-Smtp-Source: ABdhPJz5FA44jkZPisRTFGk/dKrUvxzlL2vACJneGZEh8b8drHgG35opZRyWoeP6RufBNS4qIvWk+y0fRDlvKjpYY28= X-Received: by 2002:a1f:c745:: with SMTP id x66mr15563588vkf.82.1595852829286; Mon, 27 Jul 2020 05:27:09 -0700 (PDT) MIME-Version: 1.0 References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> In-Reply-To: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> From: Ira McDonald Date: Mon, 27 Jul 2020 08:26:56 -0400 Message-ID: To: "Blumenthal, Uri - 0553 - MITLL" , Ira McDonald Cc: Stephen Farrell , Jen Linkova , OPSEC , "tls@ietf.org" , OpSec Chairs Content-Type: multipart/alternative; boundary="00000000000000e5de05ab6b7194" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 12:27:12 -0000 --00000000000000e5de05ab6b7194 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support Stephen and Uri and oppose adoption. On Mon, Jul 27, 2020 at 8:20 AM Blumenthal, Uri - 0553 - MITLL < uri@ll.mit.edu> wrote: > I support Stephen and oppose adoption. IMHO, this is not a technology tha= t > IETF should standardize. > > > =EF=BB=BFOn 7/25/20, 10:07, "TLS on behalf of Stephen Farrell" < > tls-bounces@ietf.org on behalf of stephen.farrell@cs.tcd.ie> wrote: > > > I oppose adoption. While there could be some minor benefit > in documenting the uses and abuses seen when mitm'ing tls, > I doubt that the effort to ensure a balanced document is at > all worthwhile. The current draft is too far from what it'd > need to be to be adopted. > > Send to ISE. > > S. > > On 23/07/2020 02:30, Jen Linkova wrote: > > One thing to add here: the chairs would like to hear active and > > explicit support of the adoption. So please speak up if you believe > > the draft is useful and the WG shall work on getting it published. > > > > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica > > wrote: > >> > >> Folks, > >> > >> > >> > >> This email begins a Call For Adoption on > draft-wang-opsec-tls-proxy-bp. > >> > >> > >> > >> Please send comments to opsec@ietf.org by August 3, 2020. > >> > >> > >> > >> Ro= n > >> > >> > >> > >> > >> Juniper Business Use Only > >> > >> _______________________________________________ > >> OPSEC mailing list > >> OPSEC@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsec > > > > > > > > -- > > SY, Jen Linkova aka Furry > > > > _______________________________________________ > > 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 > --00000000000000e5de05ab6b7194 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support Stephen and Uri and oppose adop= tion.

On Mon, Jul 27, 2020 at 8:20 AM Blumenthal, Uri - 0553 - MI= TLL <uri@ll.mit.edu> wrote:
=
I support Stephen a= nd oppose adoption. IMHO, this is not a technology that IETF should standar= dize.


=EF=BB=BFOn 7/25/20, 10:07, "TLS on behalf of Stephen Farrell" &l= t;tls-bounces@iet= f.org on behalf of stephen.farrell@cs.tcd.ie> wrote:


=C2=A0 =C2=A0 I oppose adoption. While there could be some minor benefit =C2=A0 =C2=A0 in documenting the uses and abuses seen when mitm'ing tls= ,
=C2=A0 =C2=A0 I doubt that the effort to ensure a balanced document is at =C2=A0 =C2=A0 all worthwhile. The current draft is too far from what it'= ;d
=C2=A0 =C2=A0 need to be to be adopted.

=C2=A0 =C2=A0 Send to ISE.

=C2=A0 =C2=A0 S.

=C2=A0 =C2=A0 On 23/07/2020 02:30, Jen Linkova wrote:
=C2=A0 =C2=A0 > One thing to add here: the chairs would like to hear act= ive and
=C2=A0 =C2=A0 > explicit support of the adoption. So please speak up if = you believe
=C2=A0 =C2=A0 > the draft is useful and the WG shall work on getting it = published.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
=C2=A0 =C2=A0 > <rbonica=3D40juniper.net@dmarc.ietf.org> wrote:
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Folks,
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> This email begins a Call For Adoption on draft-wang-= opsec-tls-proxy-bp.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Please send comments to opsec@ietf.org by August 3, 2020.
=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=A0Ron
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Juniper Business Use Only
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> _______________________________________________
=C2=A0 =C2=A0 >> OPSEC mailing list
=C2=A0 =C2=A0 >> = OPSEC@ietf.org
=C2=A0 =C2=A0 >> https://www.ietf.org/mailman/listi= nfo/opsec
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > --
=C2=A0 =C2=A0 > SY, Jen Linkova aka Furry
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > TLS mailing list
=C2=A0 =C2=A0 > TLS@ie= tf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/tl= s
=C2=A0 =C2=A0 >
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000000e5de05ab6b7194-- From nobody Mon Jul 27 05:37: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 4429F3A193B; Mon, 27 Jul 2020 05:37:17 -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 (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 4rOkRg33scFE; Mon, 27 Jul 2020 05:37:16 -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 D4CDF3A1939; Mon, 27 Jul 2020 05:37:15 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 06RCZ1uj025893; Mon, 27 Jul 2020 13:37:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=33DmEx4tjqGhejhoOGRtU/q9+ReZ1bypGlrL6mc0dkI=; b=czEbkvvN4x5NyiseBNzPsPP1bbMmXIXQGEmHDCM6HQythniyrQUILxr0RTrNa5IG5PNp MXw/cDcUHo5pqseAblQQaZR30CQ5Wm8lSrBKBalSppVgr8kyIiW/tWUSYerl/R6ym1jX bojMPYGhLEUUxwO2UVP8ZIgKAFjQQm6CeN7SdVK2TNyvp7wfTp8nDa8HRo3UArgWLS0i XMtX30+psXBI/UUoY9wX6UKQe/eTUoikwfJxbB2ONhEO929OLN0fWyguwAy/MacsK2bN h8ZiKSJ9r7o7EqrOn995d8rTi1UtGofbO0ObqSiD6wti0hpsNdT8cS3NeKUXlzsWsokF ug== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 32gd5ccjpc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 13:37:14 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06RCHFoU032072; Mon, 27 Jul 2020 08:37:14 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 32gg2xtxt2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 08:37:13 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 08:37:13 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.006; Mon, 27 Jul 2020 08:37:13 -0400 From: "Salz, Rich" To: Ira McDonald , "Blumenthal, Uri - 0553 - MITLL" CC: "tls@ietf.org" , Jen Linkova , "OpSec Chairs" , OPSEC Thread-Topic: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AdZd8qs4MVhjKcpfSaSC3eC5PK0rEQCv6iMAAH8Fd4AAWHLpgAAIokoA//+/0AA= Date: Mon, 27 Jul 2020 12:37:12 +0000 Message-ID: <411590AE-EEA6-41EE-B0C8-CC1E0C05F1CE@akamai.com> References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.114.69] Content-Type: multipart/alternative; boundary="_000_411590AEEEA641EEB0C8CC1E0C05F1CEakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-27_08:2020-07-27, 2020-07-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 spamscore=0 mlxlogscore=952 suspectscore=0 malwarescore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007270090 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-27_08:2020-07-27, 2020-07-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 lowpriorityscore=0 malwarescore=0 impostorscore=0 priorityscore=1501 phishscore=0 mlxscore=0 mlxlogscore=910 bulkscore=0 suspectscore=0 adultscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007270093 Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 12:37:18 -0000 --_000_411590AEEEA641EEB0C8CC1E0C05F1CEakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IGFkb3B0aW5nIHRoaXMgc2VlbXMgdG8gYmUgaWdub3JpbmcgcmVhbGl0eS4gVGhlcmUgYXJl IHBsYWNlcyB3aGljaCB1c2UgVExTIGludGVybWVkaWFyaWVzLiBBcmUgdGhvc2UgdXNlcnMgbm90 IHdlbGNvbWUgaGVyZT8NCg0KSSBzdXBwb3J0IGFkb3B0aW9uLg0K --_000_411590AEEEA641EEB0C8CC1E0C05F1CEakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3QgYWRvcHRpbmcgdGhpcyBzZWVtcyB0 byBiZSBpZ25vcmluZyByZWFsaXR5LiBUaGVyZSBhcmUgcGxhY2VzIHdoaWNoIHVzZSBUTFMgaW50 ZXJtZWRpYXJpZXMuIEFyZSB0aG9zZSB1c2VycyBub3Qgd2VsY29tZSBoZXJlPzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHN1cHBvcnQgYWRvcHRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_411590AEEEA641EEB0C8CC1E0C05F1CEakamaicom_-- From nobody Mon Jul 27 05:55: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 12D213A0DF7; Mon, 27 Jul 2020 05:55:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, 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=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 Av7rVqcSzreQ; Mon, 27 Jul 2020 05:55:08 -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 11B083A0DF4; Mon, 27 Jul 2020 05:55:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DEDCEBE2E; Mon, 27 Jul 2020 13:55: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 nx8M1QbrkEqg; Mon, 27 Jul 2020 13:55:03 +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 B9A60BE2F; Mon, 27 Jul 2020 13:55:02 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1595854502; bh=UIjjYUSN85g6MCDItEO6CnGIpyLvaEiUxLXc0CCGJpU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=C9TgtFivhD+TQ8fmIDXV4bvXTFXY/pALuCm6ARpUSFHfq5ET3x6qvz6CpueCSm9kX 6yJDTQMVsnWOaUgCqcnPKkvO4P5/0W5R2a/oqx3O1W0GshDRYHcWpMo429oP90Bauo vhPFsra6V5ap/A1Lb71dZccuU35a6VjDPG/gMNVw= To: "Salz, Rich" , Ira McDonald , "Blumenthal, Uri - 0553 - MITLL" Cc: Jen Linkova , OPSEC , OpSec Chairs , "tls@ietf.org" References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <411590AE-EEA6-41EE-B0C8-CC1E0C05F1CE@akamai.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: Mon, 27 Jul 2020 13:55:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <411590AE-EEA6-41EE-B0C8-CC1E0C05F1CE@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LslCFQz0IlZVtCbU53jHnj95zcEKUHhiX" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 12:55:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LslCFQz0IlZVtCbU53jHnj95zcEKUHhiX Content-Type: multipart/mixed; boundary="OO90SFTheMH4rHAzrhg7XzeBLp8vqgZjk"; protected-headers="v1" From: Stephen Farrell To: "Salz, Rich" , Ira McDonald , "Blumenthal, Uri - 0553 - MITLL" Cc: Jen Linkova , OPSEC , OpSec Chairs , "tls@ietf.org" Message-ID: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <411590AE-EEA6-41EE-B0C8-CC1E0C05F1CE@akamai.com> In-Reply-To: <411590AE-EEA6-41EE-B0C8-CC1E0C05F1CE@akamai.com> --OO90SFTheMH4rHAzrhg7XzeBLp8vqgZjk Content-Type: multipart/mixed; boundary="------------5FD8DC496B78C94C68D61B2C" Content-Language: en-US This is a multi-part message in MIME format. --------------5FD8DC496B78C94C68D61B2C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Rich, On 27/07/2020 13:37, Salz, Rich wrote: > Not adopting this seems to be ignoring reality.=20 That depends on the "this" though. This "this" seems to me to be very much ok with mitm'ing, while doing a little bit to recognise the downsides of mitm'ing. I'm not objecting to attempts to describe reality, but am rather arguing that achieving rough consensus on something starting from that "this" is not worth the effort, as we've I think seem demonstrated a couple of time recently. Cheers, S. > There are places > which use TLS intermediaries. Are those users not welcome here? >=20 > I support adoption. >=20 >=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --------------5FD8DC496B78C94C68D61B2C 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----- --------------5FD8DC496B78C94C68D61B2C-- --OO90SFTheMH4rHAzrhg7XzeBLp8vqgZjk-- --LslCFQz0IlZVtCbU53jHnj95zcEKUHhiX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl8ezqYACgkQWrL68XsX K+ol6RAAobd1Nkpll3nxqpytfKZvWr9LBGCAOzB1cYTjxFoC/9e+7kvYWpjpCOtM YBB34EjeoHOpUeivyI/oQULJe5v+Cfm9tlqXeJvPGTxgjOzK6nKKDIj4qlEZZT2y 35KfZ546o7DQHqaiXYetBClBgYdlBF5bG5xY4GGPb+35UDZ/ndjJMcX60Ydz4ueS HnyPi2TaoLBMQsaW+gvni/mTdpINx7BYH0XKB/IC4aVFz+TFuq/yS4aDkORQf6jK NamgJwgWgfXSLlvbUUK0ffNjWzX+j8tNKkmavNXRrn5Am0fYatE1OsN/Enr/+8Zy hiW68o7z+oiB3gDc1eCdQlwJGnyMiGlwegaya/5Fcypx0r3PxG3+UZPitmmiCLL9 nxfE3WflZrST3xPltCrHgxNA4MStAR/2lPa8/ZP7vFouUKlkuuGvuiE+lnkGPclL H3+SgPxWG3amKP74O/MBnqfo1dMstFBFpbTEkwC22mT9ekoP3gKdABWApZjzgObU r+Zurc1dREShPEKyPBK872hyHee2SJMiAHZN8VHX4boSNPTxqDc/oi2lZ0MHiSUQ xjNrKbIJlA7NGmRKcGcivtrvLh+0W4eNVVNv8pCSr354zwgc5TOxTcvdZhaF6X7d QTi3OPLEmdNTh+EKx930NPQrFJqcYRwkxSuqJqH3qXuweCdpotw= =VgZt -----END PGP SIGNATURE----- --LslCFQz0IlZVtCbU53jHnj95zcEKUHhiX-- From nobody Mon Jul 27 05:56: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 459733A196B; Mon, 27 Jul 2020 05:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CU02yAx8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VmjDvawH 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 utM8YmYfVsD2; Mon, 27 Jul 2020 05:56:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF063A1AC8; Mon, 27 Jul 2020 05:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3198; q=dns/txt; s=iport; t=1595854570; x=1597064170; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SWj4BSjtpw2I6iJ/7UQ6FLrk/nFdjiuXFuVd/I5GGfU=; b=CU02yAx8ScDjVA7QC1gwQoqFjGpi2WPu2yhj39orlpNia3/mF7QCvOnc O8H8ny1DwJD92QKjs96sO4PAHZEZvyhz8XeOF8RJmlwxLO+5g+jS/q2No exO9LeJc9ra9jv/KjsLaGtnJHYNRxrHNOkJRVTDrBldhRGBiGFwr8plJX c=; IronPort-PHdr: =?us-ascii?q?9a23=3AVsYHUBeGi/2GAHj6fJd+/MaslGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQA9ff77RBivaQvqz9CiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFnW5Hiz8XgfFg?= =?us-ascii?q?isfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BVCAB9zh5f/5hdJa1gDg4BAQEBAQE?= =?us-ascii?q?HAQESAQEEBAEBQIFKgVJRB29YLywKhCqDRgONMiWYYYFCgREDVQsBAQEMAQE?= =?us-ascii?q?YCwoCBAEBhEwCF4IQAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBBAEBEAs?= =?us-ascii?q?GEQwBASMJCwEPAgEIGAICJgICAiULFAEQAgQBDQUigwQBgksDLgEOohQCgTm?= =?us-ascii?q?IYXaBMoMBAQEFhTMYgg4DBoEOKoJtg1mCM4QEGoIAgREnDBCCTT6CXAEBAoE?= =?us-ascii?q?oARIBIReCfzOCLZJgkiuQYwqCXpluAx6Ce4lIkyGSFp8aAgQCBAUCDgEBBYF?= =?us-ascii?q?qI2dwcBU7KgGCPlAXAg2OHoNxhRSFBAUBOHQCNQIGAQcBAQMJfI4PAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.75,402,1589241600"; d="scan'208";a="806848440" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jul 2020 12:55:38 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 06RCtcbt029852 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jul 2020 12:55:38 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 07:55:38 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 07:55:37 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 27 Jul 2020 08:55:37 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cv1GtlFMQlGj99L3yM9w8Ickl8Ct3M0VTQ3BKjovUWXvS8uEQvsEECERofPRp9+DtivsPe8+L5whAgPaJXJZbJLkPDf3xfKoDqSu0Bje3+wgmLgrvncmgm/zMCJp7lkOe7xAHK9wM6TZ0JYOO3Eo/Slnt4t/EC/ViLtaMjiXdTrzUj4VPntzleN/cu5z3zKxL1/bmr+stTchV2R02LFQgq2IEqI7bjk7ua2YH1yy8a2Y/2s7lxFj805MT6V+lXQw2cqucrQZE8NV6m+TWE0cT7Yca0oJwaunG4yeLeP4VvodCuLPFwoqeCgyiBkCsKDE1B8NDeLpnEYLuFIR+6338g== 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=SWj4BSjtpw2I6iJ/7UQ6FLrk/nFdjiuXFuVd/I5GGfU=; b=U8PFTHGtb53UCLpqnShUJHaVc0/2qFY7pRujihJwac5bC0bSP83JzvY+844PfYgyCPv02saZKVdFgdaeEHJPPAdJjtoHbW2hzLLM3aUJV8w1+0i8lmcWWrepXy2GHkjh0l7a84YnP3CYbywo9W1ioiW/Nk4pCdCbj1oZ47/Lty7eDyRymE4DVxW5lJOwOlw5x0t8qn/NvkFAffJUGYa50rn6qB7aAqbx86zaKjjp7Y68O4WFImYNjTOVPw/MVbdzmdEw0reCamD5uLmfLxiqJl44W0U1++pocSs09KNFu1hTOgAYz8kaxzn9t+3nYs1Dg+jkerls9NThWHptwlBMSA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SWj4BSjtpw2I6iJ/7UQ6FLrk/nFdjiuXFuVd/I5GGfU=; b=VmjDvawHDbX1CdsDNvHa2wri+ijw/4DYBCrhE9buqhDg8uUj57iT+TDzQC6tWZk5g/H8ouvvBA4mtMTdPT6EbjExOSR+QuVEyDfXjSmN1o2kER37Orq8I3t8S3JkoJwSZrRuSEDpWe9WYrAsa15JvI8D1jwEJq6n6CBM5yMMwlQ= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BYAPR11MB3158.namprd11.prod.outlook.com (2603:10b6:a03:1c::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Mon, 27 Jul 2020 12:55:36 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::e42f:216e:af3e:8ce5]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::e42f:216e:af3e:8ce5%7]) with mapi id 15.20.3216.033; Mon, 27 Jul 2020 12:55:36 +0000 From: "Nancy Cam-Winget (ncamwing)" To: "Blumenthal, Uri - 0553 - MITLL" , Stephen Farrell , Jen Linkova , OPSEC , "tls@ietf.org" CC: OpSec Chairs Thread-Topic: [OPSEC] [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AQHWZBBXfEOfXmicKUiEGO0IxBKiNaka7PaA Date: Mon, 27 Jul 2020 12:55:36 +0000 Message-ID: <43A56381-0BA8-4123-A2D5-950FD1EDFC86@cisco.com> References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> In-Reply-To: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.18.200713 authentication-results: ll.mit.edu; dkim=none (message not signed) header.d=none;ll.mit.edu; dmarc=none action=none header.from=cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d1c9f0ab-5fd8-4aae-5bd1-08d8322c5b4e x-ms-traffictypediagnostic: BYAPR11MB3158: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +fY/AnkBsh5wLjlNNfqsyGJYk78CHfrGsGnwm7Y8dbx807dBHSxqEyipnF+pIDMnOSpS8GXOo74fxpnTPC6ZwtpSb6RqSAKCb/Fe6WRVCAFlhJiMvBp3Q/AbMY+GepN9mWB+8pHMRB+j26bSsVgSiuodstgVoLMFDDRXJobn8DF5hmgDgybqLNHwFT1UTF1eqx19xD3CCX1FhMcMWSe/RFqkD+hJEvXA7jR279QIamWLTYhrOX2pWnIjNPjk0Pn7Ca3AVkzAn29NkVy7glltmjGc8xNFf26j0Uccs1P4obaOBAojDX+AmrrS07YSUAAY5n27K+OYPNeplCU5M1PLOe5plMNImo9OsiYVA19ImkRPJyS2JeeSl05gd78dDNS5oSx2qGku6CUrYh8ykdLG5w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(346002)(396003)(39860400002)(376002)(5660300002)(6506007)(53546011)(66476007)(66446008)(66946007)(186003)(66556008)(76116006)(64756008)(26005)(6486002)(6512007)(4326008)(8676002)(71200400001)(966005)(316002)(2616005)(86362001)(2906002)(110136005)(36756003)(8936002)(478600001)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: AVc1T9ryuN66HGZ5eRWNFsb4hZTzLDkC0s5LpEYhK7M8vEAr8dLWAPebXagj2LD5toRslSUD7rIVCOxneCrcY8Z4UN4Z6eyLyMAzL1AG0RcAPGMTxVB3qk9Uc0d6k+209lCfVfPGcuUf7rqgq/Pnyxcoc8tS8JZ0fOsLJhH+1EwD1vpsvGekvgZoXb04yNsFuKboYSDuF/yfweN4lMiYuviCrxjia+SGFNfbg//R52+pU6lYrDmUw0PGGXTee8+siRxxxyvz1vYNYLzNPnXnRRG1Zp+3D0cub9XBYOG+AIKE0rwpWLqswYYak2dT+SgcV+vK+CpKi2+xfvWjQ8hkanRKFuxlgWfHBadPUWq06/lPOP+TpvjXUTivBAEo8mGvRpdVEanqCWRnFqjBRMsEYjBmsSTJyn6eKRS4W2/6824dw+AAw2I1vgCTako7psCBhmmuBX89bi+yEN5+NGdjBcIJlRAmjZIdjM53GTYAqNBlxYYZ6zaomF9E+fWA8daZ x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4070.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d1c9f0ab-5fd8-4aae-5bd1-08d8322c5b4e X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 12:55:36.3737 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IwcNl9W5e8ul/v6ZANtZ677OpYUGd2SqDXxuIff2tClhItlRGT5qwQSjPt3YLBmWmQ8JxugI9Qk1st9MBhLlBw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3158 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 12:56:46 -0000 VGhlIGRvY3VtZW50IGlzIG5vdCBpbXBvc2luZyBhbnkgc3RhbmRhcmRzIGJ1dCByYXRoZXIgcHJv dmlkZSBndWlkZWxpbmVzIGZvciB0aG9zZSBpbXBsZW1lbnRpbmcgVExTIHByb3hpZXM7ICBnaXZl biB0aGF0IHByb3hpZXMgd2lsbCBjb250aW51ZSB0byBleGlzdCBJJ20gbm90IHN1cmUgd2h5IHRo ZXJlIGlzIGEgYmVsaWVmIHRoYXQgdGhlIElFVEYgc2hvdWxkIGlnbm9yZSB0aGlzLg0KDQpXYXJt IHJlZ2FyZHMsIE5hbmN5DQoNCu+7v09uIDcvMjcvMjAsIDU6MjAgQU0sICJPUFNFQyBvbiBiZWhh bGYgb2YgQmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMIiA8b3BzZWMtYm91bmNlc0BpZXRm Lm9yZyBvbiBiZWhhbGYgb2YgdXJpQGxsLm1pdC5lZHU+IHdyb3RlOg0KDQogICAgSSBzdXBwb3J0 IFN0ZXBoZW4gYW5kIG9wcG9zZSBhZG9wdGlvbi4gSU1ITywgdGhpcyBpcyBub3QgYSB0ZWNobm9s b2d5IHRoYXQgSUVURiBzaG91bGQgc3RhbmRhcmRpemUuDQogICAgDQogICAgDQogICAgT24gNy8y NS8yMCwgMTA6MDcsICJUTFMgb24gYmVoYWxmIG9mIFN0ZXBoZW4gRmFycmVsbCIgPHRscy1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiB3cm90 ZToNCiAgICANCiAgICANCiAgICAgICAgSSBvcHBvc2UgYWRvcHRpb24uIFdoaWxlIHRoZXJlIGNv dWxkIGJlIHNvbWUgbWlub3IgYmVuZWZpdA0KICAgICAgICBpbiBkb2N1bWVudGluZyB0aGUgdXNl cyBhbmQgYWJ1c2VzIHNlZW4gd2hlbiBtaXRtJ2luZyB0bHMsDQogICAgICAgIEkgZG91YnQgdGhh dCB0aGUgZWZmb3J0IHRvIGVuc3VyZSBhIGJhbGFuY2VkIGRvY3VtZW50IGlzIGF0DQogICAgICAg IGFsbCB3b3J0aHdoaWxlLiBUaGUgY3VycmVudCBkcmFmdCBpcyB0b28gZmFyIGZyb20gd2hhdCBp dCdkDQogICAgICAgIG5lZWQgdG8gYmUgdG8gYmUgYWRvcHRlZC4NCiAgICANCiAgICAgICAgU2Vu ZCB0byBJU0UuDQogICAgDQogICAgICAgIFMuDQogICAgDQogICAgICAgIE9uIDIzLzA3LzIwMjAg MDI6MzAsIEplbiBMaW5rb3ZhIHdyb3RlOg0KICAgICAgICA+IE9uZSB0aGluZyB0byBhZGQgaGVy ZTogdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGhlYXIgYWN0aXZlIGFuZA0KICAgICAgICA+IGV4 cGxpY2l0IHN1cHBvcnQgb2YgdGhlIGFkb3B0aW9uLiBTbyBwbGVhc2Ugc3BlYWsgdXAgaWYgeW91 IGJlbGlldmUNCiAgICAgICAgPiB0aGUgZHJhZnQgaXMgdXNlZnVsIGFuZCB0aGUgV0cgc2hhbGwg d29yayBvbiBnZXR0aW5nIGl0IHB1Ymxpc2hlZC4NCiAgICAgICAgPiANCiAgICAgICAgPiBPbiBN b24sIEp1bCAyMCwgMjAyMCBhdCAzOjM1IEFNIFJvbiBCb25pY2ENCiAgICAgICAgPiA8cmJvbmlj YT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPiB3cm90ZToNCiAgICAgICAgPj4NCiAgICAg ICAgPj4gRm9sa3MsDQogICAgICAgID4+DQogICAgICAgID4+DQogICAgICAgID4+DQogICAgICAg ID4+IFRoaXMgZW1haWwgYmVnaW5zIGEgQ2FsbCBGb3IgQWRvcHRpb24gb24gZHJhZnQtd2FuZy1v cHNlYy10bHMtcHJveHktYnAuDQogICAgICAgID4+DQogICAgICAgID4+DQogICAgICAgID4+DQog ICAgICAgID4+IFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvIG9wc2VjQGlldGYub3JnIGJ5IEF1Z3Vz dCAzLCAyMDIwLg0KICAgICAgICA+Pg0KICAgICAgICA+Pg0KICAgICAgICA+Pg0KICAgICAgICA+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUm9uDQogICAgICAgID4+DQogICAgICAgID4+DQogICAgICAgID4+DQogICAgICAg ID4+DQogICAgICAgID4+IEp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCiAgICAgICAgPj4NCiAg ICAgICAgPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICAgICAgPj4gT1BTRUMgbWFpbGluZyBsaXN0DQogICAgICAgID4+IE9QU0VDQGlldGYub3Jn DQogICAgICAgID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzZWMN CiAgICAgICAgPiANCiAgICAgICAgPiANCiAgICAgICAgPiANCiAgICAgICAgPiAtLQ0KICAgICAg ICA+IFNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCiAgICAgICAgPiANCiAgICAgICAgPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgICAgICA+IFRM UyBtYWlsaW5nIGxpc3QNCiAgICAgICAgPiBUTFNAaWV0Zi5vcmcNCiAgICAgICAgPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KICAgICAgICA+IA0KICAgIA0KDQo= From nobody Mon Jul 27 06:18:30 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 C06993A1981; Mon, 27 Jul 2020 06:18:27 -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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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 f5YIvW9GqS9U; Mon, 27 Jul 2020 06:18:25 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.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 4A2FF3A196C; Mon, 27 Jul 2020 06:18:24 -0700 (PDT) Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTPS id 06RDIAVJ035987; Mon, 27 Jul 2020 09:18:18 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Nancy Cam-Winget (ncamwing)" , Stephen Farrell , Jen Linkova , OPSEC , "tls@ietf.org" CC: OpSec Chairs Thread-Topic: [OPSEC] [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AQHWZBVpJXnfp71rHkOfsGQ2RTr97KkbaJqA Date: Mon, 27 Jul 2020 13:18:16 +0000 Message-ID: <845E6D98-DD1C-4FD7-AEF6-A262C10B35A8@ll.mit.edu> References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <43A56381-0BA8-4123-A2D5-950FD1EDFC86@cisco.com> In-Reply-To: <43A56381-0BA8-4123-A2D5-950FD1EDFC86@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-originating-ip: [172.25.1.84] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3678686295_1733652896" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-27_08:2020-07-27, 2020-07-27 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2006250000 definitions=main-2007270097 Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 13:18:28 -0000 --B_3678686295_1733652896 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Nancy, Understood. However, in this particular case, instead of "if you want to do= this, then do it that way, and I'll help you inter-operate" I prefer "if yo= u want to do this - you're on your own, don't seek a blessing or advice from= me". Regards, Uri =EF=BB=BFOn 7/27/20, 08:56, "Nancy Cam-Winget (ncamwing)" wr= ote: The document is not imposing any standards but rather provide guideline= s for those implementing TLS proxies; given that proxies will continue to e= xist I'm not sure why there is a belief that the IETF should ignore this. Warm regards, Nancy On 7/27/20, 5:20 AM, "OPSEC on behalf of Blumenthal, Uri - 0553 - MITLL= " wrote: I support Stephen and oppose adoption. IMHO, this is not a technolo= gy that IETF should standardize. On 7/25/20, 10:07, "TLS on behalf of Stephen Farrell" wrote: I oppose adoption. While there could be some minor benefit in documenting the uses and abuses seen when mitm'ing tls, I doubt that the effort to ensure a balanced document is at all worthwhile. The current draft is too far from what it'd need to be to be adopted. Send to ISE. S. On 23/07/2020 02:30, Jen Linkova wrote: > One thing to add here: the chairs would like to hear active a= nd > explicit support of the adoption. So please speak up if you b= elieve > the draft is useful and the WG shall work on getting it publi= shed. >=20 > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica > wrote: >> >> Folks, >> >> >> >> This email begins a Call For Adoption on draft-wang-opsec-tl= s-proxy-bp. >> >> >> >> Please send comments to opsec@ietf.org by August 3, 2020. >> >> >> >> = Ron >> >> >> >> >> Juniper Business Use Only >> >> _______________________________________________ >> OPSEC mailing list >> OPSEC@ietf.org >> https://www.ietf.org/mailman/listinfo/opsec >=20 >=20 >=20 > -- > SY, Jen Linkova aka Furry >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --B_3678686295_1733652896 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQAEsOl/1qhyyOFZzgAAAASw6TANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTIwMDIxMjE2NTAyM1oXDTI1MDIx MDE2NTAyM1owYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCmeoHpDu+bGes6qLPIUd2r7EQaBwYt V254WjhvNdMry3tev5DNk7FprxZhspY0dxRoDvIUrfJ3saAcbxrVc9HnzdNTl57rtF2RiRLM Fb7wL6yz4Yis3yY6GpbONzkKX5FajFmSGuktYMMVt8CAPcPbbkUMPZ80QzMxWYolvcYH+C4z eH8Zw/oU7bzunibn0hJISHDZhNJyewLtQEhRxSHf/278CbuAbWq0YHVRwTz7Wd4FpFIvXdxj 6+c4QTMSTtWGvTNPtrYokw8g1SvZhZKYswnWHGOjGC5dr4NBfreyMq3f7y0x8Tp9dpJuDcK9 UMAMY3C0HZrNng3Y+tSc4XrhAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUaBwMva1XkRg3VVpo HkGTEOInxwEwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCjAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACYoq8k4 439LiS2zazVa7DYys6kPXsJaEVjmRmOZYOIeMA0fDV2qoKa27RnGhRvxgER7MYtiNsj95qUx EM3Ov0xnNLZONOsEYRlfdy8oR25TnuEGaVIbxqK38dYGzY0Zy2/2ZjptkXgyH6h3E50s43lr ZSm2KK39qS4o/3ZG7sPjzouWXj8lzMyQar4+2j2U3axuRlY17vXXSCGFYtUNZXWey+JhLWBf DK7EqpS811J3htiJS+eBWtkWMr6ZsnAvMWCdXZY+5Hy7qrpGUxKQA4MdFsATkPYTRE8c8u27 izPeEoZpm40nQGx+IElp1ojJDPekx2EmAbRszcbgGskh8LEwggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAEsOl/1qhyyOFZzgAAAASw6TANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCAQa6nR128nIEsY+eyYAhiB7rBQbQ4V2uyKPSL7 +LMMYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3Mjcx MzE4MTVaMA0GCSqGSIb3DQEBAQUABIIBAEyIGFSTdNFYKIfX6WgQbV6EIqTogOjBCzFCBQtY vDQGqQfbT3pcMHLZi41DFw+njosO4om99ZW1NM6y75jd3bRFqReVqLAbUDDDGhtjhnZc/Dek teaRlpfjpr6bxjYSbdDkoKQ/+SX18msQpE8H7jNlO5D/AqJJodOOzS6/0/A2eAFvRbE8z4Lh jXXaSqTBgHWWjzmBX17XfLIbkAOUUu32Do1+vRk1AwXqbbAF2czXYyy56HqNqXD82+pQ31gf ndMKKRJZmZf0C7Xp/AtOm+exjvJlQ9l+eLeC0OASjSxbt3pdFmh2xDgKyT6YkJRF2SXMTb9S v5PAxiE7ulSURcI= --B_3678686295_1733652896-- From nobody Mon Jul 27 06:31: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 D742F3A19A2 for ; Mon, 27 Jul 2020 06:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 gfchcrio-bSb for ; Mon, 27 Jul 2020 06:30:50 -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 C640F3A19F2 for ; Mon, 27 Jul 2020 06:30:48 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id l2so4345017wrc.7 for ; Mon, 27 Jul 2020 06:30:48 -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 :cc; bh=ngJC5gkgJmYNZAA3UgOwqt1nSbCNMAXTeqO5BESn1RU=; b=Q43kpMGvMqDkW1z5+1iBySHshA9s0eNhVLkOuc6oJO3JX9io8cpA90cTA4OaIwLS6I 3+iu+m9Hxk/EVFjxBPcItt8IfVMjZEuJtS3oNdIOsn7g+Skjb6o+pVuuYb60py4DkIQh zbGRGlNtjAanGfw3GqK6zlUmNcfQxPz4zMuSgLgv9pEMFa13KpxqqKiuc2wSw8GWZN95 mUpXmsTMCZiqxup42OuMUrCQ/elXAwHTNHCqyuMP1dU3LN19tiH543YRU8MMd/3Vv0PN WhwTe88kupIao9X0zl9KfkPd8WiKnriLqRiiwBiHU7C9T3gg7UBrfjN5I7/GMraUvKHw 5RMg== 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=ngJC5gkgJmYNZAA3UgOwqt1nSbCNMAXTeqO5BESn1RU=; b=grwDXpqCbew5gdULpohyMmRWf8JpYMoEyhgsfhL2sAiexzJSmtmSgm1/gEEqB8nFII eBMXrxKxYU2R7cOhLFSdqzJPQRVWiibwRLSITDFWxbH0O/vcXumMU3xOam8h4nBFvoCO 3GJqCtCfpBz3KUJNWzU96nOj4jUBTP96878RzqmRXWtWFrIkkVGPRCCcGV7WkpeX1zAv FkXHm0wgj5beEfOWkvDAixidlbZe+y/AlHNujaJonpzc9XekpOSAoq+VqtrTezQheV62 TjT7JCXHd3bL+M8iebvwzuD1VGTU04OI+ekyOWKqjmUjQVwMkjzl+83U7MgLK7KXPxNG WP9Q== X-Gm-Message-State: AOAM531vNuVLmEnnz07wNfD996V+qsflhA0bAf9fN25DL3Chj2OeNSxC fCMcoUZSCRRvwIrGiPCCGi68vopvRMXEAxcUk3Exsg== X-Google-Smtp-Source: ABdhPJyF5mix/bZQbRzs9XFCxpzTfqZOFlkE+JbKCzm1XXzWOxC26iQjlDdLfS7PrufC3DxiEEaMyg2811JPGLTvsjk= X-Received: by 2002:a5d:43c4:: with SMTP id v4mr19088055wrr.426.1595856647086; Mon, 27 Jul 2020 06:30:47 -0700 (PDT) MIME-Version: 1.0 References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <43A56381-0BA8-4123-A2D5-950FD1EDFC86@cisco.com> In-Reply-To: <43A56381-0BA8-4123-A2D5-950FD1EDFC86@cisco.com> From: Ben Schwartz Date: Mon, 27 Jul 2020 09:30:35 -0400 Message-ID: To: "Nancy Cam-Winget (ncamwing)" Cc: "Blumenthal, Uri - 0553 - MITLL" , Stephen Farrell , Jen Linkova , OPSEC , "tls@ietf.org" , OpSec Chairs Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000965d5f05ab6c54fb" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 13:30:53 -0000 --000000000000965d5f05ab6c54fb Content-Type: multipart/alternative; boundary="00000000000090436705ab6c543b" --00000000000090436705ab6c543b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm concerned about this work happening outside the TLS working group. For example, the question of proper handling of TLS extensions is not addressed at all in this draft, and has significant security and functionality implications. There are various other tricky protocol issues (e.g. version negotiation, TLS 1.3 record padding, TLS 1.3 0-RTT vs. TLS 1.2 False Start, round-trip deadlock when buffers fill, ticket (non-)reuse, client certificate linkability pre-TLS-1.3, implications of SAN scope of synthesized certificates) that could arise and are going to be difficult to get right in any other WG. The title "TLS Proxy Best Practice" implies that it is possible to proxy TLS correctly, and that this document is the main source for how to do it. I think the TLS WG is the right place to make those judgments. For the OpSec group, I think a more appropriate draft would be something like "TLS Interception Pitfalls", documenting the operational experience on failure modes of TLS interception. On Mon, Jul 27, 2020 at 8:57 AM Nancy Cam-Winget (ncamwing) wrote: > The document is not imposing any standards but rather provide guidelines > for those implementing TLS proxies; given that proxies will continue to > exist I'm not sure why there is a belief that the IETF should ignore this= . > > Warm regards, Nancy > > =EF=BB=BFOn 7/27/20, 5:20 AM, "OPSEC on behalf of Blumenthal, Uri - 0553 = - MITLL" < > opsec-bounces@ietf.org on behalf of uri@ll.mit.edu> wrote: > > I support Stephen and oppose adoption. IMHO, this is not a technology > that IETF should standardize. > > > On 7/25/20, 10:07, "TLS on behalf of Stephen Farrell" < > tls-bounces@ietf.org on behalf of stephen.farrell@cs.tcd.ie> wrote: > > > I oppose adoption. While there could be some minor benefit > in documenting the uses and abuses seen when mitm'ing tls, > I doubt that the effort to ensure a balanced document is at > all worthwhile. The current draft is too far from what it'd > need to be to be adopted. > > Send to ISE. > > S. > > On 23/07/2020 02:30, Jen Linkova wrote: > > One thing to add here: the chairs would like to hear active and > > explicit support of the adoption. So please speak up if you > believe > > the draft is useful and the WG shall work on getting it > published. > > > > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica > > wrote: > >> > >> Folks, > >> > >> > >> > >> This email begins a Call For Adoption on > draft-wang-opsec-tls-proxy-bp. > >> > >> > >> > >> Please send comments to opsec@ietf.org by August 3, 2020. > >> > >> > >> > >> > Ron > >> > >> > >> > >> > >> Juniper Business Use Only > >> > >> _______________________________________________ > >> OPSEC mailing list > >> OPSEC@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsec > > > > > > > > -- > > SY, Jen Linkova aka Furry > > > > _______________________________________________ > > 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 > --00000000000090436705ab6c543b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm concerned about this work happeni= ng outside the TLS working group.=C2=A0 For example, the question of proper= handling of TLS extensions is not addressed at all in this draft, and has = significant security and functionality implications.=C2=A0 There are variou= s other tricky protocol issues (e.g. version negotiation, TLS 1.3 record pa= dding, TLS 1.3 0-RTT vs. TLS 1.2 False Start, round-trip deadlock when buff= ers fill, ticket (non-)reuse, client certificate linkability pre-TLS-1.3, i= mplications of SAN scope of synthesized certificates) that could arise and = are going to be difficult to get right in any other WG.

= The title "TLS Proxy Best Practice" implies that it is possible t= o proxy TLS correctly, and that this document is the main source for how to= do it.=C2=A0 I think the TLS WG is the right place to make those judgments= .=C2=A0 For the OpSec group, I think a more=C2=A0appropriate draft would=C2= =A0be something like "TLS Interception Pitfalls", documenting the= operational experience on failure modes of TLS interception.
On Mon, = Jul 27, 2020 at 8:57 AM Nancy Cam-Winget (ncamwing) <ncamwing=3D40cisco.com@dmarc.ietf.org> w= rote:
The docume= nt is not imposing any standards but rather provide guidelines for those im= plementing TLS proxies;=C2=A0 given that proxies will continue to exist I&#= 39;m not sure why there is a belief that the IETF should ignore this.

Warm regards, Nancy

=EF=BB=BFOn 7/27/20, 5:20 AM, "OPSEC on behalf of Blumenthal, Uri - 05= 53 - MITLL" <opsec-bounces@ietf.org on behalf of uri@ll.mit.edu> wrote:

=C2=A0 =C2=A0 I support Stephen and oppose adoption. IMHO, this is not a te= chnology that IETF should standardize.


=C2=A0 =C2=A0 On 7/25/20, 10:07, "TLS on behalf of Stephen Farrell&quo= t; <tls-bounce= s@ietf.org on behalf of stephen.farrell@cs.tcd.ie> wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I oppose adoption. While there could be some mi= nor benefit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in documenting the uses and abuses seen when mi= tm'ing tls,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I doubt that the effort to ensure a balanced do= cument is at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 all worthwhile. The current draft is too far fr= om what it'd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 need to be to be adopted.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Send to ISE.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 S.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 23/07/2020 02:30, Jen Linkova wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > One thing to add here: the chairs would li= ke to hear active and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > explicit support of the adoption. So pleas= e speak up if you believe
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > the draft is useful and the WG shall work = on getting it published.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > <rbonica=3D40juniper.net@dmarc.ietf.org> = wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> Folks,
=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 >> This email begins a Call For Adoption = on draft-wang-opsec-tls-proxy-bp.
=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 >> Please send comments to opsec@ietf.org by August 3, 2020.=
=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 =C2=A0Ron
=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 >> Juniper Business Use Only
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> ______________________________________= _________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> OPSEC mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> OPSEC@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> https://www.ietf.org= /mailman/listinfo/opsec
=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 > SY, Jen Linkova aka Furry
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > __________________________________________= _____
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > TLS mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > TLS@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailm= an/listinfo/tls
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000090436705ab6c543b-- --000000000000965d5f05ab6c54fb Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAH8qNflD4Mi9yKttXfRdHcwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDA2MDUwODIyMjhaFw0yMDEyMDIwODIyMjhaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kbyV9S0YLplF3kV 6t3GgD7IyHe8L29pJ7l+UR0Sj31uPgXOFdSSdTVwhPfQvxmB2OUDXWDgDtZdL2xu4DgHhrDyyOXT 8uDJqUCPw004ZSuUfUor1vz5u6+oYNfx2OTPTb81vtsQO2/khni3iAeQlKgO/rUI1c9+zvT6k3mR SZUypAlk/rCyG6NV7NMJMmOaU20/kPBXG297iP8+/F9w4xs+lyb3IkcSfoSUr3fVz7mYqESFato5 JnjRQGT2/f/ehxkc09jATqVGj9nyQMoD2GNPjiNnYyTVBwK5Ol/s9+E2VSL4TSLrgS2R07kY9zPi VOM3lhDDRnceboNSaqnfMwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUwJS1fB3cBxoLgZFatdIO9Vp5wOcwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQCC91PBn9rMxo8kSo1zNY2mxkTQDTVc0oyYk8s3y72y21IEp/d/+h1H VTCD2FR30aFUv8hTJkebJ5Z1/zue2L7sx/lLEOIHm9uYxyTkTWbKup3+XrE1vhODTHVx+ktMuOTY z447/fwjy4praSaFrQsOjTPbAoU6xuC8S2j2K2Yg6XQsctcKHKeAJjN6evZYChDaTBLmtYq9LTSH KVv3Et795vNK3gWKjhEkJtaBu4FfKLoopb1PENJ/zK6p/3edCLFgCRMSlbQ0SGtdVESSJcgezSwW WK2VB1Zcj2kyVzcL1pmV8m1xQuz2aBgUMn7peoVxKxYKP12gMtzeMvkzltYBMYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhAB/KjX5Q+DIvcirbV30XR3MA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCAuVzQlz5T9JiBKUGv2lxvT97BGDSVwlPVoA2clmUgvRzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3MjcxMzMwNDdaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEALqMqcuUn1poWgENy2BGTzbYDw0NOoaWyub1w1Kpm6gjFqlornMDRg4vXmo6cJ/em3NTzhB1Y rIUPSSmrYhXCxKJP89w4zDf3KOwSDq6rhJWiWs5s6MAGihmgYoHc2kTOQ1sFWj8P1XFHeQ5CKRWw Ckp7SWFT4LbQmtQ7IqFnM9oBvX5OLd8A+Eu9KMccO5J0287t/G1l0RihaFrYTGeXtoxwOoygSa61 aqunk6Ti78wvxMti02l2+K/PE/h8c3F1zmz+K13UmQkmoOdknBFnp50Mus8H0kKyowkkvEIZ7vKZ zFY4aj8+qeb8T59nTwGU/GbJaabfbCKLsppcnxJ6vA== --000000000000965d5f05ab6c54fb-- From nobody Mon Jul 27 07:12: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 2D0CF3A19BA for ; Mon, 27 Jul 2020 07:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=unavailable 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 OQGCtqEAGGYk for ; Mon, 27 Jul 2020 07:12:08 -0700 (PDT) Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 46B3B3A19B7 for ; Mon, 27 Jul 2020 07:12:08 -0700 (PDT) Received: by mail-oo1-xc2c.google.com with SMTP id z23so3168919ood.8 for ; Mon, 27 Jul 2020 07:12:08 -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 :cc; bh=9ITzvljWIStBLwJHX9a3MQcJtkbNyykjDFLgKhZBY4o=; b=n5l6ZwwaNSOEmRVAHPd6agzakHFLLRPP2uuvSAKyO9OzR98E9tV5t/QhrUtbn/tcCh 40e74e8ff7JnVApt3V+mNC1Onmh7ciERjVfcesvgHntbK3V8E4IJNBqTI7PPLp88NGO4 dBd/ykd54nHP0N+OHHigzc4WgZaNCUGIx0dX2T8DlH7eFGEiGxojweXgAlEzsN4Je9O8 GLg/CV3+/MFM29Q/TeyxlLh6sSH5dfSneXOMn0hPw/rMjbWvVSBDYz5BvDebbO9vkSvv CXLrZkLHF2BxLozLtDUzMdJ0aNg4TbMxVrXH+CPzX82PsIPn0Lw9nRyx0hD3oweT0uAl ysUg== 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=9ITzvljWIStBLwJHX9a3MQcJtkbNyykjDFLgKhZBY4o=; b=PIaA4JNrTuiuJZtzwOz+8p+ZCyEGJr5OlY8b2eiHCMx0I2X9QcLie5QUmU7FUUrxDF N1rczRflgCELC57cu2bmoZ5LUqYOL0wnNKkH7qws+kM923Oz1Q2Thei2ojtiMdWY/ceA QZZOkScq436KcUmrgtlDXfGju8FGT9tVHsX5g/4boTM9gU88IggUA//rquB0Qs9Zu6x1 NfZhVMIYAzxnkJazK685UKu8T+3pkEAiEOeJAyDw9Dbpqa+sZnvUVHukxtf9nTe4EdjM T8syMdaBbs5sgAYX5rGLrrFIR33jCixRzdNEmjVMjQD2EfMWWpB1yzW5o1Mg/gHXbB3o 4yBQ== X-Gm-Message-State: AOAM533srduJAF8Cgmxc/tHdGm5XNVUWZOr5/NA9YtHvBj+Rk1X/c5qs nXNxgzR5B2BSre5phHxYNJ9uQwmbbJBmbtC+dDm7ac1o X-Google-Smtp-Source: ABdhPJx5tyrn4jOB+XQxXrvzzrMWVjWthykIvI6CNDBF5bmZems2ywOkn4PTf4mimYRvrGR99m3mfybbfo5OARnd/90= X-Received: by 2002:a4a:9572:: with SMTP id n47mr13356536ooi.37.1595859126895; Mon, 27 Jul 2020 07:12:06 -0700 (PDT) MIME-Version: 1.0 References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <43A56381-0BA8-4123-A2D5-950FD1EDFC86@cisco.com> In-Reply-To: From: Nick Harper Date: Mon, 27 Jul 2020 07:11:55 -0700 Message-ID: To: Ben Schwartz Cc: "Nancy Cam-Winget (ncamwing)" , Jen Linkova , OPSEC , "tls@ietf.org" , OpSec Chairs Content-Type: multipart/alternative; boundary="0000000000005f511d05ab6ce8fc" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 14:12:11 -0000 --0000000000005f511d05ab6ce8fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As currently written, this draft has multiple problems. Section 4 decides not to repeat the Protocol Invariants described in section 9.3 of RFC 8446. However, further sections are written assuming that a proxy acts in a way contrary to those Protocol Invariants. One such example is section 4.2 in this draft. It describes how a proxy might generate its list of cipher suites by modifying the client's list. A proxy that copies the cipher suites from the client-initiated ClientHello into its own ClientHello is violating the 1st and 3rd points of the TLS 1.3 Protocol Invariants. For a best practices document, I think it would be reasonable to reiterate the Protocol Invariants. In addition to reiterating the Protocol Invariants, it should also summarize the advice from the cited papers SECURITY_IMPACT and APPLIANCE_ANALYSIS. One of the problems pointed out by those papers is that TLS proxies will make connections to a server that presents a certificate the client wouldn't accept, but because of the proxy, the client isn't aware of the certificate issues. I don't see this issue addressed at all in the draft. (A similar issue with the server selecting a weak cipher suite is possibly implied by section 4.2, but it is not spelled out well.) If this draft is adopted, it needs to say the following things, which it currently doesn't. - When a TLS proxy generates its ClientHello, it should be created independently from the client-initiated ClientHello. The proxy MAY choose to omit fields from its ClientHello based on the client-initiated ClientHello, but it MUST NOT add fields to its ClientHello based on the client-initiated ClientHello. This is effectively a restatement of the 1st (a client MUST support all parameters it sends) and 3rd (it MUST generate its own ClientHello containing only parameters it understands) points of the TLS 1.3 Protocol Invariants. - If a proxy chooses to conditionally proxy TLS connections and needs more information than what is contained in the client-initiated ClientHello, then the only way to make that decision is to send its own ClientHello to the server the client is connecting to and use information observed on that connection to make the decision to proxy the pending connection. - If a proxy chooses to not proxy some TLS connections, the proxy will fail open. The only way to avoid failing open is to proxy all connections. On Mon, Jul 27, 2020 at 6:31 AM Ben Schwartz wrote: > I'm concerned about this work happening outside the TLS working group. > For example, the question of proper handling of TLS extensions is not > addressed at all in this draft, and has significant security and > functionality implications. There are various other tricky protocol issu= es > (e.g. version negotiation, TLS 1.3 record padding, TLS 1.3 0-RTT vs. TLS > 1.2 False Start, round-trip deadlock when buffers fill, ticket (non-)reus= e, > client certificate linkability pre-TLS-1.3, implications of SAN scope of > synthesized certificates) that could arise and are going to be difficult = to > get right in any other WG. > > The title "TLS Proxy Best Practice" implies that it is possible to proxy > TLS correctly, and that this document is the main source for how to do it= . > I think the TLS WG is the right place to make those judgments.. For the > OpSec group, I think a more appropriate draft would be something like "TL= S > Interception Pitfalls", documenting the operational experience on failure > modes of TLS interception. > > On Mon, Jul 27, 2020 at 8:57 AM Nancy Cam-Winget (ncamwing) 40cisco.com@dmarc.ietf.org> wrote: > >> The document is not imposing any standards but rather provide guidelines >> for those implementing TLS proxies; given that proxies will continue to >> exist I'm not sure why there is a belief that the IETF should ignore thi= s. >> >> Warm regards, Nancy >> >> =EF=BB=BFOn 7/27/20, 5:20 AM, "OPSEC on behalf of Blumenthal, Uri - 0553= - MITLL" >> wrote: >> >> I support Stephen and oppose adoption. IMHO, this is not a technolog= y >> that IETF should standardize. >> >> >> On 7/25/20, 10:07, "TLS on behalf of Stephen Farrell" < >> tls-bounces@ietf.org on behalf of stephen.farrell@cs.tcd.ie> wrote: >> >> >> I oppose adoption. While there could be some minor benefit >> in documenting the uses and abuses seen when mitm'ing tls, >> I doubt that the effort to ensure a balanced document is at >> all worthwhile. The current draft is too far from what it'd >> need to be to be adopted. >> >> Send to ISE. >> >> S. >> >> On 23/07/2020 02:30, Jen Linkova wrote: >> > One thing to add here: the chairs would like to hear active an= d >> > explicit support of the adoption. So please speak up if you >> believe >> > the draft is useful and the WG shall work on getting it >> published. >> > >> > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica >> > wrote: >> >> >> >> Folks, >> >> >> >> >> >> >> >> This email begins a Call For Adoption on >> draft-wang-opsec-tls-proxy-bp. >> >> >> >> >> >> >> >> Please send comments to opsec@ietf.org by August 3, 2020. >> >> >> >> >> >> >> >> >> Ron >> >> >> >> >> >> >> >> >> >> Juniper Business Use Only >> >> >> >> _______________________________________________ >> >> OPSEC mailing list >> >> OPSEC@ietf.org >> >> https://www.ietf.org/mailman/listinfo/opsec >> > >> > >> > >> > -- >> > SY, Jen Linkova aka Furry >> > >> > _______________________________________________ >> > 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 > --0000000000005f511d05ab6ce8fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As currently written, this draft has multiple problems.
Section 4 decides not to repeat the Protocol Invariants de= scribed in section 9.3 of RFC 8446. However, further sections are written a= ssuming that a proxy acts in a way contrary to those Protocol Invariants. O= ne such example is section 4.2 in this draft. It describes how a proxy migh= t generate its list of cipher suites by modifying the client's list. A = proxy that copies the cipher suites from the client-initiated ClientHello i= nto its own ClientHello is violating the 1st and 3rd points of the TLS 1.3 = Protocol Invariants. For a best practices document, I think it would be rea= sonable to reiterate the Protocol Invariants.

In a= ddition to reiterating the Protocol Invariants, it should also summarize th= e advice from the cited papers SECURITY_IMPACT and APPLIANCE_ANALYSIS. One = of the problems pointed out by those papers is that TLS proxies will make c= onnections to a server that presents a certificate the client wouldn't = accept, but because of the proxy, the client isn't aware of the certifi= cate issues. I don't see this issue addressed at all in the draft. (A s= imilar issue with the server selecting a weak cipher suite is possibly impl= ied by section 4.2, but it is not spelled out well.)

If this draft is adopted, it needs to say the following things, which it= currently doesn't.

- When a TLS proxy generat= es its ClientHello, it should be created independently from the client-init= iated ClientHello. The proxy MAY choose to omit fields from its ClientHello= based on the client-initiated ClientHello, but it MUST NOT add fields to i= ts ClientHello based on the client-initiated ClientHello. This is effective= ly a restatement of the 1st (a client MUST support all parameters it sends)= and 3rd (it MUST generate its own ClientHello containing only parameters i= t understands) points of the TLS 1.3 Protocol Invariants.

- If a proxy chooses to conditionally proxy TLS connections and nee= ds more information than what is contained in the client-initiated ClientHe= llo, then the only way to make that decision is to send its own ClientHello= to the server the client is connecting to and use information observed on = that connection to make the decision to proxy the pending connection.
=

- If a proxy chooses to not proxy some TLS connections,= the proxy will fail open. The only way to avoid failing open is to proxy a= ll connections.

On Mon, Jul 27, 2020 at 6:31 AM Ben Schwartz <bemas= c=3D40google.com@dmarc.ietf.= org> wrote:
I'm concerned about this work happ= ening outside the TLS working group.=C2=A0 For example, the question of pro= per handling of TLS extensions is not addressed at all in this draft, and h= as significant security and functionality implications.=C2=A0 There are var= ious other tricky protocol issues (e.g. version negotiation, TLS 1.3 record= padding, TLS 1.3 0-RTT vs. TLS 1.2 False Start, round-trip deadlock when b= uffers fill, ticket (non-)reuse, client certificate linkability pre-TLS-1.3= , implications of SAN scope of synthesized certificates) that could arise a= nd are going to be difficult to get right in any other WG.

The title "TLS Proxy Best Practice" implies that it is possibl= e to proxy TLS correctly, and that this document is the main source for how= to do it.=C2=A0 I think the TLS WG is the right place to make those judgme= nts..=C2=A0 For the OpSec group, I think a more=C2=A0appropriate draft woul= d=C2=A0be something like "TLS Interception Pitfalls", documenting= the operational experience on failure modes of TLS interception.

On M= on, Jul 27, 2020 at 8:57 AM Nancy Cam-Winget (ncamwing) <ncamwing=3D40cisco.com@dma= rc.ietf.org> wrote:
The document is not imposing any standards but rather provide gu= idelines for those implementing TLS proxies;=C2=A0 given that proxies will = continue to exist I'm not sure why there is a belief that the IETF shou= ld ignore this.

Warm regards, Nancy

=EF=BB=BFOn 7/27/20, 5:20 AM, "OPSEC on behalf of Blumenthal, Uri - 05= 53 - MITLL" <opsec-bounces@ietf.org on behalf of uri@ll.mit.edu> wrote:

=C2=A0 =C2=A0 I support Stephen and oppose adoption. IMHO, this is not a te= chnology that IETF should standardize.


=C2=A0 =C2=A0 On 7/25/20, 10:07, "TLS on behalf of Stephen Farrell&quo= t; <tls-bounce= s@ietf.org on behalf of stephen.farrell@cs.tcd.ie> wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I oppose adoption. While there could be some mi= nor benefit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 in documenting the uses and abuses seen when mi= tm'ing tls,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 I doubt that the effort to ensure a balanced do= cument is at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 all worthwhile. The current draft is too far fr= om what it'd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 need to be to be adopted.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Send to ISE.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 S.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 On 23/07/2020 02:30, Jen Linkova wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > One thing to add here: the chairs would li= ke to hear active and
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > explicit support of the adoption. So pleas= e speak up if you believe
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > the draft is useful and the WG shall work = on getting it published.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > <rbonica=3D40juniper.net@dmarc.ietf.org> = wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> Folks,
=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 >> This email begins a Call For Adoption = on draft-wang-opsec-tls-proxy-bp.
=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 >> Please send comments to opsec@ietf.org by August 3, 2020.=
=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 =C2=A0Ron
=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 >> Juniper Business Use Only
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> ______________________________________= _________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> OPSEC mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> OPSEC@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >> https://www.ietf.org= /mailman/listinfo/opsec
=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 > SY, Jen Linkova aka Furry
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > __________________________________________= _____
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > TLS mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > TLS@ietf.org
=C2=A0 =C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/mailm= an/listinfo/tls
=C2=A0 =C2=A0 =C2=A0 =C2=A0 >


_______________________________________________
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
--0000000000005f511d05ab6ce8fc-- From nobody Mon Jul 27 07:21: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 719323A19C5; Mon, 27 Jul 2020 07:21: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, DKIMWL_WL_HIGH=-0.001, 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 XsanfMt5ImOO; Mon, 27 Jul 2020 07:21:32 -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 DD6C93A19B0; Mon, 27 Jul 2020 07:21:31 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06RE7HYG025124; Mon, 27 Jul 2020 15:21:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=0H/xIehM65T2wQ6yWwNES1Qi2LGaiK3b5TJr1Lbj6E0=; b=G4559Alkpyv4k8AuEEYpE1dgC1RdYf9KhH3ArKEc12HyG/9JEGwGjEgIeW1IGyrE69W6 7DNd6VRSlyRMhBDgywnYmSdWu2Ly5ZFa2WdYEgzFZfXxVanbsaDfhPxnNPB+j8Kcc7IN r5Lu0u7o36tNJmnFilCPb8dnwkftKTX1tZPhsulyPtvefikVU7PHyAq8ieLLTwG7SyMI k6zDvtTOFwNiTwu38/KuoODpXCnoQhscsXPp+IzuTPXIDmaugdgSjTZp56/1CqOMBWMH uxvxUIJJ1UL5JIRdSVjCQbq2gq8T4D83jHityJy99TJ+II/Z7dHObqM4NjhHa6Gp/cT8 3w== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 32gcsme9us-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 15:21:27 +0100 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06RE5lYE005447; Mon, 27 Jul 2020 10:21:25 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint6.akamai.com with ESMTP id 32gg2y6r0v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 10:21:25 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 10:21:24 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.006; Mon, 27 Jul 2020 10:21:25 -0400 From: "Salz, Rich" To: Stephen Farrell , Jen Linkova , OPSEC , "tls@ietf.org" CC: OpSec Chairs Thread-Topic: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AdZd8qs4MVhjKcpfSaSC3eC5PK0rEQCv6iMAAH8Fd4AAWHLpgAAJopcAAADKqAD//86UgA== Date: Mon, 27 Jul 2020 14:21:24 +0000 Message-ID: <37F64FB8-C318-4EC4-A754-587BDEBE6F21@akamai.com> References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <43A56381-0BA8-4123-A2D5-950FD1EDFC86@cisco.com> <845E6D98-DD1C-4FD7-AEF6-A262C10B35A8@ll.mit.edu> In-Reply-To: <845E6D98-DD1C-4FD7-AEF6-A262C10B35A8@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.43.31] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-27_08:2020-07-27, 2020-07-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0 malwarescore=0 spamscore=0 mlxlogscore=692 bulkscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007270103 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-27_08:2020-07-27, 2020-07-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 mlxscore=0 adultscore=0 mlxlogscore=658 lowpriorityscore=0 clxscore=1015 spamscore=0 bulkscore=0 suspectscore=0 priorityscore=1501 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007270103 Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 14:21:35 -0000 PiAgICBVbmRlcnN0b29kLiBIb3dldmVyLCBpbiB0aGlzIHBhcnRpY3VsYXIgY2FzZSwgaW5zdGVh ZCBvZiAiaWYgeW91IHdhbnQgdG8gZG8gdGhpcywgdGhlbiBkbyBpdCB0aGF0IHdheSwgYW5kIEkn bGwgaGVscCB5b3UgaW50ZXItb3BlcmF0ZSIgSSBwcmVmZXIgImlmIHlvdSB3YW50IHRvIGRvIHRo aXMgLSB5b3UncmUgb24geW91ciBvd24sIGRvbid0IHNlZWsgYSBibGVzc2luZyBvciBhZHZpY2Ug ZnJvbSBtZSIuDQoNClNvIHlvdSBkb24ndCBmZWVsIHRoYXQgY29tbXVuaXR5IGlzIHdlbGNvbWUg aGVyZSBhdCB0aGUgSUVURiwgb3IgdGhhdCB5b3Ugd29uJ3QgcGVyc29uYWxseSBwYXJ0aWNpcGF0 ZT8NCg0KDQo= From nobody Mon Jul 27 07:32: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 685613A1A24; Mon, 27 Jul 2020 07:32:50 -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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 mfMm44-NSXli; Mon, 27 Jul 2020 07:32:49 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) (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 1A1AE3A1C6E; Mon, 27 Jul 2020 07:31:12 -0700 (PDT) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTPS id 06REUuU5019314; Mon, 27 Jul 2020 10:31:01 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Salz, Rich" , Stephen Farrell , Jen Linkova , OPSEC , "tls@ietf.org" CC: OpSec Chairs Thread-Topic: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AQHWZCFRNYnuMxdZY0275+lveJc/fqkbfNSA Date: Mon, 27 Jul 2020 14:30:59 +0000 Message-ID: References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <43A56381-0BA8-4123-A2D5-950FD1EDFC86@cisco.com> <845E6D98-DD1C-4FD7-AEF6-A262C10B35A8@ll.mit.edu> <37F64FB8-C318-4EC4-A754-587BDEBE6F21@akamai.com> In-Reply-To: <37F64FB8-C318-4EC4-A754-587BDEBE6F21@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-originating-ip: [172.25.1.85] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3678690659_1181152928" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-27_08:2020-07-27, 2020-07-27 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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2006250000 definitions=main-2007270103 Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 14:32:51 -0000 --B_3678690659_1181152928 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable As my personal opinion - both. =EF=BB=BFOn 7/27/20, 10:22, "TLS on behalf of Salz, Rich" wrote: > Understood. However, in this particular case, instead of "if you w= ant to do this, then do it that way, and I'll help you inter-operate" I pref= er "if you want to do this - you're on your own, don't seek a blessing or ad= vice from me". So you don't feel that community is welcome here at the IETF, or that y= ou won't personally participate? _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --B_3678690659_1181152928 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQAEsOl/1qhyyOFZzgAAAASw6TANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTIwMDIxMjE2NTAyM1oXDTI1MDIx MDE2NTAyM1owYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCmeoHpDu+bGes6qLPIUd2r7EQaBwYt V254WjhvNdMry3tev5DNk7FprxZhspY0dxRoDvIUrfJ3saAcbxrVc9HnzdNTl57rtF2RiRLM Fb7wL6yz4Yis3yY6GpbONzkKX5FajFmSGuktYMMVt8CAPcPbbkUMPZ80QzMxWYolvcYH+C4z eH8Zw/oU7bzunibn0hJISHDZhNJyewLtQEhRxSHf/278CbuAbWq0YHVRwTz7Wd4FpFIvXdxj 6+c4QTMSTtWGvTNPtrYokw8g1SvZhZKYswnWHGOjGC5dr4NBfreyMq3f7y0x8Tp9dpJuDcK9 UMAMY3C0HZrNng3Y+tSc4XrhAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUaBwMva1XkRg3VVpo HkGTEOInxwEwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCjAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBACYoq8k4 439LiS2zazVa7DYys6kPXsJaEVjmRmOZYOIeMA0fDV2qoKa27RnGhRvxgER7MYtiNsj95qUx EM3Ov0xnNLZONOsEYRlfdy8oR25TnuEGaVIbxqK38dYGzY0Zy2/2ZjptkXgyH6h3E50s43lr ZSm2KK39qS4o/3ZG7sPjzouWXj8lzMyQar4+2j2U3axuRlY17vXXSCGFYtUNZXWey+JhLWBf DK7EqpS811J3htiJS+eBWtkWMr6ZsnAvMWCdXZY+5Hy7qrpGUxKQA4MdFsATkPYTRE8c8u27 izPeEoZpm40nQGx+IElp1ojJDPekx2EmAbRszcbgGskh8LEwggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAEsOl/1qhyyOFZzgAAAASw6TANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCBiIO2IfATo0pApwfsZ0SwhZnqxOeAbofu9frYg DM1vsDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3Mjcx NDMwNTlaMA0GCSqGSIb3DQEBAQUABIIBAGF6n9TH8NDdDrWcaSjVyQ8StrQK/o6S6J5perG3 aDv9xKv1Ec4q4oMWI+NlHdCXgQ8BvjAKDavVDPY7k59tyjoitkFcqAlzSjVBEnCsSU6Wp7yK F0jgzTPDjVG3laEhcRE80k+WRr+7OTRD0Puv/iDTr5MH+rTtY3k7ig9GWfBGetQiiytaeOmj 1/vjavrmCd5NHOkQ7kPLSPYKUNJZOCFxr66Lv1RT9x83DHlhp06PlpVLTLeLtA8A2sVf9t3A hH0dXpqkq6dsDaY52liIvy9XFX/BmFzbsjaf97PGteJAGQP8FYy2JvuXHj8/L8SCSvgiYTuK T3yFWf8R2tzTH7c= --B_3678690659_1181152928-- From nobody Mon Jul 27 10:39: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 C96E63A1BC1; Mon, 27 Jul 2020 10:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, HTTPS_HTTP_MISMATCH=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=microsoft.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 i3CD6TfMZo1t; Mon, 27 Jul 2020 10:39:08 -0700 (PDT) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640122.outbound.protection.outlook.com [40.107.64.122]) (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 DE2473A1BE6; Mon, 27 Jul 2020 10:39:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q3rlaqStW6uQq7J1/TOZMOXgJ+HYVYwq6g94nV+XnoU+w0YTYLBrWaVXqB41wWnfHrvCjRZN7YMsdzUCvdXPVfrY2EMlfRumst0ni7v35IETUbK2exLfUd31TG5wq3g1nGaotb+9LZVAoak3x4qrGepYxUBdsLJgmO0xgUyomv5n0zZnXFjWAFj9wCIo6TTb+KiO2K10Iutx2Rrg0Bkp/qYgOtcs65vaJaXgp6s3KAV7D7RZpW2VWq93LOZWNTewv8ss/zH9Lsl6woxphj6J+yYaDsRJxTrDo0N14U1Eo2JIZrbt2b+f/EJDyScZzmgAgQzgJQ76g2C3G51jngZCSA== 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=vmdF3bp8e/CA+pYTSE1uoE2gLM+5SucSfqUYZ1Iw+Ug=; b=KCiSEpYDMf3UlEcCQ5W+LkhWEQ8tch9RXnUD2eik6ClgvPW5Moyj1iyN/N6nHiycG8AhnHRGnZGMIYE6Mu+PScwTPGdI3/5t6D1tVCrKBx0A8Kq5/aEjWReSoG/T34BgFwhwe2AiE8jahs2AN3XglFOwU7CV8JZnB8ZyF3ADvEs/Aby78VTWV1jh4wi7/8HxH6aMaja/YooQQpG9u+eTumcat+3SVlSc3+lj3zq87UTWb34l6z6547wxl3HNeat8fjfHz53075xWoR0XXKAaxkS5/WNa3mC2eeNWm2gthqQEB3geqD/mjO8HU+MCRbh6ItErXYS2RtcHBTbfPIEBEQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vmdF3bp8e/CA+pYTSE1uoE2gLM+5SucSfqUYZ1Iw+Ug=; b=RwtFatu4Yt+OePz7IO34m8LI2uq3cLZqGVuWP5uA13JH/COasgo2AwqM1/bW/f1oV+J7SPDuo0Gqtk6nM3Evx4OLenAsVk7Qipb8gnp7SV60mG34Cx3UNcOm9HPcmrZtGmwMK+rXLGey+vaNwJHuT6RiJjznSja3TilkNWrZLvA= Received: from SN6PR00MB0366.namprd00.prod.outlook.com (2603:10b6:805:c::21) by SN2PR00MB0157.namprd00.prod.outlook.com (2603:10b6:804:14::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3268.0; Mon, 27 Jul 2020 17:39:04 +0000 Received: from SN6PR00MB0366.namprd00.prod.outlook.com ([fe80::680e:e96:c9e7:83b6]) by SN6PR00MB0366.namprd00.prod.outlook.com ([fe80::680e:e96:c9e7:83b6%6]) with mapi id 15.20.3274.000; Mon, 27 Jul 2020 17:39:04 +0000 From: Andrei Popov To: Nick Harper , Ben Schwartz CC: Jen Linkova , "Nancy Cam-Winget (ncamwing)" , OpSec Chairs , OPSEC , "tls@ietf.org" Thread-Topic: [EXTERNAL] Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AQHWZBBwnFbN+qQLf06kFxSnz+aE9akbYlAAgAAJxoCAAAuMgIAALOng Date: Mon, 27 Jul 2020 17:39:04 +0000 Message-ID: References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <43A56381-0BA8-4123-A2D5-950FD1EDFC86@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-07-27T17:39:03Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=d2c384cb-6ae2-4929-a282-7370f60fb097; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.47.142.169] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2eb57763-9f08-4e05-53f5-08d83253f4f7 x-ms-traffictypediagnostic: SN2PR00MB0157: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ROKZwfJQfZkIZhvtDai/ST3yiouQML2ODB0yOdyXv36HpFEcHt0pBFLVzfBMYcUnO6TAgixjclmQfWFLQ2BH+k5iUIb8cSqVf6CQpNLN+/H/oJ2IZFHFu02DyWSFGYWXN4T69v2pMaJRQ83x1nAqB82zZ3oK4e+UVfm3T4Bz4wbrWwgmz+8KkqqrjS3WyXoiL9HkxeNwmIKoBaKRra+EgPqJPpciGUlSROxeQlMgndD60YTz5A36+1rodxQS2L06OLcAKO/TF51fRltzg5GetQoTpnZ5/m5dB8XAiJKBGJjGmuhOtHMlc5deh9Bu7yEPtZTR08yHl4MhNn/t4Di5iBVaw5akwYmzmTCDdLwOpy97nYha4CRhu/MpV0VsPXZ/9Qlpm6aov6wXNZdwLSl6Dw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR00MB0366.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(366004)(346002)(376002)(39860400002)(33656002)(26005)(6506007)(316002)(53546011)(8676002)(71200400001)(4326008)(66946007)(8990500004)(52536014)(5660300002)(66476007)(66556008)(64756008)(66446008)(83380400001)(966005)(478600001)(110136005)(54906003)(10290500003)(186003)(7696005)(86362001)(166002)(82960400001)(82950400001)(9686003)(55016002)(2906002)(8936002)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: JxQktZCD0ITEDJ/njyLhPzXU/d+tudzEqQgErAqLO0a0Z+YuotfkLpbUsQiwvxAM+wvI7jBmTUegy0+Ol6OvqV954tTgqQ4VkryKf2ISfIrYjNMYsQ846O2xAHAAFmtiEZX+0hfLSTyz06gLEKJptI42eB1xxBoKSb97NsBNlRrg/wRLkdVL/s2W5PA/9STg+/hZ8jbFBade8cnpnPHicLh1GqDHfcU12EuqCCEDfQ1KnyP0tQ2wwGqB8vIP2PC3OJ6ZZQZ07LJtLrgLHvGiZKuS25ywy04GfTa2cVeg0n/kB5staC+Xgr11ZbfV1Lkcd/VNM8F2roqsNQ+9T1tXvdb+Ffai7zofkHVrp85WV92UIZlfHQI1asylGlAc2ycs1WwVshshDmsGr9n/QhaO7Zt3ScBEqjHZaKtuKm7iHBT/+mO8CkjG70rVyZpVcXV4oJ/PYnjQ1WMdDTk3zD1+1RiDsDP57s4S+Y94nC7fxU4oMOt2Pr7x5BIgdiB3AC/n9nJn1sSEFMONhhs3N+tsnbczdDMb8o5evYRr6mfrlm0mx8LzpLaVh+PxooDqeQFPSlDKr6gh5O+lB0MJ6QvyIpTAiEXRIEOKkGvZo8ZT4rINFQe80hrvxPT5SCKVPK3Z+PEqoVxOJDeGxETO2pXVQg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR00MB0366B0069B49FD37A9D25DB38C720SN6PR00MB0366namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR00MB0366.namprd00.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2eb57763-9f08-4e05-53f5-08d83253f4f7 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 17:39:04.5449 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: w/a2y+r4qoTBzhJpTKyojD/hskTJHmSCWYJIM3j/FQSPVL3CWF7oU+i+TY4JRk8YXVWr3iyWP1O2zhVZm59/3Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR00MB0157 Archived-At: Subject: Re: [TLS] [EXTERNAL] Re: [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 17:39:19 -0000 --_000_SN6PR00MB0366B0069B49FD37A9D25DB38C720SN6PR00MB0366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgd3JpdHRlbiwgdGhlIGRvY3VtZW50IHByb3ZpZGVzIGEgYmFzaWMvZ2VuZXJhbCBkZXNjcmlw dGlvbiBvZiBNSVRNIHByb3hpZXMuIEl0IG1lbnRpb25zIHNvbWUgb2YgdGhlIGlzc3VlcyAoY2xp ZW50IGF1dGgsIGhhbmRsaW5nIG9mIDAtUlRUIGFwcGxpY2F0aW9uIGRhdGEsIHNpbmdsZSBwb2lu dCBvZiBmYWlsdXJlLCB1cGRhdGVzL3BhdGNoZXMsIHJpc2tzIG9mIGRpc2Nsb3N1cmUgb2YgUElJ L1BISSksIGJ1dCBkb2VzIG5vdCByZWFsbHkgcHJvdmlkZSBhbHRlcm5hdGl2ZXMgb3Igc3BlY2lm aWMgc29sdXRpb25zLiBJIG9wcG9zZSBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGluIGl0cyBj dXJyZW50IHNoYXBlLg0KDQpTb21lIHNwZWNpZmljIGlzc3VlczoNCg0KICAqICAgVGhlIGRvY3Vt ZW50IGRvZXMgbm90IGRlc2NyaWJlIGFsdGVybmF0aXZlcyB0byBNSVRNIHByb3hpZXMuDQogICog ICBTZWN0aW9uIDQuMS4yIOKAnEluYm91bmQgcHJvdmlzaW9uaW5n4oCdIGRvZXMgbm90IGRpc2N1 c3Mgc2VjdXJpdHkgYW5kIG9wZXJhdGlvbmFsIGlzc3VlcyBhcm91bmQgc2VydmVyIGtleSBzaGFy aW5nIHdpdGggdGhlIHByb3h5LiBObyByZWFsIGRpc2N1c3Npb24gb2Ygc2hvcnQtbGl2ZWQgY3Jl ZHMgYW5kIOKAnGtleWxlc3PigJ0gc2NlbmFyaW9zLg0KICAqICAgU2VjdGlvbiA0LjIg4oCcTWFp bnRhaW4gc2VjdXJpdHkgcG9zdHVyZSBhbmQgbGltaXQgbW9kaWZpY2F0aW9uc+KAnSBzZWVtcyB0 byByZWNvbW1lbmQgbW9kaWZpY2F0aW9ucyB0byB0aGUgQ2xpZW50SGVsbG8sIHJhdGhlciB0aGFu IGhhdmluZyB0aGUgcHJveHkgZ2VuZXJhdGUgYSBuZXcgQ2xpZW50SGVsbG8uIFByb3hpZXMgc2Vu ZGluZyBDbGllbnRIZWxsb3MgdGhleSBkaWQgbm90IGdlbmVyYXRlIGFyZSBhIGNvbW1vbiBjYXVz ZSBvZiBpbnRlcm9wIGlzc3Vlcy4NCiAgKiAgIFNlY3Rpb24gNC4yIGFsc28gZXhwbGljaXRseSBh bGxvd3MgY29tcGxldGVseSBpbnNlY3VyZSBjb25maWd1cmF0aW9uczoNCg0KICAgICAg4oCcVExT IHByb3h5IHN0YWNrcyBNQVkgcHJvdmlkZSB1c2VyIGNvbmZpZ3VyYWJsZSBvcHRpb25zLCBzdWNo IGFzIGFuDQogICBvcHRpb24gdG8gYWNjZXB0IHNlbGYtc2lnbmVkIHNlcnZlciBjZXJ0aWZpY2F0 ZXMsIGFuIG9wdGlvbiB0byBsZXQNCiAgIHRoZSBoYW5kc2hha2UgY29udGludWUgd2l0aCBleHBp cmVkIGJ1dCBvdGhlcndpc2UgdmFsaWQgc2VydmVyDQogICBjZXJ0aWZpY2F0ZXMsIGV0Yy7igJ0N Cg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KRnJvbTogVExTIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4g T24gQmVoYWxmIE9mIE5pY2sgSGFycGVyDQpTZW50OiBNb25kYXksIEp1bHkgMjcsIDIwMjAgNzox MiBBTQ0KVG86IEJlbiBTY2h3YXJ0eiA8YmVtYXNjPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9y Zz4NCkNjOiBKZW4gTGlua292YSA8ZnVycnkxM0BnbWFpbC5jb20+OyBOYW5jeSBDYW0tV2luZ2V0 IChuY2Ftd2luZykgPG5jYW13aW5nPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPjsgT3BTZWMg Q2hhaXJzIDxvcHNlYy1jaGFpcnNAaWV0Zi5vcmc+OyBPUFNFQyA8b3BzZWNAaWV0Zi5vcmc+OyB0 bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtUTFNdIFtPUFNFQ10gQ2FsbCBG b3IgQWRvcHRpb246IGRyYWZ0LXdhbmctb3BzZWMtdGxzLXByb3h5LWJwDQoNCkFzIGN1cnJlbnRs eSB3cml0dGVuLCB0aGlzIGRyYWZ0IGhhcyBtdWx0aXBsZSBwcm9ibGVtcy4NCg0KU2VjdGlvbiA0 IGRlY2lkZXMgbm90IHRvIHJlcGVhdCB0aGUgUHJvdG9jb2wgSW52YXJpYW50cyBkZXNjcmliZWQg aW4gc2VjdGlvbiA5LjMgb2YgUkZDIDg0NDYuIEhvd2V2ZXIsIGZ1cnRoZXIgc2VjdGlvbnMgYXJl IHdyaXR0ZW4gYXNzdW1pbmcgdGhhdCBhIHByb3h5IGFjdHMgaW4gYSB3YXkgY29udHJhcnkgdG8g dGhvc2UgUHJvdG9jb2wgSW52YXJpYW50cy4gT25lIHN1Y2ggZXhhbXBsZSBpcyBzZWN0aW9uIDQu MiBpbiB0aGlzIGRyYWZ0LiBJdCBkZXNjcmliZXMgaG93IGEgcHJveHkgbWlnaHQgZ2VuZXJhdGUg aXRzIGxpc3Qgb2YgY2lwaGVyIHN1aXRlcyBieSBtb2RpZnlpbmcgdGhlIGNsaWVudCdzIGxpc3Qu IEEgcHJveHkgdGhhdCBjb3BpZXMgdGhlIGNpcGhlciBzdWl0ZXMgZnJvbSB0aGUgY2xpZW50LWlu aXRpYXRlZCBDbGllbnRIZWxsbyBpbnRvIGl0cyBvd24gQ2xpZW50SGVsbG8gaXMgdmlvbGF0aW5n IHRoZSAxc3QgYW5kIDNyZCBwb2ludHMgb2YgdGhlIFRMUyAxLjMgUHJvdG9jb2wgSW52YXJpYW50 cy4gRm9yIGEgYmVzdCBwcmFjdGljZXMgZG9jdW1lbnQsIEkgdGhpbmsgaXQgd291bGQgYmUgcmVh c29uYWJsZSB0byByZWl0ZXJhdGUgdGhlIFByb3RvY29sIEludmFyaWFudHMuDQoNCkluIGFkZGl0 aW9uIHRvIHJlaXRlcmF0aW5nIHRoZSBQcm90b2NvbCBJbnZhcmlhbnRzLCBpdCBzaG91bGQgYWxz byBzdW1tYXJpemUgdGhlIGFkdmljZSBmcm9tIHRoZSBjaXRlZCBwYXBlcnMgU0VDVVJJVFlfSU1Q QUNUIGFuZCBBUFBMSUFOQ0VfQU5BTFlTSVMuIE9uZSBvZiB0aGUgcHJvYmxlbXMgcG9pbnRlZCBv dXQgYnkgdGhvc2UgcGFwZXJzIGlzIHRoYXQgVExTIHByb3hpZXMgd2lsbCBtYWtlIGNvbm5lY3Rp b25zIHRvIGEgc2VydmVyIHRoYXQgcHJlc2VudHMgYSBjZXJ0aWZpY2F0ZSB0aGUgY2xpZW50IHdv dWxkbid0IGFjY2VwdCwgYnV0IGJlY2F1c2Ugb2YgdGhlIHByb3h5LCB0aGUgY2xpZW50IGlzbid0 IGF3YXJlIG9mIHRoZSBjZXJ0aWZpY2F0ZSBpc3N1ZXMuIEkgZG9uJ3Qgc2VlIHRoaXMgaXNzdWUg YWRkcmVzc2VkIGF0IGFsbCBpbiB0aGUgZHJhZnQuIChBIHNpbWlsYXIgaXNzdWUgd2l0aCB0aGUg c2VydmVyIHNlbGVjdGluZyBhIHdlYWsgY2lwaGVyIHN1aXRlIGlzIHBvc3NpYmx5IGltcGxpZWQg Ynkgc2VjdGlvbiA0LjIsIGJ1dCBpdCBpcyBub3Qgc3BlbGxlZCBvdXQgd2VsbC4pDQoNCklmIHRo aXMgZHJhZnQgaXMgYWRvcHRlZCwgaXQgbmVlZHMgdG8gc2F5IHRoZSBmb2xsb3dpbmcgdGhpbmdz LCB3aGljaCBpdCBjdXJyZW50bHkgZG9lc24ndC4NCg0KLSBXaGVuIGEgVExTIHByb3h5IGdlbmVy YXRlcyBpdHMgQ2xpZW50SGVsbG8sIGl0IHNob3VsZCBiZSBjcmVhdGVkIGluZGVwZW5kZW50bHkg ZnJvbSB0aGUgY2xpZW50LWluaXRpYXRlZCBDbGllbnRIZWxsby4gVGhlIHByb3h5IE1BWSBjaG9v c2UgdG8gb21pdCBmaWVsZHMgZnJvbSBpdHMgQ2xpZW50SGVsbG8gYmFzZWQgb24gdGhlIGNsaWVu dC1pbml0aWF0ZWQgQ2xpZW50SGVsbG8sIGJ1dCBpdCBNVVNUIE5PVCBhZGQgZmllbGRzIHRvIGl0 cyBDbGllbnRIZWxsbyBiYXNlZCBvbiB0aGUgY2xpZW50LWluaXRpYXRlZCBDbGllbnRIZWxsby4g VGhpcyBpcyBlZmZlY3RpdmVseSBhIHJlc3RhdGVtZW50IG9mIHRoZSAxc3QgKGEgY2xpZW50IE1V U1Qgc3VwcG9ydCBhbGwgcGFyYW1ldGVycyBpdCBzZW5kcykgYW5kIDNyZCAoaXQgTVVTVCBnZW5l cmF0ZSBpdHMgb3duIENsaWVudEhlbGxvIGNvbnRhaW5pbmcgb25seSBwYXJhbWV0ZXJzIGl0IHVu ZGVyc3RhbmRzKSBwb2ludHMgb2YgdGhlIFRMUyAxLjMgUHJvdG9jb2wgSW52YXJpYW50cy4NCg0K LSBJZiBhIHByb3h5IGNob29zZXMgdG8gY29uZGl0aW9uYWxseSBwcm94eSBUTFMgY29ubmVjdGlv bnMgYW5kIG5lZWRzIG1vcmUgaW5mb3JtYXRpb24gdGhhbiB3aGF0IGlzIGNvbnRhaW5lZCBpbiB0 aGUgY2xpZW50LWluaXRpYXRlZCBDbGllbnRIZWxsbywgdGhlbiB0aGUgb25seSB3YXkgdG8gbWFr ZSB0aGF0IGRlY2lzaW9uIGlzIHRvIHNlbmQgaXRzIG93biBDbGllbnRIZWxsbyB0byB0aGUgc2Vy dmVyIHRoZSBjbGllbnQgaXMgY29ubmVjdGluZyB0byBhbmQgdXNlIGluZm9ybWF0aW9uIG9ic2Vy dmVkIG9uIHRoYXQgY29ubmVjdGlvbiB0byBtYWtlIHRoZSBkZWNpc2lvbiB0byBwcm94eSB0aGUg cGVuZGluZyBjb25uZWN0aW9uLg0KDQotIElmIGEgcHJveHkgY2hvb3NlcyB0byBub3QgcHJveHkg c29tZSBUTFMgY29ubmVjdGlvbnMsIHRoZSBwcm94eSB3aWxsIGZhaWwgb3Blbi4gVGhlIG9ubHkg d2F5IHRvIGF2b2lkIGZhaWxpbmcgb3BlbiBpcyB0byBwcm94eSBhbGwgY29ubmVjdGlvbnMuDQoN Ck9uIE1vbiwgSnVsIDI3LCAyMDIwIGF0IDY6MzEgQU0gQmVuIFNjaHdhcnR6IDxiZW1hc2M9NDBn b29nbGUuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5v cmc+PiB3cm90ZToNCkknbSBjb25jZXJuZWQgYWJvdXQgdGhpcyB3b3JrIGhhcHBlbmluZyBvdXRz aWRlIHRoZSBUTFMgd29ya2luZyBncm91cC4gIEZvciBleGFtcGxlLCB0aGUgcXVlc3Rpb24gb2Yg cHJvcGVyIGhhbmRsaW5nIG9mIFRMUyBleHRlbnNpb25zIGlzIG5vdCBhZGRyZXNzZWQgYXQgYWxs IGluIHRoaXMgZHJhZnQsIGFuZCBoYXMgc2lnbmlmaWNhbnQgc2VjdXJpdHkgYW5kIGZ1bmN0aW9u YWxpdHkgaW1wbGljYXRpb25zLiAgVGhlcmUgYXJlIHZhcmlvdXMgb3RoZXIgdHJpY2t5IHByb3Rv Y29sIGlzc3VlcyAoZS5nLiB2ZXJzaW9uIG5lZ290aWF0aW9uLCBUTFMgMS4zIHJlY29yZCBwYWRk aW5nLCBUTFMgMS4zIDAtUlRUIHZzLiBUTFMgMS4yIEZhbHNlIFN0YXJ0LCByb3VuZC10cmlwIGRl YWRsb2NrIHdoZW4gYnVmZmVycyBmaWxsLCB0aWNrZXQgKG5vbi0pcmV1c2UsIGNsaWVudCBjZXJ0 aWZpY2F0ZSBsaW5rYWJpbGl0eSBwcmUtVExTLTEuMywgaW1wbGljYXRpb25zIG9mIFNBTiBzY29w ZSBvZiBzeW50aGVzaXplZCBjZXJ0aWZpY2F0ZXMpIHRoYXQgY291bGQgYXJpc2UgYW5kIGFyZSBn b2luZyB0byBiZSBkaWZmaWN1bHQgdG8gZ2V0IHJpZ2h0IGluIGFueSBvdGhlciBXRy4NCg0KVGhl IHRpdGxlICJUTFMgUHJveHkgQmVzdCBQcmFjdGljZSIgaW1wbGllcyB0aGF0IGl0IGlzIHBvc3Np YmxlIHRvIHByb3h5IFRMUyBjb3JyZWN0bHksIGFuZCB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgdGhl IG1haW4gc291cmNlIGZvciBob3cgdG8gZG8gaXQuICBJIHRoaW5rIHRoZSBUTFMgV0cgaXMgdGhl IHJpZ2h0IHBsYWNlIHRvIG1ha2UgdGhvc2UganVkZ21lbnRzLi4gIEZvciB0aGUgT3BTZWMgZ3Jv dXAsIEkgdGhpbmsgYSBtb3JlIGFwcHJvcHJpYXRlIGRyYWZ0IHdvdWxkIGJlIHNvbWV0aGluZyBs aWtlICJUTFMgSW50ZXJjZXB0aW9uIFBpdGZhbGxzIiwgZG9jdW1lbnRpbmcgdGhlIG9wZXJhdGlv bmFsIGV4cGVyaWVuY2Ugb24gZmFpbHVyZSBtb2RlcyBvZiBUTFMgaW50ZXJjZXB0aW9uLg0KDQpP biBNb24sIEp1bCAyNywgMjAyMCBhdCA4OjU3IEFNIE5hbmN5IENhbS1XaW5nZXQgKG5jYW13aW5n KSA8bmNhbXdpbmc9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwY2lzY28uY29t QGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQpUaGUgZG9jdW1lbnQgaXMgbm90IGltcG9zaW5nIGFu eSBzdGFuZGFyZHMgYnV0IHJhdGhlciBwcm92aWRlIGd1aWRlbGluZXMgZm9yIHRob3NlIGltcGxl bWVudGluZyBUTFMgcHJveGllczsgIGdpdmVuIHRoYXQgcHJveGllcyB3aWxsIGNvbnRpbnVlIHRv IGV4aXN0IEknbSBub3Qgc3VyZSB3aHkgdGhlcmUgaXMgYSBiZWxpZWYgdGhhdCB0aGUgSUVURiBz aG91bGQgaWdub3JlIHRoaXMuDQoNCldhcm0gcmVnYXJkcywgTmFuY3kNCg0K77u/T24gNy8yNy8y MCwgNToyMCBBTSwgIk9QU0VDIG9uIGJlaGFsZiBvZiBCbHVtZW50aGFsLCBVcmkgLSAwNTUzIC0g TUlUTEwiIDxvcHNlYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvcHNlYy1ib3VuY2VzQGlldGYu b3JnPiBvbiBiZWhhbGYgb2YgdXJpQGxsLm1pdC5lZHU8bWFpbHRvOnVyaUBsbC5taXQuZWR1Pj4g d3JvdGU6DQoNCiAgICBJIHN1cHBvcnQgU3RlcGhlbiBhbmQgb3Bwb3NlIGFkb3B0aW9uLiBJTUhP LCB0aGlzIGlzIG5vdCBhIHRlY2hub2xvZ3kgdGhhdCBJRVRGIHNob3VsZCBzdGFuZGFyZGl6ZS4N Cg0KDQogICAgT24gNy8yNS8yMCwgMTA6MDcsICJUTFMgb24gYmVoYWxmIG9mIFN0ZXBoZW4gRmFy cmVsbCIgPHRscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8bWFpbHRvOnN0ZXBoZW4uZmFy cmVsbEBjcy50Y2QuaWU+PiB3cm90ZToNCg0KDQogICAgICAgIEkgb3Bwb3NlIGFkb3B0aW9uLiBX aGlsZSB0aGVyZSBjb3VsZCBiZSBzb21lIG1pbm9yIGJlbmVmaXQNCiAgICAgICAgaW4gZG9jdW1l bnRpbmcgdGhlIHVzZXMgYW5kIGFidXNlcyBzZWVuIHdoZW4gbWl0bSdpbmcgdGxzLA0KICAgICAg ICBJIGRvdWJ0IHRoYXQgdGhlIGVmZm9ydCB0byBlbnN1cmUgYSBiYWxhbmNlZCBkb2N1bWVudCBp cyBhdA0KICAgICAgICBhbGwgd29ydGh3aGlsZS4gVGhlIGN1cnJlbnQgZHJhZnQgaXMgdG9vIGZh ciBmcm9tIHdoYXQgaXQnZA0KICAgICAgICBuZWVkIHRvIGJlIHRvIGJlIGFkb3B0ZWQuDQoNCiAg ICAgICAgU2VuZCB0byBJU0UuDQoNCiAgICAgICAgUy4NCg0KICAgICAgICBPbiAyMy8wNy8yMDIw IDAyOjMwLCBKZW4gTGlua292YSB3cm90ZToNCiAgICAgICAgPiBPbmUgdGhpbmcgdG8gYWRkIGhl cmU6IHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBoZWFyIGFjdGl2ZSBhbmQNCiAgICAgICAgPiBl eHBsaWNpdCBzdXBwb3J0IG9mIHRoZSBhZG9wdGlvbi4gU28gcGxlYXNlIHNwZWFrIHVwIGlmIHlv dSBiZWxpZXZlDQogICAgICAgID4gdGhlIGRyYWZ0IGlzIHVzZWZ1bCBhbmQgdGhlIFdHIHNoYWxs IHdvcmsgb24gZ2V0dGluZyBpdCBwdWJsaXNoZWQuDQogICAgICAgID4NCiAgICAgICAgPiBPbiBN b24sIEp1bCAyMCwgMjAyMCBhdCAzOjM1IEFNIFJvbiBCb25pY2ENCiAgICAgICAgPiA8cmJvbmlj YT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGp1bmlwZXIubmV0QGRtYXJj LmlldGYub3JnPj4gd3JvdGU6DQogICAgICAgID4+DQogICAgICAgID4+IEZvbGtzLA0KICAgICAg ICA+Pg0KICAgICAgICA+Pg0KICAgICAgICA+Pg0KICAgICAgICA+PiBUaGlzIGVtYWlsIGJlZ2lu cyBhIENhbGwgRm9yIEFkb3B0aW9uIG9uIGRyYWZ0LXdhbmctb3BzZWMtdGxzLXByb3h5LWJwLg0K ICAgICAgICA+Pg0KICAgICAgICA+Pg0KICAgICAgICA+Pg0KICAgICAgICA+PiBQbGVhc2Ugc2Vu ZCBjb21tZW50cyB0byBvcHNlY0BpZXRmLm9yZzxtYWlsdG86b3BzZWNAaWV0Zi5vcmc+IGJ5IEF1 Z3VzdCAzLCAyMDIwLg0KICAgICAgICA+Pg0KICAgICAgICA+Pg0KICAgICAgICA+Pg0KICAgICAg ICA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUm9uDQogICAgICAgID4+DQogICAgICAgID4+DQogICAgICAgID4+DQogICAg ICAgID4+DQogICAgICAgID4+IEp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCiAgICAgICAgPj4N CiAgICAgICAgPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCiAgICAgICAgPj4gT1BTRUMgbWFpbGluZyBsaXN0DQogICAgICAgID4+IE9QU0VDQGlldGYu b3JnPG1haWx0bzpPUFNFQ0BpZXRmLm9yZz4NCiAgICAgICAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9vcHNlYzxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZvcHNlYyZkYXRhPTAyJTdDMDElN0NBbmRyZWkuUG9wb3YlNDBtaWNyb3Nv ZnQuY29tJTdDMjNkNWU3ZjhhYzEwNDdkOThmZTEwOGQ4MzIzNzI0YTYlN0M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MzE0NTU5NzM2NzA3NjgwJnNkYXRhPVAw UkUzbGxlUFVLUkNwOG9nMUVWbTdHNDVOMVV1aldtWTZhVE9UUkJHVUUlM0QmcmVzZXJ2ZWQ9MD4N CiAgICAgICAgPg0KICAgICAgICA+DQogICAgICAgID4NCiAgICAgICAgPiAtLQ0KICAgICAgICA+ IFNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCiAgICAgICAgPg0KICAgICAgICA+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgID4gVExTIG1h aWxpbmcgbGlzdA0KICAgICAgICA+IFRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0K ICAgICAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPGh0dHBz Oi8vbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUy RiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRscyZkYXRhPTAyJTdDMDEl N0NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdDMjNkNWU3ZjhhYzEwNDdkOThmZTEwOGQ4 MzIzNzI0YTYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3 MzE0NTU5NzM2NzEyNjcxJnNkYXRhPXZtVW5tM1JsRTRyQkJMRjZvTGxoJTJCJTJGelJlZW9yZldO cmJjenZ5VlY3Y1hJJTNEJnJlc2VydmVkPTA+DQogICAgICAgID4NCg0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExT QGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3RsczxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGlu Zm8lMkZ0bHMmZGF0YT0wMiU3QzAxJTdDQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3QzIz ZDVlN2Y4YWMxMDQ3ZDk4ZmUxMDhkODMyMzcyNGE2JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdj ZDAxMWRiNDclN0MxJTdDMCU3QzYzNzMxNDU1OTczNjcxNzY2MiZzZGF0YT0yckRTTDNhSzMxdzNm WFd2cnFBbUU1ZnJLU1RiYUFCUE5sczlIMlpGQUJVJTNEJnJlc2VydmVkPTA+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0K VExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RsczxodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlz dGluZm8lMkZ0bHMmZGF0YT0wMiU3QzAxJTdDQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3 QzIzZDVlN2Y4YWMxMDQ3ZDk4ZmUxMDhkODMyMzcyNGE2JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzMxNDU1OTczNjcyMjY1MyZzZGF0YT0lMkJ6cldqOXJW NmU0ZXdjJTJCWkp4UzRQUEZnWlJjb2klMkZCMHNkQVFLTVBOZkx3JTNEJnJlc2VydmVkPTA+DQo= --_000_SN6PR00MB0366B0069B49FD37A9D25DB38C720SN6PR00MB0366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3Jh cGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJn aW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1h cmdpbi1sZWZ0Oi41aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjMzNTg4 NTExOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMDUw NDMwMjg4IC0xNDE4OTM0MTg2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIHdyaXR0ZW4sIHRoZSBkb2N1bWVu dCBwcm92aWRlcyBhIGJhc2ljL2dlbmVyYWwgZGVzY3JpcHRpb24gb2YgTUlUTSBwcm94aWVzLiBJ dCBtZW50aW9ucyBzb21lIG9mIHRoZSBpc3N1ZXMgKGNsaWVudCBhdXRoLCBoYW5kbGluZyBvZiAw LVJUVCBhcHBsaWNhdGlvbiBkYXRhLCBzaW5nbGUgcG9pbnQgb2YgZmFpbHVyZSwgdXBkYXRlcy9w YXRjaGVzLCByaXNrcyBvZiBkaXNjbG9zdXJlIG9mIFBJSS9QSEkpLCBidXQNCiBkb2VzIG5vdCBy ZWFsbHkgcHJvdmlkZSBhbHRlcm5hdGl2ZXMgb3Igc3BlY2lmaWMgc29sdXRpb25zLiBJIG9wcG9z ZSBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IGluIGl0cyBjdXJyZW50IHNoYXBlLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Tb21lIHNwZWNpZmljIGlzc3Vlczo8bzpwPjwvbzpwPjwvcD4NCjx1 bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij5UaGUgZG9jdW1lbnQgZG9lcyBub3QgZGVzY3JpYmUgYWx0ZXJuYXRpdmVzIHRvIE1JVE0gcHJv eGllcy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5TZWN0aW9uIDQuMS4yIOKA nEluYm91bmQgcHJvdmlzaW9uaW5n4oCdIGRvZXMgbm90IGRpc2N1c3Mgc2VjdXJpdHkgYW5kIG9w ZXJhdGlvbmFsIGlzc3VlcyBhcm91bmQgc2VydmVyIGtleSBzaGFyaW5nIHdpdGggdGhlIHByb3h5 LiBObyByZWFsIGRpc2N1c3Npb24gb2Ygc2hvcnQtbGl2ZWQgY3JlZHMgYW5kIOKAnGtleWxlc3Pi gJ0NCiBzY2VuYXJpb3MuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+U2VjdGlv biA0LjIg4oCcTWFpbnRhaW4gc2VjdXJpdHkgcG9zdHVyZSBhbmQgbGltaXQgbW9kaWZpY2F0aW9u c+KAnSBzZWVtcyB0byByZWNvbW1lbmQgbW9kaWZpY2F0aW9ucyB0byB0aGUgQ2xpZW50SGVsbG8s IHJhdGhlciB0aGFuIGhhdmluZyB0aGUgcHJveHkgZ2VuZXJhdGUgYSBuZXcgQ2xpZW50SGVsbG8u IFByb3hpZXMNCiBzZW5kaW5nIENsaWVudEhlbGxvcyB0aGV5IGRpZCBub3QgZ2VuZXJhdGUgYXJl IGEgY29tbW9uIGNhdXNlIG9mIGludGVyb3AgaXNzdWVzLjxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPlNlY3Rpb24gNC4yIGFsc28gZXhwbGljaXRseSBhbGxvd3MgY29tcGxldGVs eSBpbnNlY3VyZSBjb25maWd1cmF0aW9uczo8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwcmU+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPlRMUyBwcm94eSBzdGFja3MgTUFZIHByb3ZpZGUgdXNlciBjb25maWd1cmFibGUgb3B0 aW9ucywgc3VjaCBhcyBhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBvcHRpb24gdG8gYWNjZXB0 IHNlbGYtc2lnbmVkIHNlcnZlciBjZXJ0aWZpY2F0ZXMsIGFuIG9wdGlvbiB0byBsZXQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IHRoZSBoYW5kc2hha2UgY29udGludWUgd2l0aCBleHBpcmVkIGJ1dCBv dGhlcndpc2UgdmFsaWQgc2VydmVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBjZXJ0aWZpY2F0ZXMs IGV0Yy7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QW5kcmVpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBUTFMgJmx0O3Rscy1ib3VuY2VzQGlldGYub3Jn Jmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KTmljayBIYXJwZXI8YnI+DQo8Yj5TZW50OjwvYj4g TW9uZGF5LCBKdWx5IDI3LCAyMDIwIDc6MTIgQU08YnI+DQo8Yj5Ubzo8L2I+IEJlbiBTY2h3YXJ0 eiAmbHQ7YmVtYXNjPTQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8 L2I+IEplbiBMaW5rb3ZhICZsdDtmdXJyeTEzQGdtYWlsLmNvbSZndDs7IE5hbmN5IENhbS1XaW5n ZXQgKG5jYW13aW5nKSAmbHQ7bmNhbXdpbmc9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7 OyBPcFNlYyBDaGFpcnMgJmx0O29wc2VjLWNoYWlyc0BpZXRmLm9yZyZndDs7IE9QU0VDICZsdDtv cHNlY0BpZXRmLm9yZyZndDs7IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbRVhU RVJOQUxdIFJlOiBbVExTXSBbT1BTRUNdIENhbGwgRm9yIEFkb3B0aW9uOiBkcmFmdC13YW5nLW9w c2VjLXRscy1wcm94eS1icDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B cyBjdXJyZW50bHkgd3JpdHRlbiwgdGhpcyBkcmFmdCBoYXMgbXVsdGlwbGUgcHJvYmxlbXMuPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWN0aW9uIDQgZGVj aWRlcyBub3QgdG8gcmVwZWF0IHRoZSBQcm90b2NvbCBJbnZhcmlhbnRzIGRlc2NyaWJlZCBpbiBz ZWN0aW9uIDkuMyBvZiBSRkMgODQ0Ni4gSG93ZXZlciwgZnVydGhlciBzZWN0aW9ucyBhcmUgd3Jp dHRlbiBhc3N1bWluZyB0aGF0IGEgcHJveHkgYWN0cyBpbiBhIHdheSBjb250cmFyeSB0byB0aG9z ZSBQcm90b2NvbCBJbnZhcmlhbnRzLiBPbmUgc3VjaCBleGFtcGxlIGlzIHNlY3Rpb24gNC4yDQog aW4gdGhpcyBkcmFmdC4gSXQgZGVzY3JpYmVzIGhvdyBhIHByb3h5IG1pZ2h0IGdlbmVyYXRlIGl0 cyBsaXN0IG9mIGNpcGhlciBzdWl0ZXMgYnkgbW9kaWZ5aW5nIHRoZSBjbGllbnQncyBsaXN0LiBB IHByb3h5IHRoYXQgY29waWVzIHRoZSBjaXBoZXIgc3VpdGVzIGZyb20gdGhlIGNsaWVudC1pbml0 aWF0ZWQgQ2xpZW50SGVsbG8gaW50byBpdHMgb3duIENsaWVudEhlbGxvIGlzIHZpb2xhdGluZyB0 aGUgMXN0IGFuZCAzcmQgcG9pbnRzIG9mIHRoZQ0KIFRMUyAxLjMgUHJvdG9jb2wgSW52YXJpYW50 cy4gRm9yIGEgYmVzdCBwcmFjdGljZXMgZG9jdW1lbnQsIEkgdGhpbmsgaXQgd291bGQgYmUgcmVh c29uYWJsZSB0byByZWl0ZXJhdGUgdGhlIFByb3RvY29sIEludmFyaWFudHMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGFkZGl0aW9uIHRv IHJlaXRlcmF0aW5nIHRoZSBQcm90b2NvbCBJbnZhcmlhbnRzLCBpdCBzaG91bGQgYWxzbyBzdW1t YXJpemUgdGhlIGFkdmljZSBmcm9tIHRoZSBjaXRlZCBwYXBlcnMgU0VDVVJJVFlfSU1QQUNUIGFu ZCBBUFBMSUFOQ0VfQU5BTFlTSVMuIE9uZSBvZiB0aGUgcHJvYmxlbXMgcG9pbnRlZCBvdXQgYnkg dGhvc2UgcGFwZXJzIGlzIHRoYXQgVExTIHByb3hpZXMgd2lsbCBtYWtlIGNvbm5lY3Rpb25zDQog dG8gYSBzZXJ2ZXIgdGhhdCBwcmVzZW50cyBhIGNlcnRpZmljYXRlIHRoZSBjbGllbnQgd291bGRu J3QgYWNjZXB0LCBidXQgYmVjYXVzZSBvZiB0aGUgcHJveHksIHRoZSBjbGllbnQgaXNuJ3QgYXdh cmUgb2YgdGhlIGNlcnRpZmljYXRlIGlzc3Vlcy4gSSBkb24ndCBzZWUgdGhpcyBpc3N1ZSBhZGRy ZXNzZWQgYXQgYWxsIGluIHRoZSBkcmFmdC4gKEEgc2ltaWxhciBpc3N1ZSB3aXRoIHRoZSBzZXJ2 ZXIgc2VsZWN0aW5nIGEgd2VhayBjaXBoZXIgc3VpdGUNCiBpcyBwb3NzaWJseSBpbXBsaWVkIGJ5 IHNlY3Rpb24gNC4yLCBidXQgaXQgaXMgbm90IHNwZWxsZWQgb3V0IHdlbGwuKTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGlzIGRyYWZ0 IGlzIGFkb3B0ZWQsIGl0IG5lZWRzIHRvIHNheSB0aGUgZm9sbG93aW5nIHRoaW5ncywgd2hpY2gg aXQgY3VycmVudGx5IGRvZXNuJ3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0gV2hlbiBhIFRMUyBwcm94eSBnZW5lcmF0ZXMgaXRzIENsaWVu dEhlbGxvLCBpdCBzaG91bGQgYmUgY3JlYXRlZCBpbmRlcGVuZGVudGx5IGZyb20gdGhlIGNsaWVu dC1pbml0aWF0ZWQgQ2xpZW50SGVsbG8uIFRoZSBwcm94eSBNQVkgY2hvb3NlIHRvIG9taXQgZmll bGRzIGZyb20gaXRzIENsaWVudEhlbGxvIGJhc2VkIG9uIHRoZSBjbGllbnQtaW5pdGlhdGVkIENs aWVudEhlbGxvLCBidXQgaXQgTVVTVCBOT1QNCiBhZGQgZmllbGRzIHRvIGl0cyBDbGllbnRIZWxs byBiYXNlZCBvbiB0aGUgY2xpZW50LWluaXRpYXRlZCBDbGllbnRIZWxsby4gVGhpcyBpcyBlZmZl Y3RpdmVseSBhIHJlc3RhdGVtZW50IG9mIHRoZSAxc3QgKGEgY2xpZW50IE1VU1Qgc3VwcG9ydCBh bGwgcGFyYW1ldGVycyBpdCBzZW5kcykgYW5kIDNyZCAoaXQgTVVTVCBnZW5lcmF0ZSBpdHMgb3du IENsaWVudEhlbGxvIGNvbnRhaW5pbmcgb25seSBwYXJhbWV0ZXJzIGl0IHVuZGVyc3RhbmRzKSBw b2ludHMNCiBvZiB0aGUgVExTIDEuMyBQcm90b2NvbCBJbnZhcmlhbnRzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIElmIGEgcHJveHkgY2hv b3NlcyB0byBjb25kaXRpb25hbGx5IHByb3h5IFRMUyBjb25uZWN0aW9ucyBhbmQgbmVlZHMgbW9y ZSBpbmZvcm1hdGlvbiB0aGFuIHdoYXQgaXMgY29udGFpbmVkIGluIHRoZSBjbGllbnQtaW5pdGlh dGVkIENsaWVudEhlbGxvLCB0aGVuIHRoZSBvbmx5IHdheSB0byBtYWtlIHRoYXQgZGVjaXNpb24g aXMgdG8gc2VuZCBpdHMgb3duIENsaWVudEhlbGxvIHRvIHRoZSBzZXJ2ZXIgdGhlDQogY2xpZW50 IGlzIGNvbm5lY3RpbmcgdG8gYW5kIHVzZSBpbmZvcm1hdGlvbiBvYnNlcnZlZCBvbiB0aGF0IGNv bm5lY3Rpb24gdG8gbWFrZSB0aGUgZGVjaXNpb24gdG8gcHJveHkgdGhlIHBlbmRpbmcgY29ubmVj dGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+LSBJZiBhIHByb3h5IGNob29zZXMgdG8gbm90IHByb3h5IHNvbWUgVExTIGNvbm5lY3Rpb25z LCB0aGUgcHJveHkgd2lsbCBmYWlsIG9wZW4uIFRoZSBvbmx5IHdheSB0byBhdm9pZCBmYWlsaW5n IG9wZW4gaXMgdG8gcHJveHkgYWxsIGNvbm5lY3Rpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEp1bCAyNywgMjAyMCBhdCA2 OjMxIEFNIEJlbiBTY2h3YXJ0eiAmbHQ7YmVtYXNjPTxhIGhyZWY9Im1haWx0bzo0MGdvb2dsZS5j b21AZG1hcmMuaWV0Zi5vcmciPjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gY29uY2VybmVkIGFib3V0IHRoaXMgd29yayBoYXBwZW5p bmcgb3V0c2lkZSB0aGUgVExTIHdvcmtpbmcgZ3JvdXAuJm5ic3A7IEZvciBleGFtcGxlLCB0aGUg cXVlc3Rpb24gb2YgcHJvcGVyIGhhbmRsaW5nIG9mIFRMUyBleHRlbnNpb25zIGlzIG5vdCBhZGRy ZXNzZWQgYXQgYWxsIGluIHRoaXMgZHJhZnQsIGFuZCBoYXMgc2lnbmlmaWNhbnQgc2VjdXJpdHkg YW5kIGZ1bmN0aW9uYWxpdHkgaW1wbGljYXRpb25zLiZuYnNwOw0KIFRoZXJlIGFyZSB2YXJpb3Vz IG90aGVyIHRyaWNreSBwcm90b2NvbCBpc3N1ZXMgKGUuZy4gdmVyc2lvbiBuZWdvdGlhdGlvbiwg VExTIDEuMyByZWNvcmQgcGFkZGluZywgVExTIDEuMyAwLVJUVCB2cy4gVExTIDEuMiBGYWxzZSBT dGFydCwgcm91bmQtdHJpcCBkZWFkbG9jayB3aGVuIGJ1ZmZlcnMgZmlsbCwgdGlja2V0IChub24t KXJldXNlLCBjbGllbnQgY2VydGlmaWNhdGUgbGlua2FiaWxpdHkgcHJlLVRMUy0xLjMsIGltcGxp Y2F0aW9ucyBvZg0KIFNBTiBzY29wZSBvZiBzeW50aGVzaXplZCBjZXJ0aWZpY2F0ZXMpIHRoYXQg Y291bGQgYXJpc2UgYW5kIGFyZSBnb2luZyB0byBiZSBkaWZmaWN1bHQgdG8gZ2V0IHJpZ2h0IGlu IGFueSBvdGhlciBXRy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSB0aXRsZSAmcXVvdDtUTFMgUHJveHkgQmVzdCBQcmFjdGljZSZxdW90OyBpbXBsaWVz IHRoYXQgaXQgaXMgcG9zc2libGUgdG8gcHJveHkgVExTIGNvcnJlY3RseSwgYW5kIHRoYXQgdGhp cyBkb2N1bWVudCBpcyB0aGUgbWFpbiBzb3VyY2UgZm9yIGhvdyB0byBkbyBpdC4mbmJzcDsgSSB0 aGluayB0aGUgVExTIFdHIGlzIHRoZSByaWdodCBwbGFjZSB0byBtYWtlIHRob3NlIGp1ZGdtZW50 cy4uJm5ic3A7IEZvciB0aGUgT3BTZWMgZ3JvdXAsIEkNCiB0aGluayBhIG1vcmUmbmJzcDthcHBy b3ByaWF0ZSBkcmFmdCB3b3VsZCZuYnNwO2JlIHNvbWV0aGluZyBsaWtlICZxdW90O1RMUyBJbnRl cmNlcHRpb24gUGl0ZmFsbHMmcXVvdDssIGRvY3VtZW50aW5nIHRoZSBvcGVyYXRpb25hbCBleHBl cmllbmNlIG9uIGZhaWx1cmUgbW9kZXMgb2YgVExTIGludGVyY2VwdGlvbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBKdWwgMjcs IDIwMjAgYXQgODo1NyBBTSBOYW5jeSBDYW0tV2luZ2V0IChuY2Ftd2luZykgJmx0O25jYW13aW5n PTxhIGhyZWY9Im1haWx0bzo0MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPjQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZG9jdW1l bnQgaXMgbm90IGltcG9zaW5nIGFueSBzdGFuZGFyZHMgYnV0IHJhdGhlciBwcm92aWRlIGd1aWRl bGluZXMgZm9yIHRob3NlIGltcGxlbWVudGluZyBUTFMgcHJveGllczsmbmJzcDsgZ2l2ZW4gdGhh dCBwcm94aWVzIHdpbGwgY29udGludWUgdG8gZXhpc3QgSSdtIG5vdCBzdXJlIHdoeSB0aGVyZSBp cyBhIGJlbGllZiB0aGF0IHRoZSBJRVRGIHNob3VsZCBpZ25vcmUgdGhpcy48YnI+DQo8YnI+DQpX YXJtIHJlZ2FyZHMsIE5hbmN5PGJyPg0KPGJyPg0K77u/T24gNy8yNy8yMCwgNToyMCBBTSwgJnF1 b3Q7T1BTRUMgb24gYmVoYWxmIG9mIEJsdW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBNSVRMTCZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9wc2VjLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5vcHNlYy1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1h aWx0bzp1cmlAbGwubWl0LmVkdSIgdGFyZ2V0PSJfYmxhbmsiPnVyaUBsbC5taXQuZWR1PC9hPiZn dDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBJIHN1cHBvcnQgU3RlcGhlbiBhbmQg b3Bwb3NlIGFkb3B0aW9uLiBJTUhPLCB0aGlzIGlzIG5vdCBhIHRlY2hub2xvZ3kgdGhhdCBJRVRG IHNob3VsZCBzdGFuZGFyZGl6ZS48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IE9uIDcv MjUvMjAsIDEwOjA3LCAmcXVvdDtUTFMgb24gYmVoYWxmIG9mIFN0ZXBoZW4gRmFycmVsbCZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+dGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRv OnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUiIHRhcmdldD0iX2JsYW5rIj5zdGVwaGVuLmZhcnJl bGxAY3MudGNkLmllPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IEkgb3Bwb3NlIGFkb3B0aW9uLiBXaGlsZSB0aGVyZSBjb3VsZCBiZSBz b21lIG1pbm9yIGJlbmVmaXQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaW4gZG9j dW1lbnRpbmcgdGhlIHVzZXMgYW5kIGFidXNlcyBzZWVuIHdoZW4gbWl0bSdpbmcgdGxzLDxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJIGRvdWJ0IHRoYXQgdGhlIGVmZm9ydCB0byBl bnN1cmUgYSBiYWxhbmNlZCBkb2N1bWVudCBpcyBhdDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyBhbGwgd29ydGh3aGlsZS4gVGhlIGN1cnJlbnQgZHJhZnQgaXMgdG9vIGZhciBmcm9t IHdoYXQgaXQnZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBuZWVkIHRvIGJlIHRv IGJlIGFkb3B0ZWQuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNlbmQg dG8gSVNFLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTLjxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBPbiAyMy8wNy8yMDIwIDAyOjMwLCBKZW4g TGlua292YSB3cm90ZTo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBPbmUg dGhpbmcgdG8gYWRkIGhlcmU6IHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBoZWFyIGFjdGl2ZSBh bmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyBleHBsaWNpdCBzdXBwb3J0 IG9mIHRoZSBhZG9wdGlvbi4gU28gcGxlYXNlIHNwZWFrIHVwIGlmIHlvdSBiZWxpZXZlPGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgdGhlIGRyYWZ0IGlzIHVzZWZ1bCBhbmQg dGhlIFdHIHNoYWxsIHdvcmsgb24gZ2V0dGluZyBpdCBwdWJsaXNoZWQuPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZndDsgT24gTW9uLCBKdWwgMjAsIDIwMjAgYXQgMzozNSBBTSBSb24gQm9uaWNhPGJyPg0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgJmx0O3Jib25pY2E9PGEgaHJlZj0ibWFpbHRv OjQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40MGp1bmlwZXIu bmV0QGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZndDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsm Z3Q7IEZvbGtzLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0Ozxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm Z3Q7Jmd0OyBUaGlzIGVtYWlsIGJlZ2lucyBhIENhbGwgRm9yIEFkb3B0aW9uIG9uIGRyYWZ0LXdh bmctb3BzZWMtdGxzLXByb3h5LWJwLjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm Z3Q7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmZ3Q7Jmd0OyBQbGVhc2Ugc2VuZCBjb21tZW50cyB0byA8YSBocmVmPSJtYWls dG86b3BzZWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCm9wc2VjQGlldGYub3JnPC9hPiBi eSBBdWd1c3QgMywgMjAyMC48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZn dDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZndDs8YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZndDs8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO1Jvbjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7 Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmZ3Q7Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0 OyBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZndDsmZ3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmZ3Q7IE9QU0VDIG1haWxpbmcgbGlzdDxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86T1BTRUNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5PUFNFQ0BpZXRmLm9yZzwvYT48YnI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYu b3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGb3BzZWMmYW1wO2RhdGE9MDIlN0MwMSU3Q0FuZHJl aS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN0MyM2Q1ZTdmOGFjMTA0N2Q5OGZlMTA4ZDgzMjM3MjRh NiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzczMTQ1NTk3 MzY3MDc2ODAmYW1wO3NkYXRhPVAwUkUzbGxlUFVLUkNwOG9nMUVWbTdHNDVOMVV1aldtWTZhVE9U UkJHVUUlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzZWM8L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgPGJy Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZndDsgLS08YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0 OyBTWSwgSmVuIExpbmtvdmEgYWthIEZ1cnJ5PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQombmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJmd0OyBUTFMgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZndDsgPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPlRMU0BpZXRmLm9yZzwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jmd0OyA8YSBocmVmPSJodHRwczovL25hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8l MkZ0bHMmYW1wO2RhdGE9MDIlN0MwMSU3Q0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN0My M2Q1ZTdmOGFjMTA0N2Q5OGZlMTA4ZDgzMjM3MjRhNiU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3 Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzczMTQ1NTk3MzY3MTI2NzEmYW1wO3NkYXRhPXZtVW5tM1Js RTRyQkJMRjZvTGxoJTJCJTJGelJlZW9yZldOcmJjenZ5VlY3Y1hJJTNEJmFtcDtyZXNlcnZlZD0w IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RsczwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQo8YnI+ DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NClRMUyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmFt MDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3 dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnRscyZhbXA7ZGF0YT0wMiU3QzAxJTdD QW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3QzIzZDVlN2Y4YWMxMDQ3ZDk4ZmUxMDhkODMy MzcyNGE2JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNzMx NDU1OTczNjcxNzY2MiZhbXA7c2RhdGE9MnJEU0wzYUszMXczZlhXdnJxQW1FNWZyS1NUYmFBQlBO bHM5SDJaRkFCVSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UTFNA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYW0wNi5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1h biUyRmxpc3RpbmZvJTJGdGxzJmFtcDtkYXRhPTAyJTdDMDElN0NBbmRyZWkuUG9wb3YlNDBtaWNy b3NvZnQuY29tJTdDMjNkNWU3ZjhhYzEwNDdkOThmZTEwOGQ4MzIzNzI0YTYlN0M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM3MzE0NTU5NzM2NzIyNjUzJmFtcDtz ZGF0YT0lMkJ6cldqOXJWNmU0ZXdjJTJCWkp4UzRQUEZnWlJjb2klMkZCMHNkQVFLTVBOZkx3JTNE JmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN6PR00MB0366B0069B49FD37A9D25DB38C720SN6PR00MB0366namp_-- From nobody Mon Jul 27 12:03: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 C4D103A08C0 for ; Mon, 27 Jul 2020 12:03:43 -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, DKIMWL_WL_HIGH=-0.001, 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 JRbxuWfklRsA for ; Mon, 27 Jul 2020 12:03:41 -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 0D31E3A048D for ; Mon, 27 Jul 2020 12:03:40 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 06RJ2BvZ015253; Mon, 27 Jul 2020 20:03:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=YbyXtjJuTreJMwECndbfe1dbV6+MyUI8ri1p/pEdyfA=; b=SGlYvJ0KyClpavBNeVUDzqINZ6Z5uKghVSu9mxi7vYW7qnM17VNKcUEbfMDhbailJiue cewOlBp36xHxB8l5kBRqezxuTz+TNStXvOcs/NB479xZJxLp49rh0XUuZ7gGzl/cR3EJ wdgJHobUtvjibA8Ni5QjtfQs6WJJUYFSfVXfXA5A2Y0R0xr26v3D+Yc43koniIg395zl n++sIKlIOpavPneMhWS3c6keLJiN0eMbR3n+ho0tRXXeSWJ6ve2iogORZHf5EWC2tdwT LpKzQ/5HOkHjGuuWy2A1Qa1CplInw5vY9zd6Og6JdME8Kp6XW6ANomey2Fm30pxpjouQ fg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 32g9tjp0rn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 20:03:38 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06RIlBpa019407; Mon, 27 Jul 2020 15:03:37 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 32gg2xwp22-1; Mon, 27 Jul 2020 15:03:37 -0400 Received: from akamai.com (sea-lp9yo.kendall.corp.akamai.com [172.19.16.134]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 2A5DA2C309; Mon, 27 Jul 2020 19:03:37 +0000 (GMT) Date: Mon, 27 Jul 2020 12:03:36 -0700 From: Benjamin Kaduk To: Achim Kraus Cc: "tls@ietf.org" Message-ID: <20200727190335.GS20623@akamai.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-27_13:2020-07-27, 2020-07-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 spamscore=0 mlxlogscore=999 suspectscore=0 malwarescore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007270127 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-27_13:2020-07-27, 2020-07-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 mlxlogscore=999 suspectscore=0 priorityscore=1501 adultscore=0 mlxscore=0 bulkscore=0 malwarescore=0 impostorscore=0 phishscore=0 spamscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007270129 Archived-At: Subject: Re: [TLS] draft-ietf-tls-dtls-connection-id-07 / IANA connection_id 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 Jul 2020 19:03:50 -0000 Hi Achim, My apologies for the URL mangling by my corporate spam filter. On Wed, Jul 22, 2020 at 08:53:21AM +0200, Achim Kraus wrote: > Dear list, > > are there any news about the draft-ietf-tls-dtls-connection-id and the > IANA registration of the connection_id? > > According > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtls-2Ddtls-2Dconnection-2Did&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg&s=kAlzAEjg0E4P_Cw7G3afL6NHvcFJpJLl72gJVzBvrJ8&e= the > draft expired on April 23, 2020 and according > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iana.org_assignments_tls-2Dextensiontype-2Dvalues_tls-2Dextensiontype-2Dvalues.xhtml&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg&s=poEk1-YL4mzxACY3b-Ldn9NtcPOSd-ZvDKXJcbQ3Ep0&e= > the assigned value expired on 2020-07-02. There seems to have been some oversight, as this assignment was not included in a report of "early allocations assigning in the next 60 days" that was produced on 2020-06-15. I have asked IANA to investigate (and indicated that this extension's allocation should be renewed). The draft itself is essentially done from the WG's point of view, with just the two PRs you note left to merge. It has been waiting for quite some time for me to perform an AD evaluation and start an IETF Last Call on it; I expect to do so in the next couple weeks. Thanks, Ben > I still very interested in this extension, it makes coap over dtls 1.2 a > very powerful technology for the cloud and NB IoT. > > Currently two pending threats are discussed, see the PRs in > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_dtls-2Dconn-2Did&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg&s=6LWHz8pLHziy_jeL2sXwJnw4Y7gz84VzFUe0ur4RsDg&e= . > > One of both is in my opinion a general one using UDP, several > countermeasures are discussed, including RRC. Let me add, that in my > opinion, it's also about to chose cid for the right use-case, and not > generally. That would mostly eliminated the DDoS threat, if the use-case > doesn't offer an amplification. > The other one requires in my opinion a remark about not using the option > of RFC 6347 to generate an alert on invalid MACs, if the cid is used. > Potentially, if of any interest at all, an additional remark about > AES-CBC, the CID length and "lucky 13" maybe added, though the cid > changes the 13. > > For me this looks much more, that the authors are too busy with other > work and not that this draft doesn't make sense anymore. Therefore I > would appreciate, if the temporary IANA registration for the > connection_id could be extended by an additional year. > > Best regards > Achim Kraus > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=HetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg&s=FbOzAxOPoG1SVAsJCPteFfbyv3RYaOwBj5OuZTxcerk&e= From nobody Mon Jul 27 12:10: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 F0F0B3A0B20; Mon, 27 Jul 2020 12:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=nerd.ninja 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 1ZSj44J968Kh; Mon, 27 Jul 2020 12:10:11 -0700 (PDT) Received: from sender4-of-o56.zoho.com (sender4-of-o56.zoho.com [136.143.188.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F8E3A0B1B; Mon, 27 Jul 2020 12:10:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595877006; cv=none; d=zohomail.com; s=zohoarc; b=S7LtaFbemdYLS80yoI9wtLwHpaixLjmosJqzyH/QPYx+SjvWFjKp6DAJvF9VaXwXX2kwF19/rDLrkeOX8OlmzyDNggsCBjxa36Z7uFb1qU9z2YyUVkYfnnCnJN4/RXcrp+/TdPVbAgOZ3Uv2zvG5SjgZllVuanxnm7dPFy+jYqA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1595877006; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=hBjSPHu6BCu9ENbjTPpscKRBYl7pt1TPKb5A9H0SCHo=; b=VntLRT55DWA2Vp2E+mYK1O0AqeVVRYv3fKepIJqi5i324+CK4Uq2CZUhZiVMH9yzc0pQbWjrFsxo7b2HtDxz3BGaJgMZ+G/Dfa52wCqEqhwMm0Fc/v6401B+usWEEvpVDBaUM8s9V9B2agMXzMVPxXUMVrAeVAhPvzE8U6x/U3g= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=nerd.ninja; spf=pass smtp.mailfrom=r@nerd.ninja; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1595877006; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; bh=hBjSPHu6BCu9ENbjTPpscKRBYl7pt1TPKb5A9H0SCHo=; b=QssZ9KPE/P6bay0rVLgFY5tDCkm8IpjivWdxrhuI180kTgrEallhLsNqEvZBsjf5 9xZI+njlEXqio6wuE3kDRgrCzyq9i4s/zE/4R5+brObJslHdBJFiksuDBZ9TcaR14mA /JIMPkL2d5b7RBfJpLqmNLO9120LAxDJb1CMbR74= Received: from roelofs-mbp.lan (dynamic-acs-24-112-241-136.zoominternet.net [24.112.241.136]) by mx.zohomail.com with SMTPS id 1595877001615625.2498653877881; Mon, 27 Jul 2020 12:10:01 -0700 (PDT) From: Roelof duToit Message-Id: <54986B60-E12B-4E83-AD7B-FC8F2B6F372B@nerd.ninja> Content-Type: multipart/alternative; boundary="Apple-Mail=_16E42D4D-DD46-4B60-99FD-9472F92F1F57" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 27 Jul 2020 15:09:59 -0400 In-Reply-To: Cc: Jen Linkova , OPSEC , "tls@ietf.org" , OpSec Chairs To: Ben Schwartz References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <43A56381-0BA8-4123-A2D5-950FD1EDFC86@cisco.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-ZohoMailClient: External Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 19:10:13 -0000 --Apple-Mail=_16E42D4D-DD46-4B60-99FD-9472F92F1F57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As co-author I support adoption of the draft and appreciate the = feedback. The authors agreed at the time that the OPSEC WG charter would better = match our intention of documenting the BCP for TLS proxies given that = the TLS WG charter places more of an emphasis on the TLS protocol. = Having said that, we do also agree that the TLS WG should be involved. = The recommendation from the TLS WG chairs was to continue in OPSEC and = to cc the TLS WG. --Roelof > On Jul 27, 2020, at 9:30 AM, Ben Schwartz = wrote: >=20 > I'm concerned about this work happening outside the TLS working group. = For example, the question of proper handling of TLS extensions is not = addressed at all in this draft, and has significant security and = functionality implications. There are various other tricky protocol = issues (e.g. version negotiation, TLS 1.3 record padding, TLS 1.3 0-RTT = vs. TLS 1.2 False Start, round-trip deadlock when buffers fill, ticket = (non-)reuse, client certificate linkability pre-TLS-1.3, implications of = SAN scope of synthesized certificates) that could arise and are going to = be difficult to get right in any other WG. >=20 > The title "TLS Proxy Best Practice" implies that it is possible to = proxy TLS correctly, and that this document is the main source for how = to do it. I think the TLS WG is the right place to make those = judgments.. For the OpSec group, I think a more appropriate draft would = be something like "TLS Interception Pitfalls", documenting the = operational experience on failure modes of TLS interception. >=20 > On Mon, Jul 27, 2020 at 8:57 AM Nancy Cam-Winget (ncamwing) = > wrote: > The document is not imposing any standards but rather provide = guidelines for those implementing TLS proxies; given that proxies will = continue to exist I'm not sure why there is a belief that the IETF = should ignore this. >=20 > Warm regards, Nancy >=20 > =EF=BB=BFOn 7/27/20, 5:20 AM, "OPSEC on behalf of Blumenthal, Uri - = 0553 - MITLL" on = behalf of uri@ll.mit.edu > wrote: >=20 > I support Stephen and oppose adoption. IMHO, this is not a = technology that IETF should standardize. >=20 >=20 > On 7/25/20, 10:07, "TLS on behalf of Stephen Farrell" = on behalf of = stephen.farrell@cs.tcd.ie > wrote: >=20 >=20 > I oppose adoption. While there could be some minor benefit > in documenting the uses and abuses seen when mitm'ing tls, > I doubt that the effort to ensure a balanced document is at > all worthwhile. The current draft is too far from what it'd > need to be to be adopted. >=20 > Send to ISE. >=20 > S. >=20 > On 23/07/2020 02:30, Jen Linkova wrote: > > One thing to add here: the chairs would like to hear active = and > > explicit support of the adoption. So please speak up if you = believe > > the draft is useful and the WG shall work on getting it = published. > >=20 > > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica > > > wrote: > >> > >> Folks, > >> > >> > >> > >> This email begins a Call For Adoption on = draft-wang-opsec-tls-proxy-bp. > >> > >> > >> > >> Please send comments to opsec@ietf.org = by August 3, 2020. > >> > >> > >> > >> = Ron > >> > >> > >> > >> > >> Juniper Business Use Only > >> > >> _______________________________________________ > >> OPSEC mailing list > >> OPSEC@ietf.org > >> https://www.ietf.org/mailman/listinfo/opsec = > >=20 > >=20 > >=20 > > -- > > SY, Jen Linkova aka Furry > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls = > >=20 >=20 >=20 > _______________________________________________ > 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 --Apple-Mail=_16E42D4D-DD46-4B60-99FD-9472F92F1F57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = co-author I support adoption of the draft and appreciate the = feedback.

The = authors agreed at the time that the OPSEC WG charter would better match = our intention of documenting the BCP for TLS proxies given that the TLS = WG charter places more of an emphasis on the TLS protocol.  Having = said that, we do also agree that the TLS WG should be involved. =  The recommendation from the TLS WG chairs was to continue in OPSEC = and to cc the TLS WG.

--Roelof


On Jul = 27, 2020, at 9:30 AM, Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:

I'm concerned about this work = happening outside the TLS working group.  For example, the question = of proper handling of TLS extensions is not addressed at all in this = draft, and has significant security and functionality = implications.  There are various other tricky protocol issues (e.g. = version negotiation, TLS 1.3 record padding, TLS 1.3 0-RTT vs. TLS 1.2 = False Start, round-trip deadlock when buffers fill, ticket (non-)reuse, = client certificate linkability pre-TLS-1.3, implications of SAN scope of = synthesized certificates) that could arise and are going to be difficult = to get right in any other WG.

The title "TLS Proxy Best Practice" implies that it is = possible to proxy TLS correctly, and that this document is the main = source for how to do it.  I think the TLS WG is the right place to = make those judgments..  For the OpSec group, I think a = more appropriate draft would be something like "TLS = Interception Pitfalls", documenting the operational experience on = failure modes of TLS interception.

On Mon, Jul = 27, 2020 at 8:57 AM Nancy Cam-Winget (ncamwing) <ncamwing=3D40cisco.com@dmarc.ietf.org> wrote:
The document is not imposing any = standards but rather provide guidelines for those implementing TLS = proxies;  given that proxies will continue to exist I'm not sure = why there is a belief that the IETF should ignore this.

Warm regards, Nancy

=EF=BB=BFOn 7/27/20, 5:20 AM, "OPSEC on behalf of Blumenthal, Uri - 0553 = - MITLL" <opsec-bounces@ietf.org on behalf of uri@ll.mit.edu> wrote:

    I support Stephen and oppose adoption. IMHO, this is not a = technology that IETF should standardize.


    On 7/25/20, 10:07, "TLS on behalf of Stephen Farrell" = <tls-bounces@ietf.org on behalf of stephen.farrell@cs.tcd.ie> wrote:


        I oppose adoption. While there could be some = minor benefit
        in documenting the uses and abuses seen when = mitm'ing tls,
        I doubt that the effort to ensure a balanced = document is at
        all worthwhile. The current draft is too far = from what it'd
        need to be to be adopted.

        Send to ISE.

        S.

        On 23/07/2020 02:30, Jen Linkova wrote:
        > One thing to add here: the chairs would = like to hear active and
        > explicit support of the adoption. So = please speak up if you believe
        > the draft is useful and the WG shall = work on getting it published.
        >
        > On Mon, Jul 20, 2020 at 3:35 AM Ron = Bonica
        > <rbonica=3D40juniper.net@dmarc.ietf.org> wrote:
        >>
        >> Folks,
        >>
        >>
        >>
        >> This email begins a Call For = Adoption on draft-wang-opsec-tls-proxy-bp.
        >>
        >>
        >>
        >> Please send comments to opsec@ietf.org by August 3, 2020.
        >>
        >>
        >>
        >>          =                     =                     =                Ron
        >>
        >>
        >>
        >>
        >> Juniper Business Use Only
        >>
        >> = _______________________________________________
        >> OPSEC mailing list
        >> OPSEC@ietf.org
        >> https://www.ietf.org/mailman/listinfo/opsec
        >
        >
        >
        > --
        > SY, Jen Linkova aka Furry
        >
        > = _______________________________________________
        > 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

= --Apple-Mail=_16E42D4D-DD46-4B60-99FD-9472F92F1F57-- From nobody Mon Jul 27 13:09: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 24CD53A0B9D for ; Mon, 27 Jul 2020 13:09:39 -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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-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 OWFoXrNv-jsa for ; Mon, 27 Jul 2020 13:09:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 E4DCB3A0B78 for ; Mon, 27 Jul 2020 13:09:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1595880571; bh=QzkE+AAxQgVbXP4GkZPaxkF7ICQKcVavpSKL+LZnGeI=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=hdYpay0nfSIEq/KWL20zVWcPP5+K0ZNMTnvQV03qWlHJqan/HZr8FuMV1gJclDjsd pN24UaSglQpjrbSx44XOfo6U8YAd+6Yx6RqcEo6diZlC8davPVr96Vg74/22EmXmsn jgjsu1Vd6hDOmZcF5o5BdLzh/JvUPSpQf8G70zcc= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.45] ([178.2.232.210]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MXXuH-1kI37M2bGR-00Z39I; Mon, 27 Jul 2020 22:09:31 +0200 To: Benjamin Kaduk Cc: "tls@ietf.org" References: <20200727190335.GS20623@akamai.com> From: Achim Kraus Message-ID: Date: Mon, 27 Jul 2020 22:09:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200727190335.GS20623@akamai.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:i3F/rUK6sHSPvnJ36ZvCvXThBmgnEw4lq8SoVd3PIYd40RCk1as AQy78zpY6m+HcsqubesVlGqWWYN+GmKCC+6+X+88BRpuY2mWdbwqPFSpvMTUxrv6UPqBS8o qA8vcQZKlrjWET/iagDENKj+rRCH7QejNuFJZoz5dQPnwT/IVEpBEiJzPCLdF4k1KgOc3Ex 8uJbdA8rWEwky7J0CkpeA== X-UI-Out-Filterresults: notjunk:1;V03:K0:a5nsM2zFsbU=:6R35o+CGE75eJG757BjRwQ bXoE6Gsef6ITSh9V36Fg3ulZTJZ3fMvuSgpoBmqmynxDc4ZA7XpjdSTbQET9jA76Y49/4ypAT K381vG6ZtkHPZuwC3TzLwjXNzyR4QqJ4zOfhGOFi+AF5Ors4Md+/dKOLWr7b+Un8XF/VaG9ng uaVKjpl9JEX7V5j7SLlPpCYLWDe9t+gSvlnrd357MDHR+PTjNXkpvSWTLlgJmJkys/+p4048N 0f4XWksI/UnR1MarB1e0JIr1JiEYTFOJHE6f8qxKJZ83go7u2yXa5qKXQ31ZO8UM8PcXp2td2 5Ro4gSvC74AsP9nBu4GquSfiIOCMHOXWutsFSssUYUE4bPZ0DYRlTe8Rr63O9372TSHZrWsMD uYngCbpYrHy6ZSYx1Ycnk7gcgNggiMlKEjhr3lZi1roQlZ7dR6nqy7YjnoKcMM443G9nAbv6v R1O25QMOaM4jq0M7aUSYYBEofeQc26TL0icwiimZKsORMrWblOJc8+XnBwHhx1u7LfiE5bmmK GWw6IFlJMrJ16I5Ymr14sP686eLeNbASAtm1z5DcuaezBJGQ1h14a2ruCfSr1LRY1ySbs2BSb hX5ZHU1UCnZQ0RMICfdHDUkFeR234PLf5RW0HGa7sTzRv4+xvmhowqy3/1aNQ2WD8J+aEe4n3 q+iu7Re/2TNrXv5r9+P7UkaPmtWVuiMZJbozh3QieuwykdeOYLtil0h/jd/nE/nugtiE+84vL TRF/c5VkKIU2EGtYqdrHSpdIViYdz6hhs1zUSchgmGIG9ha9e406NdnBwhy+7F1mXmjodkJXj RTeEAhNmF3vaj+hDrti7Gxb2VDIK7DZWsXcelOb2hNfNFIHofhFrOPrqfHq14LrrZXZHQAZnC hhNvGCcMM4dLgh2Xm5QxRhfdAaZZrB/STzxepgQ3e7o0OFRxLtplfH2iwoc5kf7Lu4Y/Irzm2 arEm2e8LwBWbWudoh1KvhmEbs7SRnCTe7PX6i68jtYiLv/rCK+WEzanr/OM4+qK5q6SNK9QIG /ovcVUpOXn4Db4iUjiKImUzKK8GKRfYg6HfGTsYPW9gIoqZXutrN2CCqeDvX4iHwI/lObWLFW 4LyUcDhnJTI7EOifiZ4k+7HUSsbJgt0Mi6QeWJVYdL1rbzlu/E/vC/x3jF5uO2meoEqNfjJn5 Km0wljNTdpTcHml3yRvx5KWbrB/hOndPPQhV2TeE/L1E8Qy4ktvPA+/8usYROHG2m4ci780Dc O/kY/9IkHNTclPOmBMMf2u88sWpO8UzBzG86h6Q== Archived-At: Subject: Re: [TLS] draft-ietf-tls-dtls-connection-id-07 / IANA connection_id 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 Jul 2020 20:09:39 -0000 Hello Ben, thanks for your answer and actions. best regards Achim Am 27.07.20 um 21:03 schrieb Benjamin Kaduk: > Hi Achim, > > My apologies for the URL mangling by my corporate spam filter. > > On Wed, Jul 22, 2020 at 08:53:21AM +0200, Achim Kraus wrote: >> Dear list, >> >> are there any news about the draft-ietf-tls-dtls-connection-id and the >> IANA registration of the connection_id? >> >> According >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf= .org_doc_draft-2Dietf-2Dtls-2Ddtls-2Dconnection-2Did&d=3DDwICAg&c=3D96ZbZZ= caMF4w0F4jpN6LZg&r=3DsssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=3DHetqG= KNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg&s=3DkAlzAEjg0E4P_Cw7G3afL6NHvcFJpJL= l72gJVzBvrJ8&e=3D the >> draft expired on April 23, 2020 and according >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.iana.org_ass= ignments_tls-2Dextensiontype-2Dvalues_tls-2Dextensiontype-2Dvalues.xhtml&d= =3DDwICAg&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DsssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4= p1unc7rOhM&m=3DHetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGpyeg&s=3DpoEk1-YL4mz= xACY3b-Ldn9NtcPOSd-ZvDKXJcbQ3Ep0&e=3D >> the assigned value expired on 2020-07-02. > > There seems to have been some oversight, as this assignment was not incl= uded > in a report of "early allocations assigning in the next 60 days" that wa= s produced > on 2020-06-15. I have asked IANA to investigate (and indicated that thi= s > extension's allocation should be renewed). > > The draft itself is essentially done from the WG's point of view, with j= ust > the two PRs you note left to merge. It has been waiting for quite some = time for > me to perform an AD evaluation and start an IETF Last Call on it; I expe= ct to do > so in the next couple weeks. > > Thanks, > > Ben > >> I still very interested in this extension, it makes coap over dtls 1.2 = a >> very powerful technology for the cloud and NB IoT. >> >> Currently two pending threats are discussed, see the PRs in >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_tlswg= _dtls-2Dconn-2Did&d=3DDwICAg&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DsssDLkeEEBWNIX= mTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=3DHetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGp= yeg&s=3D6LWHz8pLHziy_jeL2sXwJnw4Y7gz84VzFUe0ur4RsDg&e=3D . >> >> One of both is in my opinion a general one using UDP, several >> countermeasures are discussed, including RRC. Let me add, that in my >> opinion, it's also about to chose cid for the right use-case, and not >> generally. That would mostly eliminated the DDoS threat, if the use-cas= e >> doesn't offer an amplification. >> The other one requires in my opinion a remark about not using the optio= n >> of RFC 6347 to generate an alert on invalid MACs, if the cid is used. >> Potentially, if of any interest at all, an additional remark about >> AES-CBC, the CID length and "lucky 13" maybe added, though the cid >> changes the 13. >> >> For me this looks much more, that the authors are too busy with other >> work and not that this draft doesn't make sense anymore. Therefore I >> would appreciate, if the temporary IANA registration for the >> connection_id could be extended by an additional year. >> >> Best regards >> Achim Kraus >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_tls&d=3DDwICAg&c=3D96ZbZZcaMF4w0F4jpN6LZg&r=3DsssDLkeEEBWNIX= mTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=3DHetqGKNPLld3ESyjZr6lPT8gnkN8LiIxcivjicGp= yeg&s=3DFbOzAxOPoG1SVAsJCPteFfbyv3RYaOwBj5OuZTxcerk&e=3D From nobody Mon Jul 27 13:32: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 D07AE3A0BB6; Mon, 27 Jul 2020 13:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=nerd.ninja 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 zsm0vWtuV9Dc; Mon, 27 Jul 2020 13:32:23 -0700 (PDT) Received: from sender4-of-o56.zoho.com (sender4-of-o56.zoho.com [136.143.188.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE743A0BAE; Mon, 27 Jul 2020 13:32:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595881942; cv=none; d=zohomail.com; s=zohoarc; b=Kx6nsdIXGp39ohLm0KdXnZo4M6WXhEEoNYFP9r3txzXq37qEsa8/h/BOb0GAC69TvLXIFKwOPT+2AEZ7BA83qOadgpYleMcrfuzZ2XbcMuqMxejmpkOS8K4m2JJiD0kJQ6eTrdznKnntGGtlJTDVAFaTCOSHT3HQPSamqIeJiLU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1595881942; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=0BSEdOkrLoulAegP1zOnaqO+oja5CjqiTy3ulevd3+U=; b=VwyvgOXx55xKHiT4O347XqXlgI1PrmKIgspE9GJEBuIoyEC8xwVFTbDRJ5+dw48zRD1hXfyeSKlkHJrO2k/85aSAyehumvnfS7GwkuVN/XbVnr2QUICrNHWT8Q8rG6J5D236cP9cXIwZD28m24aIcsar6e2//D9dzxA54Cri1fc= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=nerd.ninja; spf=pass smtp.mailfrom=r@nerd.ninja; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1595881942; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; bh=0BSEdOkrLoulAegP1zOnaqO+oja5CjqiTy3ulevd3+U=; b=eKYLZ2W1+9ro8f99SlrwxktUNfdIKCqyhdGvUDnu0gfU3N15pOW1dUvgaEWmzb84 I9u2oIGh9ykAHPMM4iRxw+iSLus90XXg76wfVsv5F5veGKjNivBWpW9eOxK05E/ZQNG m2RuZFANA3YashJ1YINvoKL4VINsLwEy1sRaVf4c= Received: from roelofs-mbp.lan (dynamic-acs-24-112-241-136.zoominternet.net [24.112.241.136]) by mx.zohomail.com with SMTPS id 1595881937101735.0950950715875; Mon, 27 Jul 2020 13:32:17 -0700 (PDT) From: Roelof duToit Message-Id: <0DC7AEF1-9DAA-42B2-9DF7-E8DD4C081020@nerd.ninja> Content-Type: multipart/alternative; boundary="Apple-Mail=_147F458E-1F50-4EB8-B6FA-7DAA36986172" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 27 Jul 2020 16:32:14 -0400 In-Reply-To: Cc: Nick Harper , Ben Schwartz , "Nancy Cam-Winget (ncamwing)" , OpSec Chairs , OPSEC , "tls@ietf.org" To: Andrei Popov References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <43A56381-0BA8-4123-A2D5-950FD1EDFC86@cisco.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-ZohoMailClient: External Archived-At: Subject: Re: [TLS] [OPSEC] [EXTERNAL] Re: Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 20:32:29 -0000 --Apple-Mail=_147F458E-1F50-4EB8-B6FA-7DAA36986172 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you Andrei. > The document does not describe alternatives to MITM proxies. The [SECURITY_IMPACT] paper mentions alternatives, and we could = certainly include a high-level summary of some of those even though our = intention was to document the BCP for TLS proxies where the reader is = considering a TLS proxy network function. If we do include an expanded = section on alternatives then it should also reference the capabilities = and limitations of endpoint-only security solutions (reference: = https://datatracker.ietf.org/doc/html/draft-taddei-smart-cless-introductio= n-03 = ) > Section 4.1.2 =E2=80=9CInbound provisioning=E2=80=9D does not discuss = security and operational issues around server key sharing with the = proxy. No real discussion of short-lived creds and =E2=80=9Ckeyless=E2=80=9D= scenarios. Sections 4.1 and 4.12 provide guidelines and leaves the implementation = up to the developer. That is not to say that we cannot be more specific = about key sharing and key storage for inbound solutions. We could = certainly mention draft-ietf-tls-subcerts as well. > Section 4.2 =E2=80=9CMaintain security posture and limit = modifications=E2=80=9D seems to recommend modifications to the = ClientHello, rather than having the proxy generate a new ClientHello. = Proxies sending ClientHellos they did not generate are a common cause of = interop issues. That section needs more clarification. We are most certainly not = proposing that TLS proxies should forward the original ClientHello and = are aware of the risks - especially when RSA key exchange is used. The = intention of section 4.2 is for the TLS proxy to base certain attributes = of the generated ClientHello on what was advertised by the client, with = the goal of maintaining the security posture. > Section 4.2 also explicitly allows completely insecure configurations: > =E2=80=9CTLS proxy stacks MAY provide user configurable options, = such as an > option to accept self-signed server certificates, an option to let > the handshake continue with expired but otherwise valid server > certificates, etc.=E2=80=9D That paragraph needs examples. One such example is where = device-to-device communication in the enterprise traverses the TLS proxy = and where said devices must be excluded from further inspection based on = a combination of policy attributes - it is not always practical to = update the devices. --Apple-Mail=_147F458E-1F50-4EB8-B6FA-7DAA36986172 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank= you Andrei.

  • The document does not describe alternatives to MITM = proxies.

The [SECURITY_IMPACT] paper mentions alternatives, = and we could certainly include a high-level summary of some of those = even though our intention was to document the BCP for TLS proxies where = the reader is considering a TLS proxy network function.   If we do = include an expanded section on alternatives then it should also = reference the capabilities and limitations of endpoint-only security = solutions (reference: https://datatracker.ietf.org/doc/html/draft-taddei-smart-cless-= introduction-03)

  • Section 4.1.2 = =E2=80=9CInbound provisioning=E2=80=9D does not discuss security and = operational issues around server key sharing with the proxy. No real = discussion of short-lived creds and =E2=80=9Ckeyless=E2=80=9D = scenarios.

Sections 4.1 and 4.12 provide guidelines and = leaves the implementation up to the developer.  That is not to say = that we cannot be more specific about key sharing and key storage for = inbound solutions.   We could certainly = mention draft-ietf-tls-subcerts as well.

  • Section 4.2 =E2=80=9CMaintain security posture and limit = modifications=E2=80=9D seems to recommend modifications to the = ClientHello, rather than having the proxy generate a new ClientHello. = Proxies sending ClientHellos they did not generate are a common cause of = interop issues.

That section needs more clarification.  We = are most certainly not proposing that TLS proxies should forward the = original ClientHello and are aware of the risks - especially when RSA = key exchange is used.  The intention of section 4.2 is for the TLS = proxy to base certain attributes of the generated ClientHello on what was advertised by the = client, with the goal of maintaining the security posture.


  • Section 4.2 also = explicitly allows completely insecure configurations:
      =E2=80=9CTLS proxy stacks MAY provide user configurable options, such =
as an
   option to accept self-signed server = certificates, an option to let
   the handshake continue = with expired but otherwise valid server
   certificates, = etc.=E2=80=9D


That paragraph needs = examples.   One such example is where device-to-device = communication in the enterprise traverses the TLS proxy and where said = devices must be excluded from further inspection based on a combination = of policy attributes - it is not always practical to update the = devices.

= --Apple-Mail=_147F458E-1F50-4EB8-B6FA-7DAA36986172-- From nobody Mon Jul 27 14:21: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 47EA63A07B9; Mon, 27 Jul 2020 14:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DJAL6wFA; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Kp7Gma/0 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 h3vRRy_K0aAv; Mon, 27 Jul 2020 14:21:01 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D7783A07B3; Mon, 27 Jul 2020 14:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34449; q=dns/txt; s=iport; t=1595884861; x=1597094461; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=f2tOI3kjFHG4M1P/wZ6bcsLNiPTEl9Wh5bQXT1ecay0=; b=DJAL6wFAhxAou1rXA4zKpGL26LybjxVcYg1rLKN2isBo7ggkFGknumEr D2U7HfrOGOmKxhwZ4TKF+iiGvpWJkOxssj4AQiPCqiXu21GgqdbQjiZ8Y Sf58CjFBAL7/rAidUE/eUpRZWfGpxx5ym7+yFHXXYFbHsyfakE+Buvz8c k=; IronPort-PHdr: =?us-ascii?q?9a23=3AXGWlzRP3FipJiEyWfjol6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvK8x3lPMVJ/QrfNJl+SQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFHXq2e5qz8fBh?= =?us-ascii?q?u5MhB6daz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0R?= =?us-ascii?q?DO5HBPfrdb?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYCABtRB9f/5BdJa1gHQEBAQEJARI?= =?us-ascii?q?BBQUBggqBIy8jLgdvWC8sCoQqg0YDjTAlmGGBQoERA1ULAQEBDAEBGAEMCAI?= =?us-ascii?q?EAQGETAIXghACJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVyAQEEAQEQCwYdAQE?= =?us-ascii?q?jCQYFAQ8CAQgYIAcDAgICJQsUEQIEDgUigwQBgX5NAy4BDqRVAoE5iGF2gTK?= =?us-ascii?q?DAQEBBYUZGIIOAwaBOIJtg1mGNxqCAIERJwwQgk0+glwBAQIBgScBEgEJBhE?= =?us-ascii?q?YFoJpM4ItjyWDO4ZZi1KPXoEFCoJeiFaRGAMegnuJSJMhk36IRpEWg1YCBAI?= =?us-ascii?q?EBQIOAQEFgWojZ3BwFRohKgGCPj4SFwINjh6DcYUUhUEBdAI1AgYBBwEBAwl?= =?us-ascii?q?8jgIBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,403,1589241600"; d="scan'208,217";a="518095588" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jul 2020 21:21:00 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 06RLKx3s006583 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jul 2020 21:21:00 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 16:20:59 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 16:20:59 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 27 Jul 2020 17:20:59 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LiuaVLBvKmdRKBCOOYeN+tDj09Euhm2nT/X9NzEWI1ZAleYS1kDvcOMTwk8mliwa/W8oqVg70BYo0WQbb6M6AtHFINT80fmEThGmONeVyKJIihuShY8/LW7MBp8ysRZ0Gl6PQ9p8MCN/wMueoxLwFDc9yuDVSN4uHIGCx8lM0sCSEpV3LsMub1wfH4w2UTluUm2+2V4wa9Dh8ZN7eKADo4zXn0MuoVVtis4XXlLmX0iGFfIUa7yfT1SsJvXum80VsGppmvFkF3eF/8YWz9MurTcDwmCRCedPLo1AP/rL6Wrij3dElbFqAbYA7diAalJvR4TL27khyjXCIKQS+fVSIw== 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=f2tOI3kjFHG4M1P/wZ6bcsLNiPTEl9Wh5bQXT1ecay0=; b=hZmNmUAf5/kBYHiZTh+q7gJ9aTX7hKQvIUFQLfJ8qN4osLrIFsYUCorTYxwiAvckiUm06X1igB9Wt2YVFFDncU9ME3RUMa1sZ9vSHE/W70Lwwrw4jJx5BQJrntL08Xm1qsgi+vhOLQNUka6vwkMzTXpIau3oqecnB3ZvXg6qNVjGRJF7ccoudsXfMJnHugS94x+xdv0CNaTc+gbnm6Dy3xsHGgSTHMtZfTorqd+rYiuZRvAWulmIdWH68JtPToEJnow5MMAUjipXqsKYWRmjp7fGS7RMR1aJUbTYiRRYVWIcPOlhWyrU8zRP7naHMxiKSEyjHaw/w9rA0ouqUiftlw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f2tOI3kjFHG4M1P/wZ6bcsLNiPTEl9Wh5bQXT1ecay0=; b=Kp7Gma/0xz8z93h4gxJ9EmcRI8fdXi0+oNj76TjGgKHRHmejvZmeWOhOMyPnE/ulQkdaoeMxkjl5CJnu7vTuR5jsKEUG1qevBgoAChoZ4gHgyuRucvTt/xV50lCk5oBfnZOUcISinvlQB27c0E3xWKHPHaWSYxVlW1uo+WpU/LU= Received: from BYAPR11MB2789.namprd11.prod.outlook.com (2603:10b6:a02:cc::11) by BYAPR11MB3526.namprd11.prod.outlook.com (2603:10b6:a03:88::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.26; Mon, 27 Jul 2020 21:20:57 +0000 Received: from BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870]) by BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870%6]) with mapi id 15.20.3216.033; Mon, 27 Jul 2020 21:20:57 +0000 From: "Eric Wang (ejwang)" To: Nick Harper CC: Ben Schwartz , "Nancy Cam-Winget (ncamwing)" , OpSec Chairs , OPSEC , "tls@ietf.org" Thread-Topic: [OPSEC] [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AQHWZBBX3s7yu2FQsE+4XY6AWPSf36kbYlAAgAAJxoCAAAuNgIAAd96A Date: Mon, 27 Jul 2020 21:20:57 +0000 Message-ID: <5425303E-F86B-4D4C-9496-7F9E089D1BA5@cisco.com> References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <43A56381-0BA8-4123-A2D5-950FD1EDFC86@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.15) authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [128.107.241.182] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1a233038-c5c4-40f4-71ff-08d83272f444 x-ms-traffictypediagnostic: BYAPR11MB3526: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GGwU3PeWZDzgPQ+w6z7pj3VWhJCLVAOm15UjdU15pdF2SNrD1UtUc0BgJqIFyAOj79KYcjQsdmAdlKITMQTKqdCysWnUjh6Kq89bF6Hx7GxsBIegcru+fiBw6HifnfB/NT8ZVzwVSVCuCeVQmKTKXCFLaIm/3EtNE7y1D8p+xqRwiRzTCxIxQVpzGHC93c3jIxZ5/v1hbm0TNX0kBkSC2RyYK2ebkUgVxO51crIZS8Z3n/vuePKoD/zNEdQ6/zEQpd2KlDJpM8QL+GUZFYMS/KOJpZo4tYjNM6o1H1yotYueF5GStQVC6WxU7ad6es23HyoEX0VW2FN4rFyLd89D+MC0gCGd3Vf6aQxHmCdCvPddXlMxYVzMMsRu2Pig/isELZmLDrEUFGqJObkrdEoTmw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2789.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(396003)(39860400002)(346002)(136003)(366004)(4326008)(26005)(76116006)(2906002)(66446008)(66556008)(66476007)(8676002)(64756008)(6512007)(86362001)(66946007)(186003)(8936002)(2616005)(6486002)(166002)(33656002)(54906003)(6506007)(316002)(53546011)(478600001)(36756003)(966005)(83380400001)(71200400001)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: hbbyIHU4xOQLXrsrhRENi3dDkK8M5tEEG3pLvDNN0flxL4j4bPu/LqeDCVRTLtc4M9xNtUICXML/yvpAkz+dUpcTbylcWG5JhR07f6MBg+YAmUlELQwWvXBRnw0xpjFz3lDt+cAfbL8tx82uE3YVTrzT8md05mU1CEkFzyiTyJL0TO7MPe4bSy7d9X/dUgga09nMJBqcAFyudelhbxJfC6uK+PHmP4TOlOp2wdoPxx7YP+Ov+yZe8Kq5yLl7th6DzM1bInWzsQJV8UpZkJLdEMsL+iNuUz/6fxTjVIDfjuLG7WWKPrgbmAM30Px2bc4ALDCtS137DYcBvGVZOANcD5z8MF6U3bLLBOK+2cQk6gV8RYWoMvXHoPJ8kBYQwEF4YFjZXOfMDJg67ZgqEMnH9SlTWP4Jaiy9b+XIuIVfM/n5eFlUyDAT91KvgJndjtQKBZ8jj2krqTM0cmJbUgLg/Hl7ruf/CGK7AmlkEdmT7a4fLxH5OnCuBk1A7Cwur2No Content-Type: multipart/alternative; boundary="_000_5425303EF86B4D4C94967F9E089D1BA5ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2789.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1a233038-c5c4-40f4-71ff-08d83272f444 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 21:20:57.7532 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: br0728Zt4Evnfh8vi/0u/yOwjv2UtA3log+kE62j81Vr97hY7uq+zcjUdMOWEcih7FEVE7Emzy9LRg7guHiS2g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3526 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 21:21:06 -0000 --_000_5425303EF86B4D4C94967F9E089D1BA5ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTmljaywNCg0KTWFueSB0aGFua3MgZm9yIHRoZSBkZXRhaWxlZCBjb21tZW50cy4NCg0KSW4g Z2VuZXJhbCwgdGhlIGRyYWZ0IHRyaWVkIG5vdCB0byByZXBlYXQgdGhlIFRMUyBSRkNzLiAgRnJv bSBzZWN0aW9uIDQuMiwg4oCcQmVjYXVzZSBhIFRMUyBwcm94eSBlZmZlY3RpdmVseSBidWlsZHMg dHdvIFRMUyBzZXNzaW9ucywgb25lIHdpdGggYSBUTFMgY2xpZW50IGFuZCBvbmUgd2l0aCBhIHNl cnZlciByZXNwZWN0aXZlbHksIOKApiBUaGUgVExTIHNlcnZlciBhbmQgY2xpZW50IHN0YWNrcyBp biB0aGUgVExTIHByb3h5IE1VU1QgYmUgY29uZm9ybWFudCB0byBbUkZDODQ0Nl0gYW5kIFtSRkM1 MjQ2XS7igJ0NCg0KSXQgd2FzIHRoZSBpbnRlbnRpb24gd2l0aCBQcm90b2NvbCBJbnZhcmlhbnRz IGFzIHdlbGwsIGJ1dCBpdCBhcHBlYXJzIHRoZSB0ZXh0IGNhdXNlZCBzb21lIGNvbmZ1c2lvbiBp biBTIDQuMi4gV2Ugd2lsbCBjbGFyaWZ5IGl0LCBhbmQgaXQgaXMgd29ydGh3aGlsZSB0byBjYXB0 dXJlIHBvaW50cyBmcm9tIHRoZSBjaXRlZCBwYXBlcnMgdG9vLg0KDQpTZWN0aW9uIDUuMzxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FuZy1vcHNlYy10bHMtcHJveHktYnAtMDAj c2VjdGlvbi01LjM+IGRlc2NyaWJlcyBzZWxlY3RpdmUgZGVjcnlwdGlvbiB3aGljaCBpcyByZWxh dGVkIHRvIHlvdXIgbGFzdCB0d28gcG9pbnRzLiAgV2lsbCB1cGRhdGUgaXQgd2l0aCB5b3VyIGNv bW1lbnRzICh0aGVyZSBhcmUgdGVjaG5pcXVlcyB0byDigJxmYWlsIG9wZW7igJ0gZnJvbSBwcm94 eSBidXQgb25seSBwb3NzaWJsZSBiZWZvcmUgY2VydGFpbiBzdGFnZSBvZiB0aGUgaGFuZHNoYWtl KS4NCg0KQmVzdCwNCi1FcmljDQoNCg0KT24gSnVsIDI3LCAyMDIwLCBhdCA3OjExIEFNLCBOaWNr IEhhcnBlciA8bmhhcnBlcj00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOm5oYXJw ZXI9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQoNCkFzIGN1cnJlbnRseSB3 cml0dGVuLCB0aGlzIGRyYWZ0IGhhcyBtdWx0aXBsZSBwcm9ibGVtcy4NCg0KU2VjdGlvbiA0IGRl Y2lkZXMgbm90IHRvIHJlcGVhdCB0aGUgUHJvdG9jb2wgSW52YXJpYW50cyBkZXNjcmliZWQgaW4g c2VjdGlvbiA5LjMgb2YgUkZDIDg0NDYuIEhvd2V2ZXIsIGZ1cnRoZXIgc2VjdGlvbnMgYXJlIHdy aXR0ZW4gYXNzdW1pbmcgdGhhdCBhIHByb3h5IGFjdHMgaW4gYSB3YXkgY29udHJhcnkgdG8gdGhv c2UgUHJvdG9jb2wgSW52YXJpYW50cy4gT25lIHN1Y2ggZXhhbXBsZSBpcyBzZWN0aW9uIDQuMiBp biB0aGlzIGRyYWZ0LiBJdCBkZXNjcmliZXMgaG93IGEgcHJveHkgbWlnaHQgZ2VuZXJhdGUgaXRz IGxpc3Qgb2YgY2lwaGVyIHN1aXRlcyBieSBtb2RpZnlpbmcgdGhlIGNsaWVudCdzIGxpc3QuIEEg cHJveHkgdGhhdCBjb3BpZXMgdGhlIGNpcGhlciBzdWl0ZXMgZnJvbSB0aGUgY2xpZW50LWluaXRp YXRlZCBDbGllbnRIZWxsbyBpbnRvIGl0cyBvd24gQ2xpZW50SGVsbG8gaXMgdmlvbGF0aW5nIHRo ZSAxc3QgYW5kIDNyZCBwb2ludHMgb2YgdGhlIFRMUyAxLjMgUHJvdG9jb2wgSW52YXJpYW50cy4g Rm9yIGEgYmVzdCBwcmFjdGljZXMgZG9jdW1lbnQsIEkgdGhpbmsgaXQgd291bGQgYmUgcmVhc29u YWJsZSB0byByZWl0ZXJhdGUgdGhlIFByb3RvY29sIEludmFyaWFudHMuDQoNCkluIGFkZGl0aW9u IHRvIHJlaXRlcmF0aW5nIHRoZSBQcm90b2NvbCBJbnZhcmlhbnRzLCBpdCBzaG91bGQgYWxzbyBz dW1tYXJpemUgdGhlIGFkdmljZSBmcm9tIHRoZSBjaXRlZCBwYXBlcnMgU0VDVVJJVFlfSU1QQUNU IGFuZCBBUFBMSUFOQ0VfQU5BTFlTSVMuIE9uZSBvZiB0aGUgcHJvYmxlbXMgcG9pbnRlZCBvdXQg YnkgdGhvc2UgcGFwZXJzIGlzIHRoYXQgVExTIHByb3hpZXMgd2lsbCBtYWtlIGNvbm5lY3Rpb25z IHRvIGEgc2VydmVyIHRoYXQgcHJlc2VudHMgYSBjZXJ0aWZpY2F0ZSB0aGUgY2xpZW50IHdvdWxk bid0IGFjY2VwdCwgYnV0IGJlY2F1c2Ugb2YgdGhlIHByb3h5LCB0aGUgY2xpZW50IGlzbid0IGF3 YXJlIG9mIHRoZSBjZXJ0aWZpY2F0ZSBpc3N1ZXMuIEkgZG9uJ3Qgc2VlIHRoaXMgaXNzdWUgYWRk cmVzc2VkIGF0IGFsbCBpbiB0aGUgZHJhZnQuIChBIHNpbWlsYXIgaXNzdWUgd2l0aCB0aGUgc2Vy dmVyIHNlbGVjdGluZyBhIHdlYWsgY2lwaGVyIHN1aXRlIGlzIHBvc3NpYmx5IGltcGxpZWQgYnkg c2VjdGlvbiA0LjIsIGJ1dCBpdCBpcyBub3Qgc3BlbGxlZCBvdXQgd2VsbC4pDQoNCklmIHRoaXMg ZHJhZnQgaXMgYWRvcHRlZCwgaXQgbmVlZHMgdG8gc2F5IHRoZSBmb2xsb3dpbmcgdGhpbmdzLCB3 aGljaCBpdCBjdXJyZW50bHkgZG9lc24ndC4NCg0KLSBXaGVuIGEgVExTIHByb3h5IGdlbmVyYXRl cyBpdHMgQ2xpZW50SGVsbG8sIGl0IHNob3VsZCBiZSBjcmVhdGVkIGluZGVwZW5kZW50bHkgZnJv bSB0aGUgY2xpZW50LWluaXRpYXRlZCBDbGllbnRIZWxsby4gVGhlIHByb3h5IE1BWSBjaG9vc2Ug dG8gb21pdCBmaWVsZHMgZnJvbSBpdHMgQ2xpZW50SGVsbG8gYmFzZWQgb24gdGhlIGNsaWVudC1p bml0aWF0ZWQgQ2xpZW50SGVsbG8sIGJ1dCBpdCBNVVNUIE5PVCBhZGQgZmllbGRzIHRvIGl0cyBD bGllbnRIZWxsbyBiYXNlZCBvbiB0aGUgY2xpZW50LWluaXRpYXRlZCBDbGllbnRIZWxsby4gVGhp cyBpcyBlZmZlY3RpdmVseSBhIHJlc3RhdGVtZW50IG9mIHRoZSAxc3QgKGEgY2xpZW50IE1VU1Qg c3VwcG9ydCBhbGwgcGFyYW1ldGVycyBpdCBzZW5kcykgYW5kIDNyZCAoaXQgTVVTVCBnZW5lcmF0 ZSBpdHMgb3duIENsaWVudEhlbGxvIGNvbnRhaW5pbmcgb25seSBwYXJhbWV0ZXJzIGl0IHVuZGVy c3RhbmRzKSBwb2ludHMgb2YgdGhlIFRMUyAxLjMgUHJvdG9jb2wgSW52YXJpYW50cy4NCg0KLSBJ ZiBhIHByb3h5IGNob29zZXMgdG8gY29uZGl0aW9uYWxseSBwcm94eSBUTFMgY29ubmVjdGlvbnMg YW5kIG5lZWRzIG1vcmUgaW5mb3JtYXRpb24gdGhhbiB3aGF0IGlzIGNvbnRhaW5lZCBpbiB0aGUg Y2xpZW50LWluaXRpYXRlZCBDbGllbnRIZWxsbywgdGhlbiB0aGUgb25seSB3YXkgdG8gbWFrZSB0 aGF0IGRlY2lzaW9uIGlzIHRvIHNlbmQgaXRzIG93biBDbGllbnRIZWxsbyB0byB0aGUgc2VydmVy IHRoZSBjbGllbnQgaXMgY29ubmVjdGluZyB0byBhbmQgdXNlIGluZm9ybWF0aW9uIG9ic2VydmVk IG9uIHRoYXQgY29ubmVjdGlvbiB0byBtYWtlIHRoZSBkZWNpc2lvbiB0byBwcm94eSB0aGUgcGVu ZGluZyBjb25uZWN0aW9uLg0KDQotIElmIGEgcHJveHkgY2hvb3NlcyB0byBub3QgcHJveHkgc29t ZSBUTFMgY29ubmVjdGlvbnMsIHRoZSBwcm94eSB3aWxsIGZhaWwgb3Blbi4gVGhlIG9ubHkgd2F5 IHRvIGF2b2lkIGZhaWxpbmcgb3BlbiBpcyB0byBwcm94eSBhbGwgY29ubmVjdGlvbnMuDQoNCk9u IE1vbiwgSnVsIDI3LCAyMDIwIGF0IDY6MzEgQU0gQmVuIFNjaHdhcnR6IDxiZW1hc2M9NDBnb29n bGUuY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc+ PiB3cm90ZToNCkknbSBjb25jZXJuZWQgYWJvdXQgdGhpcyB3b3JrIGhhcHBlbmluZyBvdXRzaWRl IHRoZSBUTFMgd29ya2luZyBncm91cC4gIEZvciBleGFtcGxlLCB0aGUgcXVlc3Rpb24gb2YgcHJv cGVyIGhhbmRsaW5nIG9mIFRMUyBleHRlbnNpb25zIGlzIG5vdCBhZGRyZXNzZWQgYXQgYWxsIGlu IHRoaXMgZHJhZnQsIGFuZCBoYXMgc2lnbmlmaWNhbnQgc2VjdXJpdHkgYW5kIGZ1bmN0aW9uYWxp dHkgaW1wbGljYXRpb25zLiAgVGhlcmUgYXJlIHZhcmlvdXMgb3RoZXIgdHJpY2t5IHByb3RvY29s IGlzc3VlcyAoZS5nLiB2ZXJzaW9uIG5lZ290aWF0aW9uLCBUTFMgMS4zIHJlY29yZCBwYWRkaW5n LCBUTFMgMS4zIDAtUlRUIHZzLiBUTFMgMS4yIEZhbHNlIFN0YXJ0LCByb3VuZC10cmlwIGRlYWRs b2NrIHdoZW4gYnVmZmVycyBmaWxsLCB0aWNrZXQgKG5vbi0pcmV1c2UsIGNsaWVudCBjZXJ0aWZp Y2F0ZSBsaW5rYWJpbGl0eSBwcmUtVExTLTEuMywgaW1wbGljYXRpb25zIG9mIFNBTiBzY29wZSBv ZiBzeW50aGVzaXplZCBjZXJ0aWZpY2F0ZXMpIHRoYXQgY291bGQgYXJpc2UgYW5kIGFyZSBnb2lu ZyB0byBiZSBkaWZmaWN1bHQgdG8gZ2V0IHJpZ2h0IGluIGFueSBvdGhlciBXRy4NCg0KVGhlIHRp dGxlICJUTFMgUHJveHkgQmVzdCBQcmFjdGljZSIgaW1wbGllcyB0aGF0IGl0IGlzIHBvc3NpYmxl IHRvIHByb3h5IFRMUyBjb3JyZWN0bHksIGFuZCB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgdGhlIG1h aW4gc291cmNlIGZvciBob3cgdG8gZG8gaXQuICBJIHRoaW5rIHRoZSBUTFMgV0cgaXMgdGhlIHJp Z2h0IHBsYWNlIHRvIG1ha2UgdGhvc2UganVkZ21lbnRzLi4gIEZvciB0aGUgT3BTZWMgZ3JvdXAs IEkgdGhpbmsgYSBtb3JlIGFwcHJvcHJpYXRlIGRyYWZ0IHdvdWxkIGJlIHNvbWV0aGluZyBsaWtl ICJUTFMgSW50ZXJjZXB0aW9uIFBpdGZhbGxzIiwgZG9jdW1lbnRpbmcgdGhlIG9wZXJhdGlvbmFs IGV4cGVyaWVuY2Ugb24gZmFpbHVyZSBtb2RlcyBvZiBUTFMgaW50ZXJjZXB0aW9uLg0KDQpPbiBN b24sIEp1bCAyNywgMjAyMCBhdCA4OjU3IEFNIE5hbmN5IENhbS1XaW5nZXQgKG5jYW13aW5nKSA8 bmNhbXdpbmc9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOjQwY2lzY28uY29tQGRt YXJjLmlldGYub3JnPj4gd3JvdGU6DQpUaGUgZG9jdW1lbnQgaXMgbm90IGltcG9zaW5nIGFueSBz dGFuZGFyZHMgYnV0IHJhdGhlciBwcm92aWRlIGd1aWRlbGluZXMgZm9yIHRob3NlIGltcGxlbWVu dGluZyBUTFMgcHJveGllczsgIGdpdmVuIHRoYXQgcHJveGllcyB3aWxsIGNvbnRpbnVlIHRvIGV4 aXN0IEknbSBub3Qgc3VyZSB3aHkgdGhlcmUgaXMgYSBiZWxpZWYgdGhhdCB0aGUgSUVURiBzaG91 bGQgaWdub3JlIHRoaXMuDQoNCldhcm0gcmVnYXJkcywgTmFuY3kNCg0K77u/T24gNy8yNy8yMCwg NToyMCBBTSwgIk9QU0VDIG9uIGJlaGFsZiBvZiBCbHVtZW50aGFsLCBVcmkgLSAwNTUzIC0gTUlU TEwiIDxvcHNlYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpvcHNlYy1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgdXJpQGxsLm1pdC5lZHU8bWFpbHRvOnVyaUBsbC5taXQuZWR1Pj4gd3Jv dGU6DQoNCiAgICBJIHN1cHBvcnQgU3RlcGhlbiBhbmQgb3Bwb3NlIGFkb3B0aW9uLiBJTUhPLCB0 aGlzIGlzIG5vdCBhIHRlY2hub2xvZ3kgdGhhdCBJRVRGIHNob3VsZCBzdGFuZGFyZGl6ZS4NCg0K DQogICAgT24gNy8yNS8yMCwgMTA6MDcsICJUTFMgb24gYmVoYWxmIG9mIFN0ZXBoZW4gRmFycmVs bCIgPHRscy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZz4gb24g YmVoYWxmIG9mIHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8bWFpbHRvOnN0ZXBoZW4uZmFycmVs bEBjcy50Y2QuaWU+PiB3cm90ZToNCg0KDQogICAgICAgIEkgb3Bwb3NlIGFkb3B0aW9uLiBXaGls ZSB0aGVyZSBjb3VsZCBiZSBzb21lIG1pbm9yIGJlbmVmaXQNCiAgICAgICAgaW4gZG9jdW1lbnRp bmcgdGhlIHVzZXMgYW5kIGFidXNlcyBzZWVuIHdoZW4gbWl0bSdpbmcgdGxzLA0KICAgICAgICBJ IGRvdWJ0IHRoYXQgdGhlIGVmZm9ydCB0byBlbnN1cmUgYSBiYWxhbmNlZCBkb2N1bWVudCBpcyBh dA0KICAgICAgICBhbGwgd29ydGh3aGlsZS4gVGhlIGN1cnJlbnQgZHJhZnQgaXMgdG9vIGZhciBm cm9tIHdoYXQgaXQnZA0KICAgICAgICBuZWVkIHRvIGJlIHRvIGJlIGFkb3B0ZWQuDQoNCiAgICAg ICAgU2VuZCB0byBJU0UuDQoNCiAgICAgICAgUy4NCg0KICAgICAgICBPbiAyMy8wNy8yMDIwIDAy OjMwLCBKZW4gTGlua292YSB3cm90ZToNCiAgICAgICAgPiBPbmUgdGhpbmcgdG8gYWRkIGhlcmU6 IHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBoZWFyIGFjdGl2ZSBhbmQNCiAgICAgICAgPiBleHBs aWNpdCBzdXBwb3J0IG9mIHRoZSBhZG9wdGlvbi4gU28gcGxlYXNlIHNwZWFrIHVwIGlmIHlvdSBi ZWxpZXZlDQogICAgICAgID4gdGhlIGRyYWZ0IGlzIHVzZWZ1bCBhbmQgdGhlIFdHIHNoYWxsIHdv cmsgb24gZ2V0dGluZyBpdCBwdWJsaXNoZWQuDQogICAgICAgID4NCiAgICAgICAgPiBPbiBNb24s IEp1bCAyMCwgMjAyMCBhdCAzOjM1IEFNIFJvbiBCb25pY2ENCiAgICAgICAgPiA8cmJvbmljYT00 MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGp1bmlwZXIubmV0QGRtYXJjLmll dGYub3JnPj4gd3JvdGU6DQogICAgICAgID4+DQogICAgICAgID4+IEZvbGtzLA0KICAgICAgICA+ Pg0KICAgICAgICA+Pg0KICAgICAgICA+Pg0KICAgICAgICA+PiBUaGlzIGVtYWlsIGJlZ2lucyBh IENhbGwgRm9yIEFkb3B0aW9uIG9uIGRyYWZ0LXdhbmctb3BzZWMtdGxzLXByb3h5LWJwLg0KICAg ICAgICA+Pg0KICAgICAgICA+Pg0KICAgICAgICA+Pg0KICAgICAgICA+PiBQbGVhc2Ugc2VuZCBj b21tZW50cyB0byBvcHNlY0BpZXRmLm9yZzxtYWlsdG86b3BzZWNAaWV0Zi5vcmc+IGJ5IEF1Z3Vz dCAzLCAyMDIwLg0KICAgICAgICA+Pg0KICAgICAgICA+Pg0KICAgICAgICA+Pg0KICAgICAgICA+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgUm9uDQogICAgICAgID4+DQogICAgICAgID4+DQogICAgICAgID4+DQogICAgICAg ID4+DQogICAgICAgID4+IEp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCiAgICAgICAgPj4NCiAg ICAgICAgPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CiAgICAgICAgPj4gT1BTRUMgbWFpbGluZyBsaXN0DQogICAgICAgID4+IE9QU0VDQGlldGYub3Jn PG1haWx0bzpPUFNFQ0BpZXRmLm9yZz4NCiAgICAgICAgPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9vcHNlYw0KICAgICAgICA+DQogICAgICAgID4NCiAgICAgICAgPg0K ICAgICAgICA+IC0tDQogICAgICAgID4gU1ksIEplbiBMaW5rb3ZhIGFrYSBGdXJyeQ0KICAgICAg ICA+DQogICAgICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICAgICAgPiBUTFMgbWFpbGluZyBsaXN0DQogICAgICAgID4gVExTQGlldGYub3Jn PG1haWx0bzpUTFNAaWV0Zi5vcmc+DQogICAgICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90bHMNCiAgICAgICAgPg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8 bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdGxzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K VExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9QU0VDIG1haWxpbmcgbGlzdA0KT1BTRUNA aWV0Zi5vcmc8bWFpbHRvOk9QU0VDQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9vcHNlYw0KDQo= --_000_5425303EF86B4D4C94967F9E089D1BA5ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIE5pY2ssDQo8ZGl2IGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5NYW55IHRoYW5rcyBmb3IgdGhlIGRldGFp bGVkIGNvbW1lbnRzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+SW4gZ2VuZXJhbCwgdGhlIGRyYWZ0IHRyaWVkIG5vdCB0byByZXBlYXQg dGhlIFRMUyBSRkNzLiAmbmJzcDtGcm9tIHNlY3Rpb24gNC4yLCDigJxCZWNhdXNlIGEgVExTIHBy b3h5IGVmZmVjdGl2ZWx5IGJ1aWxkcyB0d28gVExTIHNlc3Npb25zLCBvbmUgd2l0aCBhIFRMUyBj bGllbnQgYW5kIG9uZSB3aXRoIGEgc2VydmVyIHJlc3BlY3RpdmVseSwg4oCmIFRoZSBUTFMgc2Vy dmVyIGFuZCBjbGllbnQgc3RhY2tzIGluIHRoZSBUTFMgcHJveHkNCiBNVVNUIGJlIGNvbmZvcm1h bnQgdG8gW1JGQzg0NDZdIGFuZCBbUkZDNTI0Nl0u4oCdPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JdCB3YXMgdGhlIGludGVudGlvbiB3 aXRoIFByb3RvY29sIEludmFyaWFudHMgYXMgd2VsbCwgYnV0IGl0IGFwcGVhcnMgdGhlIHRleHQg Y2F1c2VkIHNvbWUgY29uZnVzaW9uIGluIFMgNC4yLiBXZSB3aWxsIGNsYXJpZnkgaXQsIGFuZCBp dCBpcyB3b3J0aHdoaWxlIHRvIGNhcHR1cmUgcG9pbnRzIGZyb20gdGhlIGNpdGVkIHBhcGVycyB0 b28uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3 bGluZSI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FuZy1v cHNlYy10bHMtcHJveHktYnAtMDAjc2VjdGlvbi01LjMiIGNsYXNzPSIiPlNlY3Rpb24gNS4zPC9h PiZuYnNwO2Rlc2NyaWJlcyBzZWxlY3RpdmUgZGVjcnlwdGlvbiB3aGljaCBpcyByZWxhdGVkIHRv IHlvdXIgbGFzdCB0d28gcG9pbnRzLiAmbmJzcDtXaWxsIHVwZGF0ZSBpdCB3aXRoIHlvdXIgY29t bWVudHMgKHRoZXJlIGFyZSB0ZWNobmlxdWVzIHRvIOKAnGZhaWwgb3BlbuKAnSBmcm9tDQogcHJv eHkgYnV0IG9ubHkgcG9zc2libGUgYmVmb3JlIGNlcnRhaW4gc3RhZ2Ugb2YgdGhlIGhhbmRzaGFr ZSkuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5CZXN0LDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tRXJpYzwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBK dWwgMjcsIDIwMjAsIGF0IDc6MTEgQU0sIE5pY2sgSGFycGVyICZsdDs8YSBocmVmPSJtYWlsdG86 bmhhcnBlcj00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmciIGNsYXNzPSIiPm5oYXJwZXI9NDBn b29nbGUuY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9 IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJs dHIiIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogTHVjaWRh U2Fucy1UeXBld3JpdGVyOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFz cz0iIj4NCkFzIGN1cnJlbnRseSB3cml0dGVuLCB0aGlzIGRyYWZ0IGhhcyBtdWx0aXBsZSBwcm9i bGVtcy4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlNlY3Rpb24gNCBkZWNpZGVzIG5vdCB0byByZXBlYXQgdGhlIFByb3RvY29sIEludmFyaWFudHMg ZGVzY3JpYmVkIGluIHNlY3Rpb24gOS4zIG9mIFJGQyA4NDQ2LiBIb3dldmVyLCBmdXJ0aGVyIHNl Y3Rpb25zIGFyZSB3cml0dGVuIGFzc3VtaW5nIHRoYXQgYSBwcm94eSBhY3RzIGluIGEgd2F5IGNv bnRyYXJ5IHRvIHRob3NlIFByb3RvY29sIEludmFyaWFudHMuIE9uZSBzdWNoIGV4YW1wbGUgaXMg c2VjdGlvbiA0LjIgaW4gdGhpcw0KIGRyYWZ0LiBJdCBkZXNjcmliZXMgaG93IGEgcHJveHkgbWln aHQgZ2VuZXJhdGUgaXRzIGxpc3Qgb2YgY2lwaGVyIHN1aXRlcyBieSBtb2RpZnlpbmcgdGhlIGNs aWVudCdzIGxpc3QuIEEgcHJveHkgdGhhdCBjb3BpZXMgdGhlIGNpcGhlciBzdWl0ZXMgZnJvbSB0 aGUgY2xpZW50LWluaXRpYXRlZCBDbGllbnRIZWxsbyBpbnRvIGl0cyBvd24gQ2xpZW50SGVsbG8g aXMgdmlvbGF0aW5nIHRoZSAxc3QgYW5kIDNyZCBwb2ludHMgb2YgdGhlIFRMUyAxLjMNCiBQcm90 b2NvbCBJbnZhcmlhbnRzLiBGb3IgYSBiZXN0IHByYWN0aWNlcyBkb2N1bWVudCwgSSB0aGluayBp dCB3b3VsZCBiZSByZWFzb25hYmxlIHRvIHJlaXRlcmF0ZSB0aGUgUHJvdG9jb2wgSW52YXJpYW50 cy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkluIGFkZGl0aW9uIHRvIHJlaXRlcmF0aW5nIHRoZSBQcm90b2NvbCBJbnZhcmlhbnRzLCBp dCBzaG91bGQgYWxzbyBzdW1tYXJpemUgdGhlIGFkdmljZSBmcm9tIHRoZSBjaXRlZCBwYXBlcnMg U0VDVVJJVFlfSU1QQUNUIGFuZCBBUFBMSUFOQ0VfQU5BTFlTSVMuIE9uZSBvZiB0aGUgcHJvYmxl bXMgcG9pbnRlZCBvdXQgYnkgdGhvc2UgcGFwZXJzIGlzIHRoYXQgVExTIHByb3hpZXMgd2lsbCBt YWtlIGNvbm5lY3Rpb25zIHRvDQogYSBzZXJ2ZXIgdGhhdCBwcmVzZW50cyBhIGNlcnRpZmljYXRl IHRoZSBjbGllbnQgd291bGRuJ3QgYWNjZXB0LCBidXQgYmVjYXVzZSBvZiB0aGUgcHJveHksIHRo ZSBjbGllbnQgaXNuJ3QgYXdhcmUgb2YgdGhlIGNlcnRpZmljYXRlIGlzc3Vlcy4gSSBkb24ndCBz ZWUgdGhpcyBpc3N1ZSBhZGRyZXNzZWQgYXQgYWxsIGluIHRoZSBkcmFmdC4gKEEgc2ltaWxhciBp c3N1ZSB3aXRoIHRoZSBzZXJ2ZXIgc2VsZWN0aW5nIGEgd2VhayBjaXBoZXIgc3VpdGUNCiBpcyBw b3NzaWJseSBpbXBsaWVkIGJ5IHNlY3Rpb24gNC4yLCBidXQgaXQgaXMgbm90IHNwZWxsZWQgb3V0 IHdlbGwuKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+SWYgdGhpcyBkcmFmdCBpcyBhZG9wdGVkLCBpdCBuZWVkcyB0byBzYXkgdGhlIGZv bGxvd2luZyB0aGluZ3MsIHdoaWNoIGl0IGN1cnJlbnRseSBkb2Vzbid0LjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LSBXaGVuIGEgVExT IHByb3h5IGdlbmVyYXRlcyBpdHMgQ2xpZW50SGVsbG8sIGl0IHNob3VsZCBiZSBjcmVhdGVkIGlu ZGVwZW5kZW50bHkgZnJvbSB0aGUgY2xpZW50LWluaXRpYXRlZCBDbGllbnRIZWxsby4gVGhlIHBy b3h5IE1BWSBjaG9vc2UgdG8gb21pdCBmaWVsZHMgZnJvbSBpdHMgQ2xpZW50SGVsbG8gYmFzZWQg b24gdGhlIGNsaWVudC1pbml0aWF0ZWQgQ2xpZW50SGVsbG8sIGJ1dCBpdCBNVVNUIE5PVCBhZGQg ZmllbGRzDQogdG8gaXRzIENsaWVudEhlbGxvIGJhc2VkIG9uIHRoZSBjbGllbnQtaW5pdGlhdGVk IENsaWVudEhlbGxvLiBUaGlzIGlzIGVmZmVjdGl2ZWx5IGEgcmVzdGF0ZW1lbnQgb2YgdGhlIDFz dCAoYSBjbGllbnQgTVVTVCBzdXBwb3J0IGFsbCBwYXJhbWV0ZXJzIGl0IHNlbmRzKSBhbmQgM3Jk IChpdCBNVVNUIGdlbmVyYXRlIGl0cyBvd24gQ2xpZW50SGVsbG8gY29udGFpbmluZyBvbmx5IHBh cmFtZXRlcnMgaXQgdW5kZXJzdGFuZHMpIHBvaW50cyBvZiB0aGUNCiBUTFMgMS4zIFByb3RvY29s IEludmFyaWFudHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4tIElmIGEgcHJveHkgY2hvb3NlcyB0byBjb25kaXRpb25hbGx5IHByb3h5 IFRMUyBjb25uZWN0aW9ucyBhbmQgbmVlZHMgbW9yZSBpbmZvcm1hdGlvbiB0aGFuIHdoYXQgaXMg Y29udGFpbmVkIGluIHRoZSBjbGllbnQtaW5pdGlhdGVkIENsaWVudEhlbGxvLCB0aGVuIHRoZSBv bmx5IHdheSB0byBtYWtlIHRoYXQgZGVjaXNpb24gaXMgdG8gc2VuZCBpdHMgb3duIENsaWVudEhl bGxvIHRvIHRoZSBzZXJ2ZXIgdGhlIGNsaWVudA0KIGlzIGNvbm5lY3RpbmcgdG8gYW5kIHVzZSBp bmZvcm1hdGlvbiBvYnNlcnZlZCBvbiB0aGF0IGNvbm5lY3Rpb24gdG8gbWFrZSB0aGUgZGVjaXNp b24gdG8gcHJveHkgdGhlIHBlbmRpbmcgY29ubmVjdGlvbi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi0gSWYgYSBwcm94eSBjaG9vc2Vz IHRvIG5vdCBwcm94eSBzb21lIFRMUyBjb25uZWN0aW9ucywgdGhlIHByb3h5IHdpbGwgZmFpbCBv cGVuLiBUaGUgb25seSB3YXkgdG8gYXZvaWQgZmFpbGluZyBvcGVuIGlzIHRvIHByb3h5IGFsbCBj b25uZWN0aW9ucy48L2Rpdj4NCjwvZGl2Pg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogTHVjaWRhU2Fucy1UeXBld3JpdGVyOyBmb250LXNpemU6IDE0 cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEx1Y2lkYVNh bnMtVHlwZXdyaXRlcjsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQo8ZGl2 IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gTW9uLCBKdWwgMjcsIDIwMjAgYXQgNjoz MSBBTSBCZW4gU2Nod2FydHogJmx0O2JlbWFzYz08YSBocmVmPSJtYWlsdG86NDBnb29nbGUuY29t QGRtYXJjLmlldGYub3JnIiBjbGFzcz0iIj40MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+ Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFp bF9xdW90ZSIgc3R5bGU9Im1hcmdpbjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdp ZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJn YigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4NCjxkaXYgZGlyPSJsdHIiIGNs YXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SSdtIGNvbmNlcm5lZCBhYm91dCB0aGlz IHdvcmsgaGFwcGVuaW5nIG91dHNpZGUgdGhlIFRMUyB3b3JraW5nIGdyb3VwLiZuYnNwOyBGb3Ig ZXhhbXBsZSwgdGhlIHF1ZXN0aW9uIG9mIHByb3BlciBoYW5kbGluZyBvZiBUTFMgZXh0ZW5zaW9u cyBpcyBub3QgYWRkcmVzc2VkIGF0IGFsbCBpbiB0aGlzIGRyYWZ0LCBhbmQgaGFzIHNpZ25pZmlj YW50IHNlY3VyaXR5IGFuZCBmdW5jdGlvbmFsaXR5IGltcGxpY2F0aW9ucy4mbmJzcDsNCiBUaGVy ZSBhcmUgdmFyaW91cyBvdGhlciB0cmlja3kgcHJvdG9jb2wgaXNzdWVzIChlLmcuIHZlcnNpb24g bmVnb3RpYXRpb24sIFRMUyAxLjMgcmVjb3JkIHBhZGRpbmcsIFRMUyAxLjMgMC1SVFQgdnMuIFRM UyAxLjIgRmFsc2UgU3RhcnQsIHJvdW5kLXRyaXAgZGVhZGxvY2sgd2hlbiBidWZmZXJzIGZpbGws IHRpY2tldCAobm9uLSlyZXVzZSwgY2xpZW50IGNlcnRpZmljYXRlIGxpbmthYmlsaXR5IHByZS1U TFMtMS4zLCBpbXBsaWNhdGlvbnMgb2YNCiBTQU4gc2NvcGUgb2Ygc3ludGhlc2l6ZWQgY2VydGlm aWNhdGVzKSB0aGF0IGNvdWxkIGFyaXNlIGFuZCBhcmUgZ29pbmcgdG8gYmUgZGlmZmljdWx0IHRv IGdldCByaWdodCBpbiBhbnkgb3RoZXIgV0cuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgdGl0bGUgJnF1b3Q7VExTIFByb3h5IEJlc3QgUHJh Y3RpY2UmcXVvdDsgaW1wbGllcyB0aGF0IGl0IGlzIHBvc3NpYmxlIHRvIHByb3h5IFRMUyBjb3Jy ZWN0bHksIGFuZCB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgdGhlIG1haW4gc291cmNlIGZvciBob3cg dG8gZG8gaXQuJm5ic3A7IEkgdGhpbmsgdGhlIFRMUyBXRyBpcyB0aGUgcmlnaHQgcGxhY2UgdG8g bWFrZSB0aG9zZSBqdWRnbWVudHMuLiZuYnNwOyBGb3IgdGhlIE9wU2VjIGdyb3VwLCBJIHRoaW5r DQogYSBtb3JlJm5ic3A7YXBwcm9wcmlhdGUgZHJhZnQgd291bGQmbmJzcDtiZSBzb21ldGhpbmcg bGlrZSAmcXVvdDtUTFMgSW50ZXJjZXB0aW9uIFBpdGZhbGxzJnF1b3Q7LCBkb2N1bWVudGluZyB0 aGUgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZSBvbiBmYWlsdXJlIG1vZGVzIG9mIFRMUyBpbnRlcmNl cHRpb24uPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBNb24sIEp1bCAyNywg MjAyMCBhdCA4OjU3IEFNIE5hbmN5IENhbS1XaW5nZXQgKG5jYW13aW5nKSAmbHQ7bmNhbXdpbmc9 PGEgaHJlZj0ibWFpbHRvOjQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayIgY2xhc3M9IiI+NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9 Im1hcmdpbjogMHB4IDBweCAwcHggMC44ZXg7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRl ci1sZWZ0LXN0eWxlOiBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIwNCwgMjA0 KTsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4NClRoZSBkb2N1bWVudCBpcyBub3QgaW1wb3NpbmcgYW55 IHN0YW5kYXJkcyBidXQgcmF0aGVyIHByb3ZpZGUgZ3VpZGVsaW5lcyBmb3IgdGhvc2UgaW1wbGVt ZW50aW5nIFRMUyBwcm94aWVzOyZuYnNwOyBnaXZlbiB0aGF0IHByb3hpZXMgd2lsbCBjb250aW51 ZSB0byBleGlzdCBJJ20gbm90IHN1cmUgd2h5IHRoZXJlIGlzIGEgYmVsaWVmIHRoYXQgdGhlIElF VEYgc2hvdWxkIGlnbm9yZSB0aGlzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldhcm0g cmVnYXJkcywgTmFuY3k8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQrvu79PbiA3LzI3LzIw LCA1OjIwIEFNLCAmcXVvdDtPUFNFQyBvbiBiZWhhbGYgb2YgQmx1bWVudGhhbCwgVXJpIC0gMDU1 MyAtIE1JVExMJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86b3BzZWMtYm91bmNlc0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPm9wc2VjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PHNw YW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm9uIGJlaGFsZiBv ZjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVm PSJtYWlsdG86dXJpQGxsLm1pdC5lZHUiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj51cmlAbGwu bWl0LmVkdTwvYT4mZ3Q7DQogd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5i c3A7ICZuYnNwOyBJIHN1cHBvcnQgU3RlcGhlbiBhbmQgb3Bwb3NlIGFkb3B0aW9uLiBJTUhPLCB0 aGlzIGlzIG5vdCBhIHRlY2hub2xvZ3kgdGhhdCBJRVRGIHNob3VsZCBzdGFuZGFyZGl6ZS48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7IE9u IDcvMjUvMjAsIDEwOjA3LCAmcXVvdDtUTFMgb24gYmVoYWxmIG9mIFN0ZXBoZW4gRmFycmVsbCZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+dGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm9uIGJlaGFsZiBvZjxzcGFuIGNsYXNzPSJB cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c3RlcGhl bi5mYXJyZWxsQGNzLnRjZC5pZSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPnN0ZXBoZW4uZmFy cmVsbEBjcy50Y2QuaWU8L2E+Jmd0Ow0KIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJIG9wcG9zZSBh ZG9wdGlvbi4gV2hpbGUgdGhlcmUgY291bGQgYmUgc29tZSBtaW5vciBiZW5lZml0PGJyIGNsYXNz PSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGluIGRvY3VtZW50aW5nIHRoZSB1c2Vz IGFuZCBhYnVzZXMgc2VlbiB3aGVuIG1pdG0naW5nIHRscyw8YnIgY2xhc3M9IiI+DQombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSSBkb3VidCB0aGF0IHRoZSBlZmZvcnQgdG8gZW5zdXJlIGEg YmFsYW5jZWQgZG9jdW1lbnQgaXMgYXQ8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgYWxsIHdvcnRod2hpbGUuIFRoZSBjdXJyZW50IGRyYWZ0IGlzIHRvbyBmYXIgZnJv bSB3aGF0IGl0J2Q8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbmVl ZCB0byBiZSB0byBiZSBhZG9wdGVkLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTZW5kIHRvIElTRS48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUy48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgT24gMjMvMDcvMjAyMCAwMjoz MCwgSmVuIExpbmtvdmEgd3JvdGU6PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZndDsgT25lIHRoaW5nIHRvIGFkZCBoZXJlOiB0aGUgY2hhaXJzIHdvdWxkIGxpa2Ug dG8gaGVhciBhY3RpdmUgYW5kPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZndDsgZXhwbGljaXQgc3VwcG9ydCBvZiB0aGUgYWRvcHRpb24uIFNvIHBsZWFzZSBzcGVh ayB1cCBpZiB5b3UgYmVsaWV2ZTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmZ3Q7IHRoZSBkcmFmdCBpcyB1c2VmdWwgYW5kIHRoZSBXRyBzaGFsbCB3b3JrIG9uIGdl dHRpbmcgaXQgcHVibGlzaGVkLjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IE9uIE1vbiwg SnVsIDIwLCAyMDIwIGF0IDM6MzUgQU0gUm9uIEJvbmljYTxiciBjbGFzcz0iIj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7ICZsdDtyYm9uaWNhPTxhIGhyZWY9Im1haWx0bzo0MGp1 bmlwZXIubmV0QGRtYXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+NDBqdW5p cGVyLm5ldEBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OyBGb2xrcyw8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJmd0OyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJmd0OyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jmd0OyZndDsgVGhpcyBlbWFpbCBiZWdpbnMgYSBDYWxsIEZvciBBZG9wdGlvbiBvbiBkcmFmdC13 YW5nLW9wc2VjLXRscy1wcm94eS1icC48YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJmd0OyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJmd0OyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0 OyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZndDsg UGxlYXNlIHNlbmQgY29tbWVudHMgdG88c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm9wc2VjQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayIgY2xhc3M9IiI+b3BzZWNAaWV0Zi5vcmc8L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmJ5IEF1Z3VzdCAzLCAyMDIwLjxiciBjbGFzcz0iIj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmZ3Q7Jmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7Um9uPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZndDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZn dDsmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmZ3Q7 PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsmZ3Q7IEp1bmlw ZXIgQnVzaW5lc3MgVXNlIE9ubHk8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJmd0OyZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmd0OyZndDsgT1BTRUMg bWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZn dDsmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxh IGhyZWY9Im1haWx0bzpPUFNFQ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPk9Q U0VDQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2VjIiBy ZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2VjPC9hPjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm Z3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBj bGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PHNwYW4gY2xhc3M9IkFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCiZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7IC0tPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZndDsgU1ksIEplbiBMaW5rb3ZhIGFrYSBGdXJyeTxiciBjbGFzcz0iIj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDsgVExT IG1haWxpbmcgbGlzdDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm Z3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5UTFNAaWV0 Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZndDs8 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHJlbD0ibm9yZWZlcnJl ciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGxzPC9hPjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmZ3Q7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi ciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KVExTIG1haWxp bmcgbGlzdDxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIiBjbGFzcz0iIj5UTFNAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJl Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHJlbD0ibm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGxzPC9hPjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi ciBjbGFzcz0iIj4NClRMUyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWls dG86VExTQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+VExTQGlldGYub3JnPC9h PjxiciBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGxzIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogTHVjaWRhU2Fucy1UeXBld3JpdGVyOyBmb250LXNpemU6IDE0cHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IEx1Y2lkYVNhbnMtVHlwZXdyaXRlcjsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxl dHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBu b25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1mYW1pbHk6IEx1Y2lkYVNhbnMtVHlwZXdyaXRlcjsgZm9udC1zaXplOiAxNHB4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBj bGFzcz0iIj5PUFNFQw0KIG1haWxpbmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBMdWNpZGFTYW5zLVR5cGV3cml0ZXI7IGZvbnQt c2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRv Ok9QU0VDQGlldGYub3JnIiBzdHlsZT0iZm9udC1mYW1pbHk6IEx1Y2lkYVNhbnMtVHlwZXdyaXRl cjsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9y cGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5PUFNFQ0BpZXRmLm9yZzwvYT48YnIgc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBMdWNpZGFTYW5zLVR5cGV3 cml0ZXI7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNlYyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBMdWNpZGFTYW5zLVR5cGV3cml0ZXI7IGZvbnQtc2l6ZTogMTRweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNlYzwvYT48L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_5425303EF86B4D4C94967F9E089D1BA5ciscocom_-- From nobody Mon Jul 27 16: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 77B8F3A0475; Mon, 27 Jul 2020 16:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=CUdJzx4q; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vwuA6ywe 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 laCC-6ni-8tO; Mon, 27 Jul 2020 16:48:50 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961563A045B; Mon, 27 Jul 2020 16:48:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6636; q=dns/txt; s=iport; t=1595893730; x=1597103330; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=pwohvGD9IWMSV52fL47hvxgr51Q3GW0FI9D/+WN6LT0=; b=CUdJzx4qiu+0XfDmhw+CqPHRsk7T/+67kAQtTZ6G2oODvn1MY1G735UO ErFR+kxjpe7O5N8e5LK/gbFcgCEJmj3hUlmpPQ0I1m5Sy4qzgWWgLCPob i/wV6YHE9fUmbdG/YrbgL+yw1sj42dzlQe33PMx9SAP9e7tfk8yCDZSM3 s=; IronPort-PHdr: =?us-ascii?q?9a23=3A7hGHthH0oK8XBcUM7nXdY51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401gObUYDS8fkCiufKvebnQ2NTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBrni79zVUGx?= =?us-ascii?q?jjO0xyPOumUoLXht68gua1/ZCbag5UhT27NLV1Khj+rQjYusQMx4V4LaNkwR?= =?us-ascii?q?rSqXwOcONTlm4=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CoAAA6Zx9f/4YNJK1gHQEBAQEJARI?= =?us-ascii?q?BBQUBQIE3BwELAYEiL1EHb1gvLAqHcAOhTIRsgS6BJQNVCwEBAQwBARgBCgo?= =?us-ascii?q?CBAEBhEwCgicCJDUIDgIDAQELAQEFAQEBAgEGBG2FXAyFcgIEAQEQCyMBASw?= =?us-ascii?q?LAQ8CAQg/BycLFBECBA4FIoMEAYF+TQMtAQEOpGQCgTmIYXSBNIMBAQEFhS8?= =?us-ascii?q?Ygg4DBoE4AYJshgyEBBqCAIE4HIJNPoJcAQECggqDHIItkiMBhxWLUpBjCoJ?= =?us-ascii?q?emW4DHp9krVqDVgIEAgQFAg4BAQWBVQE3gVdwFTsqAYI+PhIXAg2OHoNxhRS?= =?us-ascii?q?FQnQCNQIGCAEBAwl8jgIBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,404,1589241600"; d="scan'208,217";a="518619441" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jul 2020 23:48:49 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 06RNmn6X019318 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 27 Jul 2020 23:48:49 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 18:48:49 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 27 Jul 2020 18:48:49 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 27 Jul 2020 19:48:48 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jjwYLTgRK30Upm7/AqyV1VfR8+OTwQj+PkmOGw+eBwD6oi4Ce9fLOSBxkznJZFio3e9q40ZE0iaM6DiOqMKyWv9mMbkPFMXap+ZrUwgV39OOWv/EVndU0lg4EoohIQ89ml2iO1xEjNxfWAOZD8x42dzzQqO+c0cX0EDAHJzMSjFBRz3cIsl2OoJ72eqTiezE6iSbLZXcH6Fvwy3mcGBvXtv5CQ5K9fPDnVRBxuEq98OzviZKzjYkMaBg4QgkZbd5Hxeqz2NRfGmruE6DDQ2zA5Y0fwf8Nhx8Y+0K72YBWRI5nxXsV5H1rBTdCXo2YuQHh4Xg7LnpRkXrxA/Wa8A53A== 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=Gb4mzWzF+nBKYWgFwM8QQOyBJhSJ+PF3Ut2FkwQXglI=; b=CIcvKL4a5kinqCoXBm4UxRykvrAb+mgHQ5ejxiIBMF4uvV4vmGQF6Uuqt+ugBN2h0/q0tbRPu37VMLNaQxritJPthy4lr9OmzJ94PwfDET+nnTMAeFzw48CXy8PZQB/vfHOFi7lGL5ndwAohjW5lHKfiBbye2PGXTmb3XnP6gNf1HT7wpVzJELrGdz3wXUAP7kvxkwvhmsaxqZDlHS9vuE4vJQueBc3bZGnLHps3qo6fwMgdRPNWDzulIjOqVmbxyZ62x+8i8E7toW2jNlm/6aX5QJbcd+7/kajJg1GgRJ5I0Z3FsDJ3PL7sJ74sIsYCUX7/wM3eLEuEpuB2I8EWcQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Gb4mzWzF+nBKYWgFwM8QQOyBJhSJ+PF3Ut2FkwQXglI=; b=vwuA6ywe2vJp2XYdbT7PGhy78kMnw+fEP8f+ISJC/BgoLAWBXUM2lVXhD4dV+QATE/Dm1pxvxIeo4xBAbw+q5/ndOPY4nGwi7uLRGsqgptTMcwsNeU89175N9IcRnrOliwDVd73BpZxPdf/o9ouOul3pPQ8qlRaFvSN1MYWl0Qk= Received: from BYAPR11MB2789.namprd11.prod.outlook.com (2603:10b6:a02:cc::11) by BYAPR11MB3781.namprd11.prod.outlook.com (2603:10b6:a03:b1::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20; Mon, 27 Jul 2020 23:48:48 +0000 Received: from BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870]) by BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870%6]) with mapi id 15.20.3216.033; Mon, 27 Jul 2020 23:48:48 +0000 From: "Eric Wang (ejwang)" To: "Salz, Rich" CC: Ira McDonald , "Blumenthal, Uri - 0553 - MITLL" , OPSEC , OpSec Chairs , "tls@ietf.org" Thread-Topic: [OPSEC] [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AQHWZBBX3s7yu2FQsE+4XY6AWPSf36kbWk4AgAAC3gCAALuiAA== Date: Mon, 27 Jul 2020 23:48:47 +0000 Message-ID: <25CD4A36-5BE5-4B70-ACA7-04494C017D9D@cisco.com> References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <411590AE-EEA6-41EE-B0C8-CC1E0C05F1CE@akamai.com> In-Reply-To: <411590AE-EEA6-41EE-B0C8-CC1E0C05F1CE@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.15) authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [171.68.244.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3e832567-1ba5-4984-c304-08d832879b61 x-ms-traffictypediagnostic: BYAPR11MB3781: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IXWPdijTWCKJGfjr7wURldzMyUbRruy/q6D73mAG8LmKnBUjuGBRWYRUnzlZhNl3m4fPLbezk88memQg6eV/Go2sIgjeEx+IFDFdTpEmKziZKTCd/Oymmc9d3aWdUjzfbrgh4rANVM6Z+HZapiOQEDfzY5SZ+Jk6SkAJDpG/JzkrXrWc5MwYByTtDPU5M9Fe2Nv4gRB8EkDPKNa4DgJPYexrMxstSyTPL6Yn3CGHi1m8x9xEMsLq4rxFWccXihcc/o9EjIktom74RWONpaaaNyvd3SG/6m+iiWDUNg7J9UKBoXy/8+VZVzqrRAW/q7vtO+vUgCn7TkBbrGPXYuKYxxA31ar/euDUd0hx2CNOP80e7bosmc4i75/Q5BwGGjGkBkPboxUo6Iar3Zog4s/Qug== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2789.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(136003)(376002)(346002)(396003)(64756008)(86362001)(36756003)(76116006)(5660300002)(2616005)(66476007)(71200400001)(66446008)(66556008)(91956017)(8936002)(478600001)(4744005)(6486002)(66946007)(2906002)(166002)(53546011)(316002)(83380400001)(8676002)(6506007)(6512007)(966005)(26005)(186003)(54906003)(33656002)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: UZmJF1TjNHlhuO/4SUFCvz7DOpxjHhBcdLzD5SrSqiA665rrtgRwlVc4Tzd4VveQjOJ1tdw/iGhT3K92Lc9lytr7AndYetoaN7r1fRH3qdWFdUoWTC1dUY1S4XuTj+s6qWzZ7dQHumnyg40i+jKTu4QBGzACqkRpc8sBfD0XLEGz1gVHg6/XKJ6Ke6MWEWrBmDzxWMHtBnrz0Nlz2ZTNR+cZNeaLzOOX6d5WRXHQQwxwnALWceSKHw+11rk8qiZLDGcfy34pn3FVHI317bcni1CM4XJUe6XdVU7dYQtH1dxh7GGJdqh965NWjHJJ08mhQjCQAP/pycOlLHZWQEitZaCu68T3b7ZIRyjuEGdgJzY27MpA2EMjPJzUkbnovJRFYCBsCqiTJmHeLE9uiGaV//CHEobMMHjujP1sFzKEjJZazuwIf9h3ZEymV3KBkXABpF7oU3lqC3CY6XV2PkQvL6O5Cb7hHzG12/fURzT29Ug= Content-Type: multipart/alternative; boundary="_000_25CD4A365BE54B70ACA704494C017D9Dciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2789.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3e832567-1ba5-4984-c304-08d832879b61 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 23:48:47.9135 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uc0iX2zDzktFt6+Jwj8j49gjtvnVTC9UnWM1M5LlLgnzLMXwjsdcJ7KKwHk8mLfL3lUVem0ed9hhkZPeAJzxvg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3781 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 23:48:54 -0000 --_000_25CD4A365BE54B70ACA704494C017D9Dciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks you Rich. Obviously I support the adoption as one of the authors. B= ut more importantly, the reality of growing TLS proxy was the driver for st= arting the draft. That has been a sidecar with the progression of TLS and = its wide deployment. We felt the lack of a baseline bcp is going to hurt t= he security posture of TLS rather than driving the intermediary away. Best, -Eric On Jul 27, 2020, at 5:37 AM, Salz, Rich > wrote: Not adopting this seems to be ignoring reality. There are places which use = TLS intermediaries. Are those users not welcome here? I support adoption. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec --_000_25CD4A365BE54B70ACA704494C017D9Dciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <39AC42A5817941488325BE229196B206@namprd11.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Thanks you Rich.  Obviously I support the adoption as one of the autho= rs. But more importantly, the reality of growing TLS proxy was the driver f= or starting the draft.  That has been a sidecar with the progression of TLS and its wide deployment.  We felt the lack of a baseline bcp i= s going to hurt the security posture of TLS rather than driving the interme= diary away.

Best,
-Eric

On Jul 27, 2020, at 5:37 AM, Salz, Rich <rsalz=3D40akamai.com@dma= rc.ietf.org> wrote:

Not adopting this seems to be ignoring reality. There are places which use = TLS intermediaries. Are those users not welcome here?=
 
I support adoption.
_______________________________________________ OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinf= o/opsec

--_000_25CD4A365BE54B70ACA704494C017D9Dciscocom_-- From nobody Mon Jul 27 17:35: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 A91CD3A088A; Mon, 27 Jul 2020 17:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-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=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 6uBHLP8v3Rtp; Mon, 27 Jul 2020 17:35:53 -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 58D7E3A0870; Mon, 27 Jul 2020 17:35:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1A2F4BE2F; Tue, 28 Jul 2020 01:35:51 +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 lOAf4QaRTTvh; Tue, 28 Jul 2020 01:35:49 +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 5A9ECBE2E; Tue, 28 Jul 2020 01:35:49 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1595896549; bh=WiVN1SH1zkl3dLDeTQokqwh6lbQmS+50gCnBGHtuQDk=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=MnQDBbJ8k3fPrSjI0nhDjze2vDT4ZTi82QptN0siDdaVur7Up4BDu3LAGyukVIRTU nRFCc2lZyVgAg63RWb9MIdPggi/c2E+z9ZebwSo4tLCVk0W+az3OqueRHAWiDnlGD2 JQN3U5F9rXNz/M/8QRbHI/N83+O7hDr0g9ZvcRzc= To: "Eric Wang (ejwang)" , "Salz, Rich" Cc: OPSEC , OpSec Chairs , "tls@ietf.org" References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <411590AE-EEA6-41EE-B0C8-CC1E0C05F1CE@akamai.com> <25CD4A36-5BE5-4B70-ACA7-04494C017D9D@cisco.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: Tue, 28 Jul 2020 01:35:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <25CD4A36-5BE5-4B70-ACA7-04494C017D9D@cisco.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ppSaYg5G649FbAICruxMDiop5NyMwqaEx" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 00:35:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ppSaYg5G649FbAICruxMDiop5NyMwqaEx Content-Type: multipart/mixed; boundary="aRTdMWvxoR9yhuCU9uzH8d3bkLnfjhaS7"; protected-headers="v1" From: Stephen Farrell To: "Eric Wang (ejwang)" , "Salz, Rich" Cc: OPSEC , OpSec Chairs , "tls@ietf.org" Message-ID: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <411590AE-EEA6-41EE-B0C8-CC1E0C05F1CE@akamai.com> <25CD4A36-5BE5-4B70-ACA7-04494C017D9D@cisco.com> In-Reply-To: <25CD4A36-5BE5-4B70-ACA7-04494C017D9D@cisco.com> --aRTdMWvxoR9yhuCU9uzH8d3bkLnfjhaS7 Content-Type: multipart/mixed; boundary="------------8E329ABD85B583D32F3F6586" Content-Language: en-US This is a multi-part message in MIME format. --------------8E329ABD85B583D32F3F6586 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 28/07/2020 00:48, Eric Wang (ejwang) wrote: > We felt the lack of a > baseline bcp is going to hurt the security posture of TLS rather than > driving the intermediary away. That makes no sense to me. Adopting this draft will require eliminating all such gibberish and instead finding text that can garner IETF consensus. I really do not think that effort is worth the significant cost for anyone involved, pro-MITM or not. S. --------------8E329ABD85B583D32F3F6586 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----- --------------8E329ABD85B583D32F3F6586-- --aRTdMWvxoR9yhuCU9uzH8d3bkLnfjhaS7-- --ppSaYg5G649FbAICruxMDiop5NyMwqaEx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl8fcuMACgkQWrL68XsX K+qNYg/9GESMmJzu3xKF//Kw8HnSnvGD3mesoB4K1IztBqFCTtTGYUeWRL4RfmNH 6lu/hkeGgBrggNDkfw12XNapp1CtLPjhnwkjiN0SuOR3Io2KOLmIt0k0QbI46v9H 9aUZfgM1B/iHW+yQdXe6u+T2owgdBTKxfQcH18cFZVqxHV64GqNYLPd2yKfZIo9M Htwo9Wdwhh1gq0hi61AcjEulIqmbsCxIA3lFLfXFBLWJKYeocoPcx7kF0ikS54Le 5BxFABVxqAeyvoYJ2gBmAZ0QePQR8Wwmqa4yR8q/0af3nzbyf0rQPeAZUaA9C6RR A3DXWrWGSKynRaoPKPEv+p3bhslnzBfe6TXlutmJc0WYykqSLcNJY6WU/4shkz/M cjoTdroL5o3bDfncmpO8NAfKgjKeoTOrUUBc4feHqsKWThgoLHIAClFDbhT/Ljay BD8d0G0z5nR+vm5D8myKbvlHOSgr5MPwyX5mykWJwvTR04UtpdBA1gVb9ju8od3B 32jaAj12zN8zJUaY+u27+gjmrrUDVmk0WPTQrIxLeKorBXVyTWT5HBQGq6yO3682 UV/jZklEfSFWQC6Adu34gpJkO1TaStK25POzNJdBmkBxiez/0/HX3AmvuVtxP8i1 P3/VnNy4QEZLurQYJacDWYAmHxGk6cL1kJKymOLJdS1gIhYe9Fw= =RCdp -----END PGP SIGNATURE----- --ppSaYg5G649FbAICruxMDiop5NyMwqaEx-- From nobody Mon Jul 27 19:45: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 3EE603A0B0C; Mon, 27 Jul 2020 19:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=nerd.ninja 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-Hv4JN-6YLN; Mon, 27 Jul 2020 19:44:57 -0700 (PDT) Received: from sender4-of-o56.zoho.com (sender4-of-o56.zoho.com [136.143.188.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF41D3A0B0D; Mon, 27 Jul 2020 19:44:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595904295; cv=none; d=zohomail.com; s=zohoarc; b=PJg9IM7XO0+3T2inll9Yepa6PeykuAXxtj/KLS8oD7xAox1Pu2UHqBPbDHAJwZSHlQXa4tNofpov5Jc5CkLUB5xxbiuhHo0xNOF6rD29vMRKhDKe6BTHmwhuFmpfYNUqkNVGcef718ebbp6gFAICdVXL+aczdCorotlXY1woNIg= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1595904295; h=Content-Type:Cc:Date:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:To; bh=6MiFbXYkD8/O4EGF1xV5M3pnh5NKxOau3vfpVlFKMEQ=; b=ATV6Opn9240d11DwQu358Rf8OHiDJamFGEM9ypPXWAiyaDbsE1GKtY3XK6VNEt9waBf1/xFfeSCjKEo44ObWOqjNjZ5z/OJ7qq72s4aY1MK6XNf9eSSTevzwblPnjz62byMIOYHy6dThaybe6UeGfWO443BXVCMV0kAtst2nLC4= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=nerd.ninja; spf=pass smtp.mailfrom=r@nerd.ninja; dmarc=pass header.from= header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1595904295; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; bh=6MiFbXYkD8/O4EGF1xV5M3pnh5NKxOau3vfpVlFKMEQ=; b=HkHBzc1q4lcsBtpWoQkUjoV48MTYswqS4zxqLO+fT2atZnWJ7A1BERitBdRCSEWn KrK81UCZ3ccpczHWq3qO1gyGcBESK4SYng69NRy8MhVvbik/Ra3iQ4s/KZJ2yMlLK3R QZxEnRWoWK3NQ01dz7uvMrFZjKYFI1HISO9/sdjM= Received: from roelofs-mbp.lan (dynamic-acs-24-112-241-136.zoominternet.net [24.112.241.136]) by mx.zohomail.com with SMTPS id 1595904289523893.7787461858186; Mon, 27 Jul 2020 19:44:49 -0700 (PDT) From: Roelof duToit Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5314D569-56FB-43AE-9030-0F17B22A7E2F" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 27 Jul 2020 22:44:47 -0400 In-Reply-To: Cc: "Eric Wang (ejwang)" , "Salz, Rich" , OPSEC , OpSec Chairs , "tls@ietf.org" To: Stephen Farrell References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <411590AE-EEA6-41EE-B0C8-CC1E0C05F1CE@akamai.com> <25CD4A36-5BE5-4B70-ACA7-04494C017D9D@cisco.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-ZohoMailClient: External Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 02:44:59 -0000 --Apple-Mail=_5314D569-56FB-43AE-9030-0F17B22A7E2F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii RFC 8446, section 9.3 states: Note that TLS's protocol requirements and security analysis only apply to the two connections separately. Safely deploying a TLS terminator requires additional security considerations which are beyond the scope of this document. The context of that paragraph is "A middlebox which terminates a TLS = connection" and it implies that there are undocumented security = considerations. The tls-proxy-bp draft is a contribution towards that goal and we think = it is worth the effort. --Roelof > On Jul 27, 2020, at 8:35 PM, Stephen Farrell = wrote: >=20 >=20 >=20 > On 28/07/2020 00:48, Eric Wang (ejwang) wrote: >> We felt the lack of a >> baseline bcp is going to hurt the security posture of TLS rather than >> driving the intermediary away. >=20 > That makes no sense to me. >=20 > Adopting this draft will require eliminating all such > gibberish and instead finding text that can garner IETF > consensus. I really do not think that effort is worth > the significant cost for anyone involved, pro-MITM or > not. >=20 > S. >=20 > = <0x5AB2FAF17B172BEA.asc>_______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec --Apple-Mail=_5314D569-56FB-43AE-9030-0F17B22A7E2F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii RFC = 8446, section 9.3 states:
Note that TLS's = protocol requirements and security analysis only
apply to the two connections = separately.  Safely deploying a TLS
terminator requires additional security considerations which = are
beyond the scope of this = document.

The context of that paragraph is "A middlebox = which terminates a TLS connection" and it implies that there are undocumented security considerations.
The tls-proxy-bp draft is a contribution towards that goal = and we think it is worth the effort.

--Roelof


On Jul 27, 2020, at 8:35 PM, Stephen Farrell = <stephen.farrell@cs.tcd.ie> wrote:



On 28/07/2020 00:48, Eric Wang (ejwang) = wrote:
We felt the = lack of a
baseline bcp is going to hurt the security = posture of TLS rather than
driving the intermediary = away.

That makes no sense to = me.

Adopting this draft will require = eliminating all such
gibberish and instead finding text = that can garner IETF
consensus. I really do not think that = effort is worth
the significant cost for anyone involved, = pro-MITM or
not.

S.

<0x5AB2FAF17B172BEA.asc= >_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mailman/listinfo/opsec

= --Apple-Mail=_5314D569-56FB-43AE-9030-0F17B22A7E2F-- From nobody Mon Jul 27 22:23: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 F15AF3A0C80; Mon, 27 Jul 2020 22:23:02 -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=unavailable 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 3fhT2n9vQCxK; Mon, 27 Jul 2020 22:23:00 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 857663A0C7C; Mon, 27 Jul 2020 22:23:00 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id r12so15137811ilh.4; Mon, 27 Jul 2020 22:23:00 -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=1yAlBPzFWQhfdfZmfgFk9kl8D9a0U7y2b+7wTB8BPxo=; b=b+nFl3JLf3DEmd0kzgHhyvp7tNGB5FSo8bvYNM/Fzs1kJ5bMiZv7iiUfw+GDHS7M/b V0pVNMmowuG0gPhVEOYeIsDGAm8pIJakJcEp4rJSdPbf2YocSM5YA6UvxHe7UQw6v3y4 7LjWfC1WjHOh673j/9UIdZ4E3EU4BsglG7dy4g0J3xYHWfOf0MqL/hmvSWrXykFuucfr PgQv+sfUFeSD/KY5ipDjEUtSYi3cHR+lqTVL4LCu/KEXcJxlxIkgB5w+SR33VLIi3+Og CCca/F5VzgMvymyvfQmmmEJl2H2Sr+qeMVBWV8yOu9bMXzmDwe/tA8G012yiCmoey2aE e25A== 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=1yAlBPzFWQhfdfZmfgFk9kl8D9a0U7y2b+7wTB8BPxo=; b=nfRzILza3CJxbD3hRLwYzz9gwkJVTXNNc4WsrSSXbpeeMfEWAP6TR1gzxmbCej0elI 3MK71MOTHvlbZZjuv1Twgl0c6ZgM5odXMo9txxyJ4p3IRAkHhNHXMXx/YSOenZg7EmSA GgBUx1Wn+h5yC3zIAJAVzxBrDB2vsICEu7TzOKckQ1tPS30v+0mu4hBV0U6/N7vqDDNk D8gOP5V/jjlG+HDjT49Fug+V6N6QpBypC0o35GVfkXG9WFqnQjBKyxDQT9j+IQgFcYpn WxOa/Qlw4E8ZAKWnUAuH/vtDHmiKuB+JKD51kgjysVktHfKsa/W5F3MwCPv2hOh//ZH5 Usvw== X-Gm-Message-State: AOAM531qbEALDuoloj/B+lS4DTBYpNM6gTkVSsABvYrjfSfGY1V7zxTu eBmsr0hNswgWE4TFEI57VomNkkso/40g6iI1uCB9R+On X-Google-Smtp-Source: ABdhPJwfnkOcsZsIzAnqqZ/JF4eVApGw0YbpJgQKPn42k2RKbyhIQ6/ifOxnw+PkFP38DdmEnN7dDo+rxr3ND63nmzU= X-Received: by 2002:a92:dc90:: with SMTP id c16mr27195871iln.202.1595913778324; Mon, 27 Jul 2020 22:22:58 -0700 (PDT) MIME-Version: 1.0 References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <411590AE-EEA6-41EE-B0C8-CC1E0C05F1CE@akamai.com> <25CD4A36-5BE5-4B70-ACA7-04494C017D9D@cisco.com> In-Reply-To: From: Ashutosh Singh Date: Mon, 27 Jul 2020 22:22:47 -0700 Message-ID: To: Roelof duToit Cc: Stephen Farrell , OPSEC , OpSec Chairs , "tls@ietf.org" , "Salz, Rich" , "Eric Wang (ejwang)" Content-Type: multipart/alternative; boundary="000000000000d96aae05ab79a108" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 05:23:03 -0000 --000000000000d96aae05ab79a108 Content-Type: text/plain; charset="UTF-8" I agree with the proposed approach and I also believe in discussion around safe and responsible middlebox deployment. I support the adoption of this draft! Regards -Ashu On Mon, Jul 27, 2020 at 7:45 PM Roelof duToit wrote: > RFC 8446, section 9.3 states: > *Note that TLS's protocol requirements and security analysis only* > *apply to the two connections separately. Safely deploying a TLS* > *terminator requires additional security considerations which are* > *beyond the scope of this document.* > > The context of that paragraph is "*A middlebox which terminates a TLS > connection*" and it implies that there are *undocumented* security > considerations. > The tls-proxy-bp draft is a contribution towards that goal and we think it > is worth the effort. > > --Roelof > > > On Jul 27, 2020, at 8:35 PM, Stephen Farrell > wrote: > > > > On 28/07/2020 00:48, Eric Wang (ejwang) wrote: > > We felt the lack of a > baseline bcp is going to hurt the security posture of TLS rather than > driving the intermediary away. > > > That makes no sense to me. > > Adopting this draft will require eliminating all such > gibberish and instead finding text that can garner IETF > consensus. I really do not think that effort is worth > the significant cost for anyone involved, pro-MITM or > not. > > S. > > <0x5AB2FAF17B172BEA.asc>_______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000d96aae05ab79a108 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with the proposed approach and I also believe in d= iscussion around safe and responsible middlebox deployment. I support the a= doption of this draft!

Regards
-Ashu

On M= on, Jul 27, 2020 at 7:45 PM Roelof duToit <r@nerd.ninja> wrote:
RFC 8446, section 9.3 states:
Note that TLS's protoco= l requirements and security analysis only
apply to th= e two connections separately.=C2=A0 Safely deploying a TLS
terminator requires additional security considerations which are
=
beyond the scope of this document.

The= context of that paragraph is "A middlebox which terminates a TLS c= onnection" and it implies that there are undocumented secur= ity considerations.
The tls-proxy-bp draft is a contribution towa= rds that goal and we think it is worth the effort.

--Roelof


On Ju= l 27, 2020, at 8:35 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


On 28/07/2020 00:48, Eric Wang (ejwang) wrote:
=
We felt the lack of a
baseline bcp is going to= hurt the security posture of TLS rather than
driving the intermediary a= way.

That makes no sense to me.

Adopting this dr= aft will require eliminating all such
gibberish and instead finding text= that can garner IETF
consensus. I really do not think that effort is wo= rth
the significant cost for anyone involved, pro-MITM or
not.
S.

<0x5AB2FAF17B172BEA.asc>_____________________= __________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mail= man/listinfo/opsec

__= _____________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000d96aae05ab79a108-- From nobody Tue Jul 28 00:26: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 A91DA3A0D40; Tue, 28 Jul 2020 00:26:14 -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=lowentropy.net header.b=JZ9N25ad; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MbXuatZf 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 PUuLTCxOqI98; Tue, 28 Jul 2020 00:26:12 -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 5CBE73A0D30; Tue, 28 Jul 2020 00:26:12 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 0B9751628; Tue, 28 Jul 2020 03:26:09 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 28 Jul 2020 03:26:10 -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=n2fOIHwUHzSLiTFr3CADd7WDM7Ym yk5ueapMolELL5k=; b=JZ9N25adl+gZ3sMCANJGTMVpCr1WdAffT4yqsDh5kja0 B37G2eHYW/rbWEOSo1KSNs213qAhQauhoIOewzvo+VPWVMBQvZrbtD+1XClpMzy+ 12KoOsTVZwfjt6+wUBaOVBhkDllw91IKz1wW52YC75lJ81LXK1qL6TjGd4n3NgU9 JyeO5XlaxD6+n6XDMrwr7/XJxo4RGWDCuCq98jWHPdc1ThVt76eHPl+vsXCSlkkB 4ohIOuvVmvXBkreOdRqUCVchbOmgzc7TfbQTfEkmz1+ukVEb7lL14A8f2sBlTdpS ZgOPvZgTZeB1IcszpG7fia5Mlc7Bue+UGFvVjRjeqw== 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=fm3; bh=n2fOIH wUHzSLiTFr3CADd7WDM7Ymyk5ueapMolELL5k=; b=MbXuatZfY4G+1Rov49r3Uj kJ0w//L+ltEc8/c2dGTfpIh1tGFajffhelS5gTJHDRRokjhn1D8cphkWPNqd1qWN I2tAjhCZ1hchCSyL9VG2VJG1XO086Q6JblODVCmho699Emo2gRnIZKga+DTjl6AE 9c/T3WPKXfn+VgLp8Mj5eIVb7fT5+yKEzg69uvu+cD6nldBD0P/DBtXwpfnMBx66 6vMpUxylfK3cx9iFfI/eUp0ZPYSpQEppUr7dRUO4lKPsG6IvR5jhXS0fJPr+EcsQ yrGgenHRwFqWbGtsnb4yTOQyAB9RFvaeux92Wy9F+dOC4a/WdXBa8tjrl+c8iC5Q == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedriedugdduudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefhiedttdeviefhjeejgf evfeeuudfggfekveekheeugeegleevkeevkedthfeuieenucffohhmrghinhepihgvthhf rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3EEA3E00C1; Tue, 28 Jul 2020 03:26:09 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 28 Jul 2020 17:25:48 +1000 From: "Martin Thomson" To: "Ron Bonica" , OPSEC Cc: "tls@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 07:26:15 -0000 On Mon, Jul 20, 2020, at 03:34, Ron Bonica wrote: > This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp > . I think that others have said enough about the wisdom of adoption of the approach. I agree with them, but recognize the right to disagree. Even if we were to accept that it is a good idea to document best practices for TLS proxying, this document is not currently a good basis for that work. The introduction is a little deceptive, in that it says that it is about proxying, but there are numerous places in the draft that talk about selective proxying or some amount of forwarding and inspection. Those practices would require design work. From what I can infer from the draft, it often assumes the same sort of bad designs that are specifically identified elsewhere as having bad characteristics. As it is, the draft is not consistent in terms of its approach and scope. If the goal is to describe pure proxying (a TLS server and a TLS client that intermediate), then it needs a good edit. If the goal is to describe selective proxying or selective forwarding and modification of TLS messages, then that is a much bigger task. What are often stated in the draft as requirements around this points are in fact assumptions. And many of them bad, as others have stated. --- More detail follows Intermediaries if this nature are added to effect some sort of centralized control. This seems to be the primary motivation here also. If we accept that this is happening, it is important to note the operational effects of that. Not just on those who have this desire, but on all of those affected. There is some text about the effect this might have on the ability of clients or servers to introduce new features in Section 4.8. This is nowhere near sufficient. By breaking the connection the number of stack layers that are exposed to potential interference, the consequences are not limited to TLS. Creating negative externalities contributes to TLS interception being despised. If the intent is to help, then this doesn't go nearly far enough in describing the secondary effects a proxy might cause. Probably the worst problem is rooted in Section 5.1. The introduction establishes this as being about proxying, but there are several places that talk about not-proxying sometimes. Selective non-proxying opens the document up to a whole new set of problems that arise from poor designs for deciding not to proxy. There is not nearly enough detail here to address this problem properly. A "good" design for selective TLS proxying does not seem to be the basis of the recommendations. I'll give a few examples of problems. >From the Section 4.8 again: > the TLS proxy MUST conduct proper TLS protocol checks to avoid false identification of TLS handshakes, while taking special care not to contribute to protocol ossification. This practice has been directly responsible for more ossification than intermediation, no matter what qualification exists. If per-destination not-proxying is required, the proxy can connect to a server, determine that the server is on a non-proxy list, and then complete the handshake with the client (with a caveat regarding ECH here). I can guess why this doesn't happen (it's expensive and see also Section 5.4), but that doesn't excuse the practice. The following text from Section 5.3 is deeply problematic: A decryption policy decision MAY be made based on the server certificate or other trustworthy parameters. To verify possession of private keys that are associated with a particular server certificate, the proxy SHOULD complete an out-of-band TLS handshake with the same TLS server IP address and TCP port as targeted by the TLS client. It is possible that the authors misunderstand how TLS works, but this check won't work. Not only because TLS 1.3 encrypts information, but because this is only necessary if the proxy forwards a ClientHello from the client to the server. At that point, it is too late and the damage has been done (see Andrei's review). There are a bunch of places where pure proxying - as described in the introduction - is not assumed. This leads to the same problems already cited. For instance, in Section 4.2: > The proxy MAY remove cipher suites from a client-initiated Client Hello message, add new cipher suites, and re-order them in the proxy-initiated Client Hello message. From nobody Tue Jul 28 01:36: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 4F28A3A08C1 for ; Tue, 28 Jul 2020 01:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.4 X-Spam-Level: X-Spam-Status: No, score=0.4 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, FROM_WORDY=2.5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.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 CyS7-ZpO4VjW for ; Tue, 28 Jul 2020 01:35:51 -0700 (PDT) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (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 7BB3E3A08C7 for ; Tue, 28 Jul 2020 01:35:51 -0700 (PDT) Date: Tue, 28 Jul 2020 08:35:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1595925348; bh=cyBBL9fa34xpAxLSLdKxPAxBK5TjO8OWkfG/aPdvqCI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=yE5l3Bk/ctzhUyX4sBliQDb4S6EcBwZsUWfjbpeyz0SnhBn9FcjIKUr/cg0aGbVwU RMajbKgNRyjCZ4sc6sbmzXAJSmK5yUDRBIOvzxycLJuVe2bMnmTetWXL+mbugyam6u bZi9iDvJx13g7GM7PgdwwyMi0ChQyx5tL98DrRCo= To: Jen Linkova From: "Arnaud.Taddei.IETF" Cc: OPSEC , "tls@ietf.org" , OpSec Chairs Reply-To: "Arnaud.Taddei.IETF" Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 08:35:54 -0000 I strongly support this work as it represents capabilities that are being d= eveloped, deployed and used in practice. It has good intentions and provide= s a good approach in the context of defense in depth approaches. No securit= y cannot be just on both ends of the communication. One can dream about it = but that is not how reality is. Removing this possibility is a limit to the= overall defense. I do not understand the reasons behind ignoring reality and the IETF would = have, in my naive mind, a strong interest in getting this work under good c= ommunity adoption so that it is kept in good control with validated best pr= actices. Everyone would win. I support this draft Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Thursday 23 July 2020 03:30, Jen Linkova wrote: > One thing to add here: the chairs would like to hear active and > explicit support of the adoption. So please speak up if you believe > the draft is useful and the WG shall work on getting it published. > > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica > rbonica=3D40juniper.net@dmarc.ietf.org wrote: > > > Folks, > > This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp. > > Please send comments to opsec@ietf.org by August 3, 2020. > > > > Ron > > > > > > Juniper Business Use Only > > > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > -- > > SY, Jen Linkova aka Furry > > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jul 28 04:13: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 818B03A0AFA for ; Tue, 28 Jul 2020 04:13:36 -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=unavailable 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 8Att6cwNDqza for ; Tue, 28 Jul 2020 04:13:34 -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 9440B3A0AF5 for ; Tue, 28 Jul 2020 04:13:34 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id j22so4883486lfm.2 for ; Tue, 28 Jul 2020 04:13:34 -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=t1fw6wTCMCPAeSyhrR2B8tXbk//XHBh3pEDCAjKqso8=; b=rYptd69LRvo7bpPWpGNeNNl9edzmOoonxC5drZPRQh+EO1c2uQKHghx5SbKqRwXZ5t yI0a5JPZpfEjYuTPL+28ut8VN9FDcjaUEKJbhFcPDwSa2mY8QMfNmdylIX8k7NMcixZ2 9bJHigP4CC9q7k+9sYlDlLqBR0/0gCp8n3Q7tEDOMBT2H8JoCcxStLL6g9RNYII3DR4g wvRZkzFRHmTmnUIZbc0/lNUobI/XJX/E9nVHr39EFn2+EtPNSev25JbHuneNk0BMifZM /OCZbiCx7oH2je4u2g2VXThN5fKUk4eezE4qsui+tDl0UEy9nguxmkPC1gZNMTqF8FZr BLcA== 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=t1fw6wTCMCPAeSyhrR2B8tXbk//XHBh3pEDCAjKqso8=; b=mWW7K6JwCN2BfKJ3axq/9aPsYu1fXdswZGdRqp35gGzxWshwprgXf6ZDcNoDgJ1HYt Sc9rU1gpEjV3mdF+T0aArUoyyQqCuyWmxl3jkU7FwYDv7Gq2th3Tyn0fPM95nOvslOep iQBvJKElciulTvaFlCK6ZeJK4N8Si3yaVeItvJPlFGtGXjgknFKKl94hwcJRGRRZuzw/ HJ0am196xkoP0sEpLLk9cUq5TcYtrrqahKi61la1VyCgUTWkRqCLLDNxyvc/Y4t2hTI7 lZeoIOjwnTCIZIYsAf67mDy9VpEfGw9JHjTxoGEA7eJuTgTagk1cM32mkkJ6N+fwSaxo V1fw== X-Gm-Message-State: AOAM533xiQwWNNSD8ylqbMH5ZbMzd8dPXAApJxNaKHpscauUHLhfthif /hZm8fvmUQCQurqFjY4Fbj0oujwKCYv2zyBeM5hYAg== X-Google-Smtp-Source: ABdhPJyCzd2pYHLa8Y7CjhmfHu+JA9vWIvE1KN+ZW0Gw+V5YjEzLR2TIriNKRvjepzTrKaq9AiQFTOjLWuK4S4Trqpk= X-Received: by 2002:a19:6715:: with SMTP id b21mr14178714lfc.55.1595934812279; Tue, 28 Jul 2020 04:13:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Tue, 28 Jul 2020 04:12:55 -0700 Message-ID: To: Martin Thomson Cc: Ron Bonica , OPSEC , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009232e805ab7e87a9" Archived-At: Subject: Re: [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 11:13:37 -0000 --0000000000009232e805ab7e87a9 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 28, 2020 at 12:26 AM Martin Thomson wrote: > The following text from Section 5.3 is deeply problematic: > > A decryption policy decision MAY be made based on the server > certificate or other trustworthy parameters. To verify possession of > private keys that are associated with a particular server > certificate, the proxy SHOULD complete an out-of-band TLS handshake > with the same TLS server IP address and TCP port as targeted by the > TLS client. > > It is possible that the authors misunderstand how TLS works, but this > check won't work. Not only because TLS 1.3 encrypts information, but > because this is only necessary if the proxy forwards a ClientHello from the > client to the server. In addition, this check is susceptible to trivial forwarding attack in which the server in question forwards the data to the true server. -Ekr --0000000000009232e805ab7e87a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 28, 2020 at 12:26 AM Mart= in Thomson <mt@lowentropy.net&g= t; wrote:
The following text from Section 5.3 is deeply problematic:

=C2=A0 =C2=A0A decryption policy decision MAY be made based on the server =C2=A0 =C2=A0certificate or other trustworthy parameters.=C2=A0 To verify p= ossession of
=C2=A0 =C2=A0private keys that are associated with a particular server
=C2=A0 =C2=A0certificate, the proxy SHOULD complete an out-of-band TLS hand= shake
=C2=A0 =C2=A0with the same TLS server IP address and TCP port as targeted b= y the
=C2=A0 =C2=A0TLS client.

It is possible that the authors misunderstand how TLS works, but this check= won't work.=C2=A0 Not only because TLS 1.3 encrypts information, but b= ecause this is only necessary if the proxy forwards a ClientHello from the = client to the server.

In addition, this che= ck is susceptible to trivial forwarding attack in which the server in quest= ion forwards the data to the true server.

-Ekr

--0000000000009232e805ab7e87a9-- From nobody Tue Jul 28 06:07: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 708433A0C0E; Tue, 28 Jul 2020 06:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 Vj1a9Z3nCW4J; Tue, 28 Jul 2020 06:05:47 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 1D2C73A0C13; Tue, 28 Jul 2020 06:05:47 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id w9so14707877qts.6; Tue, 28 Jul 2020 06:05:46 -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:cc; bh=Wr1iVI0npLx3AU1fdGufjo3c3RgJShVCf6BzGlpjqB8=; b=F4Bit60crak7GrUOnK8tXOaVqfgEH+koN2V/lCh2jO+tUIfmrtR6nK63h8UXuQtTAh bbIYQ+GbLmIlIQTdEGPstLJ1nj22b/9/TNBXCJpR+61a9nDIxxwuoNs338D7On0qbiwQ ef7cPJndUVvf8aUhCkp1JTc4nkaEYWT6wjogq3XbXzx2JYP56y+9hivFcGtCN2wQMqk1 KexzgsaWAO8R6s/a8ondYJ2V8PQPkBG4byKfYSwKXJMVqZ3GjPueyiqCuLiCieF4d2c6 whm/pjAaD1amszCqM9CFvAsBkzU1Ocs2YiC8969ekmaOrrUHnblX2v1bQX/YdBXJvtE+ eJ8A== 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:cc; bh=Wr1iVI0npLx3AU1fdGufjo3c3RgJShVCf6BzGlpjqB8=; b=cE91JCLnPNbG/fK8EZdE+wqCn6MzcC7GV0IFV0sBeA9BP0mowW3Q9DehulrWyoD72u B51UNkOzqUxX77WHSe9BZpZS4cJJ1sWSj0kUn2Ebm5e0NeoNrqrilbalGXkPK3cuc7ob DWoycJRvb9wpAjU9hIMPDZP1JI+7OA38oUmY+YRdLKk6U8RTh7oa4wtLQNHv3Pgijao2 eeKKz5whRuMtU332Pu0y45/8W3UZlacVYNTw8duBlFgzJJmZ+V4bED/BcAc7zQ4kjuPy 1vNJ2FQaANx74RlAmzaZIzVIsQwuSURhsQE2M1PnG8f2v+tU96JFiUDDbTJ9OsKlcNQd x/YA== X-Gm-Message-State: AOAM533b4086qUmBGqKB2tkH9BUQUeofTVDCThS99mHeZF5855ZEj7IH 5GHWOI+J1znc6Vot0vqbyALGZs9iSC/svYnzxdJxbToc X-Google-Smtp-Source: ABdhPJz7Fhy3eiC075hi8lvrHmLzajvtWGrxJQPvR6Y1/gMbvT5USAEGLIc5vMU1B/ZlOJWKZ7TaYUdBG5u6EkrOwEM= X-Received: by 2002:aed:3b0e:: with SMTP id p14mr27277785qte.149.1595941545701; Tue, 28 Jul 2020 06:05:45 -0700 (PDT) MIME-Version: 1.0 From: Jen Linkova Date: Tue, 28 Jul 2020 23:05:34 +1000 Message-ID: To: opsec WG Cc: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact 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 Jul 2020 13:05:52 -0000 This email starts the WG Last Call for draft-ietf-opsec-ns-impact , Impact of TLS 1.3 to Operational Network Security Practices, https://datatracker.ietf.org/doc/draft-ietf-opsec-ns-impact/. Taking into account IETF108, the WGLC is extended to 3 weeks and ends on Aug 18th, 23:59:59 UTC. Please review the document and express your support or concerns/comments. Thanks! -- SY, Jen Linkova aka Furry on behalf of the OpSec Chairs. From nobody Tue Jul 28 06:12:30 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 930B13A0C5E; Tue, 28 Jul 2020 06:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 zlNATaSKtzn6; Tue, 28 Jul 2020 06:12:11 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 248EF3A0C49; Tue, 28 Jul 2020 06:12:11 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id x69so18544299qkb.1; Tue, 28 Jul 2020 06:12:11 -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:cc; bh=2grHQY6vc0ND8Euo1eLvL0k2q148arMX/32c6ioDik8=; b=ed8KjxHbcYoXTLsXJVTc23a4kLNMjqexD44gZovOoPYaEeJtmor8wo5vqKPsOasRPp QWDZdgu5mTx2LLftzA4wAMS74jBrVQVX+rlGZdAe0s47GYRAK81uICMRfPe8CvVZt9LG n6a60Xzt75+RAWHywGtoUwFplfFSHPM83evjeT4fpyJi+fOG843FM7n30mluNgJ6Zwjv bJBjiTKv3sXa0ovfQzjOMZQbO294vYcOYt7c0mlPjlwBrwHs1KxjzDIC6f2wVp7yFhfz jPOtON4Iey6xYZkuspANUMfDSXEVMOV9ZF0fRkOHIgTBCSl4XwUmI+z2yCg1XsYuGLdK ViIw== 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:cc; bh=2grHQY6vc0ND8Euo1eLvL0k2q148arMX/32c6ioDik8=; b=d8wm1EJCbV4ymOj240BbqGm/4LUr8E/RDf9pLQGosbwgNV2KknwRIwqCl5ClCrqsMT EuwGPwxzBKfrQ+nDFsB11o+GZKLSLGuD46/VPyifW+hNVlbvnX8/3vQcnHHNCFFpSjhU WT1lHlWgrgqYFbXVW/ZOnf2FZCb/QWd3a0LdiuBdcgP2gA+g4QYwAbtq6zMxU/YsiYYz ydZqg6FHAgSY5no1b7AtLbgtCObUQe9TTE3xB1JNS0jKc3DhuztysveRFhzIQZRVxe1/ OBpZrKTypTSc6YYq0KKeNOgacwv3QE8mBxZdpvckTPmgdRvEz4VyQoHbBKEmBeCEW6uw V6Mg== X-Gm-Message-State: AOAM532MJJ+ShKhmDYZ+5Sr6gGaT6KVhDi4LbO+dfNitdCkcslDdCIWP UkLMGeTUUbmLB4gMB5XzfyX74niaOFuXGbn4HwUAY0mN X-Google-Smtp-Source: ABdhPJytbUKZgDOs+/6w2A+yRNY6k1eetfUbYg1XFz4YmjLHpTW0AQs8q4vjyl/Sb4wnTv5V/bGcJkYnbgtBqnhfiDA= X-Received: by 2002:a05:620a:a05:: with SMTP id i5mr12392747qka.444.1595941929971; Tue, 28 Jul 2020 06:12:09 -0700 (PDT) MIME-Version: 1.0 From: Jen Linkova Date: Tue, 28 Jul 2020 23:11:59 +1000 Message-ID: To: tls@ietf.org Cc: OpSec Chairs Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] TLS-related drafts in OpSec WG: please review 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 Jul 2020 13:12:20 -0000 Hello, As some of you might have already noticed there are two TLS-related drafts being currently discussed in OpSec WG: 1) "TLS Proxy Best Practice", https://datatracker.ietf.org/doc/draft-wang-opsec-tls-proxy-bp/ is under Call For Adoption until Aug 3rd. 2) "Impact of TLS 1.3 to Operational Network Security Practices" https://datatracker.ietf.org/doc/draft-ietf-opsec-ns-impact/ is under WGLC until Aug 18th. As those drafts are TLS-related, the OpSec chairs would like to ensure the documents in question receive thoughtful review by TLS experts. Therefore we are asking the TLS WG to review those documents and provide feedback. If you have commented on those drafts already - thank you very much! If you have not - please take a look. -- SY, Jen Linkova aka Furry on behalf of the OpSec Chairs. From nobody Tue Jul 28 09:08: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 14B583A0E60; Tue, 28 Jul 2020 09:07:59 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 aR1Ys6Xuo731; Tue, 28 Jul 2020 09:07:57 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2100.outbound.protection.outlook.com [40.107.22.100]) (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 F04123A0E5B; Tue, 28 Jul 2020 09:07:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DJA2DYXBo+0NyrnbKetspsITRzTxe5cN4kVfiNWGjPtxEYnopLlFvIiZtkKFLiTwW19A7J+fZ/nIh9dSHJOAe/hdkW7u4T4IF0dB1CRlX7b2XtnQOlqeuDW+Qlj8n5idYWihEstmnF0xjYZRrE50YWF4jrRlT5BsedfxJQkCgv50ph1cRALULI1YARGXpR+asOhKpaaIMB2w1uge6T8pIbwLUQjSpB/zDbt+X+7fusWefJwuX09Lj/Tq9+RPpmNgf+vCDZwOrw05nuEPHBVMIwd+lzHiaeht5Y86GBlBMf/s/Z5YJl4w7e+q8HAbLd5ToBBnsN5ctgODQITBNeCYqQ== 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=ypebEWp61esNOAeQn43CpzYf/o1XIUKNwJgO8p4jrvM=; b=k9mn8zmGMBLKh6C3gn6IpEFMkAa6Y91wbSh1XEsml0jY63ntbMb1RA6F9/lgRtEJeITqb8KrWYwBCsPLqrxytVevMpmS6bvGxMB6buW3rSkSx3MMUmiZUSZIZXSifMhuAIfF7EeG4DtruRXsRm/s/ZU3W0pg/StcnGM0mVRYNDq+7YADZG7L5WwulvwbmjZwi+5TPLuD7s7H+3hEjV2FE8DCBJqDPz7u2Cs9Tjynu0IJk2shCxTmbahLuMj2vcnskvSsO3aQW4HwJ+zLL2WyycQ0MmCFY5bvUb1SwKxyTE2Q1ssenaU6dTlax5PLg0KgFzFVhqS02Ph0zlF4A2Cc8A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ypebEWp61esNOAeQn43CpzYf/o1XIUKNwJgO8p4jrvM=; b=LbU6moEPiE757zPylLt10YxVKwj7+60VM/DTvacaxl2Q6ZzXnjsIGXz6kTvC+soocOpDSwp0+aCVkcLRcxc7wgls8Ivf4vs616lSf2xdx2WfguV5TsdZHz+twPFQNHpbfRDxlRDZcKMoJu1NGW2yDJksfb/i8XvCxQqOlzCJofc= Received: from DB7PR07MB5340.eurprd07.prod.outlook.com (2603:10a6:10:69::25) by DB6PR07MB3318.eurprd07.prod.outlook.com (2603:10a6:6:1e::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Tue, 28 Jul 2020 16:07:52 +0000 Received: from DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::f911:a06:2f4e:a103]) by DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::f911:a06:2f4e:a103%4]) with mapi id 15.20.3239.015; Tue, 28 Jul 2020 16:07:52 +0000 From: tom petch To: Jen Linkova , opsec WG CC: "tls@ietf.org" Thread-Topic: [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact Thread-Index: AQHWZOAEUv5F9DjalEW4QGtE95/kRakdJpAB Date: Tue, 28 Jul 2020 16:07:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [81.131.229.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5a760cc4-e3b8-424e-87d3-08d833106196 x-ms-traffictypediagnostic: DB6PR07MB3318: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jJE/7KiPRtar8ksXvc/903RW2CeUTJF8fuHr36HJ/usZnHoCPIy8+1LanKPbWxCON4axufnhyiUvO8FpkvzqAJ7lRJheI0WQ8qbmvfzw43oXDxwOCGq/vUvUO5vXixSNpwKbHlS4UW4tXqsTUMfoLZ/lpXjK7gusiSnbwa4+QTwFVOHkRrpuDLxdDsQLvGjmzuNVMmsMXxt/JSVEtZTCZCZoHQp1kAhgIaI5/eeutwRwz8v5nFyV6Zhx4d++rcvW0fif+FaM6uNZyaUmEqstJwJyA7PFa2EGc79PXzReEoEA8yVNbRrI1oJNZUdb+uWIVvQxnjaFWWZLjL7geD52VsUch25DkU/KmqH8IWGdO0L7sKA7iQODCQzj43H243mBIHS0apTzFpvbC27n453W9w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5340.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(6029001)(366004)(33656002)(966005)(9686003)(86362001)(498600001)(55016002)(8676002)(8936002)(110136005)(5660300002)(71200400001)(26005)(2906002)(186003)(52536014)(4326008)(91956017)(83380400001)(76116006)(66946007)(66476007)(66446008)(7696005)(64756008)(66556008)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: DjTY60y1ubJQ0gB+LleLodcg2wW5Yc/SDAnfU9vHRMOtOqP795ZFTMFwI8QBX2ClLScs4a0jlTY8CVkum68LfRyq1shzZLu8hreajRwgiq4+PKmLCEUmxpGuAooL5Tpq56UW/iXQhJBHlbINAP5/UNYjUQpF8Jh1Xh26MEvIbDS02w0R8UJh8vMqlAkjsH3ku48OfJt6pmxAC1xTDM7WMCrYOtv3N4+wqsJ847jkvx2LSR96DQYcLrUH+0k9dwDr45CoCSwAA2BSl3N1R57AWEJxOFUEEvdYQRH460fThREWAEfZy6biCL8x7JJ3MAuKj6+vD58IRiOz01wYX1NiEPGvEBnC/8t8EY9JVsdwLEi103k2R/x/t1OkFrPl4lVhLxTUxk0KjRWMUBtNZxnk2qCYc2sYtE2eg4uiGxbryMh27C8dInOfK0dQf/LUMQfok5lsMR37xECBoga4qV1JfIzAaVprAm0FAkM7MV2JW28KBvP11/PJHAemcEHpVI6584URpY+PD8IpXt/lujkmIc+IhrEGhzugmz2I+2Of4vTrSVuOEqT3hSjUKwnW7rx2OV4PPLTM4mO1cbWmNC3/6/TjZhC57oLmdwm9CbaBWgd+PdJg+eaKqBga5FPBWarpY9W0UxqSOcMjmqbjOWkx4A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB5340.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5a760cc4-e3b8-424e-87d3-08d833106196 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 16:07:52.1934 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: QxnpPboW6FHx2AVcPX/mgwTzsDiSXQeSujdD8ioCZFxoHmni356V4jIhXicmmCrLb52jjDbq5PTGcH7nL2NGjQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3318 Archived-At: Subject: Re: [TLS] [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact 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 Jul 2020 16:07:59 -0000 From: OPSEC on behalf of Jen Linkova =0A= Sent: 28 July 2020 14:05=0A= =0A= This email starts the WG Last Call for draft-ietf-opsec-ns-impact ,=0A= =0A= Impact of TLS 1.3 to Operational Network Security Practices,=0A= =0A= https://datatracker.ietf.org/doc/draft-ietf-opsec-ns-impact/.=0A= =0A= Taking into account IETF108, the WGLC is extended to 3 weeks and ends=0A= on Aug 18th, 23:59:59 UTC.=0A= =0A= Please review the document and express your support or concerns/comments.= =0A= =0A= =0A= OPPOSE (yes, I am shouting)=0A= =0A= This is nowhere near ready and putting it forward so soon is ... well ludic= rous comes to mind.=0A= =0A= After WG adoption, comments were made to which there was no acknowledgement= , no response, I was about to oppose the adoption of the other I-D from th= ese authors on the grounds that until they respond to comments nothing else= should happen because when they do there are more comments waiting to be a= ired. I am still of that view.=0A= =0A= I do see that a revised I-D has just appeared in among the thousand or so I= -D that appear around the time of an IETF meeting, a timing that I sometime= s think is designed to let it slip through unnoticed. Given all those othe= r I-D - silly authors - it may be more than three weeks before I get my tho= ughts together.=0A= =0A= Tom Petch=0A= =0A= Thanks!=0A= =0A= --=0A= SY, Jen Linkova aka Furry on behalf of the OpSec Chairs.=0A= =0A= _______________________________________________=0A= OPSEC mailing list=0A= OPSEC@ietf.org=0A= https://www.ietf.org/mailman/listinfo/opsec=0A= From nobody Tue Jul 28 09: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 F3BFE3A0E6C; Tue, 28 Jul 2020 09:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iuchxUSN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=E8cEDvFN 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 5chq3J9x8oqW; Tue, 28 Jul 2020 09:11:33 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FB43A0E67; Tue, 28 Jul 2020 09:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2908; q=dns/txt; s=iport; t=1595952692; x=1597162292; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=eiebskW+r1ArYdG76OFwhTu+sdGYLRW5DSi7N19SQfI=; b=iuchxUSN4P9ZaSI0zeNpJY9bAOHIBuKrIPKGjNZgprtoDTDz0h1xhHgt gZhkuLY945lLsEkuGFwqh3AN1bAaTREKR4RabDjXbauGfweMRezyDSlQY UdlrUONdToiquACL7PzYSWY35pDDLk9/W0LjZoDv3lYMHWEN4Dbg31qe2 E=; IronPort-PHdr: =?us-ascii?q?9a23=3AOS9SHRGwDSlnzpgQwf4Q1J1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401gWbV5nQ7PRChuHK9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Yvna16zgfEQ?= =?us-ascii?q?m5Pg1wdaz5H4fIhJGx0Oa/s5TYfwRPgm+7ZrV/ZBW7pAncrI8Ym4xnf60w0R?= =?us-ascii?q?DO5HBPfrdb?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9BwDlTSBf/4ENJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUiMuB29YLywKhCqDRgONMiWKAo0BgV6BQoERA1ULAQE?= =?us-ascii?q?BDAEBGAsKAgQBAYRMGYIJAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcQEBAQQ?= =?us-ascii?q?BARALBhEMAQEsCwERAQgVAQQCERUCBB8GCxUSBAENBSKDBAGCSwMuAQ6kMQK?= =?us-ascii?q?BOYhhdoEygwEBAQWBR0FCgmkNC4IOAwaBDiqCbYNZgjOEBBqCAIERJwwQgk0?= =?us-ascii?q?+ghpCAQEDAYEUEgESASE/glczgi2SZpItkBZOCoJfiFiMI4R1Ax6Ce4lJkH6?= =?us-ascii?q?CJ5EVgQKKLoJhkgsCBAIEBQIOAQEFgWojZ3BwFTsqAYI+UBcCDY4eg3GFFIV?= =?us-ascii?q?CdDcCBgEHAQEDCXyOawGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,406,1589241600"; d="scan'208";a="795192877" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jul 2020 16:11:12 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 06SGBCn1015362 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Jul 2020 16:11:12 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 11:11:11 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 11:11:11 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 28 Jul 2020 11:11:11 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dHwSuXiBcMM3th+JbNU7SVVmcDFNeqi5buN3pCxQi+VuuqtIfo1r6sfp14/YsGWVy1XVHdqV7BqX2eaCzxmHUS1XKwiFlfkfOrdr6qNnMCf8bjnzK+k2wPoMGpFHQgq7bi1NH2LVNfdIb3Cmtwf0AKTCzs9JKbb7DpKR7zuI0KVHGUhmKBEfwpb2KwYNXZufOdhHCcw0rdF8CNliGIoewJ7KYVgyaa8zRwi5PBy9WkyOMLMIgmNYRH0vVQ575AUG7N5/qnabncpWvLy2jx1U5INwlYBQUAuczRzkOMNLxvsWSTJI92qahioJ29OZ6vN5aNT4ZI2mzYHOj3rt0eBQoA== 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=eiebskW+r1ArYdG76OFwhTu+sdGYLRW5DSi7N19SQfI=; b=kmQy7iJd2K3Ct8C1Qz9ZrFE3GvLnCmoQ4vFusyPyuBYor7AGvaS+jh8z290xzqN72Sio5YnFqHV6r9bNtVHtX7TQbTdyHBdOXnz45b1sv1aBuBy2kEJ5NWgZ6youWOUWzCH9gPalahxDPwEwZD46yuwgCGtJGd2lEfvdYMJ337TAU0GN4X/AjpptpWC5kA0RoJBITQ8XYZOJ/0yRJHkKvP3ZakSCIxLuSrR8lhfAoCUp1dDynw9v88NblkyROILpTPu+vwZ6PuiHa8NW+6BNMZkd51SGjYXP834Kofw9c4S3+6WHgVmEOcvxwzFZLdruVfxNa6GjteeFOwRD5AUlJw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eiebskW+r1ArYdG76OFwhTu+sdGYLRW5DSi7N19SQfI=; b=E8cEDvFNTIKN517MKNCA77dpJzhzSmBZ/vNS3rkbdEoL/6TyY66RVkX+xgS2s07XmTNppkLfIqszlItGrWP9DzRLkv2MlpM7PMBWQ4gowGIxOjPg6Wkh6Z5yNpmtuXrTObcEaDwljW/poJ99oKClr6Cx/CfCavqLjJv9JQ8M8KQ= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BY5PR11MB4088.namprd11.prod.outlook.com (2603:10b6:a03:185::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.25; Tue, 28 Jul 2020 16:11:10 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::e42f:216e:af3e:8ce5]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::e42f:216e:af3e:8ce5%7]) with mapi id 15.20.3216.033; Tue, 28 Jul 2020 16:11:10 +0000 From: "Nancy Cam-Winget (ncamwing)" To: tom petch , Jen Linkova , opsec WG CC: "tls@ietf.org" Thread-Topic: [TLS] [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact Thread-Index: AQHWZPm176lOtIepR0yla6OAMhA9wQ== Date: Tue, 28 Jul 2020 16:11:10 +0000 Message-ID: <02491BC9-1909-4043-BB9A-1C23B8A8EB98@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.18.200713 authentication-results: btconnect.com; dkim=none (message not signed) header.d=none;btconnect.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aae7eff3-a7a3-4a81-b92e-08d83310d7d8 x-ms-traffictypediagnostic: BY5PR11MB4088: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ENQWjYu98F8Y+DcnKiZIjQujz+cr9MVGcPziaQ1Rk9Ulh7gkQTUFDQIAzddW3KZ6lT4PJzDL4Q0HEZZJoc3//NtowpQ1r64BczuWvNgHM/YJ3MDJXujAggCD/k2IaqCBq7kjKIMNglyUGgpXiwvVla7B+aPg+nLMC//rPXU8YelQgnXvXjKQdmMk/PcOkDCkfc+AAZ++tM2QK/N4i+uiPZND3u1z2pr6ljHrNQERNoolYWl+2d4KiYaL/YrqceqInOM3vpi4/5UHr7qSG6OVj2DXvQplNfGx1ZEsb75JGI9uRQsuR9ruqDER94KkTdP4MoI0ElvFaUzbnFn10OdJC+TK+oGkozA3fcXdP5/kAxZ6yoDMJK879obSO1pLBaZ2eQxIXiv9DOEFq/jG/K9c8Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(6029001)(4636009)(136003)(366004)(396003)(346002)(39860400002)(376002)(8676002)(8936002)(4326008)(6486002)(86362001)(6512007)(83380400001)(71200400001)(66476007)(66446008)(5660300002)(64756008)(76116006)(186003)(26005)(316002)(966005)(478600001)(33656002)(36756003)(2906002)(6506007)(296002)(110136005)(66946007)(66556008)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 0lfkz7KTLfxUFMdJkYiTlFi4lqLFOW0AZygmp+8C7hyzAS8lktigVzQB9gq69paXfx3ggFZyF9OTWjpIXsVVCnGhd7f9bpIZYr+IH6UFRBVBTEqo/PIL3N9mt5OXdZwvDqXyGQ8Eft7uAVocVTBe2tKorIdnisYTRA6Xa0kDnukuIRX5DwGR1V5itieOni5OUTnhpnm+Us/ToXEFdEmjUnbYG6nOUED5/SCfM72uIKgSaHSQkU00jSRrw9tpuw0I1meRtE39P+5kw57KqorXDYqFaxhOpNVyahRO6MOD/dXU3UsVYtRnoLZbKOut594uHcxRCUy87vLNHoZsQkhUQ3axKYLAtEr7zlzu8Tc66utBgU/Z6v3bRbmmePpua+cygc932uYWtja/5VGpZ7eGZrEd3OKgu6uiKm9gDe2siIie5fKCPAm3i8Fjt5xMcT8aBzNp5LGrzIBD75An9MTy8xKMC1ZBpR9XzHSBtCtLrGdOM4Q7exhesNy9tbeu1zfG x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <5BE318F140FCD94A9E0A0B05153AEE24@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4070.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: aae7eff3-a7a3-4a81-b92e-08d83310d7d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 16:11:10.5104 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: urDUOcVgZmvaRlYtm4Y/I8U0V5CUWifLngAd5IisZIqKQfz5ZESzBJ3LMTbA5d4scGThK+YtUeOQ3J+ZnyAO6g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4088 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [TLS] [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact 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 Jul 2020 16:11:36 -0000 SGkgVG9tLA0KWWVzIGFwb2xvZ2llcyBhcyB0aGUgbGF0ZXN0IHZlcnNpb24gaW5jbHVkZWQgY29t bWVudCByZXNwb25zZXMgZnJvbSBLYXRobGVlbiBhbmQgSmFzb24sIGJ1dCBJIG9taXR0ZWQgeW91 cnMuLi4ud2hpY2ggaXMgY29taW5nIHNvb24uDQpBcG9sb2dpZXMgZm9yIHRoYXQgb21pc3Npb24s IGxvb2sgZm9yIC0wMiBjb21pbmcgc29vbi4uLi4NCg0KICAgIE5hbmN5DQoNCu+7v09uIDcvMjgv MjAsIDk6MDggQU0sICJUTFMgb24gYmVoYWxmIG9mIHRvbSBwZXRjaCIgPHRscy1ib3VuY2VzQGll dGYub3JnIG9uIGJlaGFsZiBvZiBpZXRmYUBidGNvbm5lY3QuY29tPiB3cm90ZToNCg0KICAgIEZy b206IE9QU0VDIDxvcHNlYy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSmVuIExpbmtv dmEgPGZ1cnJ5MTNAZ21haWwuY29tPg0KICAgIFNlbnQ6IDI4IEp1bHkgMjAyMCAxNDowNQ0KICAg IA0KICAgIFRoaXMgZW1haWwgc3RhcnRzIHRoZSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYt b3BzZWMtbnMtaW1wYWN0ICwNCiAgICANCiAgICBJbXBhY3Qgb2YgVExTIDEuMyB0byBPcGVyYXRp b25hbCBOZXR3b3JrIFNlY3VyaXR5IFByYWN0aWNlcywNCiAgICANCiAgICBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2VjLW5zLWltcGFjdC8uDQogICAgDQog ICAgVGFraW5nIGludG8gYWNjb3VudCAgSUVURjEwOCwgdGhlIFdHTEMgaXMgZXh0ZW5kZWQgdG8g MyB3ZWVrcyBhbmQgZW5kcw0KICAgIG9uIEF1ZyAxOHRoLCAyMzo1OTo1OSBVVEMuDQogICAgDQog ICAgUGxlYXNlIHJldmlldyB0aGUgZG9jdW1lbnQgYW5kIGV4cHJlc3MgeW91ciBzdXBwb3J0IG9y IGNvbmNlcm5zL2NvbW1lbnRzLg0KICAgIA0KICAgIDx0cD4NCiAgICBPUFBPU0UgKHllcywgSSBh bSBzaG91dGluZykNCiAgICANCiAgICBUaGlzIGlzIG5vd2hlcmUgbmVhciByZWFkeSBhbmQgcHV0 dGluZyBpdCBmb3J3YXJkIHNvIHNvb24gaXMgLi4uIHdlbGwgbHVkaWNyb3VzIGNvbWVzIHRvIG1p bmQuDQogICAgDQogICAgQWZ0ZXIgV0cgYWRvcHRpb24sIGNvbW1lbnRzIHdlcmUgbWFkZSB0byB3 aGljaCB0aGVyZSB3YXMgbm8gYWNrbm93bGVkZ2VtZW50LCBubyByZXNwb25zZSwgIEkgd2FzIGFi b3V0IHRvIG9wcG9zZSB0aGUgYWRvcHRpb24gb2YgdGhlIG90aGVyIEktRCBmcm9tIHRoZXNlIGF1 dGhvcnMgb24gdGhlIGdyb3VuZHMgdGhhdCB1bnRpbCB0aGV5IHJlc3BvbmQgdG8gY29tbWVudHMg bm90aGluZyBlbHNlIHNob3VsZCBoYXBwZW4gYmVjYXVzZSB3aGVuIHRoZXkgZG8gdGhlcmUgYXJl IG1vcmUgY29tbWVudHMgd2FpdGluZyB0byBiZSBhaXJlZC4gIEkgYW0gc3RpbGwgb2YgdGhhdCB2 aWV3Lg0KICAgIA0KICAgIEkgZG8gc2VlIHRoYXQgYSByZXZpc2VkIEktRCBoYXMganVzdCBhcHBl YXJlZCBpbiBhbW9uZyB0aGUgdGhvdXNhbmQgb3Igc28gSS1EIHRoYXQgYXBwZWFyIGFyb3VuZCB0 aGUgdGltZSBvZiBhbiBJRVRGIG1lZXRpbmcsIGEgdGltaW5nIHRoYXQgSSBzb21ldGltZXMgdGhp bmsgaXMgZGVzaWduZWQgdG8gbGV0IGl0IHNsaXAgdGhyb3VnaCB1bm5vdGljZWQuICBHaXZlbiBh bGwgdGhvc2Ugb3RoZXIgSS1EIC0gc2lsbHkgYXV0aG9ycyAtIGl0IG1heSBiZSBtb3JlIHRoYW4g dGhyZWUgd2Vla3MgYmVmb3JlIEkgZ2V0IG15IHRob3VnaHRzIHRvZ2V0aGVyLg0KICAgIA0KICAg IFRvbSBQZXRjaA0KICAgIA0KICAgIFRoYW5rcyENCiAgICANCiAgICAtLQ0KICAgIFNZLCBKZW4g TGlua292YSBha2EgRnVycnkgb24gYmVoYWxmIG9mIHRoZSBPcFNlYyBDaGFpcnMuDQogICAgDQog ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBP UFNFQyBtYWlsaW5nIGxpc3QNCiAgICBPUFNFQ0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzZWMNCiAgICANCiAgICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFRMUyBtYWlsaW5nIGxpc3QNCiAg ICBUTFNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3Rscw0KICAgIA0KDQo= From nobody Tue Jul 28 09:15: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 2E9543A0E7C; Tue, 28 Jul 2020 09:15:24 -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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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=btconnect.onmicrosoft.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 5lYSZE1PM9wW; Tue, 28 Jul 2020 09:15:22 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2126.outbound.protection.outlook.com [40.107.21.126]) (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 67B2F3A0E17; Tue, 28 Jul 2020 09:15:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I8WAV5IeQ5xufC8TGy2T1Fd+U1TR6bM2oUfpS9ATjT3o8/q8YnsK/36AFz0w+6RrBrg132Mxwg28Od/1Sa3nUu9SoSHrb5UoATtE2J/76EaROMMKsoTIHUP1aEUr/l41pnZd9c4LB3vvzaZJEZbLmVJLhgVWiig7ndX/fP/rE3hRox8EXiCqH9HHPPokgsJHRYrn8By4J1l1F0TMaPYFjt06iyqMcNBmBg5iA9xf7jL2xQXZeO00Kn+brEw59nuYY4jW4a/Ik7Phr66tZhDouWOLjQ7CaIPioluCFZuG5fG+EEqYzUIUevniMqXurefAAL9z+UMjAm08fs/usKo2EQ== 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=ltD7DzLGGtDaJVzGQ1a/YH+5xVWNEw9KBPoRbaC4/Wo=; b=PmL4s7hoGFIKUhEpaE+PlLW2ZbOSmn+4bavOY0z1KJvrm6D4EtEkV9qzLj+XUVWsWj2nnH9SljyOQSwLZK1bzQZIcAe14qca6ku1xzRHYmQB3sS7oSGlrIKkWSZb5vJmr7NepahqgH1nhgKFYOP04Ywwa3eu9DN2Xvj5fDZt++nIc6ec9K0zaFyhDughCS3CvMwDoWshtmI0dc+QvG2LyYTVdYCQV+M1uKmcilldbo0U0hiGXW4gaR/B8ZLSCoUMpwj3lksPTlEBQzggnsNc/SKV5laAMTtH1VgfGXn8SwDxiisagLhYzdysykX6yi+7TsMlBkV3Z/VYMpyZoI0Y8w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ltD7DzLGGtDaJVzGQ1a/YH+5xVWNEw9KBPoRbaC4/Wo=; b=ZrOTufqaa6H/Piys1xRzOQUDlH/78ctT8MlZGPAAtPGYuLZx/ilpedYEz6t2DPWzdwq0UZPNgIigI5pFBoJHKrXdnL0EUDKlVMWCny59Fhzp5TPdsvEtD3t+kUqW6z+pj+cDEioTXdhaBu2Dedqv12/FY3lx3+bjnKMtYLXkZiU= Received: from DB7PR07MB5340.eurprd07.prod.outlook.com (2603:10a6:10:69::25) by DB6PR07MB3318.eurprd07.prod.outlook.com (2603:10a6:6:1e::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Tue, 28 Jul 2020 16:15:18 +0000 Received: from DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::f911:a06:2f4e:a103]) by DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::f911:a06:2f4e:a103%4]) with mapi id 15.20.3239.015; Tue, 28 Jul 2020 16:15:18 +0000 From: tom petch To: "Nancy Cam-Winget (ncamwing)" , Jen Linkova , OPSEC , "tls@ietf.org" CC: OpSec Chairs Thread-Topic: [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AdZd8qs4MVhjKcpfSaSC3eC5PK0rEQCniF8AAFkyZIAAwPM9tA== Date: Tue, 28 Jul 2020 16:15:18 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [81.131.229.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2606aa13-600b-40a1-1e79-08d833116bb0 x-ms-traffictypediagnostic: DB6PR07MB3318: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kSYMpgLjEe+7xNfIVZENYK6WOL/jRXuUHqTq3dlDIntnzSYKee0OYdDp8p1xe26bQkW5Xvkrfy4qb8oY+PqQOo+VVisUWZYuOCVlwz/W8BpG8k677NpZqUk6qAMIJmgJtdVzOxLkW5bLU+paM2uTwOfbhcOuyCwNPbC1o5k2U1NLrnsMWYYScXk39FjxDz/zPh2nNy3Quv5l5MgpRC4V8m/Gf+hrW57M2Nd/Z5AFUoYYyWMAVTE8f7At7+K6Fo7Pgvw3G21oLrVzck5w0YJdmJ0D6F0HzmY3D2mI/n6BvkMRb2eSW4lIyBMs0EI2Bu7t82OuePhqTu4J9evMFLa1eXDPXTCq0qhmg4u8GfyeNedx9qfh8lhE9GyTtqgLYINfdAmTyHfr2tu6E5HJnL4iCg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5340.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(366004)(396003)(136003)(376002)(39860400002)(346002)(186003)(52536014)(2906002)(26005)(71200400001)(4326008)(5660300002)(91956017)(7696005)(64756008)(66556008)(66476007)(66446008)(6506007)(53546011)(66946007)(76116006)(9686003)(966005)(86362001)(55016002)(33656002)(478600001)(8936002)(316002)(8676002)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: FuoSrq4yAg+Otf6Cl+zE5YZF+mzeUqisFMrIo1V6dyUMPCZTx2ESob1pCUw7WGBmhhJbtUaISncqZJptd+LRkk+KLNYqzn4tlEvL37nV8Q7x3sxxQjN9fY6jXnVfugbEB8XhYy7/HDCNtdqRQ/Wsrt2wNMfXmTAghXaklCB15aLP6Ko8nJjsg60Lylh6aupckl1/jznkv++SP79Z1rQrlLQ1+lylxFftDy5SuL6anpUCrF+vB3x2ZVUkwiJUV+lHxQKuNftqmHcJp/u1oZmdxCiOIKH8D08mYMN6AuLsrnWOtCgE0W5eBVktCEGIAmbvyU/+Ekzyglc1FMFMVPp8q4PEt/x+Ro4jgRFaEN8PDRBucUpEkqTyOUBioDfmpc2a5py+gb8eDgZPaHYEvj6yp3O6hWVJvrpgJOGpHC90QFk2aRbhDawbehwlU2epAaxdwFMKseKJkA1JSDSI6p3n4lfhW+3tDpGo+p4OVtf36YmTAaVcpwVJNfYWpUNzyDy3HDYjyJFKdo34qWRhCQUGudFQEUJMny+ooLYy5vWolko+XPtisw9OoNW+4q8UtUWvLAQ3gts/Ai85Ly1wDxhY3cSqrzGAShVtlFi7LPjVkOzhfDDqyUz8T/Vsyi70Xj7l0T6ac/6186WhAw4ooIkucA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB5340.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2606aa13-600b-40a1-1e79-08d833116bb0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 16:15:18.6220 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: I5P2smDwxGZE6OQj5sebTWoGF39qwnNXVeei+hJByPRlforEjtIr0DNVG9cswDTAQhR/DHJFgxBT3c/acwd7oQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3318 Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 16:15:24 -0000 RnJvbTogT1BTRUMgPG9wc2VjLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBOYW5jeSBD YW0tV2luZ2V0IChuY2Ftd2luZykgPG5jYW13aW5nPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3Jn PgpTZW50OiAyNSBKdWx5IDIwMjAgMDQ6MDQKCjx0cD4KCk9QUE9TRQoKVGhlcmUgaXMgYSBwbGFj ZSBmb3IgdGhpcyBJLUQgYXMgYW5kIHdoZW4gdGhlIGF1dGhvcnMgcmVzcG9uZCB0byB0aGUgdW5h bnN3ZXJlZCBjb21tZW50cyBvbiB0aGUgbGFzdCBJLUQgdGhhdCB0aGV5IGdvdCBhZG9wdGVkIGlu IE9QU0VDLiAgIElmIHRoZXkgZG8gbm90IGFja25vd2xlZGdlLCBsZXQgYWxvbmUgcmVzcG9uZCB0 bywgY29tbWVudHMgdGhlbiB0aGF0IHNob3VsZCBiZSBhIGJhciB0byBuZXcgd29yayBiZWNhdXNl IGFzIGFuZCB3aGVuIHRoZSBjb21tZW50cyBhcmUgYWRkcmVzc2VkIHRoZXJlIGFyZSBtb3JlIGNv bW1lbnRzIHdhaXRpbmcuCgpJIGRvIHNlZSBhIHJldmlzZWQgSS1EIG9mIHRoYXQgb3RoZXIgSS1E IGluIGFtb25nIHRoZSB2YXN0IG51bWJlciB0aGF0IGhhdmUgYXBwZWFyZWQgYXMgdGhleSBhbHdh eXMgZG8gYXJvdW5kIHRoZSB0aW1lIG9mIGFuIElFVEYsIGJ1dCBnaXZlbiB0aGF0IGl0IGlzIG9u ZSBhbW9uZyBodW5kcmVkcyBpdCB3aWxsIGJlIGEgd2hpbGUgYmVmb3JlIEkgYW0gcmVhZHkgd2l0 aCBtb3JlIGNvbW1lbnRzIG9uIHRoYXQgb3RoZXIgSS1ELiAKClRvbSBQZXRjaAoKVGhpcyBkcmFm dCBwcm92aWRlcyBndWlkZWxpbmVzIGZvciBUTFMgcHJveHkgaW1wbGVtZW50YXRpb25zOyBnaXZl biBjdXJyZW50IGFjdGl2aXRpZXMgdXNpbmcgVExTIHdpdGggcHJveHlpbmcgSSBiZWxpZXZlIHRo aXMgZG9jdW1lbnQgaXMgdXNlZnVsIGZvciB0aGUgY29tbXVuaXR5IGFuZCBpbXBsZW1lbnRvcnMu ICBJIHN1cHBvcnQgaXRzIGFkb3B0aW9uLgoKV2FybSByZWdhcmRzLCBOYW5jeQoK77u/T24gNy8y Mi8yMCwgNjozMSBQTSwgIk9QU0VDIG9uIGJlaGFsZiBvZiBKZW4gTGlua292YSIgPG9wc2VjLWJv dW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGZ1cnJ5MTNAZ21haWwuY29tPiB3cm90ZToKCiAg ICBPbmUgdGhpbmcgdG8gYWRkIGhlcmU6IHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBoZWFyIGFj dGl2ZSBhbmQKICAgIGV4cGxpY2l0IHN1cHBvcnQgb2YgdGhlIGFkb3B0aW9uLiBTbyBwbGVhc2Ug c3BlYWsgdXAgaWYgeW91IGJlbGlldmUKICAgIHRoZSBkcmFmdCBpcyB1c2VmdWwgYW5kIHRoZSBX RyBzaGFsbCB3b3JrIG9uIGdldHRpbmcgaXQgcHVibGlzaGVkLgoKICAgIE9uIE1vbiwgSnVsIDIw LCAyMDIwIGF0IDM6MzUgQU0gUm9uIEJvbmljYQogICAgPHJib25pY2E9NDBqdW5pcGVyLm5ldEBk bWFyYy5pZXRmLm9yZz4gd3JvdGU6CiAgICA+CiAgICA+IEZvbGtzLAogICAgPgogICAgPgogICAg PgogICAgPiBUaGlzIGVtYWlsIGJlZ2lucyBhIENhbGwgRm9yIEFkb3B0aW9uIG9uIGRyYWZ0LXdh bmctb3BzZWMtdGxzLXByb3h5LWJwLgogICAgPgogICAgPgogICAgPgogICAgPiBQbGVhc2Ugc2Vu ZCBjb21tZW50cyB0byBvcHNlY0BpZXRmLm9yZyBieSBBdWd1c3QgMywgMjAyMC4KICAgID4KICAg ID4KICAgID4KICAgID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFJvbgogICAgPgogICAgPgogICAgPgogICAgPgogICAgPiBK dW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5CiAgICA+CiAgICA+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCiAgICA+IE9QU0VDIG1haWxpbmcgbGlzdAogICAg PiBPUFNFQ0BpZXRmLm9yZwogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29wc2VjCgoKCiAgICAtLQogICAgU1ksIEplbiBMaW5rb3ZhIGFrYSBGdXJyeQoKICAgIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiAgICBPUFNFQyBt YWlsaW5nIGxpc3QKICAgIE9QU0VDQGlldGYub3JnCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29wc2VjCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18KT1BTRUMgbWFpbGluZyBsaXN0Ck9QU0VDQGlldGYub3JnCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb3BzZWMK From nobody Tue Jul 28 09:32: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 993813A0EA4; Tue, 28 Jul 2020 09:32:06 -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=UTv4HRkr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o402V+8s 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 dVRe5e6_3Mx9; Tue, 28 Jul 2020 09:32:04 -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 81DA03A0E85; Tue, 28 Jul 2020 09:32:04 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 957565C00E1; Tue, 28 Jul 2020 12:32:03 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Tue, 28 Jul 2020 12:32:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:cc:subject:content-type; s=fm2; bh=1t/DY2k6mc1XrU0xGjGbZc8nsW3G6rXGvIy5veQY/Bk=; b=UTv4H RkrLFAtjR2+OJxCv7pLvDieWQDh+LWa8owEcuygjuIEpjdcFXsfVeQF7jFySlv6I 8ZLFTY9HKFa26tp3xvZVtvwl3c0FA3eq7LLM+hk1BM6w5/UY0SJYWv7Lw6s98mUB fNh1g+ytjFqvjCQFVuqlnfZPQuFDBFmJaU2wgn/p15hmVCeYgNETwkGlQeuOBGah M1f3L25bKPEAq6hrFEwRRJ3aANy/7A0HfEZ2kA9K3NzdSXIeUq6D5mvcF154n2l8 Na8/4WGCSEoA8TX95fSntDtA4TC6kGCbK7SMDECFja6MRLkz3waufMPY8Vwu9/Sb GOJ1vNNeLcaNnYjxw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm3; bh=1t/DY2k6mc1XrU0xGjGbZc8nsW3G6 rXGvIy5veQY/Bk=; b=o402V+8s41ibuKI5j4AafsIUldboAVZxaEBsWR/COTQVq qPG8Sa8E3AtEe/lG/zzxnf5vQFFIsAkf6brcshMZsxX/FU5J7VdaErIGl/OGfGUO M1zp08rc8dPyblItbBurt0DPYaZwqC0z37XIvvvVpWW22aS648AYybnJijtyJmvk HVQrMBq60KKCKhg1WX1raoeuiOimbPIFCq/tG13dyfMWrpuwPLgMlh6HZLbLoZK2 IC+SQXspTSE340q2/sOIg1u+s0DMKS86Q0kVKvJu/u+13UGCJhNri2oToo38e5pL QnPaz+4+0e9KdmtPgyVjTLS6SapjBVSoujtAce1Kw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedriedvgdellecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfffhffvufgtsehttdertderredtnecuhfhrohhmpedfvehhrhhishht ohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvghtqeenuc ggtffrrghtthgvrhhnpeefleekheeffffhheeiieejgefgkedtffetjeekledtheffteeu kedvtedtfeejgeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgs ihhtshdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4AFF73C00A2; Tue, 28 Jul 2020 12:32:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: <7f7f3878-446c-4f95-9cdd-cde6bb955134@www.fastmail.com> Date: Tue, 28 Jul 2020 09:29:27 -0700 From: "Christopher Wood" To: "TLS@ietf.org" Cc: "TLS Chairs" Content-Type: text/plain Archived-At: Subject: [TLS] Draft minutes for TLS at IETF 108 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 Jul 2020 16:32:12 -0000 Hi folks, Draft minutes for today's TLS meeting at IETF 108 are now available: https://github.com/tlswg/wg-materials/blob/master/ietf108/minutes.md Thanks to Carrick and others for taking notes! Please send any corrections or updates to the list or as pull requests to the repository. Thanks, Chris, on behalf of the chairs From nobody Tue Jul 28 14:19: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 519C63A086F; Tue, 28 Jul 2020 14:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=T1G4fKx2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pflqtoVq 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 5jr-YIvK-3Mf; Tue, 28 Jul 2020 14:19:02 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277FF3A0846; Tue, 28 Jul 2020 14:19:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25151; q=dns/txt; s=iport; t=1595971142; x=1597180742; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=2qXiD3RYU4pAgubuDAu5CRinmwWPH5NWEF8dd9nM+94=; b=T1G4fKx2XUH85dG8+mXY4d73E3QthycakV/Uugni5+TEnz5+rXXtHlp/ Fi2t7+a2StDopKYK4sY1jTTNsRHN20nQ4+q0fekZ3nmPWWzsbI4F1zJCh Erh0951tzhf5OfucxY0ZcXQLBp0z1IpKzlODxRCr46ZIEpjl+y2LIXlTQ 0=; IronPort-PHdr: =?us-ascii?q?9a23=3Aab/c+RQp8HrfGiKL+GjjXdAJ3tpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB9mJ7/VbhuzKqaf4SCoG7IrS+HwBcZkZUR?= =?us-ascii?q?gDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh6TkNFx?= =?us-ascii?q?PjLw1tN6LzF5KBx8iy3vq5rpvUZQgAjTGhYLR0eROxqwiZtsQfjYZ4bKgrzR?= =?us-ascii?q?6cqXpTcOMQzmRtdl8=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrDAA5lSBf/4MNJK1ghCVRB29YLyw?= =?us-ascii?q?KhCqDRgONMpQahGyBQoERA1ULAQEBDAEBGAEKCgIEAQGETAIXggkCJDgTAgM?= =?us-ascii?q?BAQsBAQUBAQECAQYEbYVcDIVyAgQBARALBh0BASwLAQ8CAQgOMQMCAgIlCxQ?= =?us-ascii?q?RAQEEDgUbB4MEAYF+TQMtAQEOpR8CgTmIYXaBMoMBAQEFgUdBgy0Ygg4DBoE?= =?us-ascii?q?4gm2CUUhAhjcaggCBEScMEIFPfj6CXAEBAwGBJgELBwEJFy6CaTOCLY8rEYM?= =?us-ascii?q?qhlqcNwqCX4hYhWpQil4DHp9pnEWQR0+DVgIEAgQFAg4BAQWBaiNncHAVOyo?= =?us-ascii?q?Bgj4+EhcCDY4qF4NOhRSFQnQ3AgYBBwEBAwl8jTaBNQGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,407,1589241600"; d="scan'208,217";a="536977865" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jul 2020 21:19:01 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 06SLJ1pF017537 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Jul 2020 21:19:01 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 16:19:00 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 17:18:59 -0400 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 28 Jul 2020 17:18:59 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EWNb38f+NK7h4KK2qWNOHeilDGEE1zpEb8N8cg5ldAOUECf7IprxyMYnMMy84ugBLSFDMVue83vTlavCZGEVulLFNj/PoahH8vkfS2/BlIJB8432/A0KZfMiosGCPAdNC5sbovv7fvp6xNHeehuA3HjvzKW4Q+6SW836ZnV2cBQqc6OTO+d7cYgOxAftS7KKkZeGcrVL6YTa/R2Ghpq91zbOuy/p7s96cqgCfbl00Dr7jM9AwBwUTqvFChuEPJ92Tnvm8yPwsht/3i4rmyhQocEbp33nKlkRgHoHpN+UDmFEVmXPqXWiwqv8TcndQyhDS2ZmJ7jiad1c5qr5gPxJzA== 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=2qXiD3RYU4pAgubuDAu5CRinmwWPH5NWEF8dd9nM+94=; b=ftElAbsXCdrQxaUkDGVA52WgLDL/hIPFfGrBCdEcnntMtahpt6JNF9DuWGVPZVrxFIO2/OFaK+QjHWFcGqjlEzP9UszF2jxzoxsiq0hKd7ACM7nxq1WphwvWp8dRvmgXIeD54FVHJ8e0gNP8aopMDXroWmG6rmnu9YWnyriPyKFUFYE/3j+bR5R4yVa50aePgA/0+neZH8/ZTKUrZZuDXjtT3onovCGAb3ZwbgKDXU/lqU0374zK5WW9PP08C0k2Kg3FpiSym/IoMfn01HYkqtPFKlGMQBNGprlsmtMbHUweZFlQhnke/00WCGjSvZd6BFTmWX92c7hyEdvBPidrrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2qXiD3RYU4pAgubuDAu5CRinmwWPH5NWEF8dd9nM+94=; b=pflqtoVqscphb2Jrqnu39E5tU6DKQv0BQnKxaBrBtuzTSvM6RcPnx9iWmdkskStD0Clp2m+J2/a+f3TUvBAWAPWT9De9eevij07VS1bE/qmIfAZ5BdGnerOPpS2Sv40kYHd8ytHjQCVx10osX8Skz9w3A1WmdP/avPBADl6RopA= Received: from BYAPR11MB2789.namprd11.prod.outlook.com (2603:10b6:a02:cc::11) by BY5PR11MB4166.namprd11.prod.outlook.com (2603:10b6:a03:191::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Tue, 28 Jul 2020 21:18:58 +0000 Received: from BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870]) by BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870%6]) with mapi id 15.20.3216.033; Tue, 28 Jul 2020 21:18:58 +0000 From: "Eric Wang (ejwang)" To: Martin Thomson CC: Ron Bonica , OPSEC , "tls@ietf.org" Thread-Topic: [OPSEC] [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AdZd8qs4MVhjKcpfSaSC3eC5PK0rEQGvaUsAAB0Y8YA= Date: Tue, 28 Jul 2020 21:18:58 +0000 Message-ID: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.15) authentication-results: lowentropy.net; dkim=none (message not signed) header.d=none;lowentropy.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [171.68.244.70] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: db1332c4-039c-4521-165e-08d8333bd774 x-ms-traffictypediagnostic: BY5PR11MB4166: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nC9Qfn+r3qLpSaQwNpTKftzPiVoLWd91EteYR5zmCnZ8x6B3J9NXn2/QIp+qIEKADGM2jLrSiDJVC5Ms/tLrapbg9ub0Bzp3GzY7egK8kE5IcnnIaxYB99zCqGEz43L0gfOpV2eMnJJw+NtHwK7wQRJKZl/Ty927sFaHw6YGN9pd+rolp1N2453uYkEGJlfeakuPd+LEEbjM/qn6PM0bg3jUqqPG8Hk7LkM8DA2Gg9JQZAzV7GFr9d5mlHJCU+YgUrQOk+8uJhuf0fRhMkxczvwU92OHTgiRFVfwif/mrYJtEWQ6uU4Cb9sOKLIKBlrTmfipjezWMqyq0JCGC8b4sc7AqivwLOJsy6W0UTWMs/GwA5vmKDF8CzOhLIgWIKtTh67Got5G78PHfrNEjK+h6w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2789.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(39860400002)(376002)(346002)(396003)(166002)(5660300002)(66946007)(53546011)(76116006)(91956017)(66446008)(186003)(66556008)(6512007)(64756008)(6486002)(26005)(6506007)(4326008)(83380400001)(66476007)(966005)(2906002)(2616005)(86362001)(71200400001)(6916009)(54906003)(8936002)(36756003)(8676002)(478600001)(316002)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: sD50p9bVm22Bp3Pf0odEdFzvBUtpQZ4XdbaevuCIZ1SfcfL0ZJb0z8jrwsLjW6bxl+4Sj7hZI04tzPgi8+Juc1qpnm9H6vzOeHjw/MITPoOLC6mI/Hc510mWo0II3hCH42zNui6wbqUh996XBYW6AC9qXholIcemVlPMJdwzerv/qD1csxDpgZq5Dgk+uNAPyhP+zWCW/fiKjNliN3tEkisQp6qUVU2rmtCXDKKIdGRg5uS7nDPLQY303hJewAh7dZQqJgrVZwxsMcqIJTZQxEOXp7oAut3GO2yEevHdxUSOi8ADIgd/HP2f4lgVPpFmjZ7nwzXgNkZDG68UJupDzSK4NGNGBYDQ4G60LIlvHIFdF981wLjzXRwM/Yrb9vfHO9oy0+tqHIwiaplyg8bKiZm5qehTD5eIPHnHp9yL8m0yfkd4ZlWwwv/jwVXyJJdaem5ObPby/1VgyyzQFhltJOcnONcXTgrqDxbFQErsAKI= Content-Type: multipart/alternative; boundary="_000_3422664693F34592A972A55B160D5B78ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2789.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: db1332c4-039c-4521-165e-08d8333bd774 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 21:18:58.1942 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: svuwpRjz7Inl8IXiAxu7mcpuhaEqb5B38OgTAqkELsSR7MatZtM2aKdpSoMIs7zu5pgy5pnwbxF3w4HoseR4cA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4166 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 21:19:05 -0000 --_000_3422664693F34592A972A55B160D5B78ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IGZvciB0aGUgZGV0YWlsZWQgY29tbWVudHMuDQoNClRoZSBzY29wZSBvZiB0aGUg ZG9jdW1lbnQgaXMgbGltaXRlZCB0byBwcm94eSBhdCB0aGUgVExTIGxheWVyLiAgRXhwbGljaXRs eSBvdXQgb2YgdGhlIHNjb3BlIGlzIGluc3BlY3Rpb24gb2YgdGhlIHByb3hpZWQgcmVjb3JkIGRh dGEuICAgV2lsbCBjbGVhbiB1cCBkZXJpdmF0aW9ucyBmcm9tIHRoaXMgc2NvcGUuDQoNCkl0IHdh cyB0aGUgaW50ZW50aW9uIHRvIGNvdmVyIHNlbGVjdGl2ZSBwcm94eWluZyBob3dldmVyLCBiZWNh dXNlIHRoYXQgaXMgYSBwcmFjdGljYWwgcmVxdWlyZW1lbnQgZm9yIGFuIGFjdHVhbCBkZXBsb3lt ZW50LiAgVGhlIGludGVudGlvbiB3YXMgdG8gZGlzY3VzcyB0aGUgVExTIGxheWVyIGF0dHJpYnV0 ZXMgKGUuZy4gU05JLCBTZXJ2ZXIgQ2VydCkgdGhhdCBjb3VsZCBiZSB1c2VkIGFzIGlucHV0IGZv ciB0aGUgZGVjaXNpb24uICBUaGUgZG9jdW1lbnQgYWxzbyBzdGF0ZWQgdGhlIHJlcXVpcmVtZW50 IHRvIGdyYWNlZnVsbHkgcmVtb3ZlIHRoZSBwcm94eSBmcm9tIHRoZSBzZXNzaW9uIHdoZW4gbmVl ZGVkIChhbmQgcG9zc2libGUpLiAgQnV0IHRoZSBjcml0ZXJpYSBmb3Igc2VsZWN0aXZlIHByb3h5 aW5nIGRlY2lzaW9uLCBiZWluZyBjb21wbGlhbmNlLCBwcml2YWN5LCByaXNrIGxldmVsLC4uLiBh cmUgb3V0IG9mIHRoZSBzY29wZS4gIFRoZSBkZWNpc2lvbiBtYWtpbmcgb2Z0ZW4gZmFsbHMgdW5k ZXIgdGhlIGxhcmdlciDigJxwb2xpY3nigJ0gZG9tYWluIGFuZCBpcyBjb250cm9sbGVkIGF0IHN5 c3RlbSBsZXZlbCBvdXRzaWRlIG9mIHRoZSBwcm94eS4gIEl0IGFsc28gbGVmdCBvdXQgZGlzY3Vz c2lvbiBvbiB0aGUgZGV0YWlsZWQgbWVjaGFuaXNtIHdoaWNoIHdhcyBkZWVtZWQgYXMgaW1wbGVt ZW50YXRpb24gc3BlY2lmaWMuDQoNCkluIGFueSBjYXNlLCB0aGUgcHJveHkgaGFzIHRvIGNvbmR1 Y3Qgc2VsZWN0aXZlIHByb3h5aW5nIGluIGEgc2FmZSwgbm9uLWRpc3J1cHRpdmUgbWFubmVyLiBU aGlzIG1heSByZXF1aXJlIG1vcmUgZGVzaWduIHdvcmsgYXMgeW91IHBvaW50ZWQgb3V0LiAgVGhl IGRvY3VtZW50IGNvdWxkIGRlc2NyaWJlIHBvc3NpYmxlIG1lY2hhbmlzbXMgc28gdGhhdCBhbiBh Y2NlcHRhYmxlIHByYWN0aWNlIGNvdWxkIGJlIGRpc2N1c3NlZC4gIFdlIGFyZSBvcGVuIHRvIG90 aGVyIHdheXMgdG8gc2hhcGUgaXQuDQoNCk1vcmUgaW5saW5lLi4uDQoNCg0KT24gSnVsIDI4LCAy MDIwLCBhdCAxMjoyNSBBTSwgTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHkubmV0PG1haWx0 bzptdEBsb3dlbnRyb3B5Lm5ldD4+IHdyb3RlOg0KDQpPbiBNb24sIEp1bCAyMCwgMjAyMCwgYXQg MDM6MzQsIFJvbiBCb25pY2Egd3JvdGU6DQpUaGlzIGVtYWlsIGJlZ2lucyBhIENhbGwgRm9yIEFk b3B0aW9uIG9uIGRyYWZ0LXdhbmctb3BzZWMtdGxzLXByb3h5LWJwDQo8aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd2FuZy1vcHNlYy10bHMtcHJveHktYnAvPi4NCg0KSSB0 aGluayB0aGF0IG90aGVycyBoYXZlIHNhaWQgZW5vdWdoIGFib3V0IHRoZSB3aXNkb20gb2YgYWRv cHRpb24gb2YgdGhlIGFwcHJvYWNoLiAgSSBhZ3JlZSB3aXRoIHRoZW0sIGJ1dCByZWNvZ25pemUg dGhlIHJpZ2h0IHRvIGRpc2FncmVlLg0KDQpFdmVuIGlmIHdlIHdlcmUgdG8gYWNjZXB0IHRoYXQg aXQgaXMgYSBnb29kIGlkZWEgdG8gZG9jdW1lbnQgYmVzdCBwcmFjdGljZXMgZm9yIFRMUyBwcm94 eWluZywgdGhpcyBkb2N1bWVudCBpcyBub3QgY3VycmVudGx5IGEgZ29vZCBiYXNpcyBmb3IgdGhh dCB3b3JrLiAgVGhlIGludHJvZHVjdGlvbiBpcyBhIGxpdHRsZSBkZWNlcHRpdmUsIGluIHRoYXQg aXQgc2F5cyB0aGF0IGl0IGlzIGFib3V0IHByb3h5aW5nLCBidXQgdGhlcmUgYXJlIG51bWVyb3Vz IHBsYWNlcyBpbiB0aGUgZHJhZnQgdGhhdCB0YWxrIGFib3V0IHNlbGVjdGl2ZSBwcm94eWluZyBv ciBzb21lIGFtb3VudCBvZiBmb3J3YXJkaW5nIGFuZCBpbnNwZWN0aW9uLiAgVGhvc2UgcHJhY3Rp Y2VzIHdvdWxkIHJlcXVpcmUgZGVzaWduIHdvcmsuICBGcm9tIHdoYXQgSSBjYW4gaW5mZXIgZnJv bSB0aGUgZHJhZnQsIGl0IG9mdGVuIGFzc3VtZXMgdGhlIHNhbWUgc29ydCBvZiBiYWQgZGVzaWdu cyB0aGF0IGFyZSBzcGVjaWZpY2FsbHkgaWRlbnRpZmllZCBlbHNld2hlcmUgYXMgaGF2aW5nIGJh ZCBjaGFyYWN0ZXJpc3RpY3MuDQoNCkFzIGl0IGlzLCB0aGUgZHJhZnQgaXMgbm90IGNvbnNpc3Rl bnQgaW4gdGVybXMgb2YgaXRzIGFwcHJvYWNoIGFuZCBzY29wZS4gIElmIHRoZSBnb2FsIGlzIHRv IGRlc2NyaWJlIHB1cmUgcHJveHlpbmcgKGEgVExTIHNlcnZlciBhbmQgYSBUTFMgY2xpZW50IHRo YXQgaW50ZXJtZWRpYXRlKSwgdGhlbiBpdCBuZWVkcyBhIGdvb2QgZWRpdC4gIElmIHRoZSBnb2Fs IGlzIHRvIGRlc2NyaWJlIHNlbGVjdGl2ZSBwcm94eWluZyBvciBzZWxlY3RpdmUgZm9yd2FyZGlu ZyBhbmQgbW9kaWZpY2F0aW9uIG9mIFRMUyBtZXNzYWdlcywgdGhlbiB0aGF0IGlzIGEgbXVjaCBi aWdnZXIgdGFzay4gIFdoYXQgYXJlIG9mdGVuIHN0YXRlZCBpbiB0aGUgZHJhZnQgYXMgcmVxdWly ZW1lbnRzIGFyb3VuZCB0aGlzIHBvaW50cyBhcmUgaW4gZmFjdCBhc3N1bXB0aW9ucy4gIEFuZCBt YW55IG9mIHRoZW0gYmFkLCBhcyBvdGhlcnMgaGF2ZSBzdGF0ZWQuDQoNCi0tLSBNb3JlIGRldGFp bCBmb2xsb3dzDQoNCkludGVybWVkaWFyaWVzIGlmIHRoaXMgbmF0dXJlIGFyZSBhZGRlZCB0byBl ZmZlY3Qgc29tZSBzb3J0IG9mIGNlbnRyYWxpemVkIGNvbnRyb2wuICBUaGlzIHNlZW1zIHRvIGJl IHRoZSBwcmltYXJ5IG1vdGl2YXRpb24gaGVyZSBhbHNvLiAgSWYgd2UgYWNjZXB0IHRoYXQgdGhp cyBpcyBoYXBwZW5pbmcsIGl0IGlzIGltcG9ydGFudCB0byBub3RlIHRoZSBvcGVyYXRpb25hbCBl ZmZlY3RzIG9mIHRoYXQuICBOb3QganVzdCBvbiB0aG9zZSB3aG8gaGF2ZSB0aGlzIGRlc2lyZSwg YnV0IG9uIGFsbCBvZiB0aG9zZSBhZmZlY3RlZC4NCg0KVGhlcmUgaXMgc29tZSB0ZXh0IGFib3V0 IHRoZSBlZmZlY3QgdGhpcyBtaWdodCBoYXZlIG9uIHRoZSBhYmlsaXR5IG9mIGNsaWVudHMgb3Ig c2VydmVycyB0byBpbnRyb2R1Y2UgbmV3IGZlYXR1cmVzIGluIFNlY3Rpb24gNC44LiAgVGhpcyBp cyBub3doZXJlIG5lYXIgc3VmZmljaWVudC4gIEJ5IGJyZWFraW5nIHRoZSBjb25uZWN0aW9uIHRo ZSBudW1iZXIgb2Ygc3RhY2sgbGF5ZXJzIHRoYXQgYXJlIGV4cG9zZWQgdG8gcG90ZW50aWFsIGlu dGVyZmVyZW5jZSwgdGhlIGNvbnNlcXVlbmNlcyBhcmUgbm90IGxpbWl0ZWQgdG8gVExTLg0KDQpD cmVhdGluZyBuZWdhdGl2ZSBleHRlcm5hbGl0aWVzIGNvbnRyaWJ1dGVzIHRvIFRMUyBpbnRlcmNl cHRpb24gYmVpbmcgZGVzcGlzZWQuICBJZiB0aGUgaW50ZW50IGlzIHRvIGhlbHAsIHRoZW4gdGhp cyBkb2Vzbid0IGdvIG5lYXJseSBmYXIgZW5vdWdoIGluIGRlc2NyaWJpbmcgdGhlIHNlY29uZGFy eSBlZmZlY3RzIGEgcHJveHkgbWlnaHQgY2F1c2UuDQoNCg0KSW5kZWVkIGl0IHdhcyBkcml2ZW4g Ynkgc29ydCBvZiDigJxjZW50cmFsaXplZCBjb250cm9s4oCdIGZyb20gdGhlIG5ldHdvcmsgKGlu Y2x1ZGluZyBPUyBzdGFjaykuIFRoZSBpbmR1c3RyeSBoYXMgbW92ZWQgdG8gYSBoeWJyaWQgbW9k ZWwgd2l0aCBhIGNvbWJpbmF0aW9uIG9mIGVuZHBvaW50IChjbGllbnQsIHNlcnZlciksIGFwcGxp Y2F0aW9uLCBhbmQgbmV0d29yayBiYXNlZCBzb2x1dGlvbnMuIEVuZHBvaW50L0FwcCBiYXNlZCBz b2x1dGlvbiBwbGF5cyBhbiBpbmNyZWFzaW5nbHkgaW1wb3J0YW50IHJvbGUgYW5kIGxpa2VseSBu b3QgcmVxdWlyaW5nIGFuIGludGVybWVkaWFyeS4gTWVhbndoaWxlLCBuZXR3b3JrIGJhc2VkIHNv bHV0aW9uIGluY2x1ZGluZyBpbnRlcm1lZGlhcnkgY29udGludWVzIHRvIGJlIGRlcGxveWVkIGZv ciB2YXJpb3VzIHJlYXNvbnMuIFdlIGNvdWxkIGFkZCBtb3JlIGFuYWx5c2lzIHJlbGF0ZWQgYSBU TFMgcHJveHkgdGhvdWdoIGEgZnVsbCBibG93biBkaXNjdXNzaW9uIHdvdWxkIGJlIG91dCBvZiB0 aGUgc2NvcGUuDQoNCkZyb20gYW5vdGhlciBwZXJzcGVjdGl2ZSwgdGhlIHRyZW5kIGNhbGxzIGZv ciBtb3JlIGNvbGxhYm9yYXRpb24gYmV0d2VlbiB0aGUgc29sdXRpb25zIGFuZCBlbGVtZW50cywg ZXNwZWNpYWxseSBiZXR3ZWVuIGNsaWVudCBhcHBzIGFuZCB0aGUgbmV0d29yay4gIEluIHNvbWUg c2Vuc2UsIHRoaXMgZG9jdW1lbnQgYWxzbyBzdXJmYWNlcyBzb21lIGlzc3VlcyBhbmQgZ2Fwcy4g QSBwcm94eSBjYW4gb25seSBvcGVyYXRlIHdpdGhpbiB0aGUgc2NvcGUgc3BlY2lmaWVkIGJ5IHRo ZSBjdXJyZW50IHN0YW5kYXJkcy4NCg0KDQoNClByb2JhYmx5IHRoZSB3b3JzdCBwcm9ibGVtIGlz IHJvb3RlZCBpbiBTZWN0aW9uIDUuMS4gIFRoZSBpbnRyb2R1Y3Rpb24gZXN0YWJsaXNoZXMgdGhp cyBhcyBiZWluZyBhYm91dCBwcm94eWluZywgYnV0IHRoZXJlIGFyZSBzZXZlcmFsIHBsYWNlcyB0 aGF0IHRhbGsgYWJvdXQgbm90LXByb3h5aW5nIHNvbWV0aW1lcy4NCg0KU2VsZWN0aXZlIG5vbi1w cm94eWluZyBvcGVucyB0aGUgZG9jdW1lbnQgdXAgdG8gYSB3aG9sZSBuZXcgc2V0IG9mIHByb2Js ZW1zIHRoYXQgYXJpc2UgZnJvbSBwb29yIGRlc2lnbnMgZm9yIGRlY2lkaW5nIG5vdCB0byBwcm94 eS4gIFRoZXJlIGlzIG5vdCBuZWFybHkgZW5vdWdoIGRldGFpbCBoZXJlIHRvIGFkZHJlc3MgdGhp cyBwcm9ibGVtIHByb3Blcmx5LiAgQSAiZ29vZCIgZGVzaWduIGZvciBzZWxlY3RpdmUgVExTIHBy b3h5aW5nIGRvZXMgbm90IHNlZW0gdG8gYmUgdGhlIGJhc2lzIG9mIHRoZSByZWNvbW1lbmRhdGlv bnMuICBJJ2xsIGdpdmUgYSBmZXcgZXhhbXBsZXMgb2YgcHJvYmxlbXMuDQoNCkZyb20gdGhlIFNl Y3Rpb24gNC44IGFnYWluOg0KDQp0aGUgVExTIHByb3h5IE1VU1QgY29uZHVjdCBwcm9wZXIgVExT IHByb3RvY29sIGNoZWNrcyB0byBhdm9pZCBmYWxzZSBpZGVudGlmaWNhdGlvbiBvZiBUTFMgaGFu ZHNoYWtlcywgd2hpbGUgdGFraW5nIHNwZWNpYWwgY2FyZSBub3QgdG8gY29udHJpYnV0ZSB0byBw cm90b2NvbCBvc3NpZmljYXRpb24uDQoNClRoaXMgcHJhY3RpY2UgaGFzIGJlZW4gZGlyZWN0bHkg cmVzcG9uc2libGUgZm9yIG1vcmUgb3NzaWZpY2F0aW9uIHRoYW4gaW50ZXJtZWRpYXRpb24sIG5v IG1hdHRlciB3aGF0IHF1YWxpZmljYXRpb24gZXhpc3RzLg0KDQpJZiBwZXItZGVzdGluYXRpb24g bm90LXByb3h5aW5nIGlzIHJlcXVpcmVkLCB0aGUgcHJveHkgY2FuIGNvbm5lY3QgdG8gYSBzZXJ2 ZXIsIGRldGVybWluZSB0aGF0IHRoZSBzZXJ2ZXIgaXMgb24gYSBub24tcHJveHkgbGlzdCwgYW5k IHRoZW4gY29tcGxldGUgdGhlIGhhbmRzaGFrZSB3aXRoIHRoZSBjbGllbnQgKHdpdGggYSBjYXZl YXQgcmVnYXJkaW5nIEVDSCBoZXJlKS4gIEkgY2FuIGd1ZXNzIHdoeSB0aGlzIGRvZXNuJ3QgaGFw cGVuIChpdCdzIGV4cGVuc2l2ZSBhbmQgc2VlIGFsc28gU2VjdGlvbiA1LjQpLCBidXQgdGhhdCBk b2Vzbid0IGV4Y3VzZSB0aGUgcHJhY3RpY2UuDQoNClRoZSBmb2xsb3dpbmcgdGV4dCBmcm9tIFNl Y3Rpb24gNS4zIGlzIGRlZXBseSBwcm9ibGVtYXRpYzoNCg0KICBBIGRlY3J5cHRpb24gcG9saWN5 IGRlY2lzaW9uIE1BWSBiZSBtYWRlIGJhc2VkIG9uIHRoZSBzZXJ2ZXINCiAgY2VydGlmaWNhdGUg b3Igb3RoZXIgdHJ1c3R3b3J0aHkgcGFyYW1ldGVycy4gIFRvIHZlcmlmeSBwb3NzZXNzaW9uIG9m DQogIHByaXZhdGUga2V5cyB0aGF0IGFyZSBhc3NvY2lhdGVkIHdpdGggYSBwYXJ0aWN1bGFyIHNl cnZlcg0KICBjZXJ0aWZpY2F0ZSwgdGhlIHByb3h5IFNIT1VMRCBjb21wbGV0ZSBhbiBvdXQtb2Yt YmFuZCBUTFMgaGFuZHNoYWtlDQogIHdpdGggdGhlIHNhbWUgVExTIHNlcnZlciBJUCBhZGRyZXNz IGFuZCBUQ1AgcG9ydCBhcyB0YXJnZXRlZCBieSB0aGUNCiAgVExTIGNsaWVudC4NCg0KSXQgaXMg cG9zc2libGUgdGhhdCB0aGUgYXV0aG9ycyBtaXN1bmRlcnN0YW5kIGhvdyBUTFMgd29ya3MsIGJ1 dCB0aGlzIGNoZWNrIHdvbid0IHdvcmsuICBOb3Qgb25seSBiZWNhdXNlIFRMUyAxLjMgZW5jcnlw dHMgaW5mb3JtYXRpb24sIGJ1dCBiZWNhdXNlIHRoaXMgaXMgb25seSBuZWNlc3NhcnkgaWYgdGhl IHByb3h5IGZvcndhcmRzIGEgQ2xpZW50SGVsbG8gZnJvbSB0aGUgY2xpZW50IHRvIHRoZSBzZXJ2 ZXIuICBBdCB0aGF0IHBvaW50LCBpdCBpcyB0b28gbGF0ZSBhbmQgdGhlIGRhbWFnZSBoYXMgYmVl biBkb25lIChzZWUgQW5kcmVpJ3MgcmV2aWV3KS4NCg0KDQpVbmxlc3MgSSBtaXN1bmRlcnN0b29k IGl0LCB0aGUgZG9jdW1lbnQgaXMgc3VnZ2VzdGluZyB0aGUgc2FtZSBhcyB5b3UgbGlzdGVkLiAg QmFzaWNhbGx5LCB0aGUgcHJveHkgbWFrZXMgYSBzZXBhcmF0ZSBjb25uZWN0aW9uIHRvIHRoZSBz ZXJ2ZXIgYXMgYSBjbGllbnQgKOKAnG91dC1vZi1iYW5k4oCdIHdydCB0byB0aGUgb3JpZ2luYXRp bmcgY2xpZW50LXNlcnZlciBjb25uZWN0aW9uKSwgcmV0cmlldmVzIHRoZSBzZXJ2ZXLigJlzIGNl cnRpZmljYXRlIGZyb20gdGhlIHByb3h5LXNlcnZlciBoYW5kc2hha2UsIGFuZCBkZXRlcm1pbmVz IHdoZXRoZXIgdGhlIHNlcnZlciBpcyBvbiBhIG5vbi1wcm94eWluZyBsaXN0IG9yIG5vdC4gIElm IG9uIHRoZSBsaXN0LCB0aGUgcHJveHkgZm9yd2FyZHMgdGhlIG9yaWdpbmF0aW5nIGNsaWVudCBD SCBhcyBpcyB0byB0aGUgc2VydmVyLCBhbmQgc3RlcHMgYXdheXMgZnJvbSB0aGUgb3JpZ2luYXRp bmcgY2xpZW50LXNlcnZlciBoYW5kc2hha2UuDQoNClRoZXJlIGFyZSBhZGRpdGlvbmFsIGNvbnNp ZGVyYXRpb25zIGluIHRoaXMgYXBwcm9hY2ggKGxhdGVuY3kgZXRjLikuIFRoZSBkb2N1bWVudCBp bnRlbnRpb25hbGx5IGxlZnQgb3V0IHRoZSBkZXRhaWxzIHRvIGltcGxlbWVudGF0aW9ucywgYnV0 IGNvdWxkIGFsc28gY292ZXIgdGhlbSBpZiBuZWVkZWQuDQoNCg0KDQoNClRoZXJlIGFyZSBhIGJ1 bmNoIG9mIHBsYWNlcyB3aGVyZSBwdXJlIHByb3h5aW5nIC0gYXMgZGVzY3JpYmVkIGluIHRoZSBp bnRyb2R1Y3Rpb24gLSBpcyBub3QgYXNzdW1lZC4gIFRoaXMgbGVhZHMgdG8gdGhlIHNhbWUgcHJv YmxlbXMgYWxyZWFkeSBjaXRlZC4gIEZvciBpbnN0YW5jZSwgaW4gU2VjdGlvbiA0LjI6DQoNClRo ZSBwcm94eSBNQVkgcmVtb3ZlIGNpcGhlciBzdWl0ZXMgZnJvbSBhIGNsaWVudC1pbml0aWF0ZWQg Q2xpZW50IEhlbGxvIG1lc3NhZ2UsIGFkZCBuZXcgY2lwaGVyIHN1aXRlcywgYW5kIHJlLW9yZGVy IHRoZW0gaW4gdGhlIHByb3h5LWluaXRpYXRlZCBDbGllbnQgSGVsbG8gbWVzc2FnZS4NCg0KV2ls bCBjbGVhbiB1cCB0aG9zZSB0ZXh0cyBiYXNlZCBvbiB0aGlzIGFuZCBvdGhlciBkaXNjdXNzaW9u cy4NCg0KQmVzdCwNCi1FcmljDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpPUFNFQyBtYWlsaW5nIGxpc3QNCk9QU0VDQGlldGYub3JnPG1h aWx0bzpPUFNFQ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vb3BzZWMNCg0K --_000_3422664693F34592A972A55B160D5B78ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4E43983B44C56F4294E05039AEEC58C1@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQpUaGFuayB5b3UgZm9yIHRoZSBkZXRhaWxlZCBj b21tZW50cy4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQgaXMgbGltaXRlZCB0byBwcm94eSBhdCB0aGUg VExTIGxheWVyLiAmbmJzcDtFeHBsaWNpdGx5IG91dCBvZiB0aGUgc2NvcGUgaXMgaW5zcGVjdGlv biBvZiB0aGUgcHJveGllZCByZWNvcmQgZGF0YS4gJm5ic3A7IFdpbGwgY2xlYW4gdXAgZGVyaXZh dGlvbnMgZnJvbSB0aGlzIHNjb3BlLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SXQgd2FzIHRoZSBpbnRlbnRpb24gdG8gY292ZXIgc2Vs ZWN0aXZlIHByb3h5aW5nIGhvd2V2ZXIsIGJlY2F1c2UgdGhhdCBpcyBhIHByYWN0aWNhbCByZXF1 aXJlbWVudCBmb3IgYW4gYWN0dWFsIGRlcGxveW1lbnQuICZuYnNwO1RoZSBpbnRlbnRpb24gd2Fz IHRvIGRpc2N1c3MgdGhlIFRMUyBsYXllciBhdHRyaWJ1dGVzIChlLmcuIFNOSSwgU2VydmVyIENl cnQpIHRoYXQgY291bGQgYmUgdXNlZCBhcyBpbnB1dCBmb3IgdGhlIGRlY2lzaW9uLg0KICZuYnNw O1RoZSBkb2N1bWVudCBhbHNvIHN0YXRlZCB0aGUgcmVxdWlyZW1lbnQgdG8gZ3JhY2VmdWxseSBy ZW1vdmUgdGhlIHByb3h5IGZyb20gdGhlIHNlc3Npb24gd2hlbiBuZWVkZWQgKGFuZCBwb3NzaWJs ZSkuICZuYnNwO0J1dCB0aGUgY3JpdGVyaWEgZm9yIHNlbGVjdGl2ZSBwcm94eWluZyBkZWNpc2lv biwgYmVpbmcgY29tcGxpYW5jZSwgcHJpdmFjeSwgcmlzayBsZXZlbCwuLi4gYXJlIG91dCBvZiB0 aGUgc2NvcGUuICZuYnNwO1RoZSBkZWNpc2lvbiBtYWtpbmcgb2Z0ZW4NCiBmYWxscyB1bmRlciB0 aGUgbGFyZ2VyIOKAnHBvbGljeeKAnSBkb21haW4gYW5kIGlzIGNvbnRyb2xsZWQgYXQgc3lzdGVt IGxldmVsIG91dHNpZGUgb2YgdGhlIHByb3h5LiAmbmJzcDtJdCBhbHNvIGxlZnQgb3V0IGRpc2N1 c3Npb24gb24gdGhlIGRldGFpbGVkIG1lY2hhbmlzbSB3aGljaCB3YXMgZGVlbWVkIGFzIGltcGxl bWVudGF0aW9uIHNwZWNpZmljLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SW4gYW55IGNhc2UsIHRoZSBwcm94eSBoYXMgdG8gY29uZHVj dCBzZWxlY3RpdmUgcHJveHlpbmcgaW4gYSBzYWZlLCBub24tZGlzcnVwdGl2ZSBtYW5uZXIuIFRo aXMgbWF5IHJlcXVpcmUgbW9yZSBkZXNpZ24gd29yayBhcyB5b3UgcG9pbnRlZCBvdXQuICZuYnNw O1RoZSBkb2N1bWVudCBjb3VsZCBkZXNjcmliZSBwb3NzaWJsZSBtZWNoYW5pc21zIHNvIHRoYXQg YW4gYWNjZXB0YWJsZSBwcmFjdGljZSBjb3VsZCBiZSBkaXNjdXNzZWQuDQogJm5ic3A7V2UgYXJl IG9wZW4gdG8gb3RoZXIgd2F5cyB0byBzaGFwZSBpdC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdj5Nb3JlIGlubGluZS4uLjwv ZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEp1bCAyOCwg MjAyMCwgYXQgMTI6MjUgQU0sIE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bXRA bG93ZW50cm9weS5uZXQiIGNsYXNzPSIiPm10QGxvd2VudHJvcHkubmV0PC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gTW9uLCBKdWwgMjAsIDIwMjAsIGF0IDAzOjM0LCBSb24g Qm9uaWNhIHdyb3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNz PSIiPlRoaXMgZW1haWwgYmVnaW5zIGEgQ2FsbCBGb3IgQWRvcHRpb24gb24gZHJhZnQtd2FuZy1v cHNlYy10bHMtcHJveHktYnANCjxiciBjbGFzcz0iIj4NCiZsdDs8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC13YW5nLW9wc2VjLXRscy1wcm94eS1icC8iIGNs YXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdhbmctb3BzZWMt dGxzLXByb3h5LWJwLzwvYT4mZ3Q7LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxiciBj bGFzcz0iIj4NCkkgdGhpbmsgdGhhdCBvdGhlcnMgaGF2ZSBzYWlkIGVub3VnaCBhYm91dCB0aGUg d2lzZG9tIG9mIGFkb3B0aW9uIG9mIHRoZSBhcHByb2FjaC4gJm5ic3A7SSBhZ3JlZSB3aXRoIHRo ZW0sIGJ1dCByZWNvZ25pemUgdGhlIHJpZ2h0IHRvIGRpc2FncmVlLjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCkV2ZW4gaWYgd2Ugd2VyZSB0byBhY2NlcHQgdGhhdCBpdCBpcyBhIGdvb2Qg aWRlYSB0byBkb2N1bWVudCBiZXN0IHByYWN0aWNlcyBmb3IgVExTIHByb3h5aW5nLCB0aGlzIGRv Y3VtZW50IGlzIG5vdCBjdXJyZW50bHkgYSBnb29kIGJhc2lzIGZvciB0aGF0IHdvcmsuICZuYnNw O1RoZSBpbnRyb2R1Y3Rpb24gaXMgYSBsaXR0bGUgZGVjZXB0aXZlLCBpbiB0aGF0IGl0IHNheXMg dGhhdCBpdCBpcyBhYm91dCBwcm94eWluZywgYnV0IHRoZXJlIGFyZSBudW1lcm91cw0KIHBsYWNl cyBpbiB0aGUgZHJhZnQgdGhhdCB0YWxrIGFib3V0IHNlbGVjdGl2ZSBwcm94eWluZyBvciBzb21l IGFtb3VudCBvZiBmb3J3YXJkaW5nIGFuZCBpbnNwZWN0aW9uLiAmbmJzcDtUaG9zZSBwcmFjdGlj ZXMgd291bGQgcmVxdWlyZSBkZXNpZ24gd29yay4gJm5ic3A7RnJvbSB3aGF0IEkgY2FuIGluZmVy IGZyb20gdGhlIGRyYWZ0LCBpdCBvZnRlbiBhc3N1bWVzIHRoZSBzYW1lIHNvcnQgb2YgYmFkIGRl c2lnbnMgdGhhdCBhcmUgc3BlY2lmaWNhbGx5IGlkZW50aWZpZWQNCiBlbHNld2hlcmUgYXMgaGF2 aW5nIGJhZCBjaGFyYWN0ZXJpc3RpY3MuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQXMg aXQgaXMsIHRoZSBkcmFmdCBpcyBub3QgY29uc2lzdGVudCBpbiB0ZXJtcyBvZiBpdHMgYXBwcm9h Y2ggYW5kIHNjb3BlLiAmbmJzcDtJZiB0aGUgZ29hbCBpcyB0byBkZXNjcmliZSBwdXJlIHByb3h5 aW5nIChhIFRMUyBzZXJ2ZXIgYW5kIGEgVExTIGNsaWVudCB0aGF0IGludGVybWVkaWF0ZSksIHRo ZW4gaXQgbmVlZHMgYSBnb29kIGVkaXQuICZuYnNwO0lmIHRoZSBnb2FsIGlzIHRvIGRlc2NyaWJl IHNlbGVjdGl2ZSBwcm94eWluZyBvciBzZWxlY3RpdmUgZm9yd2FyZGluZw0KIGFuZCBtb2RpZmlj YXRpb24gb2YgVExTIG1lc3NhZ2VzLCB0aGVuIHRoYXQgaXMgYSBtdWNoIGJpZ2dlciB0YXNrLiAm bmJzcDtXaGF0IGFyZSBvZnRlbiBzdGF0ZWQgaW4gdGhlIGRyYWZ0IGFzIHJlcXVpcmVtZW50cyBh cm91bmQgdGhpcyBwb2ludHMgYXJlIGluIGZhY3QgYXNzdW1wdGlvbnMuICZuYnNwO0FuZCBtYW55 IG9mIHRoZW0gYmFkLCBhcyBvdGhlcnMgaGF2ZSBzdGF0ZWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KLS0tIE1vcmUgZGV0YWlsIGZvbGxvd3M8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpJbnRlcm1lZGlhcmllcyBpZiB0aGlzIG5hdHVyZSBhcmUgYWRkZWQgdG8gZWZmZWN0IHNv bWUgc29ydCBvZiBjZW50cmFsaXplZCBjb250cm9sLiAmbmJzcDtUaGlzIHNlZW1zIHRvIGJlIHRo ZSBwcmltYXJ5IG1vdGl2YXRpb24gaGVyZSBhbHNvLiAmbmJzcDtJZiB3ZSBhY2NlcHQgdGhhdCB0 aGlzIGlzIGhhcHBlbmluZywgaXQgaXMgaW1wb3J0YW50IHRvIG5vdGUgdGhlIG9wZXJhdGlvbmFs IGVmZmVjdHMgb2YgdGhhdC4gJm5ic3A7Tm90IGp1c3Qgb24gdGhvc2Ugd2hvIGhhdmUNCiB0aGlz IGRlc2lyZSwgYnV0IG9uIGFsbCBvZiB0aG9zZSBhZmZlY3RlZC48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpUaGVyZSBpcyBzb21lIHRleHQgYWJvdXQgdGhlIGVmZmVjdCB0aGlzIG1pZ2h0 IGhhdmUgb24gdGhlIGFiaWxpdHkgb2YgY2xpZW50cyBvciBzZXJ2ZXJzIHRvIGludHJvZHVjZSBu ZXcgZmVhdHVyZXMgaW4gU2VjdGlvbiA0LjguICZuYnNwO1RoaXMgaXMgbm93aGVyZSBuZWFyIHN1 ZmZpY2llbnQuICZuYnNwO0J5IGJyZWFraW5nIHRoZSBjb25uZWN0aW9uIHRoZSBudW1iZXIgb2Yg c3RhY2sgbGF5ZXJzIHRoYXQgYXJlIGV4cG9zZWQgdG8gcG90ZW50aWFsIGludGVyZmVyZW5jZSwN CiB0aGUgY29uc2VxdWVuY2VzIGFyZSBub3QgbGltaXRlZCB0byBUTFMuPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KQ3JlYXRpbmcgbmVnYXRpdmUgZXh0ZXJuYWxpdGllcyBjb250cmlidXRl cyB0byBUTFMgaW50ZXJjZXB0aW9uIGJlaW5nIGRlc3Bpc2VkLiAmbmJzcDtJZiB0aGUgaW50ZW50 IGlzIHRvIGhlbHAsIHRoZW4gdGhpcyBkb2Vzbid0IGdvIG5lYXJseSBmYXIgZW5vdWdoIGluIGRl c2NyaWJpbmcgdGhlIHNlY29uZGFyeSBlZmZlY3RzIGEgcHJveHkgbWlnaHQgY2F1c2UuPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkluZGVlZCBpdCB3YXMgZHJpdmVuIGJ5IHNv cnQgb2Yg4oCcY2VudHJhbGl6ZWQgY29udHJvbOKAnSBmcm9tIHRoZSBuZXR3b3JrIChpbmNsdWRp bmcgT1Mgc3RhY2spLiBUaGUgaW5kdXN0cnkgaGFzIG1vdmVkIHRvIGEgaHlicmlkIG1vZGVsIHdp dGggYSBjb21iaW5hdGlvbiBvZiBlbmRwb2ludCAoY2xpZW50LCBzZXJ2ZXIpLCBhcHBsaWNhdGlv biwgYW5kIG5ldHdvcmsgYmFzZWQgc29sdXRpb25zLiBFbmRwb2ludC9BcHAgYmFzZWQgc29sdXRp b24NCiBwbGF5cyBhbiBpbmNyZWFzaW5nbHkgaW1wb3J0YW50IHJvbGUgYW5kIGxpa2VseSBub3Qg cmVxdWlyaW5nIGFuIGludGVybWVkaWFyeS4gTWVhbndoaWxlLCBuZXR3b3JrIGJhc2VkIHNvbHV0 aW9uIGluY2x1ZGluZyBpbnRlcm1lZGlhcnkgY29udGludWVzIHRvIGJlIGRlcGxveWVkIGZvciB2 YXJpb3VzIHJlYXNvbnMuIFdlIGNvdWxkIGFkZCBtb3JlIGFuYWx5c2lzIHJlbGF0ZWQgYSBUTFMg cHJveHkgdGhvdWdoIGEgZnVsbCBibG93biBkaXNjdXNzaW9uDQogd291bGQgYmUgb3V0IG9mIHRo ZSBzY29wZS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkZyb20gYW5v dGhlciBwZXJzcGVjdGl2ZSwgdGhlIHRyZW5kIGNhbGxzIGZvciBtb3JlIGNvbGxhYm9yYXRpb24g YmV0d2VlbiB0aGUgc29sdXRpb25zIGFuZCBlbGVtZW50cywgZXNwZWNpYWxseSBiZXR3ZWVuIGNs aWVudCBhcHBzIGFuZCB0aGUgbmV0d29yay4gJm5ic3A7SW4gc29tZSBzZW5zZSwgdGhpcyBkb2N1 bWVudCBhbHNvIHN1cmZhY2VzIHNvbWUgaXNzdWVzIGFuZCBnYXBzLiBBIHByb3h5IGNhbiBvbmx5 IG9wZXJhdGUgd2l0aGluIHRoZSBzY29wZQ0KIHNwZWNpZmllZCBieSB0aGUgY3VycmVudCBzdGFu ZGFyZHMuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQpQcm9iYWJseSB0aGUgd29yc3QgcHJvYmxlbSBpcyByb290 ZWQgaW4gU2VjdGlvbiA1LjEuICZuYnNwO1RoZSBpbnRyb2R1Y3Rpb24gZXN0YWJsaXNoZXMgdGhp cyBhcyBiZWluZyBhYm91dCBwcm94eWluZywgYnV0IHRoZXJlIGFyZSBzZXZlcmFsIHBsYWNlcyB0 aGF0IHRhbGsgYWJvdXQgbm90LXByb3h5aW5nIHNvbWV0aW1lcy48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpTZWxlY3RpdmUgbm9uLXByb3h5aW5nIG9wZW5zIHRoZSBkb2N1bWVudCB1cCB0 byBhIHdob2xlIG5ldyBzZXQgb2YgcHJvYmxlbXMgdGhhdCBhcmlzZSBmcm9tIHBvb3IgZGVzaWdu cyBmb3IgZGVjaWRpbmcgbm90IHRvIHByb3h5LiAmbmJzcDtUaGVyZSBpcyBub3QgbmVhcmx5IGVu b3VnaCBkZXRhaWwgaGVyZSB0byBhZGRyZXNzIHRoaXMgcHJvYmxlbSBwcm9wZXJseS4gJm5ic3A7 QSAmcXVvdDtnb29kJnF1b3Q7IGRlc2lnbiBmb3Igc2VsZWN0aXZlIFRMUyBwcm94eWluZyBkb2Vz IG5vdA0KIHNlZW0gdG8gYmUgdGhlIGJhc2lzIG9mIHRoZSByZWNvbW1lbmRhdGlvbnMuICZuYnNw O0knbGwgZ2l2ZSBhIGZldyBleGFtcGxlcyBvZiBwcm9ibGVtcy48YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5Gcm9tIHRoZSBTZWN0 aW9uIDQuOCBhZ2Fpbjo8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj50aGUgVExTIHByb3h5IE1VU1QgY29u ZHVjdCBwcm9wZXIgVExTIHByb3RvY29sIGNoZWNrcyB0byBhdm9pZCBmYWxzZSBpZGVudGlmaWNh dGlvbiBvZiBUTFMgaGFuZHNoYWtlcywgd2hpbGUgdGFraW5nIHNwZWNpYWwgY2FyZSBub3QgdG8g Y29udHJpYnV0ZSB0byBwcm90b2NvbCBvc3NpZmljYXRpb24uICZuYnNwOzxiciBjbGFzcz0iIj4N CjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NClRoaXMgcHJhY3RpY2UgaGFzIGJlZW4gZGly ZWN0bHkgcmVzcG9uc2libGUgZm9yIG1vcmUgb3NzaWZpY2F0aW9uIHRoYW4gaW50ZXJtZWRpYXRp b24sIG5vIG1hdHRlciB3aGF0IHF1YWxpZmljYXRpb24gZXhpc3RzLiAmbmJzcDs8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpJZiBwZXItZGVzdGluYXRpb24gbm90LXByb3h5aW5nIGlzIHJl cXVpcmVkLCB0aGUgcHJveHkgY2FuIGNvbm5lY3QgdG8gYSBzZXJ2ZXIsIGRldGVybWluZSB0aGF0 IHRoZSBzZXJ2ZXIgaXMgb24gYSBub24tcHJveHkgbGlzdCwgYW5kIHRoZW4gY29tcGxldGUgdGhl IGhhbmRzaGFrZSB3aXRoIHRoZSBjbGllbnQgKHdpdGggYSBjYXZlYXQgcmVnYXJkaW5nIEVDSCBo ZXJlKS4gJm5ic3A7SSBjYW4gZ3Vlc3Mgd2h5IHRoaXMgZG9lc24ndCBoYXBwZW4gKGl0J3MNCiBl eHBlbnNpdmUgYW5kIHNlZSBhbHNvIFNlY3Rpb24gNS40KSwgYnV0IHRoYXQgZG9lc24ndCBleGN1 c2UgdGhlIHByYWN0aWNlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBmb2xsb3dp bmcgdGV4dCBmcm9tIFNlY3Rpb24gNS4zIGlzIGRlZXBseSBwcm9ibGVtYXRpYzo8YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtBIGRlY3J5cHRpb24gcG9saWN5IGRlY2lz aW9uIE1BWSBiZSBtYWRlIGJhc2VkIG9uIHRoZSBzZXJ2ZXI8YnIgY2xhc3M9IiI+DQombmJzcDsm bmJzcDtjZXJ0aWZpY2F0ZSBvciBvdGhlciB0cnVzdHdvcnRoeSBwYXJhbWV0ZXJzLiAmbmJzcDtU byB2ZXJpZnkgcG9zc2Vzc2lvbiBvZjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwO3ByaXZhdGUg a2V5cyB0aGF0IGFyZSBhc3NvY2lhdGVkIHdpdGggYSBwYXJ0aWN1bGFyIHNlcnZlcjxiciBjbGFz cz0iIj4NCiZuYnNwOyZuYnNwO2NlcnRpZmljYXRlLCB0aGUgcHJveHkgU0hPVUxEIGNvbXBsZXRl IGFuIG91dC1vZi1iYW5kIFRMUyBoYW5kc2hha2U8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDt3 aXRoIHRoZSBzYW1lIFRMUyBzZXJ2ZXIgSVAgYWRkcmVzcyBhbmQgVENQIHBvcnQgYXMgdGFyZ2V0 ZWQgYnkgdGhlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7VExTIGNsaWVudC48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpJdCBpcyBwb3NzaWJsZSB0aGF0IHRoZSBhdXRob3JzIG1pc3Vu ZGVyc3RhbmQgaG93IFRMUyB3b3JrcywgYnV0IHRoaXMgY2hlY2sgd29uJ3Qgd29yay4gJm5ic3A7 Tm90IG9ubHkgYmVjYXVzZSBUTFMgMS4zIGVuY3J5cHRzIGluZm9ybWF0aW9uLCBidXQgYmVjYXVz ZSB0aGlzIGlzIG9ubHkgbmVjZXNzYXJ5IGlmIHRoZSBwcm94eSBmb3J3YXJkcyBhIENsaWVudEhl bGxvIGZyb20gdGhlIGNsaWVudCB0byB0aGUgc2VydmVyLiAmbmJzcDtBdCB0aGF0IHBvaW50LCBp dA0KIGlzIHRvbyBsYXRlIGFuZCB0aGUgZGFtYWdlIGhhcyBiZWVuIGRvbmUgKHNlZSBBbmRyZWkn cyByZXZpZXcpLjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXY+VW5sZXNzIEkgbWlzdW5kZXJzdG9vZCBpdCwgdGhlIGRvY3VtZW50IGlzIHN1Z2dlc3Rpbmcg dGhlIHNhbWUgYXMgeW91IGxpc3RlZC4gJm5ic3A7QmFzaWNhbGx5LCB0aGUgcHJveHkgbWFrZXMg YSBzZXBhcmF0ZSBjb25uZWN0aW9uIHRvIHRoZSBzZXJ2ZXIgYXMgYSBjbGllbnQgKOKAnG91dC1v Zi1iYW5k4oCdIHdydCB0byB0aGUgb3JpZ2luYXRpbmcgY2xpZW50LXNlcnZlciBjb25uZWN0aW9u KSwgcmV0cmlldmVzIHRoZSBzZXJ2ZXLigJlzIGNlcnRpZmljYXRlDQogZnJvbSB0aGUgcHJveHkt c2VydmVyIGhhbmRzaGFrZSwgYW5kIGRldGVybWluZXMgd2hldGhlciB0aGUgc2VydmVyIGlzIG9u IGEgbm9uLXByb3h5aW5nIGxpc3Qgb3Igbm90LiAmbmJzcDtJZiBvbiB0aGUgbGlzdCwgdGhlIHBy b3h5IGZvcndhcmRzIHRoZSBvcmlnaW5hdGluZyBjbGllbnQgQ0ggYXMgaXMgdG8gdGhlIHNlcnZl ciwgYW5kIHN0ZXBzIGF3YXlzIGZyb20gdGhlIG9yaWdpbmF0aW5nIGNsaWVudC1zZXJ2ZXIgaGFu ZHNoYWtlLjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+VGhlcmUgYXJl IGFkZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgaW4gdGhpcyBhcHByb2FjaCAobGF0ZW5jeSBldGMu KS4gVGhlIGRvY3VtZW50IGludGVudGlvbmFsbHkgbGVmdCBvdXQgdGhlIGRldGFpbHMgdG8gaW1w bGVtZW50YXRpb25zLCBidXQgY291bGQgYWxzbyBjb3ZlciB0aGVtIGlmIG5lZWRlZC48L2Rpdj4N CjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGVyZSBhcmUgYSBidW5jaCBv ZiBwbGFjZXMgd2hlcmUgcHVyZSBwcm94eWluZyAtIGFzIGRlc2NyaWJlZCBpbiB0aGUgaW50cm9k dWN0aW9uIC0gaXMgbm90IGFzc3VtZWQuICZuYnNwO1RoaXMgbGVhZHMgdG8gdGhlIHNhbWUgcHJv YmxlbXMgYWxyZWFkeSBjaXRlZC4gJm5ic3A7Rm9yIGluc3RhbmNlLCBpbiBTZWN0aW9uIDQuMjo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj5UaGUgcHJveHkgTUFZIHJlbW92ZSBjaXBoZXIgc3VpdGVzIGZyb20gYSBjbGllbnQtaW5p dGlhdGVkIENsaWVudCBIZWxsbyBtZXNzYWdlLCBhZGQgbmV3IGNpcGhlciBzdWl0ZXMsIGFuZCBy ZS1vcmRlciB0aGVtIGluIHRoZSBwcm94eS1pbml0aWF0ZWQgQ2xpZW50IEhlbGxvIG1lc3NhZ2Uu PGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PldpbGwgY2xlYW4gdXAgdGhvc2Ug dGV4dHMgYmFzZWQgb24gdGhpcyBhbmQgb3RoZXIgZGlzY3Vzc2lvbnMuPC9kaXY+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5CZXN0LDwvZGl2Pg0KPGRpdj4tRXJpYzwvZGl2Pg0K PGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT1BTRUMgbWFpbGluZyBs aXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9QU0VDQGlldGYub3JnIiBjbGFzcz0i Ij5PUFNFQ0BpZXRmLm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL29wc2VjPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_3422664693F34592A972A55B160D5B78ciscocom_-- From nobody Tue Jul 28 14:57: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 6A6C53A0A56; Tue, 28 Jul 2020 14:57:41 -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 SKhTWeNtqsQY; Tue, 28 Jul 2020 14:57: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 A8E483A09AF; Tue, 28 Jul 2020 14:57:38 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2C3B6F40727; Tue, 28 Jul 2020 14:57:13 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, tls@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200728215713.2C3B6F40727@rfc-editor.org> Date: Tue, 28 Jul 2020 14:57:13 -0700 (PDT) Archived-At: Subject: [TLS] =?utf-8?q?RFC_8744_on_Issues_and_Requirements_for_Server_N?= =?utf-8?q?ame_Identification_=28SNI=29_Encryption_in_TLS?= 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 Jul 2020 21:57:47 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8744 Title: Issues and Requirements for Server Name Identification (SNI) Encryption in TLS Author: C. Huitema Status: Informational Stream: IETF Date: July 2020 Mailbox: huitema@huitema.net Pages: 13 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-sni-encryption-09.txt URL: https://www.rfc-editor.org/info/rfc8744 DOI: 10.17487/RFC8744 This document describes the general problem of encrypting the Server Name Identification (SNI) TLS parameter. The proposed solutions hide a hidden service behind a fronting service, only disclosing the SNI of the fronting service to external observers. This document lists known attacks against SNI encryption, discusses the current "HTTP co-tenancy" solution, and presents requirements for future TLS-layer solutions. In practice, it may well be that no solution can meet every requirement and that practical solutions will have to make some compromises. This document is a product of the Transport Layer Security Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Jul 28 15:14: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 1522C3A07F0; Tue, 28 Jul 2020 15:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 kjWjb_DUdDUn; Tue, 28 Jul 2020 15:14:51 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 3A21C3A07E8; Tue, 28 Jul 2020 15:14:51 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id d14so20324920qke.13; Tue, 28 Jul 2020 15:14:51 -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=8Og7KvmUD4hFJG5EgUHfi3Xz9+kVkv0wUYcmXol9eDc=; b=V63U5yojwvlSkkNfjkghD62dslMc4dVYXG06OrRzz4K2AuTIbGIEN8HJ2bjvP2/15t BiieVXw6lfZh0tBPXplrhraamwQiMA/dBpsz4hTiOukn90MmfvzCGnJM+aCm4PBrcDRN n7+Qy7w0vhBHDhRtEBGU6WIh6A5kQ29wh/yeoIZE1IT6BKvt/cR+lZsSmiBiLRgjPObe OlN6TG3bSQIH7i+mz7OvrLhobIJgIxwrPDwBfZ05tORtFVhKjhpBtt0QTsVtFD6sP1rT MAuw61U6JiqCjUJxwQDtuGpM9RkcmUHOTylgf8opMqQs9dLRH9pkzOoCRgHp0cPFxQ+5 GbLg== 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=8Og7KvmUD4hFJG5EgUHfi3Xz9+kVkv0wUYcmXol9eDc=; b=tsmLSwU5GPxFpwBbIZ+cD1KhHwsgE2Ck8Ym6LVJ9Wj1hnJr6b+pzX0xbCxyGF1ro3d 80GQlYXpTtEZN1nYFYstic4Y5pDJg0Q/9I7fcLqGAjwYo6SRzIrC5gfWuulRyRw+eprT UB6rOccPREb4WdPbLNxidVPY3YGs8Z7N5OF4wcvLGWwVoKN2UrwfyShVOnTgdKV+K+lU 16mkul1vxxIaWX/is8Qj4pIcoTTc2bTZnLHDg5uF5yd3gKXk2BK4pGDovj33nFIDFvUg FLUYujJbLFgPJdRd9eBlb6UugaEmtGNuFL0/KaaAcVrmdSybtorsGRmRFXwAlVfBbrX8 BNwQ== X-Gm-Message-State: AOAM532VoV7CGqNvmv4nHge3Lu2y04cazjRDQXpbEqcgalYkQzXyiUFD DvLZbRmeODliik7ARibCBJln35Hkqlpt3EmmNWo= X-Google-Smtp-Source: ABdhPJzebM/8ftZDu7CS3oVfyFntG2HNVKeHUGvmOQkfkQVDsgFxK/4FfIDEgrySXuOMyDUCL49sqKYTxM9CT11JC4M= X-Received: by 2002:a05:620a:a05:: with SMTP id i5mr14640884qka.444.1595974490282; Tue, 28 Jul 2020 15:14:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jen Linkova Date: Wed, 29 Jul 2020 08:14:38 +1000 Message-ID: To: tom petch Cc: opsec WG , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact 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 Jul 2020 22:14:53 -0000 On Wed, Jul 29, 2020 at 2:07 AM tom petch wrote: >> This email starts the WG Last Call for draft-ietf-opsec-ns-impact , >> Impact of TLS 1.3 to Operational Network Security Practices, >> https://datatracker.ietf.org/doc/draft-ietf-opsec-ns-impact/. > > OPPOSE (yes, I am shouting) > > This is nowhere near ready and putting it forward so soon is ... well lud= icrous comes to mind. > > After WG adoption, comments were made to which there was no acknowledgeme= nt, no response, I was about to oppose the adoption of the other I-D from = these authors on the grounds that until they respond to comments nothing el= se should happen because when they do there are more comments waiting to be= aired. I am still of that view. Sorry, it's partially my fault. I did explicitly ask the authors to address your comments and submit a new version. I should have double-checked that the new version incorporates the feedback. Dear authors, would you be able to address Tom's comments ASAP so the new revision can be reviewed during the WGLC? > I do see that a revised I-D has just appeared in among the thousand or so= I-D that appear around the time of an IETF meeting, a timing that I someti= mes think is designed to let it slip through unnoticed. Given all those ot= her I-D - silly authors - it may be more than three weeks before I get my t= houghts together. Just to clarify: would you prefer not to have the WGLC around IETF weeks at all? --=20 SY, Jen Linkova aka Furry From nobody Tue Jul 28 15:41: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 300783A09E8; Tue, 28 Jul 2020 15:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=bHyrHEU2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=HoVCL3nR 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 XlLcQvKe4vmI; Tue, 28 Jul 2020 15:41:02 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CE553A09E7; Tue, 28 Jul 2020 15:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3002; q=dns/txt; s=iport; t=1595976062; x=1597185662; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=gQVtlerOwLO1CcoVrurfKMU4M1EQfQQsyKitUn2EklI=; b=bHyrHEU2zuHjQQaNB2Xc4+U8fNfki0rJBn3jCjQi692rsA9FDUgGsI6u 3XXUhh+O0QS9v3uJU6ZTgKyOZ0JjBvvD2pYRrbL+5PECiFtlcB+ipVsKO itsmJ21BfV3qHrFd0kLw8zQe4KMzBPuQ9vpDHzKhlMHBXYWH/NbwAlKR/ k=; IronPort-PHdr: =?us-ascii?q?9a23=3AO9WAHhZ8cXRE8RPfgmwWRuD/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaVD4re4vNAzeHRtvOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZXxYlTTpju56jtBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBBwCwqCBf/4wNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUqBUiMuB29YLywKhCqDRgONMiWKAo5fgUKBEQNVCwEBAQw?= =?us-ascii?q?BARgLCgIEAQGETAIXggkCJDgTAgMBAQsBAQUBAQECAQYEbYVcDIVxAQEBAwE?= =?us-ascii?q?BARALBhEMAQEsCwEPAgEIDgoCAiYCAgIfBgsVEAIEAQ0FIoMEAYJLAw4gAQ6?= =?us-ascii?q?kYgKBOYhhdoEygwEBAQWBR0FCgmYNC4IOAwaBDiqCbYNZgjOEBBqCAIERJww?= =?us-ascii?q?Qgk0+ghpCAQEDAYEhBQESASGDFjOCLY8ngz+iQ04Kgl+IWIwjhHUCAR6faZI?= =?us-ascii?q?Xii6CYZILAgQCBAUCDgEBBYFqI2dwcBU7KgGCPlAXAg2OHgwXg06FFIVCdDc?= =?us-ascii?q?CBgEHAQEDCXyOawGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,408,1589241600"; d="scan'208";a="550738275" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jul 2020 22:41:01 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 06SMf1T7021560 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 28 Jul 2020 22:41:01 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 17:41:01 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 28 Jul 2020 18:40:59 -0400 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 28 Jul 2020 18:40:59 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bj+buaj87zeKaeOghv7ITaZh5dNcJzyZznGyEdu/qPdmE6J1Z1Zuxp9oudUIbzL0w/fEZYjUu10vMxWIXeFFNNjtM/uWTr3AVEkqNheY7Ys+oYZwEcGFyepdwUO4zWrPicTaTnVDH9jUaiN17vaK+PSHByV4bp4wCB5/ppjj3CRSVCH8DmvJ24imWqW/7Uvub7ilo67AdHuHwsjigy4vEQGoNnJoGYo7Vx+Yhu7onbdD7N5ZpDQ9St5I9Pt5ZBCcxainf+qe/d2Q/+qn9+UALG29/ycuf1HZgxNWa0aEOAbPghRP0yNlT5ikTRd2BNrchnm7SlP0S06bt4AthEiQjw== 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=gQVtlerOwLO1CcoVrurfKMU4M1EQfQQsyKitUn2EklI=; b=F/3lwov9MxfliRa1yb1vMAY0O9iBP3lbGMiy4cOvNJUro9PqyTnajqleY9CMvNYl2tTUXPJcmXZZ56SC4XQv1mbaREezFs7/9CARbmTevt+tkhrCGmEOVBgry1WMeeLv6QvGTEb01bCeW8k/ZZy7fj3PCb3DKQAB2ee1v39e65HqMtf1F1ngkJ9xPUupYutRdwsixhtO3+ukti9oDzqtuf+vcjMG6khHU7cH1WXx27bZsrHZYMj3iWyHy2yrdpwboDlhLWem8Q27Y+g5WKsk37XVK23B9lzKxnKfY+o23glNq97IwedBYCCQJD3boXFoIcjd3GrnIsi8qfxZK9tg9w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gQVtlerOwLO1CcoVrurfKMU4M1EQfQQsyKitUn2EklI=; b=HoVCL3nRX1Fr2w3D2nqmn2eT7sFXo8hfxWyuTLolOObxwdrtY0NEFnR9robZcX3eTKZ4WgRG94bjDHJ9VfYDS/cA3FgwdktlrkyOXFI3HupWReV08aaE+j5SuO7/GyAb1xDzgfjk6e+QjlsKXDgqcHrwq2vq6q1vWovJz+sJR6c= Received: from BY5PR11MB4070.namprd11.prod.outlook.com (2603:10b6:a03:181::16) by BYAPR11MB2981.namprd11.prod.outlook.com (2603:10b6:a03:83::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Tue, 28 Jul 2020 22:40:58 +0000 Received: from BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::e42f:216e:af3e:8ce5]) by BY5PR11MB4070.namprd11.prod.outlook.com ([fe80::e42f:216e:af3e:8ce5%7]) with mapi id 15.20.3216.033; Tue, 28 Jul 2020 22:40:58 +0000 From: "Nancy Cam-Winget (ncamwing)" To: Jen Linkova , tom petch CC: opsec WG , "tls@ietf.org" Thread-Topic: [TLS] [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact Thread-Index: AQHWZPlVwHJkW1nKsUCD9A1wLaLJ+qkdjwQA//+SAoA= Date: Tue, 28 Jul 2020 22:40:58 +0000 Message-ID: <15572610-7090-441F-B0AF-DEE789DBC42D@cisco.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/10.10.18.200713 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [73.162.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2297f609-ec14-4af1-ae60-08d833474c55 x-ms-traffictypediagnostic: BYAPR11MB2981: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7BbmhPD47xqL43hT5QeJj7ZcDJGcxzi5XpL/l1edoDUdaw5oCeNNL2rNPTCfhgMVX1QaFNXgXs2gvTn2SlrHONu8oXNcGm7DhbnOjauAuWWl0BxaSzUT/bCUzyLRArV9IF9mZkXiVeM2tzd5LEpgKNEKPKZ7eDqMzRTlz9wsPxVLvr66UgUprVZiXnsrbss3+hTs8ZPQot/w8KZWN5qcHyUQZlRpSIL1GZU0CLE1Q04uy9RQD4Vu/E7Qx+KJSmsL0SSROm+QLdcduiDGdWi+P3V+3sBHTrA/bpDCXo2NkTBPoNJkDzUKXxqy9gYQwwAQI+l/5qNovIXjoT9YQ9hitzbe8y1q9GFb5I9QZFWV7kqntXNHHkgl9efFaIYXrR8Ne5LlVCarPxmEvLgSDkBvEg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4070.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(6029001)(4636009)(346002)(396003)(136003)(39860400002)(376002)(366004)(64756008)(4326008)(6486002)(86362001)(2616005)(316002)(2906002)(66556008)(71200400001)(66446008)(8936002)(478600001)(6512007)(36756003)(54906003)(76116006)(26005)(6506007)(53546011)(186003)(8676002)(966005)(5660300002)(83380400001)(110136005)(33656002)(66476007)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: rkhtlq9kwlSmfq8IS8ZI2aF10yDrcDb+zVm+2dDuJEZG+t70wrReWaJIDkM03WP5Z2IYI68onGL6GBxkJ558yHWbKd+s0as06EvBXkdI1xqn7K/ulXoXHtEjclLi7IUCcwi/OEG/fcLVWR/IryyGbeUBh04HuHtO2LHJlHhJeSh9KbAFW5CO1bBSzNmtRDnguI8zKoqd2zTHW3JF3B3hmgIc3H8auR93X0LLm/R8fhB8ijTI0fo7gW9hoEaYoV2L+mTgmWL4jg9e8XtUOywbl848WxXmTEsJShVwfEVR0My7+vmxNh7tlqUsjb6p9QHQnfXdZ3NphHsGOjzy2/yMmtBLVmk8hEz3QwhOmH5byRjdPl6Cxngvb6T+vfenPzcFAONzw+NlhPBNjOFnT18e0OnrWHjrAZlx0dSl5zdbUVVI9CL3YjNkHa1xQM+Uszl27Cji4H+EL6scsiwwVRmae01EZPhixTcjGe83KAFmDlVLHef4xP9shlLKm16pF+v3xu8YSJQRj0uIG/lBwt2BFzDBCtmMkLvwkV/DzXy6UgQjpcFSh4I199HAbpcVAI+JGW/d8/RkcDjC8IS58ePWVLdlzcNxAUDoz19ccXgLzIhl0VRsdja9bICEm6WPwrpr4in4Pfv612YlxQx4hEhklA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <30C4C47146282D47938EC885D183C5A5@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4070.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2297f609-ec14-4af1-ae60-08d833474c55 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 22:40:58.7714 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mWHOB81LM+HnpIBzhpFvVgjF+PrUTpFuO738zFD5BsZUbdtDbGYZv397twzE4JVkYwElacOWhJm+yvGd2CRnsA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2981 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [TLS] [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact 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 Jul 2020 22:41:05 -0000 SGkgSmVuLA0KWWVzLCB5ZXMuLi4uYW5kIGFnYWluIGFwb2xvZ2llcyBmb3IgbWlzc2luZyBUb20n cyBjb21tZW50cy4gIEZvciBzb21lIHJlYXNvbiB3ZSAodGhlIGF1dGhvcnMpIGRpZCBub3Qgc2Vl IGhpcyBlbWFpbCBjb21lIHRocnUsIGJ1dCBJIGRpZCBjb3ZlciBLYXRobGVlbidzIGFuZCBKYXNv bidzIGNvbW1lbnRzIChhbmQgZGlkIHJlc3BvbmQgdG8gdGhlbSB3aGVuIHRoZWlyIGNvbW1lbnRz IGNhbWUgaW4pLg0KDQpXaWxsIHRyeSB0byBkbyBpdCBpbiB0aGUgbmV4dCBkYXkgb3Igc28uLi4u DQpCZXN0LCBOYW5jeQ0KDQrvu79PbiA3LzI4LzIwLCAzOjE1IFBNLCAiVExTIG9uIGJlaGFsZiBv ZiBKZW4gTGlua292YSIgPHRscy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBmdXJyeTEz QGdtYWlsLmNvbT4gd3JvdGU6DQoNCiAgICBPbiBXZWQsIEp1bCAyOSwgMjAyMCBhdCAyOjA3IEFN IHRvbSBwZXRjaCA8aWV0ZmFAYnRjb25uZWN0LmNvbT4gd3JvdGU6DQogICAgPj4gVGhpcyBlbWFp bCBzdGFydHMgdGhlIFdHIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi1vcHNlYy1ucy1pbXBhY3Qg LA0KICAgID4+IEltcGFjdCBvZiBUTFMgMS4zIHRvIE9wZXJhdGlvbmFsIE5ldHdvcmsgU2VjdXJp dHkgUHJhY3RpY2VzLA0KICAgID4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtb3BzZWMtbnMtaW1wYWN0Ly4NCiAgICANCiAgICA+IDx0cD4NCiAgICA+IE9QUE9T RSAoeWVzLCBJIGFtIHNob3V0aW5nKQ0KICAgID4NCiAgICA+IFRoaXMgaXMgbm93aGVyZSBuZWFy IHJlYWR5IGFuZCBwdXR0aW5nIGl0IGZvcndhcmQgc28gc29vbiBpcyAuLi4gd2VsbCBsdWRpY3Jv dXMgY29tZXMgdG8gbWluZC4NCiAgICA+DQogICAgPiBBZnRlciBXRyBhZG9wdGlvbiwgY29tbWVu dHMgd2VyZSBtYWRlIHRvIHdoaWNoIHRoZXJlIHdhcyBubyBhY2tub3dsZWRnZW1lbnQsIG5vIHJl c3BvbnNlLCAgSSB3YXMgYWJvdXQgdG8gb3Bwb3NlIHRoZSBhZG9wdGlvbiBvZiB0aGUgb3RoZXIg SS1EIGZyb20gdGhlc2UgYXV0aG9ycyBvbiB0aGUgZ3JvdW5kcyB0aGF0IHVudGlsIHRoZXkgcmVz cG9uZCB0byBjb21tZW50cyBub3RoaW5nIGVsc2Ugc2hvdWxkIGhhcHBlbiBiZWNhdXNlIHdoZW4g dGhleSBkbyB0aGVyZSBhcmUgbW9yZSBjb21tZW50cyB3YWl0aW5nIHRvIGJlIGFpcmVkLiAgSSBh bSBzdGlsbCBvZiB0aGF0IHZpZXcuDQogICAgDQogICAgU29ycnksIGl0J3MgcGFydGlhbGx5IG15 IGZhdWx0LiBJIGRpZCBleHBsaWNpdGx5IGFzayB0aGUgYXV0aG9ycyB0bw0KICAgIGFkZHJlc3Mg eW91ciBjb21tZW50cyBhbmQgc3VibWl0IGEgbmV3IHZlcnNpb24uIEkgc2hvdWxkIGhhdmUNCiAg ICBkb3VibGUtY2hlY2tlZCB0aGF0IHRoZSBuZXcgdmVyc2lvbiBpbmNvcnBvcmF0ZXMgdGhlIGZl ZWRiYWNrLg0KICAgIA0KICAgIERlYXIgYXV0aG9ycywgd291bGQgeW91IGJlIGFibGUgdG8gYWRk cmVzcyBUb20ncyBjb21tZW50cyBBU0FQIHNvIHRoZQ0KICAgIG5ldyByZXZpc2lvbiBjYW4gYmUg cmV2aWV3ZWQgZHVyaW5nIHRoZSBXR0xDPw0KICAgIA0KICAgID4gSSBkbyBzZWUgdGhhdCBhIHJl dmlzZWQgSS1EIGhhcyBqdXN0IGFwcGVhcmVkIGluIGFtb25nIHRoZSB0aG91c2FuZCBvciBzbyBJ LUQgdGhhdCBhcHBlYXIgYXJvdW5kIHRoZSB0aW1lIG9mIGFuIElFVEYgbWVldGluZywgYSB0aW1p bmcgdGhhdCBJIHNvbWV0aW1lcyB0aGluayBpcyBkZXNpZ25lZCB0byBsZXQgaXQgc2xpcCB0aHJv dWdoIHVubm90aWNlZC4gIEdpdmVuIGFsbCB0aG9zZSBvdGhlciBJLUQgLSBzaWxseSBhdXRob3Jz IC0gaXQgbWF5IGJlIG1vcmUgdGhhbiB0aHJlZSB3ZWVrcyBiZWZvcmUgSSBnZXQgbXkgdGhvdWdo dHMgdG9nZXRoZXIuDQogICAgDQogICAgSnVzdCB0byBjbGFyaWZ5OiB3b3VsZCB5b3UgcHJlZmVy IG5vdCB0byBoYXZlIHRoZSBXR0xDIGFyb3VuZCBJRVRGDQogICAgd2Vla3MgYXQgYWxsPw0KICAg IA0KICAgIC0tIA0KICAgIFNZLCBKZW4gTGlua292YSBha2EgRnVycnkNCiAgICANCiAgICBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFRMUyBtYWls aW5nIGxpc3QNCiAgICBUTFNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3Rscw0KICAgIA0KDQo= From nobody Tue Jul 28 17:24: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 147503A0CC6; Tue, 28 Jul 2020 17:24:05 -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 fJvP7D-H6B56; Tue, 28 Jul 2020 17:24:03 -0700 (PDT) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 98E783A0CB4; Tue, 28 Jul 2020 17:24:02 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id d2so6388968lfj.1; Tue, 28 Jul 2020 17:24:02 -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=m6IhJAtiKndgiNdN1ZPIKIIUwrNDZtIw8ze5LktucsQ=; b=eo0KaVLK3Fs9OFu9RWLsT3koM4J1t2e/4hnacshNH87voJpMXoiZuUcdp9EbgIxpm0 Hm5unEY4GumzzHAYQWnNZg+ulOiB18nFzZIje3BrYos0ltNWLUUog9zeShzuARwQtYgL WJ75fWeY7Is4oDItC7jeUpWSaCnWRRx8v1WwjxSKOJiKt2qJUeUlPgbhJuPGUfIufKYQ oe0HkaMBvBKgn7g1Sv4pLzWtbmjmieB166l1BQQYUy1jqryMMRixQUFpbzdUeP2n0cFm d4fS0Y0G1Kv6Ck5qpdEmLJ0DOfmR/8GJe6KacULOAiq6WBJNlyDvAUcpa61qu8DWcYR8 Y0gA== 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=m6IhJAtiKndgiNdN1ZPIKIIUwrNDZtIw8ze5LktucsQ=; b=fP0tdy38XPFe+MvY0WysFRMfEQ+VxB+HLjjS9RYZpPG+2emhXx7/sUtNzp0CRcLSXs Qyjr4EJ704310El3+1htRS2tiyfEXFKeSAfvJmOoX0wfxT09+Azs7D12L2Enapu0CCfX 8cJKCBNyhdO1Apeu9mkgiWVFPBgHzBUgVu87NZwjeyGANxwAb6rldExKeI+EXOwBbBSg sLlA2lnrEYCmLLDc56htY6Amf3PdgCtq8qsMk6JSHNXDg4FDpJQeCBEKqbZn3wk7t7fD etAfeEvfcdllImoVCtOg8o2Qon7yGyfHvaLxszT9H5hxFbIhDvkvh0ZeESPBBYmx+V4w AUMQ== X-Gm-Message-State: AOAM533kbzoHbV+EH5xyHCOFaVULWGnhXwvjw7dOx6fGpEvLuraNDFQ+ qDV2snAj4LNt0dkkmf7S2lVZDIErMZtoJgMZp0o= X-Google-Smtp-Source: ABdhPJzhNbFrBMw95/vhudknTZzO761ubmEPKDtPJuUijRpdkTsWPB/4oFslvSVUegUPsJJlIC70D+nUF015DJyl77g= X-Received: by 2002:a19:f601:: with SMTP id x1mr16155428lfe.209.1595982240768; Tue, 28 Jul 2020 17:24:00 -0700 (PDT) MIME-Version: 1.0 References: <4937FCE4-23EF-4585-8675-C07F3B347AC6@cisco.com> In-Reply-To: <4937FCE4-23EF-4585-8675-C07F3B347AC6@cisco.com> From: Watson Ladd Date: Tue, 28 Jul 2020 20:23:48 -0400 Message-ID: To: "Eric Wang (ejwang)" Cc: Stephen Farrell , Jen Linkova , OpSec Chairs , OPSEC , "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000087681405ab899264" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 00:24:05 -0000 --00000000000087681405ab899264 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jul 27, 2020, 1:15 AM Eric Wang (ejwang) wrote: > Hi Stephen, > > Thanks for your feedback. I=E2=80=99d like to clarify, given the reality= today > that CDN/load balancers and enterprises deploy TLS proxy, this draft is > merely to lay out a baseline guidance to the implementation and > operation[1]. It is not meant to analyze "use and abuse" or "pros and > cons", for which there were many discussions and publications in the past > and the draft references some of them. > CDNs are usually aware of application level semantics and have some interesting security problems when not. There's no generic safe way to terminate TLS, and that's a real problem for this draft: it needs to be specific to certain use cases. > Given the progression of TLS and its wide adoption, the use of TLS proxy > is also becoming a practice and is growing in enterprise/CDN. We felt it= =E2=80=99s > a good thing for the community to define a set of best practices for > practitioners to reference when implementing and operating TLS proxy. > Without one, TLS deployments would be negatively impacted. Also, given > some of the implementation inconsistencies noted during the TLS 1.3 > evolution, we felt a bcp guide could help the community moving forward. > That=E2=80=99s the purpose of this draft. > We've seen middlebox writers ignore black letter extensibility requirements in the existing RFCs and adopt broken patterns before. Why will another draft help? > Best, > -Eric > > [1] https://tools.ietf.org/html/draft-wang-opsec-tls-proxy-bp-00#section-= 1 > > > On Jul 25, 2020, at 7:07 AM, Stephen Farrell > wrote: > > > I oppose adoption. While there could be some minor benefit > in documenting the uses and abuses seen when mitm'ing tls, > I doubt that the effort to ensure a balanced document is at > all worthwhile. The current draft is too far from what it'd > need to be to be adopted. > > Send to ISE. > > S. > > On 23/07/2020 02:30, Jen Linkova wrote: > > One thing to add here: the chairs would like to hear active and > explicit support of the adoption. So please speak up if you believe > the draft is useful and the WG shall work on getting it published. > > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica > wrote: > > > Folks, > > > > This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp. > > > > Please send comments to opsec@ietf.org by August 3, 2020. > > > > Ron > > > > > Juniper Business Use Only > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > > > > -- > SY, Jen Linkova aka Furry > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > <0x5AB2FAF17B172BEA.asc>_______________________________________________ > 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 > --00000000000087681405ab899264 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 27, 2020, 1:15 AM Eric Wang (ejwang) <e= jwang=3D40cisco.com@dmarc.ietf.org> wr= ote:
Hi Stephen,=C2=A0
=C2=A0
Thanks for your feedback.=C2=A0 I=E2=80=99d like to clarify, given the real= ity today that CDN/load balancers and enterprises deploy TLS proxy, this dr= aft is merely to lay out a baseline guidance to the implementation=C2=A0and= operation[1].=C2=A0 It is not meant to analyze "use and abuse" or "pros and cons", for which there were many discus= sions and publications in the past and the draft references some of them.

CDNs are usually aware of application level semantics and h= ave some interesting security problems when not.
There's no generic safe way to terminate TLS, = and that's a real problem for this draft: it needs to be specific to ce= rtain use cases.


Given the progression of TLS and its wide adoption, the use of TLS proxy is= also becoming a practice and is growing in enterprise/CDN.=C2=A0 We felt i= t=E2=80=99s a good thing for the community to define a set of best=C2=A0pra= ctices for practitioners to reference when implementing and operating TLS proxy.=C2=A0 Without one, TLS deployments would be negat= ively impacted.=C2=A0 Also,=C2=A0given some of the implementation inconsist= encies noted during the TLS 1.3 evolution, we felt a bcp guide could help t= he community moving forward.=C2=A0 That=E2=80=99s the purpose of this draft.

We've seen middlebox writers ignore bl= ack letter extensibility requirements in the existing RFCs and adopt broken= patterns before. Why will another draft help?

<= /div>
<= div>
Best,
-Eric

[1]=C2=A0https://tools.ietf.org/html/draft-wang-opsec-tls-proxy-bp-= 00#section-1


On Jul 25, 2020, at 7:07 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


I oppose adoption. While there could be some minor benefit
in documenting the uses and abuses seen when mitm'ing tls,
I doubt that the effort to ensure a balanced document is at
all worthwhile. The current draft is too far from what it'd
need to be to be adopted.

Send to ISE.

S.

On 23/07/2020 02:30, Jen Linkova wrote:
One thing to add here: the chairs would like to hear active and
explicit support of the adoption. So please speak up if you believe
the draft is useful and the WG shall work on getting it published.

On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
<rbonica=3D40junipe= r.net@dmarc.ietf.org> wrote:

Folks,



This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp.



Please send comments to opsec@ietf.org by = August 3, 2020.



=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=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= =A0Ron




Juniper Business Use Only

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
https://www.ietf.org/mai= lman/listinfo/opsec



--
SY, Jen Linkova aka Furry

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailm= an/listinfo/tls

<0x5AB2FAF17B172BEA.asc>________________________________________= _______
TLS mailing list
TLS@ietf.org
https://www.ietf.or= g/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.iet= f.org/mailman/listinfo/tls
--00000000000087681405ab899264-- From nobody Tue Jul 28 17:35: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 8396A3A0D1C for ; Tue, 28 Jul 2020 17:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=unavailable 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 E-aHK0v29Z8J for ; Tue, 28 Jul 2020 17:35:12 -0700 (PDT) Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (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 DB57C3A0D36 for ; Tue, 28 Jul 2020 17:35:11 -0700 (PDT) Received: by mail-oo1-xc32.google.com with SMTP id w1so4188183ooj.2 for ; Tue, 28 Jul 2020 17:35:11 -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 :cc; bh=DiVMhP6rguChkU1zMqGnUqDW8CJP8K3GYzcGnwxiKjs=; b=S7vJ6xY9J88qP3R1B2BPEHyL3OVNzQfkSEC7p6WByrFebSVs0zYFOvkUbWY49FA/w9 8rvPbgVUY8iFCSe6qafXBInJY1kz7pwY6uvZCqkaZNyURsPWtyL485yUxnIE+DG0Z6W6 ylV+v19nt+WJ6k/bajetmpShzjM0nrKxoSu82fGqgxy3CZkNBz1zqSp4wPMh9iy0hz+2 oAaMdWn8AI3ALVTbubztaT5QdTPP4ngyflJLGZ2kqbDa+8XEPwez5u/LXY5QcxyenAIZ 4e8RSCPO6Wn0ZZ09sasCam3wZEeDfX3gGpy7ea+c13VxnL5gI78mX2/YvcAbVd1YH63N OutQ== 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=DiVMhP6rguChkU1zMqGnUqDW8CJP8K3GYzcGnwxiKjs=; b=MTm9sHVm1vlKUCMokILW3JijOd8dJuuO/uKrg1g+kyu12pLBLGEJNeP0S3HbA/63v7 1tvOdgehR4ZqaPTvsU8t8gbDx7Vg+42hP7HycYkfx4YldbQdxFFdD4F7FXGcKUO6DZLY 0MjknxfwK7Ygc3h2yOPBVgGWhRFOWMvPCuuZYGG7glRK1HpuR/y8h6VXosV67SbiCHLL jAhMWqC0OP43imsl6JK2/duQdi4G3y90VdcrbDM5oUjH5Goqf0HX5R28jLG+zYtrv6Fg BY6357R2Y8ncfwZ1yYrSGy1tm9SfKn6iCusNpWHdpI7ccEn0DkXI5to0rwK2QmCPVKho v+Zw== X-Gm-Message-State: AOAM533Q5BMMGHPMIgdaE2uX1muHpI2chQ6UPO0A4r7e0ZDrH9sU52Ct /w0uaOzG2FoBmeBiUaj2e7gUOyJn1kKtXfx4tjgN6Q== X-Google-Smtp-Source: ABdhPJz/gu1027CbP8drwcBGLvm0TIToZyGcqayKny1VZu7vkeSiR6EK+9lcOJOppAC+YUmQS2BRIlBuqy0AqaSCgMU= X-Received: by 2002:a4a:9572:: with SMTP id n47mr19612383ooi.37.1595982910530; Tue, 28 Jul 2020 17:35:10 -0700 (PDT) MIME-Version: 1.0 References: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> In-Reply-To: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> From: Nick Harper Date: Tue, 28 Jul 2020 17:34:59 -0700 Message-ID: To: "Eric Wang (ejwang)" Cc: Martin Thomson , Ron Bonica , OPSEC , "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000073d73c05ab89babd" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 00:35:19 -0000 --00000000000073d73c05ab89babd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 28, 2020 at 2:19 PM Eric Wang (ejwang) wrote: > Thank you for the detailed comments. > > The scope of the document is limited to proxy at the TLS layer. > Explicitly out of the scope is inspection of the proxied record data. > Will clean up derivations from this scope. > > It was the intention to cover selective proxying however, because that is > a practical requirement for an actual deployment. The intention was to > discuss the TLS layer attributes (e.g. SNI, Server Cert) that could be us= ed > as input for the decision. The document also stated the requirement to > gracefully remove the proxy from the session when needed (and possible). > But the criteria for selective proxying decision, being compliance, > privacy, risk level,... are out of the scope. The decision making often > falls under the larger =E2=80=9Cpolicy=E2=80=9D domain and is controlled = at system level > outside of the proxy. It also left out discussion on the detailed > mechanism which was deemed as implementation specific. > > In any case, the proxy has to conduct selective proxying in a safe, > non-disruptive manner. This may require more design work as you pointed > out. The document could describe possible mechanisms so that an acceptab= le > practice could be discussed. We are open to other ways to shape it. > An acceptable practice MUST include not violating the protocol invariants in RFC 8446. It is not possible for a proxy to obey the protocol invariants and selectively proxy based on the contents of the TLS handshake between the proxy and the server a client wishes to connect to. > > More inline... > > > Probably the worst problem is rooted in Section 5.1. The introduction > establishes this as being about proxying, but there are several places th= at > talk about not-proxying sometimes. > > Selective non-proxying opens the document up to a whole new set of > problems that arise from poor designs for deciding not to proxy. There i= s > not nearly enough detail here to address this problem properly. A "good" > design for selective TLS proxying does not seem to be the basis of the > recommendations. I'll give a few examples of problems. > > From the Section 4.8 again: > > > the TLS proxy MUST conduct proper TLS protocol checks to avoid false > identification of TLS handshakes, while taking special care not to > contribute to protocol ossification. > > > This practice has been directly responsible for more ossification than > intermediation, no matter what qualification exists. > > If per-destination not-proxying is required, the proxy can connect to a > server, determine that the server is on a non-proxy list, and then comple= te > the handshake with the client (with a caveat regarding ECH here). I can > guess why this doesn't happen (it's expensive and see also Section 5.4), > but that doesn't excuse the practice. > > The following text from Section 5.3 is deeply problematic: > > A decryption policy decision MAY be made based on the server > certificate or other trustworthy parameters. To verify possession of > private keys that are associated with a particular server > certificate, the proxy SHOULD complete an out-of-band TLS handshake > with the same TLS server IP address and TCP port as targeted by the > TLS client. > > It is possible that the authors misunderstand how TLS works, but this > check won't work. Not only because TLS 1.3 encrypts information, but > because this is only necessary if the proxy forwards a ClientHello from t= he > client to the server. At that point, it is too late and the damage has > been done (see Andrei's review). > > > > Unless I misunderstood it, the document is suggesting the same as you > listed. Basically, the proxy makes a separate connection to the server a= s > a client (=E2=80=9Cout-of-band=E2=80=9D wrt to the originating client-ser= ver connection), > retrieves the server=E2=80=99s certificate from the proxy-server handshak= e, and > determines whether the server is on a non-proxying list or not. If on th= e > list, the proxy forwards the originating client CH as is to the server, a= nd > steps aways from the originating client-server handshake. > The proxy MUST generate a fresh ClientHello when doing this (something Andrei and I previously mentioned). When the proxy makes its separate connection to the server, the server can behave differently when responding to the proxy compared to when it responds to the client, and could present itself to the proxy as something innocuous that should not be proxied. Assuming at this point that the proxy has held onto the client's ClientHello (waiting for the response from the server to the proxy's ClientHello), the proxy decides either to intercept this connection or allow the client's ClientHello to go through to the server. When the proxy allows the client's ClientHello to go through to the server (without interception), there's no guarantee that the server will respond to the client the same way it did to the proxy, or even that the identity the server presented to the proxy is the server's real identity. If the proxy copies extensions unknown to it from the client's ClientHello to its own, then it will not be able to parse the response from the server when the server acts on those unknown extensions. This caused a year of delay in finishing TLS 1.3, and is bad for everyone. A malicious client and cooperating server don't even need to use an extensibility point unknown to the proxy to evade a proxy selectively terminating connections based on the TLS handshake between the proxy and server. This sort of selective proxying is fundamentally broken and should not be recommended as a best practice. > > There are additional considerations in this approach (latency etc.). The > document intentionally left out the details to implementations, but could > also cover them if needed. > > > > > There are a bunch of places where pure proxying - as described in the > introduction - is not assumed. This leads to the same problems already > cited. For instance, in Section 4.2: > > The proxy MAY remove cipher suites from a client-initiated Client Hello > message, add new cipher suites, and re-order them in the proxy-initiated > Client Hello message. > > > Will clean up those texts based on this and other discussions. > > Best, > -Eric > > > > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000073d73c05ab89babd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jul 28, 2020 at 2:19 PM Eric = Wang (ejwang) <ejwang=3D40= cisco.com@dmarc.ietf.org> wrote:
Thank you for the detailed comments.

The scope of the document is limited to proxy at the TLS layer.=C2=A0 = Explicitly out of the scope is inspection of the proxied record data. =C2= =A0 Will clean up derivations from this scope.

It was the intention to cover selective proxying however, because that= is a practical requirement for an actual deployment.=C2=A0 The intention w= as to discuss the TLS layer attributes (e.g. SNI, Server Cert) that could b= e used as input for the decision. =C2=A0The document also stated the requirement to gracefully remove the pr= oxy from the session when needed (and possible).=C2=A0 But the criteria for= selective proxying decision, being compliance, privacy, risk level,... are= out of the scope.=C2=A0 The decision making often falls under the larger =E2=80=9Cpolicy=E2=80=9D domain and is controlled a= t system level outside of the proxy.=C2=A0 It also left out discussion on t= he detailed mechanism which was deemed as implementation specific.

In any case, the proxy has to conduct selective proxying in a safe, no= n-disruptive manner. This may require more design work as you pointed out.= =C2=A0 The document could describe possible mechanisms so that an acceptabl= e practice could be discussed. =C2=A0We are open to other ways to shape it.

An acceptable practice MUST include not violating the = protocol invariants in RFC 8446. It is not possible for a proxy to obey the= protocol invariants and selectively proxy based on the contents of the TLS= handshake between the proxy and the server a client wishes to connect to.= =C2=A0

More inline...

Probably the worst problem is rooted in Section 5.1.=C2=A0 The introduction= establishes this as being about proxying, but there are several places tha= t talk about not-proxying sometimes.

Selective non-proxying opens the document up to a whole new set of problems= that arise from poor designs for deciding not to proxy.=C2=A0 There is not= nearly enough detail here to address this problem properly.=C2=A0 A "= good" design for selective TLS proxying does not seem to be the basis of the recommendations.=C2=A0 I'll give a few exa= mples of problems.

From the Section 4.8 again:

the TLS proxy MUST conduct proper TLS protocol ch= ecks to avoid false identification of TLS handshakes, while taking special = care not to contribute to protocol ossification. =C2=A0

This practice has been directly responsible for more ossification than inte= rmediation, no matter what qualification exists. =C2=A0

If per-destination not-proxying is required, the proxy can connect to a ser= ver, determine that the server is on a non-proxy list, and then complete th= e handshake with the client (with a caveat regarding ECH here).=C2=A0 I can= guess why this doesn't happen (it's expensive and see also Section 5.4), but that doesn't excuse the pract= ice.

The following text from Section 5.3 is deeply problematic:

=C2=A0=C2=A0A decryption policy decision MAY be made based on the server =C2=A0=C2=A0certificate or other trustworthy parameters.=C2=A0 To verify po= ssession of
=C2=A0=C2=A0private keys that are associated with a particular server
=C2=A0=C2=A0certificate, the proxy SHOULD complete an out-of-band TLS hands= hake
=C2=A0=C2=A0with the same TLS server IP address and TCP port as targeted by= the
=C2=A0=C2=A0TLS client.

It is possible that the authors misunderstand how TLS works, but this check= won't work.=C2=A0 Not only because TLS 1.3 encrypts information, but b= ecause this is only necessary if the proxy forwards a ClientHello from the = client to the server.=C2=A0 At that point, it is too late and the damage has been done (see Andrei's review).


Unless I misunderstood it, the document is suggesting the same as you = listed.=C2=A0 Basically, the proxy makes a separate connection to the serve= r as a client (=E2=80=9Cout-of-band=E2=80=9D wrt to the originating client-= server connection), retrieves the server=E2=80=99s certificate from the proxy-server handshake, and determines whether the server is on a= non-proxying list or not.=C2=A0 If on the list, the proxy forwards the ori= ginating client CH as is to the server, and steps aways from the originatin= g client-server handshake.
<= br>
The proxy MUST generate a fresh ClientHello when doing this (= something Andrei and I previously mentioned). When the proxy makes its sepa= rate connection to the server, the server can behave differently when respo= nding to the proxy compared to when it responds to the client, and could pr= esent itself to the proxy as something innocuous=C2=A0that should not be pr= oxied. Assuming at this point that the proxy has held onto the client's= ClientHello (waiting for the response from the server to the proxy's C= lientHello), the proxy decides either to intercept this connection or allow= the client's ClientHello to go through to the server. When the proxy a= llows the client's ClientHello to go through to the server (without int= erception), there's no guarantee that the server will respond to the cl= ient the same way it did to the proxy, or even that the identity the server= presented to the proxy is the server's real identity.
If the proxy copies extensions unknown to it from the client&#= 39;s ClientHello to its own, then it will not be able to parse the response= from the server when the server acts on those unknown extensions. This cau= sed a year of delay in finishing TLS 1.3, and is bad for everyone. A malici= ous client and cooperating server don't even need to use an extensibili= ty point unknown to the proxy to evade a proxy selectively terminating conn= ections based on the TLS handshake between the proxy and server.
=
This sort of selective proxying is fundamentally broken and = should not be recommended as a best practice.

There are additional considerations in this approach (latency etc.). T= he document intentionally left out the details to implementations, but coul= d also cover them if needed.




There are a bunch of places where pure proxying - as described in the intro= duction - is not assumed.=C2=A0 This leads to the same problems already cit= ed.=C2=A0 For instance, in Section 4.2:

The proxy MAY remove cipher suites from a client-= initiated Client Hello message, add new cipher suites, and re-order them in= the proxy-initiated Client Hello message.

Will clean up those texts based on this and other discussions.

Best,
-Eric




_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/opsec

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000073d73c05ab89babd-- From nobody Tue Jul 28 17:54: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 C194F3A0DD4; Tue, 28 Jul 2020 17:54:33 -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 4tDrQmAlYo1p; Tue, 28 Jul 2020 17:54:32 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0: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 341D73A0DC0; Tue, 28 Jul 2020 17:54:32 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id l17so7707084ilq.13; Tue, 28 Jul 2020 17:54:32 -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=CGt7bxY0BXMjSgDBA80ElYDvPhSxDpD7tezN+8wy7sM=; b=oDiRGxFPzAGIRP4pKL3/T9ATAk40Azukh1Blv++HRaVjMOcc5FwjmsdSBINQiTJ9RK RaTp4EQz0Yz5nvAFQhfHFkd4gP40OFqE6uoSi8EUrmgFrZR+aa1U0M7bFa58ZhXdNJxV sMwE/kqizMQoJXVmzSmzB/tpRibcfttmNCfYNfzc4eSaR0YsIGHvGVH8XV0Q1eJ3yM+6 BQOtXArtugPbLou96/9G5hDEqNkcNu44yUfQ6SjKA8gKtA1UKPQYTwflE9XblqFO+bqW k/aYKU+mJ4pAev3RktTtvC1jg2FfMRDOSc4JBsL1/PgzOAUAWlY7EMkfetNRa7EPtjBJ tKxQ== 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=CGt7bxY0BXMjSgDBA80ElYDvPhSxDpD7tezN+8wy7sM=; b=rjdNzvijfz3wFTL+IUtCP/X7VdtR2LhisM3Utmh9NoqgAk3NLg/pg6qG5omUa7i9Co bAJ4yQewW6A8OfsCS/5B0Lij9DotWa/q5lrYq9K1QWzby0C6b29wn7emadxWFxmL/3ih +ab4Ql208VSJ2FgKQ0XvScoTmuxuYnLWtCZ0DiyZjyIXq44eVcucOhgcnEHUkjiKOPyV crwG7HqBAi5GJf0n4zHHoFLIECKhQJ0yZek+cyLPRIOF5fNDXssVWCGFhcjSPzCO3syt aZgBJP5OGnUdayvN3OcwGTtvqv67mrguH/ZPK36p188RujOv2yWzBITAXvtKC5tyKEtL 9KNA== X-Gm-Message-State: AOAM533S7SKPpuCCdtZwlpNRr7593SRgtbr5Z4Hs97BnpRJDHqU5UqkV l4eNPb8aU6nvEe0lkFKwm3RNG/UWUWedkUTDsa+rgCq6 X-Google-Smtp-Source: ABdhPJzTTvemahmZZ3bSE+GZWjzTZoy92Y2+SPUNYWzLZ8JiZcohpxISGBzcGbN0BmgVl1kjpKZguHU0kkYjYJy2QTU= X-Received: by 2002:a92:858d:: with SMTP id f135mr15785591ilh.257.1595984071367; Tue, 28 Jul 2020 17:54:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Tue, 28 Jul 2020 17:54:20 -0700 Message-ID: To: Ron Bonica Cc: OPSEC , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a423d805ab89ff18" Archived-At: Subject: Re: [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 00:54:36 -0000 --000000000000a423d805ab89ff18 Content-Type: text/plain; charset="UTF-8" Oppose. Nothing new to add. thanks, Rob On Sun, Jul 19, 2020 at 10:35 AM Ron Bonica wrote: > Folks, > > > > This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp > . > > > > Please send comments to opsec@ietf.org by August 3, > 2020. > > > > Ron > > > > Juniper Business Use Only > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000a423d805ab89ff18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oppose.

Nothing new to add.
<= br>
thanks,
Rob


On Sun, Jul 19, 202= 0 at 10:35 AM Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> wrote:

Folks,

=C2=A0

This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp.

=C2=A0

Please send comments to opsec@ietf.org by August 3, 2020.

=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=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=A0Ron

=C2=A0


Juniper Business Use Only

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000a423d805ab89ff18-- From nobody Tue Jul 28 18:13: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 7C5FE3A0DF8; Tue, 28 Jul 2020 18:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-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=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 Vx0NtXZVslOX; Tue, 28 Jul 2020 18:12:31 -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 6245D3A0DF6; Tue, 28 Jul 2020 18:12:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5B567BE5B; Wed, 29 Jul 2020 02:12:28 +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 hoo865xtAE_5; Wed, 29 Jul 2020 02:12:26 +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 43D26BE56; Wed, 29 Jul 2020 02:12:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1595985146; bh=11p5LGPbEANrywc3QyE9nzBj7XgusOTHnTxbt8cAxCw=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=ESo2r5UKaeiXhcGNdjvCMnrCguIweEAaHPKNAsgUTh+ig/F92p6B/xOhvJy6CA5o/ ssSQ3/+yJrNpNk23Nr9C1AEGB+XzuE18TtK5iTIaP/OJMFjJ+uro3MkFLVImhnSj7m UDOMB9XzECeNCDFGEcCUlvqq1R1kH1hAPZZLEavc= To: Jen Linkova , opsec WG Cc: tls@ietf.org 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: <8fbc4a58-4f20-7fa5-99e8-fda6fcec76ee@cs.tcd.ie> Date: Wed, 29 Jul 2020 02:12:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="zeCGfhBSCWC5c6UOS6bjWrsWHQiLGGLJw" Archived-At: Subject: Re: [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact 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 Jul 2020 01:12:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --zeCGfhBSCWC5c6UOS6bjWrsWHQiLGGLJw Content-Type: multipart/mixed; boundary="KCd8EYWUZ6FDBl4qfWHGYlKp9U4i1NNEt"; protected-headers="v1" From: Stephen Farrell To: Jen Linkova , opsec WG Cc: tls@ietf.org Message-ID: <8fbc4a58-4f20-7fa5-99e8-fda6fcec76ee@cs.tcd.ie> Subject: Re: [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact References: In-Reply-To: --KCd8EYWUZ6FDBl4qfWHGYlKp9U4i1NNEt Content-Type: multipart/mixed; boundary="------------DC2B0F1C3CCD7A0F1E38C41E" Content-Language: en-US This is a multi-part message in MIME format. --------------DC2B0F1C3CCD7A0F1E38C41E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable IMO this document is absolutely not ready to become an RFC. It basically ignores the purpose of TLS which is to prevent exactly the MITM attacks being espoused here (IMO). In ignoring that, it ignores all of the bad consequences of such MITM attacks. As evidence: "To proxy a TLS session, a TLS Proxy must be able to present a valid X.509 certificate to the TLS client to appear as a valid TLS Server;" That assumes that an x.509 data structure created on the fly, with no interaction with the named subject can be "valid." That is antithetical to the intent of x.509 and TLS. That is such a fundamental misconstruction of x.509, of PKI and of TLS that it alone means that the draft is sufficiently inaccurate to be unworthy of publication as an IETF consensus RFC. If really necessary I'm sure many other related problems can and will be found in the text. I hope that waste of effort is not needed. The basic problem here seem to me to be an effort to justify (and perhaps promote?) existing MITM practices without fairly or accurately describing their downsides. As I also commented on a related document: the effort expended on attempts to garner IETF consensus on such text is not worthwhile. If someone actually wrote truly objective text on the reasons why people deploy TLS MITM attack boxes and on the real downsides that would be different. This is nowhere near such objective text. My recommendation: declare this document dead. And don't bother with the supposed BCP. Instead, try to find someone who can write an evidence-based description of the falsifiable pros and cons of these TLS MITM products. And then send that to the ISE. S. PS: I'm sure someone will claim that being logical about this "ignores reality" so just to get in a comment on that ahead of time: reality includes lots of bad engineering - if and when we want to document that, there is an onus on us to say why it is bad and how to do better. That would require offering evidence as to the efficacy or otherwise of TLS MTIM boxes when compared to the benefits of using TLS as-designed. That evidence, in my experience, never seems to actually be offered by those who espouse these MITM attack products. --------------DC2B0F1C3CCD7A0F1E38C41E 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----- --------------DC2B0F1C3CCD7A0F1E38C41E-- --KCd8EYWUZ6FDBl4qfWHGYlKp9U4i1NNEt-- --zeCGfhBSCWC5c6UOS6bjWrsWHQiLGGLJw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl8gzPkACgkQWrL68XsX K+obrA//d+0xaNdeaE+JH4fE90+ZlYVWItMaaOg6N8KUbAAhhRR5Orw4bPPtl0b2 dsq1ZfMQ7IQYZPDWlf3WkNTFhfPLMTBepzuycnFvrqUTtJ255aUVbMMVDGNe2+vV oMxHpmrsfdfiCA/PPiaw1PF5caOJHX9y5BgKFUYZtE3yrx9DlN6NiB3sratXc+vS Q7/3voiwe0sqpC30Ey6/eNVZnM6bZpxR/OeY/6OCJScxB+s9+Z7IGA1LiAkLFSFF pwPNXvUm0mzJ5BjCrWF24wgy3cAQpZptf72y+s8tf1fWfT+D7kad01B/fG+OSZ3q Yvoh3z2yLmvh+N4LSbksn633c2v02UYOdeyGKGYqwF57NUQN/1OeFT7fb3SpFGZI 4Z6AVN/jxaYvpEDDrBdltddh+2m/R9nIQcwBYCLor/pcD37yIs1Iwu6vJDHW66bW HI4/kSpERpug4IXrYlFmBqucHB5lfav+EajVfrPPovPUQeVt4UbBNrPEGG8+FaLA 5Z2nKE1p2N4Rf6nTdMFN7HlNhotDuirpdanega7nVMzlpii3dlDoFzKHuTfBiGud KTGCXwZAff+ZtIfvzOnqEbLfB6KpdVqs9eVVxhQ0en3+7N+yoT+rSfK/+NtOViPe f42Mo9m53C6K4zmGspG+GnoC6/XCJQhWvjLneZnhJCPeKsKrMG4= =tDcH -----END PGP SIGNATURE----- --zeCGfhBSCWC5c6UOS6bjWrsWHQiLGGLJw-- From nobody Tue Jul 28 18:40: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 C7C943A0E62 for ; Tue, 28 Jul 2020 18:40:52 -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=selfienetworks-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 UukTH1GqZMdu for ; Tue, 28 Jul 2020 18:40:45 -0700 (PDT) Received: from mail-ua1-x942.google.com (mail-ua1-x942.google.com [IPv6:2607:f8b0:4864:20::942]) (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 2F56B3A0E69 for ; Tue, 28 Jul 2020 18:40:31 -0700 (PDT) Received: by mail-ua1-x942.google.com with SMTP id p27so2893286uaa.12 for ; Tue, 28 Jul 2020 18:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfienetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:cc:subject:to:in-reply-to:references :from; bh=iU7GUqJpwn+dI5ocoF4qrzbKc+9N0hulNNiUNZciNLk=; b=RD+gvsGhljVYeFtXpAw8KsmqoQGY5s7kZKSF3fEjtk0Q5UyqT7PAqQcMa9fgR06lza M7fLcn7pdo5w+2vgQM3hkpUluJ4tCSlE8mjFAb85IIv5oNZmlat3a2mELVAeGQpIUclt WhBNNl76PkwPzskCqbBeGFl38YUI201MQBZUN+jwaIG1mHpg5LDc/ZfYqUME9Up9Do3I N/WsLEbxWQ1nBkbkcXJ4iw3AnPkYQd6JHn1ftAC4jmNXVsefhQ5NcdW+DNaTZiMIvVUv gyoxQkZrS1ze+FdagXrD0PGtzkrlLetjm8AIZBOnUrS+jggGf630cWIhAMm8Yk7C1PbG dWdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:date:message-id:cc:subject:to :in-reply-to:references:from; bh=iU7GUqJpwn+dI5ocoF4qrzbKc+9N0hulNNiUNZciNLk=; b=G2QN7jvQZKSj8DLnr38o4zMCCZIZZD+6u0thupnJHuIAyOEdiGfOYU+WAkI7oHXHea VYSxNvTzebKNzd3ZA1i/GiXtZ3TjJx9FFeE9Z2BIiCsG1Dzf4hpYevnoG6VMRzNSKYyu 0BntvjK5VWg7BFEL4GVT2P0jWfl6yAIRzlLOEtKWCp94wKbHafa+tV1w88MJkPQefWQs f6rohXi5BYBovxS8S2SGscGU5BMteoM/LTsbiqhfVdIZZky1+2wDrQg7dtBjS945lbFQ 3ZWIXy4auQKBPIKzHEJPyTsDWNhFUSHG8Oh+y0R97vNU6R+FeL735IhrNfHPznYFw228 ZPqQ== X-Gm-Message-State: AOAM530KGtAd121iiVPChB/93n8IsrR/v8V0mR6alvLtMOgSEdbQKExV qmUrDuW73SiNxhwra9Hhv+qVv64JudI= X-Google-Smtp-Source: ABdhPJwrC26aiLGXD4hEu/hJdtaFJamL8BURmMRvhItpdlrH1uptH2KOCpMicqJWiDxo9PTQf2GqdQ== X-Received: by 2002:ab0:6c50:: with SMTP id q16mr23065991uas.94.1595986829775; Tue, 28 Jul 2020 18:40:29 -0700 (PDT) Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with ESMTPSA id p142sm63264vke.17.2020.07.28.18.40.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Jul 2020 18:40:29 -0700 (PDT) Mime-Version: 1.0 X-Superhuman-ID: kd6pc4xe.497ad9dc-bb9d-4e1a-b9c4-df7659a8b750 Date: Wed, 29 Jul 2020 01:40:26 +0000 Message-ID: Cc: "Melinda Shore" , tls@ietf.org To: "Christian Huitema" X-Mailer: Superhuman Desktop (2020-07-27T22:06:08Z) X-Superhuman-Draft-ID: draft004b7e29270badcd In-Reply-To: <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net> References: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net> From: "Yiannis Yiakoumis" Content-Type: multipart/alternative; boundary=2cb12b6ffc4a8f97f33df5eb8b846323fc6223cfc9cf0d53b6eced94d24f Archived-At: Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI 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 Jul 2020 01:40:53 -0000 --2cb12b6ffc4a8f97f33df5eb8b846323fc6223cfc9cf0d53b6eced94d24f Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Hi everyone, Just a quick follow-up that there will be the following talks on Wednesday = and Thursday around network tokens. *=20 July 29 , 1:00-1:50pm UTC: TSV Open Meeting *=20 July 30 , 12:30pm-2:00pm UTC: APN Side Meeting *=20 July 30 , 4pm-5pm UTC: Network Tokens Side Meeting (details available here)= ( https://github.com/Network-Tokens/network-tokens-rfc/wiki/IETF-108---Net= work-Tokens-Side-Meeting ) Best, Yiannis On Fri, Jun 26, 2020 at 10:42 AM, Christian Huitema < huitema@huitema.net >= wrote: >=20 > On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote: >=20 >=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Fri, Jun 26 , 2020 at 7:29 AM, Christian Huitema < huitema@ huitema. = net >> ( huitema@huitema.net ) > wrote: >>=20 >>>=20 >>>=20 >>> On 6/25/2020 11:11 PM, Melinda Shore wrote: >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> On 6/25/20 3:29 PM, Erik Nygren wrote: >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>> One quick comment is that binding tokens to IP addresses is strongly >>>>> counter-recommended. >>>>> It doesn't survive NATs or proxies, mobility, and it is especially >>>>> problematic in IPv6+IPv4 dual-stack environments. >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> There's been a bunch of past work done developing similar sorts of >>>> protocols, and for what it's worth I wrote up a mechanism for using >>>> address tags and address rewrites, but unfortunately Cisco decided to >>>> patent it. Anyway, there are ways of dealing with this problem that do= n't >>>> require binding the address to the token ("all technical problems can = be >>>> solved by introducing a layer of indirection"). >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> There is also an interesting privacy issue. The token is meant to let a >>> provider identify some properties of the connection. I suppose there ar= e >>> ways to do that without having it become a unique identifier that can b= e >>> tracked by, well, pretty much everybody. But you have better spell out >>> these ways. >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> You are right that for the duration of a token, one could use it to >> identify an endpoint (either application or most likely a combination of >> user/application). Tokens expire and intermediary nodes cannot correlate >> tokens with each other as they are encrypted. So tracking cannot happen >> across different tokens (of the same user), or between token-enabled and >> non-token-enabled traffic. I guess similar type of tracking happens when >> users are not behind a NAT and their IP address can be used to track the= m. >> Would it make sense to have the user add a random value to a token, and >> then encrypt it with the network's public key, so that each token become= s >> unique and cannot be tracked. Would that address the privacy concerns >> better? >>=20 >>=20 >=20 >=20 >=20 > That would certainly be better. The basic rule is that any such identifie= r > should be used only once. Pretty much the same issue as the session resum= e > tickets. >=20 >=20 >=20 >>=20 >>=20 >>=20 >>>=20 >>>=20 >>> Then, there are potential interactions with ESNI/ECH. The whole point o= f >>> ECH is to keep private extensions private. The token extension would ne= ed >>> to be placed in the outer envelope, which is public but does not expose >>> seemingly important information like the SNI or the ALPN. >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> Ah, I was not aware that ESNI can now include all CH extensions - thanks >> for the pointer. Yes, the token would have to stay on the outer envelope >> so the network can process it. The main idea is you can encrypt everythi= ng >> that is client-server specific, and just keep a token to explicitly >> exchange information with trusted networks. >>=20 >>=20 >>=20 >>=20 >>>=20 >>>=20 >>> There are also implications for QUIC, in which the TLS data is part of = an >>> encrypted payload. The encryption key of the TLS carrying initial packe= ts >>> is not secret in V1, but it might well become so in a future version. >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> Haven't looked into QUIC yet, but is on the list of things to do. If >> anyone is interested to help us explore this, please let me know. >>=20 >>=20 >=20 >=20 >=20 > You may want to have that discussion in the QUIC WG. If you are building > some kind of QoS service, you probably want it to work with QUIC too. >=20 >=20 >=20 >=20 > -- Christian Huitema >=20 >=20 >=20 > --2cb12b6ffc4a8f97f33df5eb8b846323fc6223cfc9cf0d53b6eced94d24f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
3D"
Hi everyone,

=
Just a quick follow-up that there will be the following tal= ks on Wednesday=C2=A0and Thursday=C2=A0around network tokens.=C2=A0

  • July 29, 1:00-1:50pm UTC: TSV O= pen Meeting

  • July 30, 12:30pm-2:00pm UTC: APN Side Meeting

  • July 30, 4pm-= 5pm UTC: Network Tokens Side Meeting (details available=C2= =A0here)

Best,
Yian= nis

O= n Fri, Jun 26, 2020 at 10:42 AM, Christian Huitema <huitema@= huitema.net> wrote:
=
On 6/26/2020 = 10:16 AM, Yiannis Yiakoumis wrote:
=20
=20



On Fri, = Jun 26, 2020 at 7:29 AM, Christian Huitema <huitema@huitema.net> wrote:

On 6/25/2020<= /span> 11:11 PM, Melinda Shore wrote:

On 6/25/20 3:29 PM, Erik Nygren wrote:

One quick comment is that binding tokens to IP addresses is strongly counter-recommended.
It doesn't survive NATs or proxies, mobility, and it is especially problematic in IPv6+IPv4 dual-stack environments.

There's been a bunch of past work done developing similar sorts of protocols, and for what it's worth I wrote up a mechanism for using address tags and address rewrites, but unfortunately Cisco decided to patent it. Anyway, there are ways of dealing with this problem that don't require binding the address to the token ("all technical problems can be solved by introducing a layer of indirection").

There is also an interesting privacy issue. The token is meant to let a provider identify some properties of the connection. I suppose there are ways to do that without having it become a unique identifier that can be tracked by, well, pretty much everybody. But you have better spell out these ways.


You are right that for the duration of a token, one could use it to identify an endpoint (either application or most likely a combination of user/application). Tokens expire and intermediary nodes cannot correlate tokens with each other as they are encrypted. So tracking cannot happen across different tokens (of the same user), or between token-enabled and non-token-enabled traffic. I guess similar type of tracking happens when users are not behind a NAT and their IP address can be used to track them. Would it make sense to have the user add a random value to a token, and then encrypt it with the network's public key, so that each token becomes unique and cannot be tracked. Would that address the privacy concerns better?

That would certainly be better. The basic rule is that an= y such identifier should be used only once. Pretty much the same issue as the session resume tickets.


Then, there are potential interactions with ESNI/ECH. The whole point of ECH is to keep private extensions private. The token extension would need to be placed in the outer envelope, which is public but does not expose seemingly important information like the SNI or the ALPN.


Ah, I was not aware that ESNI can now include= all CH extensions - thanks for the pointer. Yes, the token would have to stay on the outer envelope so the network can process it. The main idea is you can encrypt everything that is client-server specific, and just keep a token to explicitly exchange information with trusted networks.=C2=A0

There are also implications for QUIC, in which the TLS data is part of an encrypted payload. The encryption key of the TLS carrying initial packets is not secret in V1, but it might well become so in a future version.


Haven't looked into QUIC yet, but is on t= he list of things to do. If anyone is interested to help us explore this, please let me know.

You may want to have that discussion in the QUIC WG. If y= ou are building some kind of QoS service, you probably want it to work with QUIC too.

-- Christian Huitema


--2cb12b6ffc4a8f97f33df5eb8b846323fc6223cfc9cf0d53b6eced94d24f-- From nobody Tue Jul 28 18:52: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 5881E3A0E7B; Tue, 28 Jul 2020 18:52:18 -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 WqDh5eGQ8iJQ; Tue, 28 Jul 2020 18:52:16 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0: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 9FE273A0E76; Tue, 28 Jul 2020 18:52:16 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id l17so7801710ilq.13; Tue, 28 Jul 2020 18:52:16 -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=njbYQqdi0ql+PQVxqw003ZQjCNNmmgxKirZTdcQwyMc=; b=VMM4LqIXsNGnASo0WVFV2ZWGSHGqWE/wZwO32lF1fnkYRQxmCJej+fv9uSozUGJySX rpQ9aizPG9IIzibSQ6mtcUjkyU96yiYpSKCcrCmhBGJKAfBXXA8T4+InNLPSB4RCA7i9 lBBviA3bSe657I3cX+l2MJyh6EseLpkPb+K73XJNHoZhp1OSmXhXZrymASTc62PBEUpU cop8R9V1Da4gyRsSd6VejaAP8BkzBjSysA9YniA/PX1+jdCyCsSIe0FHrHRzG2oWQea2 opbLhOq8CIp8yzJ9EMZZCQWtx54rGd6ls0FdnjIFXXckEFdQQD46lW5ZzfbyRMgLtIS0 TcAQ== 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=njbYQqdi0ql+PQVxqw003ZQjCNNmmgxKirZTdcQwyMc=; b=mqBiOyGRjIW3QVtaAR2IL7Rddwo68WrGuhC+RazxN7b/MjkJQCDVH1HoXxReldULX5 X2icaAyE8jNKHZIGpabE6m56QygwHlW35uhA3HlqV6UX3wBtcHGY/IX8uri/Rhzqamf4 lkY8jDxhWA7jER4ROpCVS83QLc/YJvupw2UwDi/ThniF2uE3/x5BVGoAG27Hz0E0g8oq HsgrIU9pQmUCSL8z+eUnlzuaCFbwCqGieti/O0ftw6I8NUX9TCPE0jy2CIZW0dwwSyGC nZ/NK/sUQ/NFQM47sXodLGcYl87MbPw+AtH6FpHQNZHU81KT7cMC7uQE3PaVbZIZy7s3 rfXw== X-Gm-Message-State: AOAM5303YNKLifXlnjTvQRaUWy9rwYuGnuth466AAfEn+n0MoixZsJo1 /NRYESFOwSSCbeqzICm4upNfnEAOi1LXvgat5/M= X-Google-Smtp-Source: ABdhPJw4RoNtv1qwhCUUEkio9rtj1G4VwSNZqEWzM4/ow3LkUTQaChHC2QjuXcleONxZe/gxKaezpPGwaVYKl7+zSyI= X-Received: by 2002:a92:cf06:: with SMTP id c6mr32078357ilo.73.1595987535766; Tue, 28 Jul 2020 18:52:15 -0700 (PDT) MIME-Version: 1.0 References: <8fbc4a58-4f20-7fa5-99e8-fda6fcec76ee@cs.tcd.ie> In-Reply-To: <8fbc4a58-4f20-7fa5-99e8-fda6fcec76ee@cs.tcd.ie> From: Rob Sayre Date: Tue, 28 Jul 2020 18:52:04 -0700 Message-ID: To: Stephen Farrell Cc: Jen Linkova , opsec WG , "TLS@ietf.org" Content-Type: multipart/alternative; boundary="00000000000022ac3505ab8ace0c" Archived-At: Subject: Re: [TLS] OpSec WGLC for draft-ietf-opsec-ns-impact 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 Jul 2020 01:52:19 -0000 --00000000000022ac3505ab8ace0c Content-Type: text/plain; charset="UTF-8" On Tue, Jul 28, 2020 at 6:13 PM Stephen Farrell wrote: > > PS: I'm sure someone will claim that being logical about > this "ignores reality" so just to get in a comment on > that ahead of time: reality includes lots of bad > engineering... > I agree with this comment. In particular, I object to phrases along the lines of: "TLS 1.3 considerations: reduced effectiveness" Ignoring their aims, I don't think these products work, and I don't think the IETF should publish documents that make it seem like they do. I would support an ISE submission. thanks, Rob --00000000000022ac3505ab8ace0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 28, 2020 at 6:13 PM Stephen F= arrell <stephen.farrell@cs.= tcd.ie> wrote:

PS: I'm sure someone will claim that being logical about
this "ignores reality" so just to get in a comment on
that ahead of time: reality includes lots of bad
engineering...

I agree with this commen= t. In particular, I object to phrases along the lines of:

"TLS 1.3 considerations: reduced effectiveness"

Ignoring their aims, I don't think these products work,= and I don't think the IETF should publish documents that make it seem = like they do.

I would support an ISE submission.

thanks,
Rob

--00000000000022ac3505ab8ace0c-- From nobody Tue Jul 28 20: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 F27383A0B38; Tue, 28 Jul 2020 20:26:35 -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=lowentropy.net header.b=ZbfGLsAX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=M8NNWx55 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 5fntAfm2KTKN; Tue, 28 Jul 2020 20:26:34 -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 9BC273A0B31; Tue, 28 Jul 2020 20:26:34 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 9925642A; Tue, 28 Jul 2020 23:26:33 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 28 Jul 2020 23:26:33 -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=cQmUMN7lwIXrTInPjDol4VYlC2DH JljCrhfrv9cMr8o=; b=ZbfGLsAXqQVJuGBMqLLSk3jjMhCZYduKkk67ln90ijFn A/1JhDFOIl+1CuRmWyAtpW5QhhBTofSpQrc8Jd4iL/EP7GgizLDsYb13QWd/XYsf vURWN4NIxrTlNsSJ/Exr6fP53cc/ZR60UQtniIUx+oWyQENbu6bje5fRwoo6E5lf 3r+XPf7XPyuNoUhUUv3sOf1OnjBAWkMAn28/pGOm+plnu+49gTHbHShrgm7PIOKT jKsAqOnxvirco2ACDgR6PpIP59gqJY4xwMU/dFY4jQ0qw6yxlNu5YrNxrb3NUsRe PiFSAWCEVpoCNljv3jX0BDBJSV/mYu04Dyy+p1y5mA== 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=fm3; bh=cQmUMN 7lwIXrTInPjDol4VYlC2DHJljCrhfrv9cMr8o=; b=M8NNWx55AV4xjc1Jvs1WU3 ObrHDnR04uTczOlTfmRZvbvgrxema4sBEZ/1LA3O2ofU6cGead3/mEUQxvN3t+C3 K1e4mykmaywvfZn8L9D1MMl6p1m7PPARliV1AwydkTLe5ghCngrx+udEUnBaiOSk qap9TLnEBOba9UQQFczL1zSuoYPlhGhrvFsErownWUwCdLX7646x56ZK4G/lrmT7 t/kGMuj2ML1mZRzNdJnibG7zTxFrDEn9X9eIk4pa8HAqUh8wHkjURFSEo5DbyOQd y/ClvVz3jt0BEk2ye8r/7dnFc/hJdDAWCTeId+YBfslmvhHfhKbQLulx8jYLi3tQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrieefgdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtf frrghtthgvrhhnpeekteeuieektdekleefkeevhfekffevvdevgfekgfeluefgvdejjeeg ffeigedtjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 367F0E00A6; Tue, 28 Jul 2020 23:26:32 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-128-gd51a832-fm-20200728.001-gd51a8328 Mime-Version: 1.0 Message-Id: <90e5b7d5-a015-40f6-9d5b-b263c85cb2d3@www.fastmail.com> In-Reply-To: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> References: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> Date: Wed, 29 Jul 2020 13:26:13 +1000 From: "Martin Thomson" To: "Eric Wang (ejwang)" Cc: "Ron Bonica" , OPSEC , "tls@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 03:26:36 -0000 Hi Eric, On Wed, Jul 29, 2020, at 07:18, Eric Wang (ejwang) wrote: > In any case, the proxy has to conduct selective proxying in a safe, > non-disruptive manner. I will try to be clearer on this point. This requires design work and this document is a poor vehicle for that. It needs a separate document that documents the design, the properties of that design, and the assumptions that it requires to achieve those properties. The TLS working group has decided not to undertake work in this area. That TLS working group decision needs to be respected by other parts of the IETF. From nobody Wed Jul 29 01:41: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 78AE43A10D2; Wed, 29 Jul 2020 01:41:08 -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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 b5wNMStRFxCH; Wed, 29 Jul 2020 01:41:04 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70091.outbound.protection.outlook.com [40.107.7.91]) (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 D622E3A10CF; Wed, 29 Jul 2020 01:41:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=duNESbwcr7sWQU0XJuDq2vsgl2R5/UDEdVFwiIiwjz2fT8x3X4ol4KH5CMprJQ09yH4MVkJDgHlZYX4+15gGTMyffMILH7LR7oPX5xaDgQ0wxpZliyoz2oTTl8MX/FtX71slwzVKJ7rcxUgH4R040m1catF+GdTBK+NTi0UDpeZFS3IIpwwPDN9CwXtzr+YXrQJqddXmzHYVCXWv8AjFyLJEPdApd+0oMLrCQCV3/xyeVy13bKShFgIO4a6G1uQJWJJ0Lc4yUU8Mko4PXWgceGICRTbVDaXGgmk2VUZsjmPmSpWOxLL0KKSGkwx0Ba1dUYpK/AHIPQTucApJoQibFQ== 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=rsT1tbX7cmGXCAQp12bN/k2YaAGP5bCXaqOZJe5QDzU=; b=d0PUwa+EaguY5BIvUlUH3KWcEWHYvdzjqW5zRX7UYdpfcvpSH39lDWmgdSgkcv7sIDB5HK+GIDx8poeqrHK01ahGsDFazol0vz555dT5G4028F2e+uLw5MmB1K9XDXqGDCwFfMrXJVkFM/Cil+2Aui/F2nsx9+Z1MBDFNiHvrGYjuAZ1gfdoicgayVPBdX0AWXCTYlRToczx2UBN5mXDinMQna0H3mnteHHKG9L/AgpZUc+GR8sG7T+zVRs1EuPbiJM2h6zDIVTMUVKgHke0YamxjAO4l4ukZDYj/holY9PxeXsGq3tszWh5dV44gEeGlghaXrVgOb/x/JN+foD5pQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rsT1tbX7cmGXCAQp12bN/k2YaAGP5bCXaqOZJe5QDzU=; b=PFVzjYzJjp7MZA9xTWxAQGcCrhIXlDXjwMHP6+1gb1KnBRW+PlJjABHWRjpWM46yPF8NeBPMVNmCCFm9RS3Xn6gH7XREkcWIEjb98DVMkBO9kF50ekusnezuKUN2zS5G2Gt0pOaIxxQ7zFHVaMPLiHuDxZ9wPMoomE8wvB/31fE= Received: from DB7PR07MB5340.eurprd07.prod.outlook.com (2603:10a6:10:69::25) by DB6PR0701MB2632.eurprd07.prod.outlook.com (2603:10a6:4:21::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Wed, 29 Jul 2020 08:41:01 +0000 Received: from DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::f911:a06:2f4e:a103]) by DB7PR07MB5340.eurprd07.prod.outlook.com ([fe80::f911:a06:2f4e:a103%4]) with mapi id 15.20.3239.016; Wed, 29 Jul 2020 08:41:01 +0000 From: tom petch To: Jen Linkova CC: opsec WG , "tls@ietf.org" Thread-Topic: [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact Thread-Index: AQHWZOAEUv5F9DjalEW4QGtE95/kRakdJpABgABopwCAAKtIcw== Date: Wed, 29 Jul 2020 08:41:01 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=btconnect.com; x-originating-ip: [81.131.229.35] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4aba07b5-9135-4b84-ec1d-08d8339b1f63 x-ms-traffictypediagnostic: DB6PR0701MB2632: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: NUQpwbfUGIGs9t3JnknjjCqp1oewTGbwjvwSs+O3WpRH1kyzUaQA+kea60kpyX2r3yMXSQwhPSHObbZDwIldTu3U4Fh60nhZP6RHxkHfn2KBY+RjfBi5hMO0so/7utUlky6L0wkbWWWBXVb+nQ9RadLzh2mglgvYWp90q9cYPzKrSH/1Yb/AZrACNM6NB1SwF8YCpr0YQdMpq4Ay6fuWLB0Sw9aSnaeDphV+2RR01hqaamkX/beIyb+sOEEe6aVoYq/1f4/ogptXFThOj2lDghe1lDguBdJrUp7dY9AMpr+hq7/bpomZAc9aXS7nUUsWQrSrNqpt5MB8atsAiZrmdQsR0rZg7busW60xxyjVVrM4jFPudUIYjzrojPyENuZz5xQZh3Fo0IWr9ytYn0tSig== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB5340.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(6029001)(346002)(136003)(396003)(376002)(39860400002)(366004)(91956017)(4326008)(9686003)(966005)(83380400001)(66476007)(64756008)(53546011)(7696005)(54906003)(26005)(186003)(478600001)(6506007)(76116006)(66556008)(71200400001)(8936002)(55016002)(6916009)(52536014)(2906002)(86362001)(66946007)(316002)(8676002)(66446008)(5660300002)(33656002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: tRhu6i8UkmgDcDmZrqdLnKGuJwMl95CcA+XxELeqkdlLvzV2onQSDBWZPpFaLdxOXXNs2Ot8tTw2Ea+nhffBBekOdU/jkx9CyWeRYlq1mR0u+DM5L9/GjDAtOLnfHncjXZe1SuasVx3L9yqwkBqwTmGOvCjnuP1UkJCL2H0FWbI8DEgtPz2BopARPhb19DrDjbonRQ3fB+iY9nRUfavBzQN/KPOn6pe8LbY+2zQZROQT5Yr3a88NnN5/YEpd9fyeEnYHh4AwYnaiu/0CX/3jr9ZeIDEzMRkZ+Jdi5rC8gTkU9/Opgc4UbNrd7O/ak9xFygfGiq9nhi+5sThmrrK4Uqm7IzJZKA7cPmA9sHtC4e9Z9ieSR4RNkC1A4cdYysb5viCsrCQt79e8nEkWrbd9tCtvCpRG+ihHEqYuLNmykBnNe4t4mU2q72y2xTjwJBV9ohv2yIuFAa6ewpaxlrtZ2DTi7kZoYije4f7hqOZjPXTg8oAggoW7pK34gn4AooEpDi1N0DQCTil/wFMkDpfP2naENa0EkY/Gd9uOJdP8J1Hu8F4pUEFfWs2JC9YLL4ZlkrnLyc54JIhL0L42WEYzmKQ4uCzOlNtp9xmPAyU6ZtTpoX1svlMBSLEudunO7rRFzZZEiKymcJof2FBeFwKxRg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB5340.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4aba07b5-9135-4b84-ec1d-08d8339b1f63 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2020 08:41:01.1985 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 5F1zYOSROBSwiet2KgEswb9SEPAig1IbjF8AN8kO9w1t9q8/sMDVvjj2kOsRKvCnoFJGUtUtyyErW0uvwK+zLg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2632 Archived-At: Subject: Re: [TLS] [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact 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 Jul 2020 08:41:09 -0000 From: Jen Linkova =0A= Sent: 28 July 2020 23:14=0A= To: tom petch=0A= On Wed, Jul 29, 2020 at 2:07 AM tom petch wrote:=0A= >> This email starts the WG Last Call for draft-ietf-opsec-ns-impact ,=0A= >> Impact of TLS 1.3 to Operational Network Security Practices,=0A= >> https://datatracker.ietf.org/doc/draft-ietf-opsec-ns-impact/.=0A= =0A= > =0A= > OPPOSE (yes, I am shouting)=0A= >=0A= > This is nowhere near ready and putting it forward so soon is ... well lud= icrous comes to mind.=0A= >=0A= > After WG adoption, comments were made to which there was no acknowledgeme= nt, no response, I was about to oppose the adoption of the other I-D from = these authors on the grounds that until they respond to comments nothing el= se should happen because when they do there are more comments waiting to be= aired. I am still of that view.=0A= =0A= Sorry, it's partially my fault. I did explicitly ask the authors to=0A= address your comments and submit a new version. I should have=0A= double-checked that the new version incorporates the feedback.=0A= =0A= =0A= Jen, it is more than that. I think that the IETF way of working is to make = comments, get an acknowledgement and a response, from author, others, Chair= , AD i.a., discuss the issues, accept or reject changes, new version, rinse= and repeat. In this case, the next post after my comments was WGLC. This= is not the process I expect. ( I thought there were other comments at adop= tion but cannot see them now). I did see Kathleen promising a further revi= ew; that would be helpful.=0A= =0A= And as I alluded to, four weeks ago was a quiet time, a time to progress th= is. Now, cut-off and post cut-off, it is that time of madness in the IETF = when everyone comes out of hibernation and posts revised I-D. I track TEAS= and they have just posted 484 - yes four hundred and eighty four - pages o= f revised I-Ds which will keep me quiet for much of August. Interesting as = TLS is, it is behind them in the queue.=0A= =0A= Tom Petch =0A= =0A= Dear authors, would you be able to address Tom's comments ASAP so the=0A= new revision can be reviewed during the WGLC?=0A= =0A= > I do see that a revised I-D has just appeared in among the thousand or so= I-D that appear around the time of an IETF meeting, a timing that I someti= mes think is designed to let it slip through unnoticed. Given all those ot= her I-D - silly authors - it may be more than three weeks before I get my t= houghts together.=0A= =0A= Just to clarify: would you prefer not to have the WGLC around IETF=0A= weeks at all?=0A= =0A= --=0A= SY, Jen Linkova aka Furry=0A= From nobody Wed Jul 29 02:20: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 84C9C3A0CD8; Wed, 29 Jul 2020 02:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 7_zYSqpuadbY; Wed, 29 Jul 2020 02:20:44 -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 74C373A0CAB; Wed, 29 Jul 2020 02:20:44 -0700 (PDT) Received: by mail-qk1-x72e.google.com with SMTP id d14so21494248qke.13; Wed, 29 Jul 2020 02:20:44 -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=PCIBqJNdT+XgBvyacPtUjdn0fM1trOUIZ3mxyNMVfz8=; b=mcc/fneBuLGITTECZQIsb8ktdC//4ylP765crwWy0rlkr1K+sDr0Y0kXdK5GL2CUeG NypqGRUWV7XkrGhykxLspWdKPdd+kcbJjQ7dDuWKIppJO+L9cxTUnP7LDsxVWb+miJ3C 1oe6z+tiFlnVfGXvfNLHdwUz035QDRo8AsIzKS58NA3T4CSsAwCQfcApBvJAT19Kh/gz 0JOYQyXsxUK2P3k3CdM8zmsMPYhoRaAtf+v8VReEQqzAv9QiMNWM1NZYQQ4j7wS6DOC4 qRAmB7xfiHNBotZGM+6tdFa5V/z2fS+3d4dIt73pbQRnM6L43r14BmzfR0klfdDdsbW7 CNKA== 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=PCIBqJNdT+XgBvyacPtUjdn0fM1trOUIZ3mxyNMVfz8=; b=tsIzL6L0WvvXp/3tMB+rai8ai5kFxPOkNevuAIZe1UUpI6OP5m8rpAIntHHGA7i7NV QHJU0r8LPSDk2sIZGVi8T0BQzfMSUxsSPGQwefy5G27V2Z7WUkogPFKCFHV6I//HiLF8 n6IxTdzaVGVedPEHf+/w2OKOyIMgMwILUrE8oSnotrSU4ptUMKBjOjomvIXWx0kT8Uy5 jNubriLRI0tCQ+3FpN/GIHWPHfnQXORGlbLnvL8uZ4cc4oB6rWGfOsY0IkYrxy8QAcpT qS4apbsJE6pTTwvs7AotfIPR2cPNlT8RqxyZxFhxP+Q7RUZB//ddQrnkm9pWL1sXhOf6 bkXQ== X-Gm-Message-State: AOAM5311DdQ0OiWBZEF+g9ltHFwxrreT+1v1MuKW818Sw2bhZHEmoqhD 9G0b4IeKFP25vAts98IFIpubHVye0VjJS8IczS+ZvHYqMKU= X-Google-Smtp-Source: ABdhPJyrZuMJIbJDZwqi+qGtNT5nwHm7hckpQrKMed4dyoRCp7l9MUeDQWyfp6RtUgw4Omqf22i3ldmgNEVqN88P5rw= X-Received: by 2002:a37:9c4b:: with SMTP id f72mr25741472qke.332.1596014443537; Wed, 29 Jul 2020 02:20:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jen Linkova Date: Wed, 29 Jul 2020 19:20:32 +1000 Message-ID: To: tom petch Cc: opsec WG , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact 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 Jul 2020 09:20:47 -0000 On Wed, Jul 29, 2020 at 6:41 PM tom petch wrote: > Jen, it is more than that. I think that the IETF way of working is to mak= e comments, get an acknowledgement and a response, from author, others, Cha= ir, AD i.a., discuss the issues, accept or reject changes, new version, rin= se and repeat. In this case, the next post after my comments was WGLC. Just to clarify: - I saw your comments not being acknowledged/confirmed so we discussed it with the authors and the proposed course of actions was: -01 is posted to incorporate your comments and then we issue the WGLC. So strictly speaking the next port after your comments was -01 (which was *suppossed* to address your comments) and then WGLC. >This is not the process I expect. ( I thought there were other comments at= adoption but cannot see them now). I did see Kathleen promising a further= review; that would be helpful. As I can see Kathleen confirmed that her comments had been addressed. > And as I alluded to, four weeks ago was a quiet time, a time to progress = this. Now, cut-off and post cut-off, it is that time of madness in the IET= F when everyone comes out of hibernation and posts revised I-D. I track TE= AS and they have just posted 484 - yes four hundred and eighty four - pages= of revised I-Ds which will keep me quiet for much of August. Interesting a= s TLS is, it is behind them in the queue. I'm sorry about adding more stuff onto your plate. Lesson learner, we'll try to avoid issuing adoption/WGLC around IETF week. On the other hand...I have a weird feeling that a lot of people: 1) do not comment outside of adoption call//WGLC 2) are more active around the IETF week. So issuing the WGLC in the trough between IETF meetings caused an undesirable outcome of people not paying enough attention. But thanks for the comments, I'll take it into account - let's consider it my learning curve.. BTW -02 has been posted so I hope your comments have been incorporated. --=20 SY, Jen Linkova aka Furry From nobody Wed Jul 29 03:00: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 381B73A0645 for ; Wed, 29 Jul 2020 03:00:24 -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 5AYJe4rCEDft for ; Wed, 29 Jul 2020 03:00: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 5FA4F3A05A7 for ; Wed, 29 Jul 2020 03:00:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E09D1F4074D; Wed, 29 Jul 2020 02:59:55 -0700 (PDT) To: tim@dierks.org, 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: voip.isdn@gmail.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200729095955.E09D1F4074D@rfc-editor.org> Date: Wed, 29 Jul 2020 02:59:55 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC5246 (6244) 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 Jul 2020 10:00:25 -0000 The following errata report has been submitted for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6244 -------------------------------------- Type: Editorial Reported by: Victor S. Osipov Section: 6.2.3.2 Original Text ------------- IV The Initialization Vector (IV) SHOULD be chosen at random, and MUST be unpredictable. Note that in versions of TLS prior to 1.1, there was no IV field, and the last ciphertext block of the previous record (the "CBC residue") was used as the IV. This was changed to prevent the attacks described in [CBCATT]. For block ciphers, the IV length is of length SecurityParameters.record_iv_length, which is equal to the SecurityParameters.block_size. Corrected Text -------------- IV The Initialization Vector (IV) SHOULD be chosen at random, and MUST be unpredictable. Note that in versions of TLS prior to 1.1, there was no IV field, and the last ciphertext block of the previous record (the "CBC residue") was used as the IV. This was changed to prevent the attacks described in [CBCATT]. For block ciphers, the IV length is of length SecurityParameters.record_iv_length, which is equal to the SecurityParameters.block_length. Notes ----- This is an error here. The structure SecurityParameters hasn't the element block_size. It has the element block_length. See in section 6.1: struct { ConnectionEnd entity; PRFAlgorithm prf_algorithm; BulkCipherAlgorithm bulk_cipher_algorithm; CipherType cipher_type; uint8 enc_key_length; uint8 block_length; uint8 fixed_iv_length; uint8 record_iv_length; MACAlgorithm mac_algorithm; uint8 mac_length; uint8 mac_key_length; CompressionMethod compression_algorithm; opaque master_secret[48]; opaque client_random[32]; opaque server_random[32]; } SecurityParameters; 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. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Jul 29 04:20: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 AADE43A0934; Wed, 29 Jul 2020 04:20:14 -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=unavailable 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 j0c8ZFRo16Fi; Wed, 29 Jul 2020 04:20:13 -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 241063A0924; Wed, 29 Jul 2020 04:20:13 -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 06TBHYdG030600; Wed, 29 Jul 2020 12:20:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=Sn8qqZGBQ4138R399Goj+VRJ4axzxjUuBohbOL40mWE=; b=k2t952QvMFQtQ8ood9Vl8Vv5zmNZxGpAd3ZQ4vvxgY0PAsoQmmxNt3QFl08WtfRtSS4M anHjQ9V+o8V7WIJCQP/WL6hi4Gl9TfzvkkmhCXeGQ+btvTzBn+SXXhNl4jRbtvhqZsgZ noI8VI5I8xDgaQx0vP/vggApy6z4TtRhgAkyVPtA3blqwFX682z60wW1lAV0fcKeGnyC 0dZXkicbTc+lb2oeb4zyneQ8pVtpiVl5gdaRu2x0zWs26wlo0RhE5IN1EV8WMskrd0M4 9jxkzZ4baiulO3y7oKpvWbHjYRqPfOCNGVPoAXWLFA/dtxwTZewjoE0ImO/Mdx9brnOx QA== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 32gcd3njwd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jul 2020 12:20:11 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06TB2TX8030909; Wed, 29 Jul 2020 04:20:06 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint5.akamai.com with ESMTP id 32gjqbacx2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 29 Jul 2020 04:20:06 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 07:20:05 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.006; Wed, 29 Jul 2020 07:20:05 -0400 From: "Salz, Rich" To: Watson Ladd , "Eric Wang (ejwang)" CC: "tls@ietf.org" , Jen Linkova , "OpSec Chairs" , OPSEC Thread-Topic: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AdZd8qs4MVhjKcpfSaSC3eC5PK0rEQCv6iMAAH8Fd4AAUf7RAABaakYAAA6JtwA= Date: Wed, 29 Jul 2020 11:20:04 +0000 Message-ID: References: <4937FCE4-23EF-4585-8675-C07F3B347AC6@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.240] Content-Type: multipart/alternative; boundary="_000_E39579F4B5614B12A9BF8625B05ACA34akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-29_04:2020-07-29, 2020-07-29 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 suspectscore=0 mlxlogscore=833 bulkscore=0 adultscore=0 spamscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007290071 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-29_04:2020-07-29, 2020-07-29 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 adultscore=0 mlxlogscore=790 priorityscore=1501 phishscore=0 malwarescore=0 lowpriorityscore=0 suspectscore=0 mlxscore=0 bulkscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007290073 Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 11:20:15 -0000 --_000_E39579F4B5614B12A9BF8625B05ACA34akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxzbywgYSBDRE4gaXMgbm90IGEgcHJveHkuICBJdCAqSVMqIGFuIGVudGl0eSB0aGF0IHRoZSBv cmlnaW4gaGFzIGNvbnRyYWN0ZWQgd2l0aCB0byBwZXJmb3JtIGNlcnRhaW4gZnVuY3Rpb25zLg0K DQo= --_000_E39579F4B5614B12A9BF8625B05ACA34akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <0D7CF0414008784B85DDF64CDC56D496@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCBhIENETiBpcyBub3QgYSBwcm94 eS4mbmJzcDsgSXQgKjxiPklTPC9iPiogYW4gZW50aXR5IHRoYXQgdGhlIG9yaWdpbiBoYXMgY29u dHJhY3RlZCB3aXRoIHRvIHBlcmZvcm0gY2VydGFpbiBmdW5jdGlvbnMuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_E39579F4B5614B12A9BF8625B05ACA34akamaicom_-- From nobody Wed Jul 29 07: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 7A8363A0B86; Wed, 29 Jul 2020 07:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 e0e6a7FlJjNr; Wed, 29 Jul 2020 07:42:19 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.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 BC5183A0B84; Wed, 29 Jul 2020 07:42:16 -0700 (PDT) Received: from [66.31.15.242] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1k0nHY-0003PJ-W1; Wed, 29 Jul 2020 10:42:13 -0400 Date: Wed, 29 Jul 2020 10:42:13 -0400 From: Bill Frantz To: Jen Linkova cc: tom petch , opsec WG , tls@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79f3104690fb6afc49ea7b4b604e004eae350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.31.15.242 Archived-At: Subject: Re: [TLS] [OPSEC] OpSec WGLC for draft-ietf-opsec-ns-impact 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 Jul 2020 14:42:22 -0000 On 7/29/20 at 5:20 AM, furry13@gmail.com (Jen Linkova) wrote: >So issuing the WGLC in the trough between IETF meetings caused an >undesirable outcome of people not paying enough attention. >But thanks for the comments, I'll take it into account - let's >consider it my learning curve.. As a long-time lurker on the TLS list, I don't think these=20 comments apply to the TLS working group. I see the ongoing=20 business of draft, comment, new draft etc. going on=20 continuously, only to be interrupted with email about IETF=20 scheduling and agendas. I would suggest that anything requiring input from the TLS=20 working group be presented between IETF meetings, when there are=20 many TLS experts who will take the time to review and comment. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz | "I wish there was a knob on the TV to turn=20 up the 408-348-7900 | intelligence. There's a knob called=20 "brightness", but www.pwpconsult.com | it doesn't work. -- Gallagher From nobody Wed Jul 29 13: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 499B53A0EF6 for ; Wed, 29 Jul 2020 13:48:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 y2sw7W-yxjN0 for ; Wed, 29 Jul 2020 13:48:47 -0700 (PDT) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (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 047703A0EF4 for ; Wed, 29 Jul 2020 13:48:46 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id x5so3890027wmi.2 for ; Wed, 29 Jul 2020 13:48:46 -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 :cc; bh=wJLCC986mqxFrzxfQzNf2bmedeaqCnA7UEbeUV3GmfQ=; b=efDGx4OKUD6YuArYBssgpJxnig2zGvHRH3blQtqQvv+2RkroVJI20pJRcsMFeLZcTA regPl2wXZjIxzcjRW5DuG4MnvBthBsowFUArKbYGg4IN2RKA8wIH3avy/XjlodicA9x7 jOwUMzRv7j1G9MrToVcbA/rNxajJT4JP/mf68nM60fDH1rFzVZVs0MbXv82c6iyC27X1 ZO6+pGYVV8AE8ILQhCb755RoQFG7xI/fwfPIMGxXSdUis82+2skIC135/DGgvwW7CQew PPQweLaJvARMGevqOcMayV/gquoKUuamBEGjgnVpLmIVzFxXwkJgeChkdcJS1bgKLSrB CIEQ== 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=wJLCC986mqxFrzxfQzNf2bmedeaqCnA7UEbeUV3GmfQ=; b=pMFfb4cWql5ZgpHP4AZXPwfE6dBYu4a+IjEXy/hU4ZshiE/luXXo3Umpaq15v1ZZE4 nfZu4q7Ub0GH8Va3QLDCzSo0MJZABEivINT++VDkXGM85BDmPg9/Tv23TJcSLpnky1El z0t7+YURSfxqyNbVTHB0hN01uSR4yrI2EEf+Hte1w4C7t0xgaFx5QlaLJ6FRElSZcSvP M0t5A1ZGYwM23wyNJZR643vUmq6wTtWWh8Y2Z+XcTH3rY2zswborEOyVNsCk1LMq/sOe 8R9FwVR3RJt+g2yL/4i58mwnCX72ql4drD2ndqfvrYkfFRPOhgNLETInQBZbNI9jNsYl eJig== X-Gm-Message-State: AOAM530um5lPi49oekk1JumoGWbFC+3L3ysufK33eWG7tA+LVz5c/TOz gh7dRWbAczLtJVtMtz/cnNH/i31/6uGufkpaHPzHyHukW4k= X-Google-Smtp-Source: ABdhPJwJy+hKA8gdW946ft46MRwQtnEK42QssB4DGLaWjE2u4wxCfD2BRE3lDE13atEh9oDrvRc1FX+aK8YSN7EyVOI= X-Received: by 2002:a1c:4183:: with SMTP id o125mr10216871wma.101.1596055725154; Wed, 29 Jul 2020 13:48:45 -0700 (PDT) MIME-Version: 1.0 References: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net> In-Reply-To: <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net> From: Ben Schwartz Date: Wed, 29 Jul 2020 16:48:33 -0400 Message-ID: To: Christian Huitema Cc: Yiannis Yiakoumis , network-tokens@ietf.org, "" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000092a11305ab9aae93" Archived-At: Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI 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 Jul 2020 20:48:52 -0000 --00000000000092a11305ab9aae93 Content-Type: multipart/alternative; boundary="0000000000008aa97e05ab9aae36" --0000000000008aa97e05ab9aae36 Content-Type: text/plain; charset="UTF-8" This proposal is highly ossifying. Application protocols that are included in this scheme become very difficult to update. For example, in the case of zero-rating, this proposal would only be able to zero-rate application protocols that are understood by the network's token-parsing appliance. This seems likely to have serious negative consequences for protocol innovation, as these applications would no longer be able to implement novel protocols without losing whatever advantage the network token offers. For TLS, this proposal would ossify the extension format, which could no longer evolve in future TLS versions without risking loss of network services. The proposal also violates the TLS Protocol Invariants, by attempting to process the ServerHello after forwarding an arbitrary ClientHello. It would also fail for QUIC, as previously noted, due to QUIC's mobility support, which is important for performance on mobile devices. Additionally, storing this information in the TLS handshake causes an unnecessary privacy loss: it forces the token to be visible across the whole internet, even though it is only relevant on the near-client network segment. Even if the token is entirely opaque, a pervasive surveillance adversary could distinguish between connections with and without tokens, likely differentiating certain applications from others. I recommend that the authors focus on the draft's proposal to use an IPv6 extension header, and remove the other proposed encapsulations. Also, please remove the specific extension number from Section 7.1 unless and until IANA has allocated a number. For testing, you should use a value from the Private Use range, 65282-65535. On Fri, Jun 26, 2020 at 1:43 PM Christian Huitema wrote: > > On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote: > > > > > On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema > wrote: > >> On 6/25/2020 11:11 PM, Melinda Shore wrote: >> >> On 6/25/20 3:29 PM, Erik Nygren wrote: >> >> One quick comment is that binding tokens to IP addresses is strongly >> counter-recommended. >> It doesn't survive NATs or proxies, mobility, and it is especially >> problematic in IPv6+IPv4 dual-stack environments. >> >> There's been a bunch of past work done developing similar sorts of >> protocols, and for what it's worth I wrote up a mechanism for using address >> tags and address rewrites, but unfortunately Cisco decided to patent it. >> Anyway, there are ways of dealing with this problem that don't require >> binding the address to the token ("all technical problems can be solved by >> introducing a layer of indirection"). >> >> There is also an interesting privacy issue. The token is meant to let a >> provider identify some properties of the connection. I suppose there are >> ways to do that without having it become a unique identifier that can be >> tracked by, well, pretty much everybody. But you have better spell out >> these ways. >> > > You are right that for the duration of a token, one could use it to > identify an endpoint (either application or most likely a combination of > user/application). Tokens expire and intermediary nodes cannot correlate > tokens with each other as they are encrypted. So tracking cannot happen > across different tokens (of the same user), or between token-enabled and > non-token-enabled traffic. I guess similar type of tracking happens when > users are not behind a NAT and their IP address can be used to track them. > Would it make sense to have the user add a random value to a token, and > then encrypt it with the network's public key, so that each token becomes > unique and cannot be tracked. Would that address the privacy concerns > better? > > That would certainly be better. The basic rule is that any such identifier > should be used only once. Pretty much the same issue as the session resume > tickets. > > > Then, there are potential interactions with ESNI/ECH. The whole point of >> ECH is to keep private extensions private. The token extension would need >> to be placed in the outer envelope, which is public but does not expose >> seemingly important information like the SNI or the ALPN. >> > > Ah, I was not aware that ESNI can now include all CH extensions - thanks > for the pointer. Yes, the token would have to stay on the outer envelope so > the network can process it. The main idea is you can encrypt everything > that is client-server specific, and just keep a token to explicitly > exchange information with trusted networks. > > There are also implications for QUIC, in which the TLS data is part of an >> encrypted payload. The encryption key of the TLS carrying initial packets >> is not secret in V1, but it might well become so in a future version. >> > > Haven't looked into QUIC yet, but is on the list of things to do. If > anyone is interested to help us explore this, please let me know. > > You may want to have that discussion in the QUIC WG. If you are building > some kind of QoS service, you probably want it to work with QUIC too. > > -- Christian Huitema > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000008aa97e05ab9aae36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This proposal is highly ossifying.=C2=A0 Application proto= cols that are included in this scheme become very difficult to update.=C2= =A0 For example, in the case of zero-rating, this proposal would only be ab= le to zero-rate application protocols that are understood by the network= 9;s token-parsing appliance.=C2=A0 This seems likely to have serious negati= ve consequences for protocol innovation, as these applications would no lon= ger be able to implement novel protocols without losing whatever advantage = the network token offers.=C2=A0 For TLS, this proposal would ossify the ext= ension format, which could no longer evolve in future TLS versions without = risking loss of network services.=C2=A0 The proposal also violates the TLS = Protocol Invariants, by attempting to process the ServerHello after forward= ing an arbitrary ClientHello.=C2=A0 It would also fail for QUIC, as previou= sly noted, due to QUIC's mobility support, which is important for perfo= rmance on mobile devices.

Additionally, storing this inf= ormation in the TLS handshake causes an unnecessary privacy loss: it forces= the token to be visible across the whole internet, even though it is only = relevant on the near-client network segment.=C2=A0 Even if the token is ent= irely opaque, a pervasive surveillance adversary could distinguish between = connections with and without tokens, likely differentiating certain applica= tions from others.

I recommend that the autho= rs focus on the draft's proposal to use an IPv6 extension header, and r= emove the other proposed encapsulations.=C2=A0 Also, please remove the spec= ific extension number from Section 7.1 unless and until IANA has allocated = a number.=C2=A0 For testing, you should use a value from the Private Use ra= nge,=C2=A065282= -65535.

On Fri, Jun 26, 2020 at 1:43 PM Christian Huitema= <huitema@huitema.net> wro= te:
=20 =20 =20


On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:
=20
3D""



On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema <huitema@huitema.net> wrote:

On 6/25/2020 11:11 PM, Melinda Shore wrote:

On 6/25/20 3:29 PM, Erik Nygren wrote:

One quick comment is that binding tokens to IP addresses is strongly counter-recommended.
It doesn't survive NATs or proxies, mobility, and it is especially problematic in IPv6+IPv4 dual-stack environments.

There's been a bunch of past work done developing similar sorts of protocols, and for what it's worth I wrote up a mechanism for using address tags and address rewrites, but unfortunately Cisco decided to patent it. Anyway, there are ways of dealing with this problem that don't require binding the address to the token ("all technical problems can be solved by introducing a layer of indirection").

There is also an interesting privacy issue. The token is meant to let a provider identify some properties of the connection. I suppose there are ways to do that without having it become a unique identifier that can be tracked by, well, pretty much everybody. But you have better spell out these ways.


You are right that for the duration of a token, one could use it to identify an endpoint (either application or most likely a combination of user/application). Tokens expire and intermediary nodes cannot correlate tokens with each other as they are encrypted. So tracking cannot happen across different tokens (of the same user), or between token-enabled and non-token-enabled traffic. I guess similar type of tracking happens when users are not behind a NAT and their IP address can be used to track them. Would it make sense to have the user add a random value to a token, and then encrypt it with the network's public key, so that each token becomes unique and cannot be tracked. Would that address the privacy concerns better?

That would certainly be better. The basic rule is that any such identifier should be used only once. Pretty much the same issue as the session resume tickets.


Then, there are potential interactions with ESNI/ECH. The whole point of ECH is to keep private extensions private. The token extension would need to be placed in the outer envelope, which is public but does not expose seemingly important information like the SNI or the ALPN.


Ah, I was not aware that ESNI can now include all CH extensions - thanks for the pointer. Yes, the token would have to stay on the outer envelope so the network can process it. The main idea is you can encrypt everything that is client-server specific, and just keep a token to explicitly exchange information with trusted networks.=C2=A0

There are also implications for QUIC, in which the TLS data is part of an encrypted payload. The encryption key of the TLS carrying initial packets is not secret in V1, but it might well become so in a future version.


Haven't looked into QUIC yet, but is on the list of things to do. If anyone is interested to help us explore this, please let me know.

You may want to have that discussion in the QUIC WG. If you are building some kind of QoS service, you probably want it to work with QUIC too.

-- Christian Huitema

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000008aa97e05ab9aae36-- --00000000000092a11305ab9aae93 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAH8qNflD4Mi9yKttXfRdHcwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDA2MDUwODIyMjhaFw0yMDEyMDIwODIyMjhaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kbyV9S0YLplF3kV 6t3GgD7IyHe8L29pJ7l+UR0Sj31uPgXOFdSSdTVwhPfQvxmB2OUDXWDgDtZdL2xu4DgHhrDyyOXT 8uDJqUCPw004ZSuUfUor1vz5u6+oYNfx2OTPTb81vtsQO2/khni3iAeQlKgO/rUI1c9+zvT6k3mR SZUypAlk/rCyG6NV7NMJMmOaU20/kPBXG297iP8+/F9w4xs+lyb3IkcSfoSUr3fVz7mYqESFato5 JnjRQGT2/f/ehxkc09jATqVGj9nyQMoD2GNPjiNnYyTVBwK5Ol/s9+E2VSL4TSLrgS2R07kY9zPi VOM3lhDDRnceboNSaqnfMwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUwJS1fB3cBxoLgZFatdIO9Vp5wOcwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQCC91PBn9rMxo8kSo1zNY2mxkTQDTVc0oyYk8s3y72y21IEp/d/+h1H VTCD2FR30aFUv8hTJkebJ5Z1/zue2L7sx/lLEOIHm9uYxyTkTWbKup3+XrE1vhODTHVx+ktMuOTY z447/fwjy4praSaFrQsOjTPbAoU6xuC8S2j2K2Yg6XQsctcKHKeAJjN6evZYChDaTBLmtYq9LTSH KVv3Et795vNK3gWKjhEkJtaBu4FfKLoopb1PENJ/zK6p/3edCLFgCRMSlbQ0SGtdVESSJcgezSwW WK2VB1Zcj2kyVzcL1pmV8m1xQuz2aBgUMn7peoVxKxYKP12gMtzeMvkzltYBMYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhAB/KjX5Q+DIvcirbV30XR3MA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCD11GBcrH3+fQAhgjTrSUaPZKP8MwXxmfKrLliTtguFazAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3MjkyMDQ4NDVaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAIHwr44FHQaQ19mqG96+z2MZ65PfI5J4S/ylYWuEH2cROjayIg5cVIUmQl9qZGyD7SEtbsyap mNc2+HadDsTJEuPxi6/b92An6Njp+UlomcgAITts8F727dG3/6+5vJzolWCY/R3eWJQUYaDRv4r5 G7AO2OTcKH3hgr660Hb3z/bDKG9AtcKQ4O++4REnFdfXZwgdPuVB70wrecOI2KE2shgg5Yhc2cl4 xVJHQqqGjMbK8+mxgLRezxPLfQRM/S1SylKDSiVcbDmYJVAnRc7vCOW8bCqHTi7n/12rLU7snl7J aemvYj6VTGgtjH7ZWsfqlcbgxQbRB1rCK5JklMbGQQ== --00000000000092a11305ab9aae93-- From nobody Wed Jul 29 15:46: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 B904A3A08FF; Wed, 29 Jul 2020 15:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 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, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=VdiRNDs7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Thk4pvOO 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 r3eDTcZ1cW9w; Wed, 29 Jul 2020 15:46:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E56833A08F8; Wed, 29 Jul 2020 15:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28537; q=dns/txt; s=iport; t=1596062789; x=1597272389; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IQoApdB7p8cEUqv+hFSNKp0WtkAs9KV8QSQxwWDtVJE=; b=VdiRNDs7pIh+Lx6bFhmjL6CiLkSyfz8sSKiLYiiLNhQZGXlaD0GsImEe d8QiGVcWRneamdsGvnTdPcKV49Y/YRDbSF36quSCH7CHndkrInmhPcYXj QNmLCG2rgClu5ljmBEm3pwP8TEhX2HiKUDolxU5V/E4E7T2AO65FsVTQN o=; IronPort-PHdr: =?us-ascii?q?9a23=3AsEoERBAjM1YrGn4zawTbUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw30A3FWIzB4LRFhvbY9af6Vj9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7ep3So5ngTFw?= =?us-ascii?q?nxcw1vKbe9Fovblc/i0ee09tXaaBlJgzzoZ7R0IV22oAzdu9NQj5FlL/M6yw?= =?us-ascii?q?DCpT1DfOEFyA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAgCK+yFf/4sNJK1XCR0BAQEBCQE?= =?us-ascii?q?SAQUFAYF5BQELAYEiLyMuB29YLywKhCuDRgONKpkGglMDVQsBAQEMAQEYAQw?= =?us-ascii?q?IAgQBAYRMAheCDQIkNwYOAgMBAQsBAQUBAQECAQYEbYVcDIVyAgQBARALBh0?= =?us-ascii?q?BASwLAQ8CAQg/AwICAiULFBECBA4FIoMEAYF+TQMuAQ6kfAKBOYhhdoEygwE?= =?us-ascii?q?BAQWFFhiCDgMGgTgBgm6CUktChj8aggCBEScMEIFPfj6CXAEBAgGBMAMRFy6?= =?us-ascii?q?CaTOCLY80EYMrhl2cOwqCX4hbhj+KZQMen3ScU5BHT4NWAgQCBAUCDgEBBYF?= =?us-ascii?q?pJIFXcBU7KgGCPj4SFwINjh4MF4NOhRSFQnQCNQIGAQcBAQMJfI01gTUBgRA?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.75,412,1589241600"; d="scan'208,217";a="714723825" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jul 2020 22:46:28 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 06TMkSLx012613 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jul 2020 22:46:28 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 17:46:28 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 18:46:27 -0400 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 29 Jul 2020 18:46:27 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ndMBSHMoDt14a0Xlr7/swN6Sjq9oGGlpFAbr+q2SAZaj7Qi2ThxhunKtIU/s1JjlnB1G4mnHNQziwvm5oMY5KL8GjynA1d4+C/MLi4moZI7UME5m+V8f/oVbM4shyLou1llTqJyPf1Rs+c50s9uMVcTyaZMM11Enxd+ve7JJALetRIwxDEFWEzeqyHsLo8+Al73dvEKA2yDsmQSj2MFwhZB5sFfwvGm+TkNH1LFN2bIp9XGPlZcROgyiFZBX+kgFZBwk1AJVpUzlKLsN8b1li70y/RizBIzF55/E+1XWO7Vwj3w+3lOdVDMHED7oKaayS8SP3t+KIyI5W1nyIt3sGg== 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=IQoApdB7p8cEUqv+hFSNKp0WtkAs9KV8QSQxwWDtVJE=; b=mcFg/+/9wxNQ5+P7+Hd3Y3pALTPUVKoQNcD6/GLgCAenrK8a1J+7ZNDeh/Ks6JbsUWwsRurM8weMl8RlarfkFjReN6HCRLb/TxtKFG9rpx84b0rWLqv1B7IKjprueJqDvWagomVJLg6dm2yxzsO3LAlGdo/uwwg4/1WYtcfy+kVY60uAKRi/2enAyWk4kx3ip+n6OJhRers1caGBc0b5/rBftWtMA0bbGLw4xWw2zrMRI5cfSQrhjLB2FXIPqwPX9lTPqDMfltszn0za2zCGsR5pC4jh8ePvWsgAUcjCphZDMJw03hkoVDCEzX/5TaZTGESJnSee33yR6uog78SNcw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IQoApdB7p8cEUqv+hFSNKp0WtkAs9KV8QSQxwWDtVJE=; b=Thk4pvOOHqJpgpxLuk+bzjl/q4ey3dtLxIBjhlyXp9ZEU16sdtQviNU59cK5o58bYyzDa4yeqelrr2Z95K/jl6w21tME0OBgHbfpyiQWAeKN9/1q3V0XeDNtN/Rw1GJK7nUUfZIffkTTP/rF+0suNbACJKgTIXm783XUNG6kSlY= Received: from BYAPR11MB2789.namprd11.prod.outlook.com (2603:10b6:a02:cc::11) by BYAPR11MB2758.namprd11.prod.outlook.com (2603:10b6:a02:c9::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17; Wed, 29 Jul 2020 22:46:26 +0000 Received: from BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870]) by BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870%6]) with mapi id 15.20.3216.033; Wed, 29 Jul 2020 22:46:26 +0000 From: "Eric Wang (ejwang)" To: Nick Harper CC: Martin Thomson , Ron Bonica , OPSEC , "tls@ietf.org" Thread-Topic: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AQHWZUAxl1+CjQkbHU6//l5iRsxvD6kfKasA Date: Wed, 29 Jul 2020 22:46:26 +0000 Message-ID: References: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.15) authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [128.107.241.169] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a7fab501-c214-4850-a674-08d8341139da x-ms-traffictypediagnostic: BYAPR11MB2758: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: K5jnIFoIKzep35vYt7XcFKZmBl/gbWlC3KJG3b6c0W9pqYuRJS3GJIlGjfpZTrpXWDgmYkmD33RY8by/nuzQsymK9ALeYDYlOi31vEfN3zWJjw5FQJ6FDUVKY0Gvk8p+cGgQyeoRk1XRKmBc/q18Prt7A8bsWZhCIuLXjLTIj0RE3Q9k/+RJB4/j8++bck/yu0TH2sPTL20shcniJvqS8D32gvIl8K4qAjhWo//eKA8wghBsEOINszCMAF6kcLfNp3NdVIEllFMRDcZNsXb6qGtYKuLJToCG2E/MuKRf9kRuDu9hI9M184eQCkUVk12TDp2XZCgmYLRbb7P9C70YxrBnl9LqYdfSXmCaPq8oT5wCfDGK875kuIdmBzDsClupSqt1UqRTMFf2S2RWFiNKZQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2789.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(366004)(396003)(346002)(376002)(8676002)(2906002)(2616005)(83380400001)(6506007)(53546011)(5660300002)(316002)(6512007)(36756003)(4326008)(54906003)(26005)(166002)(33656002)(186003)(76116006)(64756008)(66476007)(86362001)(66446008)(91956017)(66556008)(71200400001)(966005)(6486002)(478600001)(66946007)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 2o87w+P0FJnDAHRE2KbiNl7ML71zaqM4WVH8kBTFVG5VWeOHsgaSERb3JqCU7PPD+iHtm67uMcPu2gKjZNYa2BExBn0TmhLFrbcLePLNsPXTyHHi9S/T9Is8j8vP6gMiaG6AeMQKGEcNtH7RuYNIFg5E8bk71mDeHKqrQPud1U1e1JjdukFPuLr3bisNDJA5hInKG6w03jVFOqIsJpwkUOpJPo/ZEbeftZZ+uLPFsMDxyzR33iMCtgcd+IQrtJNLPqsbGxOf8P7DD7m4QkB81aBB3rUmCv2GqJ9bOWOtocngXpCqfTwbrjgZhjpEHKrG61rw/FX4f0j5SWg5CAyvbWIFqv9KBMcgVOfVtpvLHxUC1+PTRfPRG0pZxtCNa6m8GUDSKTQv/CbmP74Y5/thH5UiIQaHmNdd6mQRbiPf3YFQhm7JHBs9k/+DmYL3zuhvGf7Es6Lz1G6+r5Etx/8PDwms6I2SxMM5IteCH2/4jpiCPqNT81/fk0B+yiTM3HTYEpi5QqIJZbldRT2RjGMNcze90Ha+BecR9h7VgJGOjGgT0DGY/DsHccmjQMo9HEuPQ70t36YuwBZd/sew7FpurHc4tCWtSwoVECHeS6gvfgXpqzoZXtHFevmj2GDefrksWLXIejamNTyvesL/Zd7fpw== Content-Type: multipart/alternative; boundary="_000_F40B9423B0D549938A3DD875C62951E4ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2789.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a7fab501-c214-4850-a674-08d8341139da X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2020 22:46:26.1534 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dNx5ytY0iyjdltCaQuJk4+URVneP2YTCxG1pTRt0wZCbF3EWgy3nbdPyAQySJ8RhARwhd0h5GeC+s/2meiWXJg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2758 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 22:46:34 -0000 --_000_F40B9423B0D549938A3DD875C62951E4ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgbG9va3MgdGhlIOKAnHNlbGVjdGl2ZSBwcm94eWluZ+KAnSB0b3BpYyByZXF1aXJlcyBhIGZ1 bGwgZG9jdW1lbnQgdG8gYW5hbHl6ZSBpdC4gIFRoZSBjby1hdXRob3JzIGRpc2N1c3NlZCBhbmQg aXQgd291bGQgYmUgYSBnb29kIGlkZWEgdG8gcmVtb3ZlIGl0IGZyb20gdGhpcyBkcmFmdC4gIFdl IHdpbGwgbWFkZSB0aGUgdXBkYXRlcy4NCg0KVGhlIGNvbmNlcm4gaXMgdmFsaWQgdGhhdCAidGhl cmUncyBubyBndWFyYW50ZWUgdGhhdCB0aGUgc2VydmVyIHdpbGwgcmVzcG9uZCB0byB0aGUgY2xp ZW50IHRoZSBzYW1lIHdheSBpdCBkaWQgdG8gdGhlIHByb3h5LCBvciBldmVuIHRoYXQgdGhlIGlk ZW50aXR5IHRoZSBzZXJ2ZXIgcHJlc2VudGVkIHRvIHRoZSBwcm94eSBpcyB0aGUgc2VydmVyJ3Mg cmVhbCBpZGVudGl0eeKAnS4gIFdlIGFsc28gaGF2ZSB0byBkaXZlIGludG8gdGhlIGRldGFpbHMg YWJvdXQgd2hpY2ggcGllY2Ugb2Ygc2VydmVyIHJlc3BvbmRlZCBpbmZvcm1hdGlvbiBpcyBiZWlu ZyB1c2VkIGZvciBzZWxlY3RpdmUgcHJveHlpbmcsIGFuZCBob3cgb2Z0ZW4vd2hhdCB0byBkbyB3 aGVuIHRoYXQgY2hhbmdlcy4NCg0KVGhlICJtYWxpY2lvdXMgY2xpZW50IGFuZCBjb29wZXJhdGlu ZyBzZXJ2ZXLigJ0gcHJvYmxlbSBleGlzdHMgb3V0c2lkZSBvZiBhIFRMUyBwcm94eSBkZXBsb3lt ZW50LiBUaGVyZSBhcmUgbWFueSB3YXlzIHRvIGNpcmN1bXZlbnQgYSBUTFMgcHJveHkgaWYgb25l IGNvbnRyb2xzIGJvdGggc2lkZXMuICBUaGUgZG9jdW1lbnQgdG91Y2hlZCBpdCBpbiBTZWN0aW9u IDUuMjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FuZy1vcHNlYy10bHMtcHJv eHktYnAtMDAjc2VjdGlvbi01LjI+Lg0KDQpTb21lIFRMUyBwcm94eSBpbXBsZW1lbnRhdGlvbnMg dmlvbGF0ZWQgdGhlIFJGQyBpbiB0aGUgcGFzdCwgYnV0IG5vdGhpbmcgaW4gb3VyIGRyYWZ0IHN1 Z2dlc3RzIHRoYXQgYSBtb2Rlcm4gVExTIHByb3h5IGRvZXMgb3Igc2hvdWxkIHZpb2xhdGUgdGhl IFRMUyBzcGVjLiAgSXQgd2FzIHRoZSBtb3RpdmF0aW9uIG9mIHRoaXMgZHJhZnQgdG8gaGVscCBy ZWR1Y2UvcHJldmVudCBub24tY29tcGxpYW5jZSwgYXMgbWVudGlvbmVkIGVhcmxpZXIuDQoNCg0K T24gSnVsIDI4LCAyMDIwLCBhdCA1OjM0IFBNLCBOaWNrIEhhcnBlciA8bmhhcnBlcj00MGdvb2ds ZS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOm5oYXJwZXI9NDBnb29nbGUuY29tQGRtYXJjLmll dGYub3JnPj4gd3JvdGU6DQoNCg0KDQpPbiBUdWUsIEp1bCAyOCwgMjAyMCBhdCAyOjE5IFBNIEVy aWMgV2FuZyAoZWp3YW5nKSA8ZWp3YW5nPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPG1haWx0 bzo0MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KVGhhbmsgeW91IGZvciB0aGUg ZGV0YWlsZWQgY29tbWVudHMuDQoNClRoZSBzY29wZSBvZiB0aGUgZG9jdW1lbnQgaXMgbGltaXRl ZCB0byBwcm94eSBhdCB0aGUgVExTIGxheWVyLiAgRXhwbGljaXRseSBvdXQgb2YgdGhlIHNjb3Bl IGlzIGluc3BlY3Rpb24gb2YgdGhlIHByb3hpZWQgcmVjb3JkIGRhdGEuICAgV2lsbCBjbGVhbiB1 cCBkZXJpdmF0aW9ucyBmcm9tIHRoaXMgc2NvcGUuDQoNCkl0IHdhcyB0aGUgaW50ZW50aW9uIHRv IGNvdmVyIHNlbGVjdGl2ZSBwcm94eWluZyBob3dldmVyLCBiZWNhdXNlIHRoYXQgaXMgYSBwcmFj dGljYWwgcmVxdWlyZW1lbnQgZm9yIGFuIGFjdHVhbCBkZXBsb3ltZW50LiAgVGhlIGludGVudGlv biB3YXMgdG8gZGlzY3VzcyB0aGUgVExTIGxheWVyIGF0dHJpYnV0ZXMgKGUuZy4gU05JLCBTZXJ2 ZXIgQ2VydCkgdGhhdCBjb3VsZCBiZSB1c2VkIGFzIGlucHV0IGZvciB0aGUgZGVjaXNpb24uICBU aGUgZG9jdW1lbnQgYWxzbyBzdGF0ZWQgdGhlIHJlcXVpcmVtZW50IHRvIGdyYWNlZnVsbHkgcmVt b3ZlIHRoZSBwcm94eSBmcm9tIHRoZSBzZXNzaW9uIHdoZW4gbmVlZGVkIChhbmQgcG9zc2libGUp LiAgQnV0IHRoZSBjcml0ZXJpYSBmb3Igc2VsZWN0aXZlIHByb3h5aW5nIGRlY2lzaW9uLCBiZWlu ZyBjb21wbGlhbmNlLCBwcml2YWN5LCByaXNrIGxldmVsLC4uLiBhcmUgb3V0IG9mIHRoZSBzY29w ZS4gIFRoZSBkZWNpc2lvbiBtYWtpbmcgb2Z0ZW4gZmFsbHMgdW5kZXIgdGhlIGxhcmdlciDigJxw b2xpY3nigJ0gZG9tYWluIGFuZCBpcyBjb250cm9sbGVkIGF0IHN5c3RlbSBsZXZlbCBvdXRzaWRl IG9mIHRoZSBwcm94eS4gIEl0IGFsc28gbGVmdCBvdXQgZGlzY3Vzc2lvbiBvbiB0aGUgZGV0YWls ZWQgbWVjaGFuaXNtIHdoaWNoIHdhcyBkZWVtZWQgYXMgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMu DQoNCkluIGFueSBjYXNlLCB0aGUgcHJveHkgaGFzIHRvIGNvbmR1Y3Qgc2VsZWN0aXZlIHByb3h5 aW5nIGluIGEgc2FmZSwgbm9uLWRpc3J1cHRpdmUgbWFubmVyLiBUaGlzIG1heSByZXF1aXJlIG1v cmUgZGVzaWduIHdvcmsgYXMgeW91IHBvaW50ZWQgb3V0LiAgVGhlIGRvY3VtZW50IGNvdWxkIGRl c2NyaWJlIHBvc3NpYmxlIG1lY2hhbmlzbXMgc28gdGhhdCBhbiBhY2NlcHRhYmxlIHByYWN0aWNl IGNvdWxkIGJlIGRpc2N1c3NlZC4gIFdlIGFyZSBvcGVuIHRvIG90aGVyIHdheXMgdG8gc2hhcGUg aXQuDQoNCkFuIGFjY2VwdGFibGUgcHJhY3RpY2UgTVVTVCBpbmNsdWRlIG5vdCB2aW9sYXRpbmcg dGhlIHByb3RvY29sIGludmFyaWFudHMgaW4gUkZDIDg0NDYuIEl0IGlzIG5vdCBwb3NzaWJsZSBm b3IgYSBwcm94eSB0byBvYmV5IHRoZSBwcm90b2NvbCBpbnZhcmlhbnRzIGFuZCBzZWxlY3RpdmVs eSBwcm94eSBiYXNlZCBvbiB0aGUgY29udGVudHMgb2YgdGhlIFRMUyBoYW5kc2hha2UgYmV0d2Vl biB0aGUgcHJveHkgYW5kIHRoZSBzZXJ2ZXIgYSBjbGllbnQgd2lzaGVzIHRvIGNvbm5lY3QgdG8u DQoNCk1vcmUgaW5saW5lLi4uDQoNClByb2JhYmx5IHRoZSB3b3JzdCBwcm9ibGVtIGlzIHJvb3Rl ZCBpbiBTZWN0aW9uIDUuMS4gIFRoZSBpbnRyb2R1Y3Rpb24gZXN0YWJsaXNoZXMgdGhpcyBhcyBi ZWluZyBhYm91dCBwcm94eWluZywgYnV0IHRoZXJlIGFyZSBzZXZlcmFsIHBsYWNlcyB0aGF0IHRh bGsgYWJvdXQgbm90LXByb3h5aW5nIHNvbWV0aW1lcy4NCg0KU2VsZWN0aXZlIG5vbi1wcm94eWlu ZyBvcGVucyB0aGUgZG9jdW1lbnQgdXAgdG8gYSB3aG9sZSBuZXcgc2V0IG9mIHByb2JsZW1zIHRo YXQgYXJpc2UgZnJvbSBwb29yIGRlc2lnbnMgZm9yIGRlY2lkaW5nIG5vdCB0byBwcm94eS4gIFRo ZXJlIGlzIG5vdCBuZWFybHkgZW5vdWdoIGRldGFpbCBoZXJlIHRvIGFkZHJlc3MgdGhpcyBwcm9i bGVtIHByb3Blcmx5LiAgQSAiZ29vZCIgZGVzaWduIGZvciBzZWxlY3RpdmUgVExTIHByb3h5aW5n IGRvZXMgbm90IHNlZW0gdG8gYmUgdGhlIGJhc2lzIG9mIHRoZSByZWNvbW1lbmRhdGlvbnMuICBJ J2xsIGdpdmUgYSBmZXcgZXhhbXBsZXMgb2YgcHJvYmxlbXMuDQoNCkZyb20gdGhlIFNlY3Rpb24g NC44IGFnYWluOg0KDQp0aGUgVExTIHByb3h5IE1VU1QgY29uZHVjdCBwcm9wZXIgVExTIHByb3Rv Y29sIGNoZWNrcyB0byBhdm9pZCBmYWxzZSBpZGVudGlmaWNhdGlvbiBvZiBUTFMgaGFuZHNoYWtl cywgd2hpbGUgdGFraW5nIHNwZWNpYWwgY2FyZSBub3QgdG8gY29udHJpYnV0ZSB0byBwcm90b2Nv bCBvc3NpZmljYXRpb24uDQoNClRoaXMgcHJhY3RpY2UgaGFzIGJlZW4gZGlyZWN0bHkgcmVzcG9u c2libGUgZm9yIG1vcmUgb3NzaWZpY2F0aW9uIHRoYW4gaW50ZXJtZWRpYXRpb24sIG5vIG1hdHRl ciB3aGF0IHF1YWxpZmljYXRpb24gZXhpc3RzLg0KDQpJZiBwZXItZGVzdGluYXRpb24gbm90LXBy b3h5aW5nIGlzIHJlcXVpcmVkLCB0aGUgcHJveHkgY2FuIGNvbm5lY3QgdG8gYSBzZXJ2ZXIsIGRl dGVybWluZSB0aGF0IHRoZSBzZXJ2ZXIgaXMgb24gYSBub24tcHJveHkgbGlzdCwgYW5kIHRoZW4g Y29tcGxldGUgdGhlIGhhbmRzaGFrZSB3aXRoIHRoZSBjbGllbnQgKHdpdGggYSBjYXZlYXQgcmVn YXJkaW5nIEVDSCBoZXJlKS4gIEkgY2FuIGd1ZXNzIHdoeSB0aGlzIGRvZXNuJ3QgaGFwcGVuIChp dCdzIGV4cGVuc2l2ZSBhbmQgc2VlIGFsc28gU2VjdGlvbiA1LjQpLCBidXQgdGhhdCBkb2Vzbid0 IGV4Y3VzZSB0aGUgcHJhY3RpY2UuDQoNClRoZSBmb2xsb3dpbmcgdGV4dCBmcm9tIFNlY3Rpb24g NS4zIGlzIGRlZXBseSBwcm9ibGVtYXRpYzoNCg0KICBBIGRlY3J5cHRpb24gcG9saWN5IGRlY2lz aW9uIE1BWSBiZSBtYWRlIGJhc2VkIG9uIHRoZSBzZXJ2ZXINCiAgY2VydGlmaWNhdGUgb3Igb3Ro ZXIgdHJ1c3R3b3J0aHkgcGFyYW1ldGVycy4gIFRvIHZlcmlmeSBwb3NzZXNzaW9uIG9mDQogIHBy aXZhdGUga2V5cyB0aGF0IGFyZSBhc3NvY2lhdGVkIHdpdGggYSBwYXJ0aWN1bGFyIHNlcnZlcg0K ICBjZXJ0aWZpY2F0ZSwgdGhlIHByb3h5IFNIT1VMRCBjb21wbGV0ZSBhbiBvdXQtb2YtYmFuZCBU TFMgaGFuZHNoYWtlDQogIHdpdGggdGhlIHNhbWUgVExTIHNlcnZlciBJUCBhZGRyZXNzIGFuZCBU Q1AgcG9ydCBhcyB0YXJnZXRlZCBieSB0aGUNCiAgVExTIGNsaWVudC4NCg0KSXQgaXMgcG9zc2li bGUgdGhhdCB0aGUgYXV0aG9ycyBtaXN1bmRlcnN0YW5kIGhvdyBUTFMgd29ya3MsIGJ1dCB0aGlz IGNoZWNrIHdvbid0IHdvcmsuICBOb3Qgb25seSBiZWNhdXNlIFRMUyAxLjMgZW5jcnlwdHMgaW5m b3JtYXRpb24sIGJ1dCBiZWNhdXNlIHRoaXMgaXMgb25seSBuZWNlc3NhcnkgaWYgdGhlIHByb3h5 IGZvcndhcmRzIGEgQ2xpZW50SGVsbG8gZnJvbSB0aGUgY2xpZW50IHRvIHRoZSBzZXJ2ZXIuICBB dCB0aGF0IHBvaW50LCBpdCBpcyB0b28gbGF0ZSBhbmQgdGhlIGRhbWFnZSBoYXMgYmVlbiBkb25l IChzZWUgQW5kcmVpJ3MgcmV2aWV3KS4NCg0KDQpVbmxlc3MgSSBtaXN1bmRlcnN0b29kIGl0LCB0 aGUgZG9jdW1lbnQgaXMgc3VnZ2VzdGluZyB0aGUgc2FtZSBhcyB5b3UgbGlzdGVkLiAgQmFzaWNh bGx5LCB0aGUgcHJveHkgbWFrZXMgYSBzZXBhcmF0ZSBjb25uZWN0aW9uIHRvIHRoZSBzZXJ2ZXIg YXMgYSBjbGllbnQgKOKAnG91dC1vZi1iYW5k4oCdIHdydCB0byB0aGUgb3JpZ2luYXRpbmcgY2xp ZW50LXNlcnZlciBjb25uZWN0aW9uKSwgcmV0cmlldmVzIHRoZSBzZXJ2ZXLigJlzIGNlcnRpZmlj YXRlIGZyb20gdGhlIHByb3h5LXNlcnZlciBoYW5kc2hha2UsIGFuZCBkZXRlcm1pbmVzIHdoZXRo ZXIgdGhlIHNlcnZlciBpcyBvbiBhIG5vbi1wcm94eWluZyBsaXN0IG9yIG5vdC4gIElmIG9uIHRo ZSBsaXN0LCB0aGUgcHJveHkgZm9yd2FyZHMgdGhlIG9yaWdpbmF0aW5nIGNsaWVudCBDSCBhcyBp cyB0byB0aGUgc2VydmVyLCBhbmQgc3RlcHMgYXdheXMgZnJvbSB0aGUgb3JpZ2luYXRpbmcgY2xp ZW50LXNlcnZlciBoYW5kc2hha2UuDQoNClRoZSBwcm94eSBNVVNUIGdlbmVyYXRlIGEgZnJlc2gg Q2xpZW50SGVsbG8gd2hlbiBkb2luZyB0aGlzIChzb21ldGhpbmcgQW5kcmVpIGFuZCBJIHByZXZp b3VzbHkgbWVudGlvbmVkKS4gV2hlbiB0aGUgcHJveHkgbWFrZXMgaXRzIHNlcGFyYXRlIGNvbm5l Y3Rpb24gdG8gdGhlIHNlcnZlciwgdGhlIHNlcnZlciBjYW4gYmVoYXZlIGRpZmZlcmVudGx5IHdo ZW4gcmVzcG9uZGluZyB0byB0aGUgcHJveHkgY29tcGFyZWQgdG8gd2hlbiBpdCByZXNwb25kcyB0 byB0aGUgY2xpZW50LCBhbmQgY291bGQgcHJlc2VudCBpdHNlbGYgdG8gdGhlIHByb3h5IGFzIHNv bWV0aGluZyBpbm5vY3VvdXMgdGhhdCBzaG91bGQgbm90IGJlIHByb3hpZWQuIEFzc3VtaW5nIGF0 IHRoaXMgcG9pbnQgdGhhdCB0aGUgcHJveHkgaGFzIGhlbGQgb250byB0aGUgY2xpZW50J3MgQ2xp ZW50SGVsbG8gKHdhaXRpbmcgZm9yIHRoZSByZXNwb25zZSBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhl IHByb3h5J3MgQ2xpZW50SGVsbG8pLCB0aGUgcHJveHkgZGVjaWRlcyBlaXRoZXIgdG8gaW50ZXJj ZXB0IHRoaXMgY29ubmVjdGlvbiBvciBhbGxvdyB0aGUgY2xpZW50J3MgQ2xpZW50SGVsbG8gdG8g Z28gdGhyb3VnaCB0byB0aGUgc2VydmVyLiBXaGVuIHRoZSBwcm94eSBhbGxvd3MgdGhlIGNsaWVu dCdzIENsaWVudEhlbGxvIHRvIGdvIHRocm91Z2ggdG8gdGhlIHNlcnZlciAod2l0aG91dCBpbnRl cmNlcHRpb24pLCB0aGVyZSdzIG5vIGd1YXJhbnRlZSB0aGF0IHRoZSBzZXJ2ZXIgd2lsbCByZXNw b25kIHRvIHRoZSBjbGllbnQgdGhlIHNhbWUgd2F5IGl0IGRpZCB0byB0aGUgcHJveHksIG9yIGV2 ZW4gdGhhdCB0aGUgaWRlbnRpdHkgdGhlIHNlcnZlciBwcmVzZW50ZWQgdG8gdGhlIHByb3h5IGlz IHRoZSBzZXJ2ZXIncyByZWFsIGlkZW50aXR5Lg0KDQpJZiB0aGUgcHJveHkgY29waWVzIGV4dGVu c2lvbnMgdW5rbm93biB0byBpdCBmcm9tIHRoZSBjbGllbnQncyBDbGllbnRIZWxsbyB0byBpdHMg b3duLCB0aGVuIGl0IHdpbGwgbm90IGJlIGFibGUgdG8gcGFyc2UgdGhlIHJlc3BvbnNlIGZyb20g dGhlIHNlcnZlciB3aGVuIHRoZSBzZXJ2ZXIgYWN0cyBvbiB0aG9zZSB1bmtub3duIGV4dGVuc2lv bnMuIFRoaXMgY2F1c2VkIGEgeWVhciBvZiBkZWxheSBpbiBmaW5pc2hpbmcgVExTIDEuMywgYW5k IGlzIGJhZCBmb3IgZXZlcnlvbmUuIEEgbWFsaWNpb3VzIGNsaWVudCBhbmQgY29vcGVyYXRpbmcg c2VydmVyIGRvbid0IGV2ZW4gbmVlZCB0byB1c2UgYW4gZXh0ZW5zaWJpbGl0eSBwb2ludCB1bmtu b3duIHRvIHRoZSBwcm94eSB0byBldmFkZSBhIHByb3h5IHNlbGVjdGl2ZWx5IHRlcm1pbmF0aW5n IGNvbm5lY3Rpb25zIGJhc2VkIG9uIHRoZSBUTFMgaGFuZHNoYWtlIGJldHdlZW4gdGhlIHByb3h5 IGFuZCBzZXJ2ZXIuDQoNClRoaXMgc29ydCBvZiBzZWxlY3RpdmUgcHJveHlpbmcgaXMgZnVuZGFt ZW50YWxseSBicm9rZW4gYW5kIHNob3VsZCBub3QgYmUgcmVjb21tZW5kZWQgYXMgYSBiZXN0IHBy YWN0aWNlLg0KDQpUaGVyZSBhcmUgYWRkaXRpb25hbCBjb25zaWRlcmF0aW9ucyBpbiB0aGlzIGFw cHJvYWNoIChsYXRlbmN5IGV0Yy4pLiBUaGUgZG9jdW1lbnQgaW50ZW50aW9uYWxseSBsZWZ0IG91 dCB0aGUgZGV0YWlscyB0byBpbXBsZW1lbnRhdGlvbnMsIGJ1dCBjb3VsZCBhbHNvIGNvdmVyIHRo ZW0gaWYgbmVlZGVkLg0KDQoNCg0KDQpUaGVyZSBhcmUgYSBidW5jaCBvZiBwbGFjZXMgd2hlcmUg cHVyZSBwcm94eWluZyAtIGFzIGRlc2NyaWJlZCBpbiB0aGUgaW50cm9kdWN0aW9uIC0gaXMgbm90 IGFzc3VtZWQuICBUaGlzIGxlYWRzIHRvIHRoZSBzYW1lIHByb2JsZW1zIGFscmVhZHkgY2l0ZWQu ICBGb3IgaW5zdGFuY2UsIGluIFNlY3Rpb24gNC4yOg0KDQpUaGUgcHJveHkgTUFZIHJlbW92ZSBj aXBoZXIgc3VpdGVzIGZyb20gYSBjbGllbnQtaW5pdGlhdGVkIENsaWVudCBIZWxsbyBtZXNzYWdl LCBhZGQgbmV3IGNpcGhlciBzdWl0ZXMsIGFuZCByZS1vcmRlciB0aGVtIGluIHRoZSBwcm94eS1p bml0aWF0ZWQgQ2xpZW50IEhlbGxvIG1lc3NhZ2UuDQoNCldpbGwgY2xlYW4gdXAgdGhvc2UgdGV4 dHMgYmFzZWQgb24gdGhpcyBhbmQgb3RoZXIgZGlzY3Vzc2lvbnMuDQoNCkJlc3QsDQotRXJpYw0K DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K T1BTRUMgbWFpbGluZyBsaXN0DQpPUFNFQ0BpZXRmLm9yZzxtYWlsdG86T1BTRUNAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2VjDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0 DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg== --_000_F40B9423B0D549938A3DD875C62951E4ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+SXQgbG9va3MgdGhlIOKA nHNlbGVjdGl2ZSBwcm94eWluZ+KAnSB0b3BpYyByZXF1aXJlcyBhIGZ1bGwgZG9jdW1lbnQgdG8g YW5hbHl6ZSBpdC4gJm5ic3A7VGhlIGNvLWF1dGhvcnMgZGlzY3Vzc2VkIGFuZCBpdCB3b3VsZCBi ZSBhIGdvb2QgaWRlYSB0byByZW1vdmUgaXQgZnJvbSB0aGlzIGRyYWZ0LiAmbmJzcDtXZSB3aWxs IG1hZGUgdGhlIHVwZGF0ZXMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KVGhlIGNvbmNlcm4gaXMgdmFsaWQgdGhhdCAmcXVvdDt0aGVyZSdzIG5vIGd1YXJhbnRl ZSB0aGF0IHRoZSBzZXJ2ZXIgd2lsbCByZXNwb25kIHRvIHRoZSZuYnNwO2NsaWVudCB0aGUgc2Ft ZSB3YXkgaXQgZGlkIHRvIHRoZSBwcm94eSwgb3IgZXZlbiB0aGF0IHRoZSBpZGVudGl0eSB0aGUg c2VydmVyJm5ic3A7cHJlc2VudGVkIHRvIHRoZSBwcm94eSBpcyB0aGUgc2VydmVyJ3MgcmVhbCBp ZGVudGl0eeKAnS4gJm5ic3A7V2UgYWxzbyBoYXZlIHRvIGRpdmUgaW50byB0aGUgZGV0YWlscyBh Ym91dA0KIHdoaWNoIHBpZWNlIG9mIHNlcnZlciByZXNwb25kZWQgaW5mb3JtYXRpb24gaXMgYmVp bmcgdXNlZCBmb3Igc2VsZWN0aXZlIHByb3h5aW5nLCBhbmQgaG93IG9mdGVuL3doYXQgdG8gZG8g d2hlbiB0aGF0IGNoYW5nZXMuICZuYnNwOw0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlICZxdW90O21hbGljaW91cyBjbGllbnQgYW5kIGNvb3Bl cmF0aW5nIHNlcnZlcuKAnSBwcm9ibGVtIGV4aXN0cyBvdXRzaWRlIG9mIGEgVExTIHByb3h5IGRl cGxveW1lbnQuJm5ic3A7VGhlcmUgYXJlIG1hbnkgd2F5cyB0byBjaXJjdW12ZW50IGEgVExTIHBy b3h5IGlmIG9uZSBjb250cm9scyBib3RoIHNpZGVzLiAmbmJzcDtUaGUgZG9jdW1lbnQgdG91Y2hl ZCBpdCBpbiBTZWN0aW9uJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXdhbmctb3BzZWMtdGxzLXByb3h5LWJwLTAwI3NlY3Rpb24tNS4yIiBjbGFzcz0iIj41 LjI8L2E+LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+U29tZSBUTFMgcHJveHkgaW1wbGVtZW50YXRpb25zIHZpb2xhdGVkIHRoZSBSRkMg aW4gdGhlIHBhc3QsIGJ1dCBub3RoaW5nIGluIG91ciBkcmFmdCBzdWdnZXN0cyB0aGF0IGEgbW9k ZXJuIFRMUyBwcm94eSBkb2VzIG9yJm5ic3A7c2hvdWxkIHZpb2xhdGUgdGhlIFRMUyBzcGVjLiAm bmJzcDtJdCB3YXMgdGhlIG1vdGl2YXRpb24gb2YgdGhpcyBkcmFmdCB0byBoZWxwIHJlZHVjZS9w cmV2ZW50IG5vbi1jb21wbGlhbmNlLCBhcyBtZW50aW9uZWQNCiBlYXJsaWVyLjwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdWwgMjgsIDIwMjAsIGF0IDU6MzQgUE0s IE5pY2sgSGFycGVyICZsdDs8YSBocmVmPSJtYWlsdG86bmhhcnBlcj00MGdvb2dsZS5jb21AZG1h cmMuaWV0Zi5vcmciIGNsYXNzPSIiPm5oYXJwZXI9NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3Jn PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUi Pg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogTHVj aWRhU2Fucy1UeXBld3JpdGVyOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEx1Y2lkYVNhbnMtVHlwZXdyaXRlcjsgZm9udC1zaXpl OiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxf YXR0ciI+T24gVHVlLCBKdWwgMjgsIDIwMjAgYXQgMjoxOSBQTSBFcmljIFdhbmcgKGVqd2FuZykg Jmx0O2Vqd2FuZz08YSBocmVmPSJtYWlsdG86NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmciIGNs YXNzPSIiPjQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46IDBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVm dC1zdHlsZTogc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IHBh ZGRpbmctbGVmdDogMWV4OyI+DQo8ZGl2IHN0eWxlPSJvdmVyZmxvdy13cmFwOiBicmVhay13b3Jk OyIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9Im92ZXJmbG93LXdyYXA6IGJyZWFr LXdvcmQ7IiBjbGFzcz0iIj5UaGFuayB5b3UgZm9yIHRoZSBkZXRhaWxlZCBjb21tZW50cy4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZSBzY29w ZSBvZiB0aGUgZG9jdW1lbnQgaXMgbGltaXRlZCB0byBwcm94eSBhdCB0aGUgVExTIGxheWVyLiZu YnNwOyBFeHBsaWNpdGx5IG91dCBvZiB0aGUgc2NvcGUgaXMgaW5zcGVjdGlvbiBvZiB0aGUgcHJv eGllZCByZWNvcmQgZGF0YS4gJm5ic3A7IFdpbGwgY2xlYW4gdXAgZGVyaXZhdGlvbnMgZnJvbSB0 aGlzIHNjb3BlLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+SXQgd2FzIHRoZSBpbnRlbnRpb24gdG8gY292ZXIgc2VsZWN0aXZlIHByb3h5 aW5nIGhvd2V2ZXIsIGJlY2F1c2UgdGhhdCBpcyBhIHByYWN0aWNhbCByZXF1aXJlbWVudCBmb3Ig YW4gYWN0dWFsIGRlcGxveW1lbnQuJm5ic3A7IFRoZSBpbnRlbnRpb24gd2FzIHRvIGRpc2N1c3Mg dGhlIFRMUyBsYXllciBhdHRyaWJ1dGVzIChlLmcuIFNOSSwgU2VydmVyIENlcnQpIHRoYXQgY291 bGQgYmUgdXNlZCBhcyBpbnB1dCBmb3IgdGhlIGRlY2lzaW9uLg0KICZuYnNwO1RoZSBkb2N1bWVu dCBhbHNvIHN0YXRlZCB0aGUgcmVxdWlyZW1lbnQgdG8gZ3JhY2VmdWxseSByZW1vdmUgdGhlIHBy b3h5IGZyb20gdGhlIHNlc3Npb24gd2hlbiBuZWVkZWQgKGFuZCBwb3NzaWJsZSkuJm5ic3A7IEJ1 dCB0aGUgY3JpdGVyaWEgZm9yIHNlbGVjdGl2ZSBwcm94eWluZyBkZWNpc2lvbiwgYmVpbmcgY29t cGxpYW5jZSwgcHJpdmFjeSwgcmlzayBsZXZlbCwuLi4gYXJlIG91dCBvZiB0aGUgc2NvcGUuJm5i c3A7IFRoZSBkZWNpc2lvbiBtYWtpbmcgb2Z0ZW4NCiBmYWxscyB1bmRlciB0aGUgbGFyZ2VyIOKA nHBvbGljeeKAnSBkb21haW4gYW5kIGlzIGNvbnRyb2xsZWQgYXQgc3lzdGVtIGxldmVsIG91dHNp ZGUgb2YgdGhlIHByb3h5LiZuYnNwOyBJdCBhbHNvIGxlZnQgb3V0IGRpc2N1c3Npb24gb24gdGhl IGRldGFpbGVkIG1lY2hhbmlzbSB3aGljaCB3YXMgZGVlbWVkIGFzIGltcGxlbWVudGF0aW9uIHNw ZWNpZmljLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+SW4gYW55IGNhc2UsIHRoZSBwcm94eSBoYXMgdG8gY29uZHVjdCBzZWxlY3RpdmUg cHJveHlpbmcgaW4gYSBzYWZlLCBub24tZGlzcnVwdGl2ZSBtYW5uZXIuIFRoaXMgbWF5IHJlcXVp cmUgbW9yZSBkZXNpZ24gd29yayBhcyB5b3UgcG9pbnRlZCBvdXQuJm5ic3A7IFRoZSBkb2N1bWVu dCBjb3VsZCBkZXNjcmliZSBwb3NzaWJsZSBtZWNoYW5pc21zIHNvIHRoYXQgYW4gYWNjZXB0YWJs ZSBwcmFjdGljZSBjb3VsZCBiZSBkaXNjdXNzZWQuDQogJm5ic3A7V2UgYXJlIG9wZW4gdG8gb3Ro ZXIgd2F5cyB0byBzaGFwZSBpdC48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BbiBh Y2NlcHRhYmxlIHByYWN0aWNlIE1VU1QgaW5jbHVkZSBub3QgdmlvbGF0aW5nIHRoZSBwcm90b2Nv bCBpbnZhcmlhbnRzIGluIFJGQyA4NDQ2LiBJdCBpcyBub3QgcG9zc2libGUgZm9yIGEgcHJveHkg dG8gb2JleSB0aGUgcHJvdG9jb2wgaW52YXJpYW50cyBhbmQgc2VsZWN0aXZlbHkgcHJveHkgYmFz ZWQgb24gdGhlIGNvbnRlbnRzIG9mIHRoZSBUTFMgaGFuZHNoYWtlIGJldHdlZW4gdGhlIHByb3h5 IGFuZCB0aGUgc2VydmVyDQogYSBjbGllbnQgd2lzaGVzIHRvIGNvbm5lY3QgdG8uJm5ic3A7PC9k aXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdC13 aWR0aDogMXB4OyBib3JkZXItbGVmdC1zdHlsZTogc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiBy Z2IoMjA0LCAyMDQsIDIwNCk7IHBhZGRpbmctbGVmdDogMWV4OyI+DQo8ZGl2IHN0eWxlPSJvdmVy Zmxvdy13cmFwOiBicmVhay13b3JkOyIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9 Im92ZXJmbG93LXdyYXA6IGJyZWFrLXdvcmQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5Nb3JlIGlu bGluZS4uLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KUHJv YmFibHkgdGhlIHdvcnN0IHByb2JsZW0gaXMgcm9vdGVkIGluIFNlY3Rpb24gNS4xLiZuYnNwOyBU aGUgaW50cm9kdWN0aW9uIGVzdGFibGlzaGVzIHRoaXMgYXMgYmVpbmcgYWJvdXQgcHJveHlpbmcs IGJ1dCB0aGVyZSBhcmUgc2V2ZXJhbCBwbGFjZXMgdGhhdCB0YWxrIGFib3V0IG5vdC1wcm94eWlu ZyBzb21ldGltZXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2VsZWN0aXZlIG5vbi1w cm94eWluZyBvcGVucyB0aGUgZG9jdW1lbnQgdXAgdG8gYSB3aG9sZSBuZXcgc2V0IG9mIHByb2Js ZW1zIHRoYXQgYXJpc2UgZnJvbSBwb29yIGRlc2lnbnMgZm9yIGRlY2lkaW5nIG5vdCB0byBwcm94 eS4mbmJzcDsgVGhlcmUgaXMgbm90IG5lYXJseSBlbm91Z2ggZGV0YWlsIGhlcmUgdG8gYWRkcmVz cyB0aGlzIHByb2JsZW0gcHJvcGVybHkuJm5ic3A7IEEgJnF1b3Q7Z29vZCZxdW90OyBkZXNpZ24g Zm9yIHNlbGVjdGl2ZSBUTFMgcHJveHlpbmcgZG9lcyBub3QNCiBzZWVtIHRvIGJlIHRoZSBiYXNp cyBvZiB0aGUgcmVjb21tZW5kYXRpb25zLiZuYnNwOyBJJ2xsIGdpdmUgYSBmZXcgZXhhbXBsZXMg b2YgcHJvYmxlbXMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+RnJvbSB0aGUgU2VjdGlvbiA0LjggYWdhaW46PGJyIGNsYXNzPSIi Pg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIg Y2xhc3M9IiI+dGhlIFRMUyBwcm94eSBNVVNUIGNvbmR1Y3QgcHJvcGVyIFRMUyBwcm90b2NvbCBj aGVja3MgdG8gYXZvaWQgZmFsc2UgaWRlbnRpZmljYXRpb24gb2YgVExTIGhhbmRzaGFrZXMsIHdo aWxlIHRha2luZyBzcGVjaWFsIGNhcmUgbm90IHRvIGNvbnRyaWJ1dGUgdG8gcHJvdG9jb2wgb3Nz aWZpY2F0aW9uLiAmbmJzcDs8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9 IiI+DQpUaGlzIHByYWN0aWNlIGhhcyBiZWVuIGRpcmVjdGx5IHJlc3BvbnNpYmxlIGZvciBtb3Jl IG9zc2lmaWNhdGlvbiB0aGFuIGludGVybWVkaWF0aW9uLCBubyBtYXR0ZXIgd2hhdCBxdWFsaWZp Y2F0aW9uIGV4aXN0cy4gJm5ic3A7PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSWYgcGVy LWRlc3RpbmF0aW9uIG5vdC1wcm94eWluZyBpcyByZXF1aXJlZCwgdGhlIHByb3h5IGNhbiBjb25u ZWN0IHRvIGEgc2VydmVyLCBkZXRlcm1pbmUgdGhhdCB0aGUgc2VydmVyIGlzIG9uIGEgbm9uLXBy b3h5IGxpc3QsIGFuZCB0aGVuIGNvbXBsZXRlIHRoZSBoYW5kc2hha2Ugd2l0aCB0aGUgY2xpZW50 ICh3aXRoIGEgY2F2ZWF0IHJlZ2FyZGluZyBFQ0ggaGVyZSkuJm5ic3A7IEkgY2FuIGd1ZXNzIHdo eSB0aGlzIGRvZXNuJ3QgaGFwcGVuIChpdCdzDQogZXhwZW5zaXZlIGFuZCBzZWUgYWxzbyBTZWN0 aW9uIDUuNCksIGJ1dCB0aGF0IGRvZXNuJ3QgZXhjdXNlIHRoZSBwcmFjdGljZS48YnIgY2xhc3M9 IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGUgZm9sbG93aW5nIHRleHQgZnJvbSBTZWN0aW9uIDUuMyBp cyBkZWVwbHkgcHJvYmxlbWF0aWM6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7 Jm5ic3A7QSBkZWNyeXB0aW9uIHBvbGljeSBkZWNpc2lvbiBNQVkgYmUgbWFkZSBiYXNlZCBvbiB0 aGUgc2VydmVyPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Y2VydGlmaWNhdGUgb3Igb3RoZXIg dHJ1c3R3b3J0aHkgcGFyYW1ldGVycy4mbmJzcDsgVG8gdmVyaWZ5IHBvc3Nlc3Npb24gb2Y8YnIg Y2xhc3M9IiI+DQombmJzcDsmbmJzcDtwcml2YXRlIGtleXMgdGhhdCBhcmUgYXNzb2NpYXRlZCB3 aXRoIGEgcGFydGljdWxhciBzZXJ2ZXI8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDtjZXJ0aWZp Y2F0ZSwgdGhlIHByb3h5IFNIT1VMRCBjb21wbGV0ZSBhbiBvdXQtb2YtYmFuZCBUTFMgaGFuZHNo YWtlPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7d2l0aCB0aGUgc2FtZSBUTFMgc2VydmVyIElQ IGFkZHJlc3MgYW5kIFRDUCBwb3J0IGFzIHRhcmdldGVkIGJ5IHRoZTxiciBjbGFzcz0iIj4NCiZu YnNwOyZuYnNwO1RMUyBjbGllbnQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSXQgaXMg cG9zc2libGUgdGhhdCB0aGUgYXV0aG9ycyBtaXN1bmRlcnN0YW5kIGhvdyBUTFMgd29ya3MsIGJ1 dCB0aGlzIGNoZWNrIHdvbid0IHdvcmsuJm5ic3A7IE5vdCBvbmx5IGJlY2F1c2UgVExTIDEuMyBl bmNyeXB0cyBpbmZvcm1hdGlvbiwgYnV0IGJlY2F1c2UgdGhpcyBpcyBvbmx5IG5lY2Vzc2FyeSBp ZiB0aGUgcHJveHkgZm9yd2FyZHMgYSBDbGllbnRIZWxsbyBmcm9tIHRoZSBjbGllbnQgdG8gdGhl IHNlcnZlci4mbmJzcDsgQXQgdGhhdCBwb2ludCwgaXQNCiBpcyB0b28gbGF0ZSBhbmQgdGhlIGRh bWFnZSBoYXMgYmVlbiBkb25lIChzZWUgQW5kcmVpJ3MgcmV2aWV3KS48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlVubGVzcyBJIG1pc3VuZGVyc3Rvb2QgaXQsIHRoZSBkb2N1bWVudCBpcyBzdWdnZXN0aW5n IHRoZSBzYW1lIGFzIHlvdSBsaXN0ZWQuJm5ic3A7IEJhc2ljYWxseSwgdGhlIHByb3h5IG1ha2Vz IGEgc2VwYXJhdGUgY29ubmVjdGlvbiB0byB0aGUgc2VydmVyIGFzIGEgY2xpZW50ICjigJxvdXQt b2YtYmFuZOKAnSB3cnQgdG8gdGhlIG9yaWdpbmF0aW5nIGNsaWVudC1zZXJ2ZXIgY29ubmVjdGlv biksIHJldHJpZXZlcyB0aGUgc2VydmVy4oCZcyBjZXJ0aWZpY2F0ZQ0KIGZyb20gdGhlIHByb3h5 LXNlcnZlciBoYW5kc2hha2UsIGFuZCBkZXRlcm1pbmVzIHdoZXRoZXIgdGhlIHNlcnZlciBpcyBv biBhIG5vbi1wcm94eWluZyBsaXN0IG9yIG5vdC4mbmJzcDsgSWYgb24gdGhlIGxpc3QsIHRoZSBw cm94eSBmb3J3YXJkcyB0aGUgb3JpZ2luYXRpbmcgY2xpZW50IENIIGFzIGlzIHRvIHRoZSBzZXJ2 ZXIsIGFuZCBzdGVwcyBhd2F5cyBmcm9tIHRoZSBvcmlnaW5hdGluZyBjbGllbnQtc2VydmVyIGhh bmRzaGFrZS48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ VGhlIHByb3h5IE1VU1QgZ2VuZXJhdGUgYSBmcmVzaCBDbGllbnRIZWxsbyB3aGVuIGRvaW5nIHRo aXMgKHNvbWV0aGluZyBBbmRyZWkgYW5kIEkgcHJldmlvdXNseSBtZW50aW9uZWQpLiBXaGVuIHRo ZSBwcm94eSBtYWtlcyBpdHMgc2VwYXJhdGUgY29ubmVjdGlvbiB0byB0aGUgc2VydmVyLCB0aGUg c2VydmVyIGNhbiBiZWhhdmUgZGlmZmVyZW50bHkgd2hlbiByZXNwb25kaW5nIHRvIHRoZSBwcm94 eSBjb21wYXJlZCB0byB3aGVuDQogaXQgcmVzcG9uZHMgdG8gdGhlIGNsaWVudCwgYW5kIGNvdWxk IHByZXNlbnQgaXRzZWxmIHRvIHRoZSBwcm94eSBhcyBzb21ldGhpbmcgaW5ub2N1b3VzJm5ic3A7 dGhhdCBzaG91bGQgbm90IGJlIHByb3hpZWQuIEFzc3VtaW5nIGF0IHRoaXMgcG9pbnQgdGhhdCB0 aGUgcHJveHkgaGFzIGhlbGQgb250byB0aGUgY2xpZW50J3MgQ2xpZW50SGVsbG8gKHdhaXRpbmcg Zm9yIHRoZSByZXNwb25zZSBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIHByb3h5J3MgQ2xpZW50SGVs bG8pLA0KIHRoZSBwcm94eSBkZWNpZGVzIGVpdGhlciB0byBpbnRlcmNlcHQgdGhpcyBjb25uZWN0 aW9uIG9yIGFsbG93IHRoZSBjbGllbnQncyBDbGllbnRIZWxsbyB0byBnbyB0aHJvdWdoIHRvIHRo ZSBzZXJ2ZXIuIFdoZW4gdGhlIHByb3h5IGFsbG93cyB0aGUgY2xpZW50J3MgQ2xpZW50SGVsbG8g dG8gZ28gdGhyb3VnaCB0byB0aGUgc2VydmVyICh3aXRob3V0IGludGVyY2VwdGlvbiksIHRoZXJl J3Mgbm8gZ3VhcmFudGVlIHRoYXQgdGhlIHNlcnZlciB3aWxsDQogcmVzcG9uZCB0byB0aGUgY2xp ZW50IHRoZSBzYW1lIHdheSBpdCBkaWQgdG8gdGhlIHByb3h5LCBvciBldmVuIHRoYXQgdGhlIGlk ZW50aXR5IHRoZSBzZXJ2ZXIgcHJlc2VudGVkIHRvIHRoZSBwcm94eSBpcyB0aGUgc2VydmVyJ3Mg cmVhbCBpZGVudGl0eS48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklmIHRoZSBwcm94eSBjb3BpZXMgZXh0ZW5z aW9ucyB1bmtub3duIHRvIGl0IGZyb20gdGhlIGNsaWVudCdzIENsaWVudEhlbGxvIHRvIGl0cyBv d24sIHRoZW4gaXQgd2lsbCBub3QgYmUgYWJsZSB0byBwYXJzZSB0aGUgcmVzcG9uc2UgZnJvbSB0 aGUgc2VydmVyIHdoZW4gdGhlIHNlcnZlciBhY3RzIG9uIHRob3NlIHVua25vd24gZXh0ZW5zaW9u cy4gVGhpcyBjYXVzZWQgYSB5ZWFyIG9mIGRlbGF5IGluIGZpbmlzaGluZyBUTFMNCiAxLjMsIGFu ZCBpcyBiYWQgZm9yIGV2ZXJ5b25lLiBBIG1hbGljaW91cyBjbGllbnQgYW5kIGNvb3BlcmF0aW5n IHNlcnZlciBkb24ndCBldmVuIG5lZWQgdG8gdXNlIGFuIGV4dGVuc2liaWxpdHkgcG9pbnQgdW5r bm93biB0byB0aGUgcHJveHkgdG8gZXZhZGUgYSBwcm94eSBzZWxlY3RpdmVseSB0ZXJtaW5hdGlu ZyBjb25uZWN0aW9ucyBiYXNlZCBvbiB0aGUgVExTIGhhbmRzaGFrZSBiZXR3ZWVuIHRoZSBwcm94 eSBhbmQgc2VydmVyLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+VGhpcyBzb3J0IG9mIHNlbGVjdGl2ZSBwcm94eWluZyBpcyBmdW5kYW1l bnRhbGx5IGJyb2tlbiBhbmQgc2hvdWxkIG5vdCBiZSByZWNvbW1lbmRlZCBhcyBhIGJlc3QgcHJh Y3RpY2UuPC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46IDBweCAwcHggMHB4IDAuOGV4OyBib3JkZXItbGVmdC13aWR0aDogMXB4OyBib3JkZXItbGVm dC1zdHlsZTogc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IHBh ZGRpbmctbGVmdDogMWV4OyI+DQo8ZGl2IHN0eWxlPSJvdmVyZmxvdy13cmFwOiBicmVhay13b3Jk OyIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9Im92ZXJmbG93LXdyYXA6IGJyZWFr LXdvcmQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlcmUgYXJlIGFk ZGl0aW9uYWwgY29uc2lkZXJhdGlvbnMgaW4gdGhpcyBhcHByb2FjaCAobGF0ZW5jeSBldGMuKS4g VGhlIGRvY3VtZW50IGludGVudGlvbmFsbHkgbGVmdCBvdXQgdGhlIGRldGFpbHMgdG8gaW1wbGVt ZW50YXRpb25zLCBidXQgY291bGQgYWxzbyBjb3ZlciB0aGVtIGlmIG5lZWRlZC48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGVy ZSBhcmUgYSBidW5jaCBvZiBwbGFjZXMgd2hlcmUgcHVyZSBwcm94eWluZyAtIGFzIGRlc2NyaWJl ZCBpbiB0aGUgaW50cm9kdWN0aW9uIC0gaXMgbm90IGFzc3VtZWQuJm5ic3A7IFRoaXMgbGVhZHMg dG8gdGhlIHNhbWUgcHJvYmxlbXMgYWxyZWFkeSBjaXRlZC4mbmJzcDsgRm9yIGluc3RhbmNlLCBp biBTZWN0aW9uIDQuMjo8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIiBjbGFzcz0iIj5UaGUgcHJveHkgTUFZIHJlbW92ZSBjaXBoZXIgc3VpdGVzIGZy b20gYSBjbGllbnQtaW5pdGlhdGVkIENsaWVudCBIZWxsbyBtZXNzYWdlLCBhZGQgbmV3IGNpcGhl ciBzdWl0ZXMsIGFuZCByZS1vcmRlciB0aGVtIGluIHRoZSBwcm94eS1pbml0aWF0ZWQgQ2xpZW50 IEhlbGxvIG1lc3NhZ2UuPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPldpbGwgY2xlYW4gdXAgdGhvc2UgdGV4dHMgYmFzZWQgb24gdGhpcyBhbmQg b3RoZXIgZGlzY3Vzc2lvbnMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj5CZXN0LDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tRXJpYzwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyIGNsYXNz PSIiPg0KT1BTRUMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9Q U0VDQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+T1BTRUNAaWV0Zi5vcmc8L2E+ PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9vcHNlYyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vb3BzZWM8L2E+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIg Y2xhc3M9IiI+DQpUTFMgbWFpbGluZyBsaXN0PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRv OlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPlRMU0BpZXRmLm9yZzwvYT48 YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RscyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F40B9423B0D549938A3DD875C62951E4ciscocom_-- From nobody Wed Jul 29 15: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 767823A0915; Wed, 29 Jul 2020 15:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=PuOxFI61; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tKljYrYS 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 MwBIBmwLLOUr; Wed, 29 Jul 2020 15:55:25 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0074B3A090E; Wed, 29 Jul 2020 15:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6191; q=dns/txt; s=iport; t=1596063325; x=1597272925; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kZZjOhUl2QL6pAiuVeWFAxSgXvMZcqJLoqOyE9bt5/g=; b=PuOxFI61VQh6vxAWR8egqbHIeuoQGd+GIW0t6192oEea4ShKLl9/GcUV thCZ2WjSWrIucVp5/C0jOejvd/5aK/4uz/E+dnQvl6pVFVG7cJ4wY1gkr nQdb/A2QRgnfPPOsoobS5Mg1FOZOa38BcycklV+/UrVBIMO7ckT8ap4Rq 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AifjV3xQLSLp/kHI/8VYYiV+A4dpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQB9mJ7/VbhuzKqaf4SCoG7IrS+HwBcZkZUR?= =?us-ascii?q?gDhI1WmgE7G8eKBAX9K+KidC01GslOFToHt3G2OERYAoDyMlvVpHDh6TkNFx?= =?us-ascii?q?PjLw1tN6LzF5KBx8iy3vq5rpvUZQgAjTGhYLR0eROxqwiZtsQfjYZ4bKgrzR?= =?us-ascii?q?6cqXpTcOMQzmRtdl8=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CAAACt/SFf/5FdJa1gHQEBAQEJARI?= =?us-ascii?q?BBQUBgXYIAQsBgVFRB4FHLywKhCuDRgOEWIhTlBqEbIEugSUDVQsBAQEMAQE?= =?us-ascii?q?tAgQBAYRMAheCDQIkNAkOAgMBAQsBAQUBAQECAQYEbYVcDIVyAgQSCwYdAQE?= =?us-ascii?q?3AQ8CAQgECjEDAgICMBQRAQEEDgUigwSBf00DLgGkfQKBOYhhdoEygwEBAQW?= =?us-ascii?q?FGhiCDgmBOAGCboNfhj8aggCBOAwQgk0+hCUXgxczgi2ScIZdi1aQZQqCX5l?= =?us-ascii?q?/Ax6fdK1pg1YCBAIEBQIOAQEFgVM6gVdwFWUBgj4+EhcCDY4eg3GKVnQ3AgY?= =?us-ascii?q?BBwEBAwl8jmoBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.75,412,1589241600"; d="scan'208,217";a="537556315" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jul 2020 22:55:24 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 06TMtOqb019326 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Jul 2020 22:55:24 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 17:55:23 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 18:55:22 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 29 Jul 2020 17:55:22 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MoI8SAQha+6bMLe+3No2Q5Dgzqgnv65aE0nYZZ99KaOi+4M4I1iUKXip8znrKMJOriz0t5UuRn/oGbUS1bhpICES/OKVSoSk6a0BvlW4iChmyHSTootzUhA/y87TIEjA7rbavj+Ka+IbLrw9IY3D7rdtX/O+XWc8O2J6Vg80Fkl/hlIAMyDVcDDlyzTHJgUVW6h6LRx+H9GDnaKtU5SsdeBMmLU5voLOiAYFa/2Cw6H4ibZc8scm6OENkWN6mxsfKXzDbFamWQnChGzovdOmWrbBkYU+EEH6njVCsz8X7AQ2IxCobcjHBE/cQKGqzLXywMwOGxFAwCq3NHsZ+b6+Ww== 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=kZZjOhUl2QL6pAiuVeWFAxSgXvMZcqJLoqOyE9bt5/g=; b=TTaGyK/Py90Q8Qm4GRBJ/mfCebkiyW0eKJzJLqTirkYszquchCaQPu8Fonmz0o+Hnn1A/S7szQstjy+2DuS7rF11KgRqC3iFqjeUfFkfrz70b++CvrZ+ENzWN+399VzG2ndXzHwtkTm51TMkEer8mve1IkbXSzDzeh0dQnHV9D/NnW6EVa6CuyTAG600caqWb70c3GADhsA5GW6fFqGN/+6AvaHPkLEs6uypEcVqYx65HTr+Zy11/adENeXbh73V9CZMdAfJYIIu+labU2z+hdzbwFBY7rWm5JVhIOL+5hsMA+ZH+Mz5g0H+1Yz6FnaNtkbzUInYYEB0FLM6s8T2hA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kZZjOhUl2QL6pAiuVeWFAxSgXvMZcqJLoqOyE9bt5/g=; b=tKljYrYSCBRPRQI7nBNORgwLo55A7WvTzp4Ctg+vmyZf14jUX6MrDlqdHujw0YriP/hdWz3XwbKzDC+63ZL8zaNLODAkOZtwy4kGzSje+YpmwVpkA1FHyIZVcVnjFOQijo/4JFtMbel7jpqRsTsvH9rgVoFSBcQZbhHiyMfrJA8= Received: from BYAPR11MB2789.namprd11.prod.outlook.com (2603:10b6:a02:cc::11) by BY5PR11MB4465.namprd11.prod.outlook.com (2603:10b6:a03:1c0::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17; Wed, 29 Jul 2020 22:55:21 +0000 Received: from BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870]) by BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870%6]) with mapi id 15.20.3216.033; Wed, 29 Jul 2020 22:55:21 +0000 From: "Eric Wang (ejwang)" To: Martin Thomson CC: Ron Bonica , OPSEC , "tls@ietf.org" Thread-Topic: [OPSEC] [TLS] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AdZd8qs4MVhjKcpfSaSC3eC5PK0rEQGvaUsAAB0Y8YAADNOfgAAo1N6A Date: Wed, 29 Jul 2020 22:55:21 +0000 Message-ID: References: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> <90e5b7d5-a015-40f6-9d5b-b263c85cb2d3@www.fastmail.com> In-Reply-To: <90e5b7d5-a015-40f6-9d5b-b263c85cb2d3@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.15) authentication-results: lowentropy.net; dkim=none (message not signed) header.d=none;lowentropy.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [128.107.241.169] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bc9c254e-9adf-48e1-b71d-08d8341278f2 x-ms-traffictypediagnostic: BY5PR11MB4465: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: m5BQZlFYbY3Zb4X1wN4xVAu03LfcBC2FdaWETtviiDawQ4EEK4MAEcpwdhPRUj3D7KuyyToNGDNWmYGMFSHQeZVI1KBF7mrj6QL7HxZvzJ7NxOXEzUdq704zLPJFwtYf+vO/KS11QDfSgUibxl1KjdxXsyA+C5dvuc4cvndSoz9pJxtYOmw1Vy8mQehWIoznb2UGq1/Od4RkBh6khIp5V1S44HpwtBMZhDEQkerqJgwp8jw4iJ6hHXsLReJmeBcbIu7l95+y5JGmNJbwYgBXFul/ssYWgKFo2blm9vezbIUWVxIPOybEmZzF5fKYyetx7SuZ8kwBZgK5LurqHUmhbw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2789.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(396003)(376002)(366004)(39860400002)(86362001)(8936002)(2616005)(2906002)(478600001)(8676002)(91956017)(6506007)(53546011)(4326008)(71200400001)(26005)(316002)(6486002)(66946007)(66446008)(6916009)(186003)(33656002)(6512007)(66476007)(64756008)(54906003)(36756003)(66556008)(5660300002)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: EH38XYmwoHxZWaK6SX8IiauY8j4nPAbGBjFtttYgokgpvimPGecDv5Q0RdutKbqV+yTYGL7PNoTicfDuQpjZDuAXQnWwjhz4y+AJz+55pnFUoJ5E+vsEU7tA7Dd2c+DyoioN3mWpR4R1IBUK4Z5oizHkMih5vxWK//gNPZ/BM/TSYtyhCLtYd6ts5r26Z9yktRTsRSoUJ/Vh6Hp9imIueQQ0wh1GhLqTnc+SkdSasbYFbyS1bEYzvij/GnjMqX2prH2UqveF/o3pnPrrr4mM5IF+V4q/YF10lk1F8EuO/6oUHJ6GO4D3JCzGHQV9DVNumz9pi06VQ8kPiV4a1/mpYLf+qlsOa4V6RcRXfkO3TCCOL6GNxWcROhcn9dEfyIKPYT8ch5rZ3QClzV2DBIftgYpfczfCWqfisCbM5RMIEb1HjBkZlHIw8TQUnzKGglANujoG/GKbf65vS+yjLaFX61Y2QcmAAWzFR3xA8jWKMRNfXpNcS/OIHtjtE7sTTIqwfwkuGEdCgfMUf4q3fCu2XO2TqqhNL3oIc82q5AEPDd/OdaKf9j15T72xabg/zfxSUptBn1pnH/I5Hb+XiSjkSO9cYMvU/e75h/h/5874veNvJcwSkpIuVbhyuKshazuFN8HvIRMpSR2NqQrI+cO5+A== Content-Type: multipart/alternative; boundary="_000_F357E87CE6524048BF17F9C039D2CF19ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2789.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: bc9c254e-9adf-48e1-b71d-08d8341278f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2020 22:55:21.5403 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9wJFJmomnZRmN3RmDWi+BF2H5P3ulW7p2d9nMDxfweEpFtNMtVwlSJtWsjETlIjaJti6Nn+pXFnrleocXNxwPQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB4465 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 22:55:28 -0000 --_000_F357E87CE6524048BF17F9C039D2CF19ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFydGluLA0KDQpJIHVuZGVyc3RhbmQgeW91ciBwb2ludC4NCg0KV2hlbiBzdGFydGluZyB0 aGlzIGRvY3VtZW50LCB3ZSBhbmFseXplZCBUTFMgcHJveHkgZm9yIDMgcG9zc2liaWxpdGllczoN Cg0KMS4gSXQgbWF5IHZpb2xhdGUgZXhpc3Rpbmcgc3BlY3MgaW5ldml0YWJseTsNCg0KMi4gSXQg Y2FuIGJlIGNvbXBsaWFudCBidXQgbmVlZHMgZGV2ZWxvcG1lbnQgd29yayBmb3Igc29tZSBuZXcg 4oCcaGVscGVy4oCdIHByb3RvY29sOw0KDQozLiBOZWl0aGVyICMxIG9yICMyLCBidXQgaXQgbmVl ZHMgYSBzZXQgb2YgcmVxdWlyZW1lbnRzIHRvIGJlIGRlZmluZWQuDQoNCkZyb20gdGhlIGRpc2N1 c3Npb25zIHNvIGZhciwgYSBwbGFpbiBUTFMgcHJveHkgZml0cyBpbiAjMy4gIFRvIHRoZSBlbmQs IGl0IGlzIGEgVExTIHNlcnZlciBhbmQgYSBUTFMgY2xpZW50IGRlcGxveWVkIGJhY2sgdG8gYmFj aywgYW5kIGJvdGggbXVzdCBiZSBhbmQgY2FuIGJlIGNvbXBsaWFudC4NCg0KSXQgbG9va3Mg4oCc c2VsZWN0aXZlIHByb3h5aW5n4oCdIGlzIGluIHF1ZXN0aW9uIGFuZCByZXF1aXJlcyBkZWVwZXIg ZGlzY3Vzc2lvbnMsIHNvIGl0IHNob3VsZCBiZSBhZGRyZXNzZWQgc2VwYXJhdGVseS4NCg0KSG93 IGFib3V0IGEgc2NvcGUgb2YgIzMgYXMgYSBzdGFydGluZyBwb2ludCBnaXZlbiBubyBkZXNpZ24g d29yayBuZWVkZWQgYnkgdGhlIFRMUyB3b3JraW5nIGdyb3VwPw0KDQoNCk9uIEp1bCAyOCwgMjAy MCwgYXQgODoyNiBQTSwgTWFydGluIFRob21zb24gPG10QGxvd2VudHJvcHkubmV0PG1haWx0bzpt dEBsb3dlbnRyb3B5Lm5ldD4+IHdyb3RlOg0KDQpIaSBFcmljLA0KDQpPbiBXZWQsIEp1bCAyOSwg MjAyMCwgYXQgMDc6MTgsIEVyaWMgV2FuZyAoZWp3YW5nKSB3cm90ZToNCkluIGFueSBjYXNlLCB0 aGUgcHJveHkgaGFzIHRvIGNvbmR1Y3Qgc2VsZWN0aXZlIHByb3h5aW5nIGluIGEgc2FmZSwNCm5v bi1kaXNydXB0aXZlIG1hbm5lci4NCg0KSSB3aWxsIHRyeSB0byBiZSBjbGVhcmVyIG9uIHRoaXMg cG9pbnQuDQoNClRoaXMgcmVxdWlyZXMgZGVzaWduIHdvcmsgYW5kIHRoaXMgZG9jdW1lbnQgaXMg YSBwb29yIHZlaGljbGUgZm9yIHRoYXQuICBJdCBuZWVkcyBhIHNlcGFyYXRlIGRvY3VtZW50IHRo YXQgZG9jdW1lbnRzIHRoZSBkZXNpZ24sIHRoZSBwcm9wZXJ0aWVzIG9mIHRoYXQgZGVzaWduLCBh bmQgdGhlIGFzc3VtcHRpb25zIHRoYXQgaXQgcmVxdWlyZXMgdG8gYWNoaWV2ZSB0aG9zZSBwcm9w ZXJ0aWVzLg0KDQpUaGUgVExTIHdvcmtpbmcgZ3JvdXAgaGFzIGRlY2lkZWQgbm90IHRvIHVuZGVy dGFrZSB3b3JrIGluIHRoaXMgYXJlYS4gIFRoYXQgVExTIHdvcmtpbmcgZ3JvdXAgZGVjaXNpb24g bmVlZHMgdG8gYmUgcmVzcGVjdGVkIGJ5IG90aGVyIHBhcnRzIG9mIHRoZSBJRVRGLg0KDQo= --_000_F357E87CE6524048BF17F9C039D2CF19ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9IndvcmQt d3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBh ZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgTWFydGluLA0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSB1bmRlcnN0YW5kIHlvdXIgcG9p bnQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5XaGVuIHN0YXJ0aW5nIHRoaXMgZG9jdW1lbnQsIHdlIGFuYWx5emVkIFRMUyBw cm94eSBmb3IgMyBwb3NzaWJpbGl0aWVzOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MS4gSXQgbWF5IHZpb2xhdGUgZXhpc3Rpbmcgc3Bl Y3MgaW5ldml0YWJseTs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjIuIEl0IGNhbiBiZSBjb21wbGlhbnQgYnV0IG5lZWRzIGRldmVsb3Bt ZW50IHdvcmsgZm9yIHNvbWUgbmV3IOKAnGhlbHBlcuKAnSBwcm90b2NvbDs8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjMuIE5laXRoZXIg IzEgb3IgIzIsIGJ1dCBpdCBuZWVkcyBhIHNldCBvZiByZXF1aXJlbWVudHMgdG8gYmUgZGVmaW5l ZC48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPkZyb20gdGhlIGRpc2N1c3Npb25zIHNvIGZhciwgYSBwbGFpbiBUTFMgcHJveHkgZml0cyBp biAjMy4gJm5ic3A7VG8gdGhlIGVuZCwgaXQgaXMgYSBUTFMgc2VydmVyIGFuZCBhIFRMUyBjbGll bnQgZGVwbG95ZWQgYmFjayB0byBiYWNrLCBhbmQgYm90aCBtdXN0IGJlIGFuZCBjYW4gYmUgY29t cGxpYW50LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+SXQgbG9va3Mg4oCcc2VsZWN0aXZlIHByb3h5aW5n4oCdIGlzIGluIHF1ZXN0aW9u IGFuZCByZXF1aXJlcyBkZWVwZXIgZGlzY3Vzc2lvbnMsIHNvIGl0IHNob3VsZCBiZSBhZGRyZXNz ZWQgc2VwYXJhdGVseS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdj5Ib3cgYWJvdXQgYSBzY29wZSBvZiAjMyBhcyBhIHN0YXJ0 aW5nIHBvaW50IGdpdmVuIG5vIGRlc2lnbiB3b3JrIG5lZWRlZCBieSB0aGUgVExTIHdvcmtpbmcg Z3JvdXA/PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+T24gSnVsIDI4LCAyMDIwLCBhdCA4OjI2IFBNLCBNYXJ0aW4gVGhvbXNvbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOm10QGxvd2VudHJvcHkubmV0IiBjbGFzcz0iIj5tdEBsb3dlbnRy b3B5Lm5ldDwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5n ZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkhpIEVyaWMsPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KT24gV2VkLCBKdWwgMjksIDIwMjAsIGF0IDA3OjE4LCBF cmljIFdhbmcgKGVqd2FuZykgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSIgY2xhc3M9IiI+SW4gYW55IGNhc2UsIHRoZSBwcm94eSBoYXMgdG8gY29uZHVjdCBzZWxl Y3RpdmUgcHJveHlpbmcgaW4gYSBzYWZlLA0KPGJyIGNsYXNzPSIiPg0Kbm9uLWRpc3J1cHRpdmUg bWFubmVyLiA8YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpJIHdp bGwgdHJ5IHRvIGJlIGNsZWFyZXIgb24gdGhpcyBwb2ludC48YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpUaGlzIHJlcXVpcmVzIGRlc2lnbiB3b3JrIGFuZCB0aGlzIGRvY3VtZW50IGlzIGEg cG9vciB2ZWhpY2xlIGZvciB0aGF0LiAmbmJzcDtJdCBuZWVkcyBhIHNlcGFyYXRlIGRvY3VtZW50 IHRoYXQgZG9jdW1lbnRzIHRoZSBkZXNpZ24sIHRoZSBwcm9wZXJ0aWVzIG9mIHRoYXQgZGVzaWdu LCBhbmQgdGhlIGFzc3VtcHRpb25zIHRoYXQgaXQgcmVxdWlyZXMgdG8gYWNoaWV2ZSB0aG9zZSBw cm9wZXJ0aWVzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSBUTFMgd29ya2luZyBn cm91cCBoYXMgZGVjaWRlZCBub3QgdG8gdW5kZXJ0YWtlIHdvcmsgaW4gdGhpcyBhcmVhLiAmbmJz cDtUaGF0IFRMUyB3b3JraW5nIGdyb3VwIGRlY2lzaW9uIG5lZWRzIHRvIGJlIHJlc3BlY3RlZCBi eSBvdGhlciBwYXJ0cyBvZiB0aGUgSUVURi48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_F357E87CE6524048BF17F9C039D2CF19ciscocom_-- From nobody Wed Jul 29 16:27:04 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 585D03A09EB; Wed, 29 Jul 2020 16:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-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=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 7u6h-yvKi8rJ; Wed, 29 Jul 2020 16:26:53 -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 375E43A09E1; Wed, 29 Jul 2020 16:26:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EB6F0BE47; Thu, 30 Jul 2020 00:26:50 +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 HO41ba1jz_jO; Thu, 30 Jul 2020 00:26:49 +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 D6628BE3E; Thu, 30 Jul 2020 00:26:48 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1596065209; bh=+f6ZJHmyV56cf0cnkQ/tYXyVvl81CgHnUFWsMp1xFQA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Gyk7gZE4+dU0rwTEpVz4nQ9MVymigTNlIjQmuab+0ngacl6eG7mEZsUtGEcG5uBO1 CzWFr71+bxWfeV0Y/AxK+yh241dhLgEd9ZzU9z1bZRyoc3EC+zeUGPP4gbKpfJ3lWA Hs1wCYeKpRMWmq7eQoaD7UC0RIsc1aDPin0TewzY= To: "Eric Wang (ejwang)" , Nick Harper Cc: Ron Bonica , OPSEC , "tls@ietf.org" References: <34226646-93F3-4592-A972-A55B160D5B78@cisco.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: <9e413fb1-da38-6a1f-8fca-a0dd5a6b6ebd@cs.tcd.ie> Date: Thu, 30 Jul 2020 00:26:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ixaetkDmsLVGAJB8fno2Qs6Kbeyv0BvhR" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 23:26:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ixaetkDmsLVGAJB8fno2Qs6Kbeyv0BvhR Content-Type: multipart/mixed; boundary="rpZzDjIQiMxDRRykAbUBVOJmV6zqSzwqH"; protected-headers="v1" From: Stephen Farrell To: "Eric Wang (ejwang)" , Nick Harper Cc: Ron Bonica , OPSEC , "tls@ietf.org" Message-ID: <9e413fb1-da38-6a1f-8fca-a0dd5a6b6ebd@cs.tcd.ie> Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp References: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> In-Reply-To: --rpZzDjIQiMxDRRykAbUBVOJmV6zqSzwqH Content-Type: multipart/mixed; boundary="------------6D9FB51817743AE999DF5FFC" Content-Language: en-US This is a multi-part message in MIME format. --------------6D9FB51817743AE999DF5FFC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 29/07/2020 23:46, Eric Wang (ejwang) wrote: > It was the motivation of this draft to help reduce/prevent > non-compliance, as mentioned earlier. TLS MITM products, by design, do not comply with the TLS protocol, which is a 2 party protocol. There is *only* non-compliance in this space. S. --------------6D9FB51817743AE999DF5FFC 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----- --------------6D9FB51817743AE999DF5FFC-- --rpZzDjIQiMxDRRykAbUBVOJmV6zqSzwqH-- --ixaetkDmsLVGAJB8fno2Qs6Kbeyv0BvhR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl8iBbcACgkQWrL68XsX K+odmw/+Lp4g9MK7aPkAmLTunJfvLsFcEk6iUamS896IkrqzVLvr+u81XFFzAUKG xGnR3yWRrF/C1xEoGJe00FGdTrtEzRTvSQvuCfR7MwZtK+PjSufWzOEWGzfrHeth xeZrwHz8wDtsOIAEj8+uOomJi0aVt9wooWpQzaz2cEW+48mN123MJ4ifxkmz5YES vWf+6jloriP+T/3UJlbXmpwiPRopfIrFLtURWNh3NGNiIMLlEf91dMK5KbNl65F4 AcWx0V3E/Kb0m0ITEcbe9RdG7ojwpCyFbqS2HDZla6C0us6QO9uqy/SZ3vqsRfiM W0eAaPNlDa+UOhoVl80KDA3/h+qLyPY+2/Ys7U0c3U+/qPqb3CtYPVNWgcPtCb5E o+NG9vUOL8pWEkihj9t3y9t+G2lD48Y6jTTS6tOvRwxOBzgJ+9Pn1TPkXVmL3z0i 9PfSJ8O68yPWua2yL5+rqj+dmZKkRin6egUo4ED1ONksbZ09186oe23hUotoAqsL sT1zw16eekzekpPkTilLPm2nQpPdZjorzwLZtGQ2bb1oficVIWo9Bk3T3dGzXkXS ygy5n4NdWW0lpM/fP/PD5YHtUxl+vm8U33JmP2bwS1zIHmvwgM/eGe4KoEEsGhfV qtiHqzJIHqV7Ooy768BX5TLCqdFklEKhWxgjCHqLc5zM591Ago4= =cAB4 -----END PGP SIGNATURE----- --ixaetkDmsLVGAJB8fno2Qs6Kbeyv0BvhR-- From nobody Wed Jul 29 16:51: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 E6C163A0A56 for ; Wed, 29 Jul 2020 16:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_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=selfienetworks-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 I96wuPpNPknI for ; Wed, 29 Jul 2020 16:51:18 -0700 (PDT) Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) (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 856B23A0A64 for ; Wed, 29 Jul 2020 16:51:18 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id j186so13009476vsd.10 for ; Wed, 29 Jul 2020 16:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=selfienetworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:from:to:date:message-id:subject:cc :references; bh=kjVBM5JPuhmaNnBkZBFxyLGuIHOO84rx2mtXBKGQGrg=; b=c5/mVPH7vEjHFG1wjqTEpYvTAnYV4psUsLiAcLHRB75WfFRJmQpzVS10RKmuNSTPqb la44lJnceb/lx91qisfPIsliA4Kh2FxkTV59AhC33BWFI14iNbZZfDxicRKoDXYpQzfZ KtL03mrIimkcpXBQXKO3c9hyQqXBkrjpBgirLfFfKD7N2g3LrChBFQKK+beZDtD8e+NG PEFe+NLHar3/ZZ7EF0IotgOzartXgcF29r7ZHZTZ5yic/rYnjl0+WXiRXo0uIhcvoLWG Ne8EM4g1NWj67hxxevqpHse5Sshg/ywsmedq78qlplsL0fy8fXI/GZ0UuYCN6b8UYpVD e/Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:from:to:date:message-id :subject:cc:references; bh=kjVBM5JPuhmaNnBkZBFxyLGuIHOO84rx2mtXBKGQGrg=; b=Tnn8i5NjGN6pTb2BUHu3NYy3BwwpOn2By0fvCiCN+dfEXU+UJ8+VjVzOMU+x/yrc0F HaDGx5mof2+dYUZApCR39/HhZ7NQB7eUcBnU0V7xoDrkCE4ltdkqFqAeF4dJryCFKl3h mQOtlchv1hQeCwyka8w5x849yOg8VPWOz5Xk+98YWbDJbd55ruyOixIGUpauP/b8tuOf K3vG8N6Eqggbw18LBIMXZ/1npXDgjhxZWQMaGkPSj2ZOtBe/3fotOPVAC4T8IkWNYDqE J5WF/D3L+p4JgzLBDcdksanmbQyflpsLA3wTNxb0gL+mdRUgpWe/fEOArBu91TexOrp7 wiCQ== X-Gm-Message-State: AOAM530YxDNn/esMTZjz/Fu1j78FiiKDUcXkAoUwHMH7W28o3cs0WTEH IT5t0WxKSX9Z9foRx7ILsIJ5W06vz6I= X-Google-Smtp-Source: ABdhPJzo1yK+GoGGIN0wh8Tcnp5zu9VkIIE9i2j9lC4B+ScvO84bb2JCmrDZJg/m/W4O1cVHvggvbA== X-Received: by 2002:a67:310a:: with SMTP id x10mr77631vsx.48.1596066677067; Wed, 29 Jul 2020 16:51:17 -0700 (PDT) Received: from localhost (0.92.231.35.bc.googleusercontent.com. [35.231.92.0]) by smtp.gmail.com with ESMTPSA id j20sm475037uan.13.2020.07.29.16.51.16 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Jul 2020 16:51:16 -0700 (PDT) Mime-Version: 1.0 X-Superhuman-ID: kd80vkc9.42105bac-f924-46a6-99bf-24d396a890dc X-Superhuman-Draft-ID: draft00fcb7a481c64637 In-Reply-To: From: "Yiannis Yiakoumis" To: "Ben Schwartz" X-Mailer: Superhuman Desktop (2020-07-28T22:06:12Z) Date: Wed, 29 Jul 2020 23:51:15 +0000 Message-ID: Cc: network-tokens@ietf.org, "" , "Christian Huitema" References: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net> Content-Type: multipart/alternative; boundary=21a598affa915774e0650c630dda6ed3f17fbebb34032dabfae57523ba40 Archived-At: Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI 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 Jul 2020 23:51:22 -0000 --21a598affa915774e0650c630dda6ed3f17fbebb34032dabfae57523ba40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Hi Ben, Thanks for your comments. Please find some responses inline. On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz < bemasc@google.com > wrote: >=20 > This proposal is highly ossifying.=C2=A0 Application protocols that are > included in this scheme become very difficult to update.=C2=A0 For exampl= e, in > the case of zero-rating, this proposal would only be able to zero-rate > application protocols that are understood by the network's token-parsing > appliance.=C2=A0 This seems likely to have serious negative consequences = for > protocol innovation, as these applications would no longer be able to > implement novel protocols without losing whatever advantage the network > token offers.=C2=A0 For TLS, this proposal would ossify the extension for= mat, > which could no longer evolve in future TLS versions without risking loss > of network services. >=20 >=20 In an ideal world, everything beyond IP would be encrypted and opaque to th= e network, and network tokens would be embedded in IPv6 extension headers. = In practice, this has several (well-known) issues, here is my take on the t= rade-offs: Tokens as IPv6 extension headers have the benefit that they are applicable = to all traffic/applications, and could potentially be enforced by the netwo= rk in a stateless, per-packet manner. The problems are that i) IPv6 extensi= on headers are often dropped by network operators, ii) there are no good AP= Is to expose L3 socket APIs to the app developers who would eventually acqu= ire and insert tokens, and iii) it doesn't work with IPv4. Tokens as TLS extensions address the major shortcomings for IPv6, i.e., the= y have integrity protection so they cannot be dropped by intermediary nodes= , they are closer to the app developer and can therefore expose APIs for th= em to add/remove tokens, and iii) they work across both IPv4 and IPv6. Obvi= ously, they will support only the specific type of transport which limits t= he scope. Specifically on your comment about protocol innovation, and using ESNI as a= n example: my understanding, is that dependency on existing network service= s will be an issue for ESNI adoption, and I agree that this is frustrating.= I will counter argue though, that the problem is not that the network appl= iance doesn't adopt to a new format or novel protocol, but rather that ther= e is no protocol and means in place for endpoints to explicitly coordinate = with the network. In that sense, having a thin mechanism to do this coordin= ation can accelerate innovation in all other aspects. Does the group have any sense on the impact of existing DPI-based services = on adoption of new ideas on TLS? Also note that something like network tokens would be implemented in progra= mmable hardware and/or software, and in principle should be much quicker to= adopt to format changes comparing to fixed-silicon appliances. >=20 > The proposal also violates the TLS Protocol Invariants, by attempting to > process the ServerHello after forwarding an arbitrary ClientHello. >=20 >=20 Not sure I understand this. Can you explain what you mean by arbitrary Clie= ntHello, or point me to the related TLS section? >=20 > It would also fail for QUIC, as previously noted, due to QUIC's mobility > support, which is important for performance on mobile devices. >=20 >=20 Not very familiar with QUIC, will have to read on this. >=20 > Additionally, storing this information in the TLS handshake causes an > unnecessary privacy loss: it forces the token to be visible across the > whole internet, even though it is only relevant on the near-client networ= k > segment. >=20 >=20 The token is not necessarily relevant only to the near-client network segme= nt. For example, in a zero-rating scenario where the token comes from the s= erver, there are intermediary networks that are not relevant for charging. >=20 > Even if the token is entirely opaque, a pervasive surveillance adversary > could distinguish between connections with and without tokens, likely > differentiating certain applications from others. >=20 >=20 You can already infer use of applications just by using IP addresses. Also,= the amount of information you can extract from the presence of tokens decr= eases rapidly with the number of users that participate in them. >=20 > I recommend that the authors focus on the draft's proposal to use an IPv6 > extension header, and remove the other proposed encapsulations.=C2=A0 Als= o, > please remove the specific extension number from Section 7.1 unless and > until IANA has allocated a number.=C2=A0 For testing, you should use a va= lue > from the Private Use range, 65282-65535. >=20 >=20 OK - I'll pick one from them private range - thanks. Best, Yiannis >=20 > On Fri, Jun 26, 2020 at 1:43 PM Christian Huitema < huitema@ huitema. net= ( > huitema@huitema.net ) > wrote: >=20 >=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote: >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Fri, Jun 26 , 2020 at 7:29 AM, Christian Huitema < huitema@ huitema.= net >>> ( huitema@huitema.net ) > wrote: >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> On 6/25/2020 11:11 PM, Melinda Shore wrote: >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>=20 >>>>> On 6/25/20 3:29 PM, Erik Nygren wrote: >>>>>=20 >>>>>=20 >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> One quick comment is that binding tokens to IP addresses is strongly >>>>>> counter-recommended. >>>>>>=20 >>>>>> It doesn't survive NATs or proxies, mobility, and it is especially >>>>>> problematic in IPv6+IPv4 dual-stack environments. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> There's been a bunch of past work done developing similar sorts of >>>>> protocols, and for what it's worth I wrote up a mechanism for using >>>>> address tags and address rewrites, but unfortunately Cisco decided to >>>>> patent it. Anyway, there are ways of dealing with this problem that d= on't >>>>> require binding the address to the token ("all technical problems can= be >>>>> solved by introducing a layer of indirection"). >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> There is also an interesting privacy issue. The token is meant to let = a >>>> provider identify some properties of the connection. I suppose there a= re >>>> ways to do that without having it become a unique identifier that can = be >>>> tracked by, well, pretty much everybody. But you have better spell out >>>> these ways. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> You are right that for the duration of a token, one could use it to >>> identify an endpoint (either application or most likely a combination o= f >>> user/application). Tokens expire and intermediary nodes cannot correlat= e >>> tokens with each other as they are encrypted. So tracking cannot happen >>> across different tokens (of the same user), or between token-enabled an= d >>> non-token-enabled traffic. I guess similar type of tracking happens whe= n >>> users are not behind a NAT and their IP address can be used to track th= em. >>> Would it make sense to have the user add a random value to a token, and >>> then encrypt it with the network's public key, so that each token becom= es >>> unique and cannot be tracked. Would that address the privacy concerns >>> better? >>>=20 >>>=20 >>=20 >>=20 >>=20 >> That would certainly be better. The basic rule is that any such identifi= er >> should be used only once. Pretty much the same issue as the session resu= me >> tickets. >>=20 >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> Then, there are potential interactions with ESNI/ECH. The whole point = of >>>> ECH is to keep private extensions private. The token extension would n= eed >>>> to be placed in the outer envelope, which is public but does not expos= e >>>> seemingly important information like the SNI or the ALPN. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> Ah, I was not aware that ESNI can now include all CH extensions - thank= s >>> for the pointer. Yes, the token would have to stay on the outer envelop= e >>> so the network can process it. The main idea is you can encrypt everyth= ing >>> that is client-server specific, and just keep a token to explicitly >>> exchange information with trusted networks. >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> There are also implications for QUIC, in which the TLS data is part of= an >>>> encrypted payload. The encryption key of the TLS carrying initial pack= ets >>>> is not secret in V1, but it might well become so in a future version. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> Haven't looked into QUIC yet, but is on the list of things to do. If >>> anyone is interested to help us explore this, please let me know. >>>=20 >>>=20 >>=20 >>=20 >>=20 >> You may want to have that discussion in the QUIC WG. If you are building >> some kind of QoS service, you probably want it to work with QUIC too. >>=20 >>=20 >>=20 >>=20 >> -- Christian Huitema >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> TLS mailing list >>=20 >> TLS@ ietf. org ( TLS@ietf.org ) >>=20 >> https:/ / www. ietf. org/ mailman/ listinfo/ tls ( >> https://www.ietf.org/mailman/listinfo/tls ) >>=20 >>=20 >=20 > --21a598affa915774e0650c630dda6ed3f17fbebb34032dabfae57523ba40 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
3D"
Hi Ben,

Thanks for your comments. Please find some responses inline.=C2= =A0

<= div class=3D"">On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz <bemasc@google.com> wrote:

In an ideal world, everything beyond IP would be encrypted and opaque= to the network, and network tokens would be embedded in IPv6 extension hea= ders. In practice, this has several (well-known) issues, here is my take on= the trade-offs:

Tokens as IPv6 extension headers have the benefit that they are applicable= to all traffic/applications, and could potentially be enforced by the netw= ork in a stateless, per-packet manner. The problems are that i) IPv6 extens= ion headers are often dropped by network operators, ii) there are no good A= PIs to expose L3 socket APIs to the app developers who would eventually acq= uire and insert tokens, and iii) it doesn't work with IPv4.=C2=A0
<= /div>

Tokens as TLS extensions ad= dress the major shortcomings for IPv6, i.e., they have integrity protection= so they cannot be dropped by intermediary nodes, they are closer to the ap= p developer and can therefore expose APIs for them to add/remove tokens, an= d iii) they work across both IPv4 and IPv6. Obviously, they will support on= ly the specific type of transport which limits the scope.=C2=A0
<= div class=3D"">
Specifically on your comment abou= t protocol innovation, and using ESNI as an example: my understanding, is t= hat dependency on existing network services will be an issue for ESNI adopt= ion, and I agree that this is frustrating. I will counter argue though, tha= t the problem is not that the network appliance doesn't adopt to a new = format or novel protocol, but rather that there is no protocol and means in= place for endpoints to explicitly coordinate with the network. In that sen= se, having a thin mechanism to do this coordination can accelerate innovati= on in all other aspects.

Does the group have any sense on the impact of existing DPI-based ser= vices on adoption of new ideas on TLS?

Also note that something like network tokens would be impl= emented in programmable hardware and/or software, and in principle should b= e much quicker to adopt to format changes comparing to fixed-silicon applia= nces.=C2=A0=C2=A0

The proposal also violates the= TLS Protocol Invariants, by attempting to process the ServerHello after fo= rwarding an arbitrary ClientHello.=C2=A0



Not very familiar with QU= IC, will have to read on this.=C2=A0

<= /div>
Addit= ionally, storing this information in the TLS handshake causes an unnecessar= y privacy loss: it forces the token to be visible across the whole internet= , even though it is only relevant on the near-client network segment.=C2=A0=

The token is not necessa= rily relevant only to the near-client network segment. For example, in a ze= ro-rating scenario where the token comes from the server, there are interme= diary networks that are not relevant for charging.

Even if the token is entirely opaque, a pervasive = surveillance adversary could distinguish between connections with and witho= ut tokens, likely differentiating certain applications from others.

You can already infer = use of applications just by using IP addresses. Also, the amount of informa= tion you can extract from the presence of tokens decreases rapidly with the= number of users that participate in them.

I recommend that the authors foc= us on the draft's proposal to use an IPv6 extension header, and remove = the other proposed encapsulations.=C2=A0 Also, please remove the specific e= xtension number from Section 7.1 unless and until IANA has allocated a numb= er.=C2=A0 For testing, you should use a value from the Private Use range,= =C2=A06528= 2-65535.

OK - I'll pick one from t= hem private range - thanks.=C2=A0

Best,
=
Yiannis



On Fri, Jun 26, 2020 at 1:43 PM Christian Huitema <huitema@huitema.net> wrote:


O= n 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:
=



On Fri, Jun 26, 2020 at 7:= 29 AM, Christian Huitema <huitema@huitema.net> wrote:

On 6/25/2020 11:11 PM, Melind= a Shore wrote:

On 6/25/20 3:29 PM, Erik Nygren wrote:

One quick comment is that binding token= s to IP addresses is strongly counter-recommended.
It doesn't survive NATs or proxies, mobility, and it is especially problematic in IPv6+IPv4 dual-stack environments.

<= p class=3D"">There's been a bunch of past work done developing similar sorts of protocols, and for what it's worth I wrote up a mechanism for using address tags and address rewrites, but unfortunately Cisco decided to patent it. Anyway, there are ways of dealing with this problem that don't require binding the address to the token ("all technical problems can be solved by introducing a layer of indirection").

There is also an interesting privacy issue. The token is meant to let a provider identify some properties of the connection. I suppose there are ways to do that without having it become a unique identifier that can be tracked by, well, pretty much everybody. But you have better spell out these ways.


You are right that for the duration of a token, one could use it to identify an endpoint (either application or most likely a combination of user/application). Tokens expire and intermediary nodes cannot correlate tokens with each other as they are encrypted. So tracking cannot happen across different tokens (of the same user), or between token-enabled and non-token-enabled traffic. I guess similar type of tracking happens when users are not behind a NAT and their IP address can be used to track them. Would it make sense to have the user add a random value to a token, and then encrypt it with the network's public key, so that each token becomes unique and cannot be tracked. Would that address the privacy concerns better?

That would certainly be better. The basic ru= le is that any such identifier should be used only once. Pretty much the same issue as the session resume tickets.


Then, there are potential interactions with ESNI/ECH. The whole point of ECH is to keep private extensions private. The token extension would need to be placed in the outer envelope, which is public but does not expose seemingly important information like the SNI or the ALPN.



=

There ar= e also implications for QUIC, in which the TLS data is part of an encrypted payload. The encryption key of the TLS carrying initial packets is not secret in V1, but it might well become so in a future version.

=

Have= n't looked into QUIC yet, but is on the list of things to do. If anyone is interested to help us explore this, please let me know.

You may want to have that discussion in the QU= IC WG. If you are building some kind of QoS service, you probably want it to work with QUIC too.

-- Christian Huitema

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



--21a598affa915774e0650c630dda6ed3f17fbebb34032dabfae57523ba40-- From nobody Wed Jul 29 16:57: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 30F1F3A0A3F for ; Wed, 29 Jul 2020 16:57:21 -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=unavailable 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 Z_5qZCouGPcb for ; Wed, 29 Jul 2020 16:57:18 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 3C1603A09AC for ; Wed, 29 Jul 2020 16:57:18 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id q7so26948984ljm.1 for ; Wed, 29 Jul 2020 16:57: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=s4MXlbFnJNNa5yGVx6Vd632wpMWa4KnpFiTwrDFAGu0=; b=dQ3aRkxh7VZ96tCWvknv0Wj6L0DuHMiYcvx+JxR76PxuDBOgswYgxmPMsrLxeFsEJE V4Yq/yMjqKfFTBSEvdle8uWz5vWnuUOeH56nf4Lfo4E09TwJ5fbPmh0RiKT8EZqToWJW nXEzz9fVZ4n0pHtTejjz6IGysf/5DOpRjlHnfa8usvSOj6QuoWzddS0vdz14kJcplhLp oycA+oxMG17NqaOc2MNSy4EqLRKXbqgT5rigsouuJ/iYFpiHikzWZB+nrOIdEGrFfLu4 oOHiGPnIWmmoJ0/LQLMg2zCUm00EFkrCdZClM5tLTtD+E5iFzZq8MquLvJZYIMqQB0yw O7TA== 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=s4MXlbFnJNNa5yGVx6Vd632wpMWa4KnpFiTwrDFAGu0=; b=R0Zf25vz7+Y6jJikYr7dRyo1MRrZ9sM6F1SsR53ZdpdOjeDPvaykrQ7nN9EOGF1ojP BHisM0v4mDYqgqh853wjVxTyKuJOY7yVUA/uUXsiOtijLHya+thr7zMrAchFus1eZ+kV eCkSHqovBmV3drBBjib9ugWMOKJgite/Sct7vumnyLcum9+gcWLK/7ZnzOGexVt/OtWu 79wG8Fa/FMCQPev77QAnnmT36XP8IghheIFGUo95TELXFHeaRZC99hmyVQMqQhcvrPxP CbM9TlWU0okAorxcHpiDChzrI9AtzkipuKSzOa1jgo15DTuFTdNW/kzWUaEzfVCQbe4X XBQQ== X-Gm-Message-State: AOAM531yakgRJVkFdRq7xHZJFj+WpBehmQATxIKUL49ecSqLFNcViZjn 3HyoF5OoPPDRJS9VqhDaXI0ovvR2Di2tVBfBnrW0Tg== X-Google-Smtp-Source: ABdhPJwb+7PnLfodjPYd9f3ZWRHWNLkXB32XEdaglPbeTANVGCanmygXQQaEKomjKIOfF7euY2UOBMEtgAt0QCia6Eo= X-Received: by 2002:a05:651c:549:: with SMTP id q9mr144126ljp.199.1596067035724; Wed, 29 Jul 2020 16:57:15 -0700 (PDT) MIME-Version: 1.0 References: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> <9e413fb1-da38-6a1f-8fca-a0dd5a6b6ebd@cs.tcd.ie> In-Reply-To: <9e413fb1-da38-6a1f-8fca-a0dd5a6b6ebd@cs.tcd.ie> From: Eric Rescorla Date: Wed, 29 Jul 2020 16:56:39 -0700 Message-ID: To: Stephen Farrell Cc: "Eric Wang (ejwang)" , Nick Harper , Ron Bonica , OPSEC , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b3d30305ab9d50e5" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 23:57:21 -0000 --000000000000b3d30305ab9d50e5 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 29, 2020 at 4:27 PM Stephen Farrell wrote: > > Hiya, > > On 29/07/2020 23:46, Eric Wang (ejwang) wrote: > > It was the motivation of this draft to help reduce/prevent > > non-compliance, as mentioned earlier. > TLS MITM products, by design, do not comply with the TLS > protocol, which is a 2 party protocol. > Without taking a position on this document, I do not believe this statement to be correct. 1. TLS doesn't document at all how the server is validated, so from a technical perspective a MITM proxy is simply a TLS server with a certificate issued by a locally installed CA attached to a TLS client that connects to the server (what is known in SIP as a B2BUA). 2. TLS 1.3 specifically documents invariants for TLS terminating middleboxes, including MITM proxies ( https://tools.ietf.org/rfcmarkup?doc=8446#section-9.3). 3. Ignoring MITM proxies, TLS is widely deployed in operating configurations where the client connects to a TLS reverse proxy (i.e., a CDN) which then connects to the server; this is also not a two-party situation. What text in TLS do you believe terminating proxies (in either direction) do not conform to? -Ekr --000000000000b3d30305ab9d50e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 29, 2020 at 4:27 PM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:

Hiya,

On 29/07/2020 23:46, Eric Wang (ejwang) wrote:
> It was the motivation of this draft to help reduce/prevent
> non-compliance, as mentioned earlier.
TLS MITM products, by design, do not comply with the TLS
protocol, which is a 2 party protocol.

= Without taking a position on this document, I do not believe this statement= to be correct.

1. TLS doesn't document at all= how the server is validated, so from a technical perspective a MITM proxy = is simply a TLS server with a certificate issued by a locally installed CA = attached to a TLS client that connects to the server (what is known in SIP = as a B2BUA).
2. TLS 1.3 specifically documents invariants for TLS= terminating middleboxes, including MITM proxies (https://tools.ietf.org/rfcmarkup= ?doc=3D8446#section-9.3).
3. Ignoring MITM proxies, TLS is wi= dely deployed in operating configurations where the client connects to a TL= S reverse proxy (i.e., a CDN) which then connects to the server; this is al= so not a two-party situation.

What text in TLS do = you believe terminating proxies (in either direction) do not conform to?

-Ekr

--000000000000b3d30305ab9d50e5-- From nobody Wed Jul 29 17:07: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 B6C823A0A98; Wed, 29 Jul 2020 17:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-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=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 q4BQYaLU1NYT; Wed, 29 Jul 2020 17:06:53 -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 8C10E3A0A8C; Wed, 29 Jul 2020 17:06:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2B2ABBE47; Thu, 30 Jul 2020 01:06:50 +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 iOeTplstRjHf; Thu, 30 Jul 2020 01:06:48 +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 2A3A2BE39; Thu, 30 Jul 2020 01:06:48 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1596067608; bh=AQ62cupX2BDJrNrZqC8o2z6NLJ0qwUTSiCNGFJSN+FA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=f0N03X3CiMRN/lFMl9hfGmCidZiIRi/E4gq7hq3s+HewELnE6KZcrY61xZCsn2uAJ YFjno9efcumLRQaCKW1VfqfieqA8nnJjvJELN0frkRnCvaDHnHDxIFhSjXTAQ21UZl ix1qlFUvnHpUk/iZDlt0Aa9jujBj5O5pjIj+E0Z0= To: Eric Rescorla Cc: "Eric Wang (ejwang)" , Nick Harper , Ron Bonica , OPSEC , "tls@ietf.org" References: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> <9e413fb1-da38-6a1f-8fca-a0dd5a6b6ebd@cs.tcd.ie> 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: <32561228-08fc-79ea-1b2e-f5de87b9c8fe@cs.tcd.ie> Date: Thu, 30 Jul 2020 01:06:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NJ3eRDARPis9ZGANU0srbizE33sIGVEAH" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 00:06:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --NJ3eRDARPis9ZGANU0srbizE33sIGVEAH Content-Type: multipart/mixed; boundary="HrC0ZzfT9KRBimIl8NTnNkCfiUXqFFdbw"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: "Eric Wang (ejwang)" , Nick Harper , Ron Bonica , OPSEC , "tls@ietf.org" Message-ID: <32561228-08fc-79ea-1b2e-f5de87b9c8fe@cs.tcd.ie> Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp References: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> <9e413fb1-da38-6a1f-8fca-a0dd5a6b6ebd@cs.tcd.ie> In-Reply-To: --HrC0ZzfT9KRBimIl8NTnNkCfiUXqFFdbw Content-Type: multipart/mixed; boundary="------------CC25420F0AF5E2F11BAA4E66" Content-Language: en-US This is a multi-part message in MIME format. --------------CC25420F0AF5E2F11BAA4E66 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 30/07/2020 00:56, Eric Rescorla wrote: > What text in TLS do you believe terminating proxies (in either directio= n) > do not conform to? I gtend to start with the abstract: "TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery." I think that text has remained through various iterations. More importantly, the analyses done for tls1.3 afaik do not consider such 3rd parties except as an attacker. I'm by no means denying the fact that MITM boxen are deployed, but the idea that some of them are "conformant" and some are not seems bogus. S. --------------CC25420F0AF5E2F11BAA4E66 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----- --------------CC25420F0AF5E2F11BAA4E66-- --HrC0ZzfT9KRBimIl8NTnNkCfiUXqFFdbw-- --NJ3eRDARPis9ZGANU0srbizE33sIGVEAH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl8iDxcACgkQWrL68XsX K+rVNBAAuvvqty9YJopqtRskD7+dvZdGPcxarixaa2y0zZ8i109ExSzze/ghg6Qq ujFAXhtyqQiXkuBOyYQqQc7hFxdBdbPG9gPQ6aQ9+OKmiTWwHSVvCjM+2oTuYM7j fmx/ztrH8+GGkA3Hv1O09kEVFX7OghgF6kbd58oFKMhPau9pivpR/rptijKI5sdO gKaNeqzNpInTACVw2fhAFum7ylfxks7ZnvSP8x6jXLvG/HhSMeGjE15Ro0O85SGT LgUwOsrkJkqTqe3UATunMKsun7LdNmUOuE8EJ5liW4BEPJfPbJQC/EMEQacW1Jp6 XbsuCrt3YAJqmKCm5Xt0XEeAnXv7IjXLHGlzKJgotJEVg+PwmCesIOIA6EDJIXyK FN681dOIo/BYrufwEARCrlD960ulttjejNAjM0cEiDPBiMbtLYVQwLPDqWj+RhRB U/nnFMxsTCBMhBUx7b11wjc4eeeaJF59NkPHskHYRyPqZSb4hQ6KeMnfNN2VQ22N /2cRcJ18gk3osjEZqACpHojz8be6dAov3s6c5dVc19dp4NxOSiIzOBwURCz9Egcz eZKL94ZGJDQzRjnmoisPznscQ0TOZFzrXlkX8NHhUDnl0S+2J2WSkvfZMc4rv8Gb Ne8hxywLnPyO2Xi60u5lPSAxkaNJXWIDqCLNJp1PoCxhXXVh5HA= =YPrO -----END PGP SIGNATURE----- --NJ3eRDARPis9ZGANU0srbizE33sIGVEAH-- From nobody Wed Jul 29 17:29: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 32E463A0AE1 for ; Wed, 29 Jul 2020 17:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-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=icloud.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 517JRkNYyPzR for ; Wed, 29 Jul 2020 17:28:59 -0700 (PDT) Received: from mr85p00im-ztdg06021801.me.com (mr85p00im-ztdg06021801.me.com [17.58.23.195]) (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 0623B3A0ADF for ; Wed, 29 Jul 2020 17:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=1a1hai; t=1596068938; bh=Gp1xw8ppSTiTWLneG8nYLTJafBXg+FsCRw6Lxox+w6o=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=wD58WJBoxL8hlijb/rF0mju6EfWJOkdNFvO6DHc7n4b4GmUfZ3q0OTsL8EEqWKyCD 3f5YDzYb3jDcSVGWE9+F7COI9lIBD3jIDbsNlkx0IoAPOtGA4DxLhVauc9Wg94ubs+ BsvZvIaIQN4JDOlVZ5lPNDTPNdhr+2Zt4KuroycpHbULLhUKv6zZ1rCbN8gaQ+ZzAb vrhUoereEMZqtz0ohvzSF65wSvE2up9lVC5aTVvLORZX9tKbGB1JCc0ttgGHC4a5Kx zQk7vMlv6j3UIzsF8cfbvc6NiIMigD3Ys7zD8+cYFuQLGJOHDqCKPc/rM7jKohFydz JToydMVw5qI2g== Received: from [17.232.176.230] (unknown [17.232.176.230]) by mr85p00im-ztdg06021801.me.com (Postfix) with ESMTPSA id 35081180991; Thu, 30 Jul 2020 00:28:58 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3622.0.7\)) From: Carrick Bartle In-Reply-To: <32561228-08fc-79ea-1b2e-f5de87b9c8fe@cs.tcd.ie> Date: Wed, 29 Jul 2020 17:28:57 -0700 Cc: Eric Rescorla , Ron Bonica , OPSEC , Nick Harper , "tls@ietf.org" , "Eric Wang (ejwang)" Content-Transfer-Encoding: quoted-printable Message-Id: <6D2456B4-4725-47B9-AAF9-67C0ABDFA802@icloud.com> References: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> <9e413fb1-da38-6a1f-8fca-a0dd5a6b6ebd@cs.tcd.ie> <32561228-08fc-79ea-1b2e-f5de87b9c8fe@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3622.0.7) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-29_18:2020-07-29, 2020-07-29 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2007300000 Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 00:29:00 -0000 > I gtend to start with the abstract: "TLS allows > client/server applications to communicate over the > Internet in a way that is designed to prevent > eavesdropping, tampering, and message forgery." It seems clear that TLS proxies obey the letter, if not the spirit, of = that statement. However, it seems to me that no further discussion in the TLSWG is = necessary given Martin's assertion that "The TLS working group has = decided not to undertake work in this area." > On Jul 29, 2020, at 5:06 PM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 30/07/2020 00:56, Eric Rescorla wrote: >> What text in TLS do you believe terminating proxies (in either = direction) >> do not conform to? >=20 > I gtend to start with the abstract: "TLS allows > client/server applications to communicate over the > Internet in a way that is designed to prevent > eavesdropping, tampering, and message forgery." >=20 > I think that text has remained through various > iterations. >=20 > More importantly, the analyses done for tls1.3 > afaik do not consider such 3rd parties except as > an attacker. >=20 > I'm by no means denying the fact that MITM boxen > are deployed, but the idea that some of them are > "conformant" and some are not seems bogus. >=20 > S. > = <0x5AB2FAF17B172BEA.asc>_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 29 17:36: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 DE88B3A0A83 for ; Wed, 29 Jul 2020 17:35:57 -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=unavailable 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 U_ZBV86rWSsR for ; Wed, 29 Jul 2020 17:35:55 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 B923D3A09A9 for ; Wed, 29 Jul 2020 17:35:54 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id h19so26997967ljg.13 for ; Wed, 29 Jul 2020 17:35: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=kXetPutOfQyB2nQTflISzhEwxSlgF4BqOkvsGH6J2C8=; b=ebMTxbIHLy4niyER/SZj7chr2ElMTFeJEZn0TWxD+dJEEMe0LEVpTnY+uEIWk4c/FM lUbXEWqSCGIly5Y1+TcX+t9+S0EHT3N+UdeZ5Rqm1vWIXLhmtutu0tGTH12MnDmKHknR Npesk02NdOge8/hEo0/fJEH/jjJ7z1lx3s2qwF69iUiuyYIQHwf4KInIglf0unblL5tq WJn8Djlvqxzd9J1Yb3+Kbjs4Pcz1IV0OB0HzOEsHgFZrBbLaqsb77UW0k0n5o8J6uVs+ 49y+nslVj2SQSriIRMDoGDeDtVqw74GqCgVPjwNt6i+MX/BO0QTp0wsZCrkDedD7/4+G YG9g== 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=kXetPutOfQyB2nQTflISzhEwxSlgF4BqOkvsGH6J2C8=; b=skALal6cGnA+A+WTwDprT0wKGr5+/iYfmVtBplx85z7JbhdegLRWShk4mdzR6afRIX Eit37H1Prv4DCL7cTZbtgbbvKWycglbKiyueDUvPfKxZPySRFGzXnpaHyTmJAVymXP1I WkKigCRLcr0CFPm4VxsSQiLmpv0cUqcx9MNhgJc8RtQUfQixm82LWr69NPyxtOlHOEjk WQv3+MhNNr8W8MUteiMkFMYiptHCcIwPkyRpBVWhnKgYwyPF7TrhipDnboo5nry1YWp0 9BmNpNL28yrGzlr/4yeXpU13x1elFYoSvRd8Fn3JCRM8dNLzwfkcbkVIQfbl8+efHOYM ji4A== X-Gm-Message-State: AOAM532mVKhdRBmgzdJdL4IEmb3MzbvBUnJIRwlXsmsWQicTBfxXeyDD HRG8d0+b6pSisP6ZE7Anwq4n6gSHdL1W+vBedQXhWA== X-Google-Smtp-Source: ABdhPJz03D/QPnblX43ca314fQr5lsQ5aBEcGsWSO+3bL0SnSgLYV1iCDadYU7tatLJjpdZQtQ9Fk9CUJUH4nl0W8rw= X-Received: by 2002:a2e:9d04:: with SMTP id t4mr198750lji.184.1596069352849; Wed, 29 Jul 2020 17:35:52 -0700 (PDT) MIME-Version: 1.0 References: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> <9e413fb1-da38-6a1f-8fca-a0dd5a6b6ebd@cs.tcd.ie> <32561228-08fc-79ea-1b2e-f5de87b9c8fe@cs.tcd.ie> In-Reply-To: <32561228-08fc-79ea-1b2e-f5de87b9c8fe@cs.tcd.ie> From: Eric Rescorla Date: Wed, 29 Jul 2020 17:35:16 -0700 Message-ID: To: Stephen Farrell Cc: "Eric Wang (ejwang)" , Nick Harper , Ron Bonica , OPSEC , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d05e3f05ab9ddae2" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 00:35:58 -0000 --000000000000d05e3f05ab9ddae2 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 29, 2020 at 5:06 PM Stephen Farrell wrote: > > Hiya, > > On 30/07/2020 00:56, Eric Rescorla wrote: > > What text in TLS do you believe terminating proxies (in either direction) > > do not conform to? > > I gtend to start with the abstract: "TLS allows > client/server applications to communicate over the > Internet in a way that is designed to prevent > eavesdropping, tampering, and message forgery." > > I think that text has remained through various > iterations. > Yes, and in this context, the MITM proxy is a server from the client's perspective and a client from the origin server's perspective. More importantly, the analyses done for tls1.3 > afaik do not consider such 3rd parties except as > an attacker. > I would say rather that those analyses consider them as protocol endpoints and address the two individual connections terminated by the proxy and have nothing to say about the composition of those two connections. I'm by no means denying the fact that MITM boxen > are deployed, but the idea that some of them are > "conformant" and some are not seems bogus. > Well, they are either conformant with the text of 8446 S 9.3 or they are not (and just to be clear, being conformant with 9.3 does not make them good for the reason indicated above). -Ekr --000000000000d05e3f05ab9ddae2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 29, 2020 at 5:06 PM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:

Hiya,

On 30/07/2020 00:56, Eric Rescorla wrote:
> What text in TLS do you believe terminating proxies (in either directi= on)
> do not conform to?

I gtend to start with the abstract: "TLS allows
client/server applications to communicate over the
Internet in a way that is designed to prevent
eavesdropping, tampering, and message forgery."

I think that text has remained through various
iterations.

Yes, and in this context, t= he MITM proxy is a server from the client's perspective and a client fr= om the origin server's perspective.


=
More importantly, the analyses done for tls1.3
afaik do not consider such 3rd parties except as
an attacker.

I would say rather that th= ose analyses consider them as protocol endpoints and address the two indivi= dual connections terminated by the proxy and have nothing to say about the = composition of those two connections.


I'm by no means denying the fact that MITM boxen
are deployed, but the idea that some of them are
"conformant" and some are not seems bogus.
<= br>
Well, they are either conformant with the text of 8446 S 9.3 = or they are not (and just to be clear, being conformant with 9.3 does not m= ake them good for the reason indicated above).

-Ekr


--000000000000d05e3f05ab9ddae2-- From nobody Wed Jul 29 17:48: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 81F913A0B00; Wed, 29 Jul 2020 17:48:20 -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 LjPq3-Rb05Tc; Wed, 29 Jul 2020 17:48:18 -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 8A6863A0AFE; Wed, 29 Jul 2020 17:48:18 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id a5so11289041ioa.13; Wed, 29 Jul 2020 17:48:18 -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=GWFzlXlHBhRtQEGEjms8HjFvHiHbBVluW9WoF2P7DJ8=; b=qGW9b7ZsN3si4jb79ocwdnYZfCgjaFaVXByduR7POkN52C3tOSzy8LmwDjtcjqHG7v BHQZ7I4VHXZGV3Z83wHqkUHE3EzVIUgWWpWx73p7bmxf3TEaYcEtX0/ND9jLzRhMeRIb AK6YBT+a4uUKb8PB/RgJuzv0R6KB2TwaMoS9lTYADT3ygJXchEjhFX73wgzl4hgR0rpw 5q7uwsejZ5lvgphuPqCSor0zWhYY5XjueSWc70eHfDO/vHN6ijnzHlDMCp0w8p460dqO xQ8YgCEqpwktSlpSMQv+uMQHwF/5jT4H8njYHfVpTxSp2Ksv45NOhEBrcaiGcgi2ioYy a+uw== 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=GWFzlXlHBhRtQEGEjms8HjFvHiHbBVluW9WoF2P7DJ8=; b=oArTuRNqr0RJ0ilxXrDpVy9fOshLMyOvs0e3J9rQRt3MxcFtWHi7Y9dQ0f2LR6hH9n jK95mcmefJ4Qi4jDB00Ne8xkcrxtC2Qkh0oUAZrc+gJwYxD2rE5osGHHaGQA0MJcRmp3 vO0WP1uHamjaNenIuNOwsAR1KAaWJAfrvKtnvRCMZsjDkBQqmvxdNcPjh5yOVf3MSkjT OHNJtVggxw8Q99OJx+yBYnWnJIM96mD50U1d6NkLNDyZJpf4bfJnABdPFw0UWpclvkEQ W7AkucnvPCxMyjo97kSuWFSkcxkyumBKk1PFmJylBcQyUV/mWIFtTafd7xCy18gN+sc+ a2zg== X-Gm-Message-State: AOAM531FpNa1DnxZtYoUJXVIYxaCLpdcW8XhY3+Uuou4Xy/GJuJy8hRe OCnzHaKpSnG+Mj0JW0dp/aFyOsJboIuRaEu0Nqs= X-Google-Smtp-Source: ABdhPJw48JmRORP13IlK3WRrV1CPIWrszub9eDnXYr+3+BEKjlGgILvbgDpeqVes0oqrKJWKYJP2oJUOOMAsYZMeanI= X-Received: by 2002:a02:108a:: with SMTP id 132mr766594jay.131.1596070097755; Wed, 29 Jul 2020 17:48:17 -0700 (PDT) MIME-Version: 1.0 References: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> <9e413fb1-da38-6a1f-8fca-a0dd5a6b6ebd@cs.tcd.ie> <32561228-08fc-79ea-1b2e-f5de87b9c8fe@cs.tcd.ie> In-Reply-To: From: Rob Sayre Date: Wed, 29 Jul 2020 17:48:06 -0700 Message-ID: To: Eric Rescorla Cc: Stephen Farrell , Ron Bonica , OPSEC , Nick Harper , "tls@ietf.org" , "Eric Wang (ejwang)" Content-Type: multipart/alternative; boundary="00000000000036a58f05ab9e07f9" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 00:48:21 -0000 --00000000000036a58f05ab9e07f9 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 29, 2020 at 5:36 PM Eric Rescorla wrote: > I'm by no means denying the fact that MITM boxen >> are deployed, but the idea that some of them are >> "conformant" and some are not seems bogus. >> > > Well, they are either conformant with the text of 8446 S 9.3 or they are > not (and just to be clear, being conformant with 9.3 does not make them > good for the reason indicated above). > This argument doesn't seem baseless, but I think these MITM documents also presume IETF consensus on the current PKI system, and I am not sure that has ever been tested. thanks, Rob --00000000000036a58f05ab9e07f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 29, 2020 at 5:36 PM Eric Resc= orla <ekr@rtfm.com> wrote:
I'm by no means denying the fact that MITM boxen
are deployed, but the idea that some of them are
"conformant" and some are not seems bogus.
<= br>
Well, they are either conformant with the text of 8446 S 9.3 = or they are not (and just to be clear, being conformant with 9.3 does not m= ake them good for the reason indicated above).

This argument doesn't seem baseless, but I think = these MITM documents also presume IETF consensus on the current PKI system,= and I am not sure that has ever been tested.

than= ks,
Rob

=C2=A0
--00000000000036a58f05ab9e07f9-- From nobody Wed Jul 29 18:26: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 85C763A0B5D; Wed, 29 Jul 2020 18:26: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, 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 (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 9J77m6gZEzZM; Wed, 29 Jul 2020 18:26:09 -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 D02393A0B5C; Wed, 29 Jul 2020 18:26:08 -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 06U1OFJl017886; Thu, 30 Jul 2020 02:26:03 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=aMmzjix2Fc69wun2PFfrPh0ZkO2CBRsEopiRZBZnXr4=; b=ItmEZAzcVr+jWbL+bu81WvcMUFCthuNGMsWYw3M9vJ7ufolNWcKHYkciCnmc6nXD0Q9m AzK9uKc9GD+5KDI8l1XhqrNqJjXuG97yIzdWrhU2nU8xcs+l4tfTntMNr/Blqo4SljGa TeW6nVJ07K7ZTtLsRa+BW0iBZoe1+iN2AZrb1Po0c98kxTasLbTKpzWIP8d1zwgbGkSv 0MBvKgkosgFl+gIV9Zml6Mb2GRo9e34wtRrdl0tW1RNfjGlext5wY+F5Dri0nYgkMV2B /Fg1crQ4kr9SgrLCXHy089Xj3O447j4uVVy5i5XJ00CJ1/wEZPNZ2Z9FHhwDC7GZVDt1 Vg== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 32gc0yc50w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jul 2020 02:26:03 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06U16QVY015906; Wed, 29 Jul 2020 21:26:02 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint3.akamai.com with ESMTP id 32j460uvv1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 29 Jul 2020 21:26:02 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 20:26: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; Wed, 29 Jul 2020 20:26:01 -0500 From: "Salz, Rich" To: Eric Rescorla , Stephen Farrell CC: Ron Bonica , OPSEC , Nick Harper , "tls@ietf.org" , "Eric Wang (ejwang)" Thread-Topic: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AQHWZShvBNRDUlrsVEq2Ye+Fh4dCL6kd+OuAgAGExACAAAtGgIAACFiAgAAC1YCAAAf1AP//yx8A Date: Thu, 30 Jul 2020 01:26:01 +0000 Message-ID: <3AC7B7C6-E616-40DA-95A3-A8DE7927E17F@akamai.com> References: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> <9e413fb1-da38-6a1f-8fca-a0dd5a6b6ebd@cs.tcd.ie> <32561228-08fc-79ea-1b2e-f5de87b9c8fe@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.132] Content-Type: multipart/alternative; boundary="_000_3AC7B7C6E61640DA95A3A8DE7927E17Fakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-29_18:2020-07-29, 2020-07-29 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 mlxlogscore=999 suspectscore=0 mlxscore=0 adultscore=0 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007300004 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-29_18:2020-07-29, 2020-07-29 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1011 malwarescore=0 bulkscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 priorityscore=1501 suspectscore=0 adultscore=0 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007300007 Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 01:26:11 -0000 --_000_3AC7B7C6E61640DA95A3A8DE7927E17Fakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pkkgd291bGQgc2F5IHJhdGhlciB0aGF0IHRob3NlIGFuYWx5c2VzIGNvbnNpZGVyIHRoZW0gYXMg cHJvdG9jb2wgZW5kcG9pbnRzIGFuZCBhZGRyZXNzIHRoZSB0d28gaW5kaXZpZHVhbCBjb25uZWN0 aW9ucyB0ZXJtaW5hdGVkIGJ5IHRoZSBwcm94eSBhbmQgaGF2ZSBub3RoaW5nIHRvIHNheSBhYm91 dCB0aGUgY29tcG9zaXRpb24gb2YgdGhvc2UgdHdvIGNvbm5lY3Rpb25zLg0KDQpJIHRoaW5rIHRo YXQgc29tZSBvZiB0aG9zZSBvcHBvc2VkIGFyZSBjb25mbGF0aW5nIHRoZSBnZW5lcmFsIOKAnGVu ZCB0byBlbmTigJ0gYXJndW1lbnQgd2l0aCB3aGF0IHRoZSBUTFMgcHJvdG9jb2wgUkZDIHNheXMs IGFzIGVrciBpcyBzYXlpbmcuDQoNCkNvbmZvcm1hbmNlIGlzbuKAmXQgdGhlIGlzc3VlLCByZWFs bHksIGl04oCZcyBpY2tpbmVzcy4gIEl04oCZcyBvbmUgdGhpbmcgaWYgYW4gZW50ZXJwcmlzZSBp bnN0YWxsIGludGVybWVkaWFyaWVzIHRvIG1vbml0b3IgdGhlIG91dGJvdW5kIHRyYWZmaWMgb24g aXRzIG1hY2hpbmVzLCBpdOKAmXMgYW5vdGhlciBpZiBhIG5hdGlvbmFsLXNjYWxlIGF0dGFja2Vy IGRvZXMgc3VycmVwdGl0aW91c2x5LCBhbmQgaXTigJlzIHZhcmlvdXMgb3RoZXIgdGhpbmdzIGFs b25nIHRob3NlIHNwZWN0cnVtcy4gV2XigJlkIGFsbCBsaWtlIGEgY2xlYXIgYnJpZ2h0IGxpbmUg dG8gc2F5IFlFUyBoZXJlLCBOTyB0aGVyZSwgYW5kIFdFTEwgTUFZQkUgSUYgWU9VIE1VU1Qgb3Zl ciB0aGVyZSwgYnV0IHRoYXTigJlzIG5vdCBwb3NzaWJsZS4NCg== --_000_3AC7B7C6E61640DA95A3A8DE7927E17Fakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 SSB3b3VsZCBzYXkgcmF0aGVyIHRoYXQgdGhvc2UgYW5hbHlzZXMgY29uc2lkZXIgdGhlbSBhcyBw cm90b2NvbCBlbmRwb2ludHMgYW5kIGFkZHJlc3MgdGhlIHR3byBpbmRpdmlkdWFsIGNvbm5lY3Rp b25zIHRlcm1pbmF0ZWQgYnkgdGhlIHByb3h5IGFuZCBoYXZlIG5vdGhpbmcgdG8gc2F5IGFib3V0 IHRoZSBjb21wb3NpdGlvbiBvZiB0aG9zZSB0d28gY29ubmVjdGlvbnMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGF0IHNvbWUgb2YgdGhv c2Ugb3Bwb3NlZCBhcmUgY29uZmxhdGluZyB0aGUgZ2VuZXJhbCDigJxlbmQgdG8gZW5k4oCdIGFy Z3VtZW50IHdpdGggd2hhdCB0aGUgVExTIHByb3RvY29sIFJGQyBzYXlzLCBhcyBla3IgaXMgc2F5 aW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db25mb3JtYW5jZSBpc27igJl0IHRoZSBpc3N1 ZSwgcmVhbGx5LCBpdOKAmXMgaWNraW5lc3MuJm5ic3A7IEl04oCZcyBvbmUgdGhpbmcgaWYgYW4g ZW50ZXJwcmlzZSBpbnN0YWxsIGludGVybWVkaWFyaWVzIHRvIG1vbml0b3IgdGhlIG91dGJvdW5k IHRyYWZmaWMgb24gaXRzIG1hY2hpbmVzLCBpdOKAmXMgYW5vdGhlciBpZiBhIG5hdGlvbmFsLXNj YWxlIGF0dGFja2VyIGRvZXMgc3VycmVwdGl0aW91c2x5LCBhbmQgaXTigJlzIHZhcmlvdXMNCiBv dGhlciB0aGluZ3MgYWxvbmcgdGhvc2Ugc3BlY3RydW1zLiBXZeKAmWQgYWxsIGxpa2UgYSBjbGVh ciBicmlnaHQgbGluZSB0byBzYXkgWUVTIGhlcmUsIE5PIHRoZXJlLCBhbmQgV0VMTCBNQVlCRSBJ RiBZT1UgTVVTVCBvdmVyIHRoZXJlLCBidXQgdGhhdOKAmXMgbm90IHBvc3NpYmxlLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3AC7B7C6E61640DA95A3A8DE7927E17Fakamaicom_-- From nobody Wed Jul 29 18:28: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 B82873A0B5E for ; Wed, 29 Jul 2020 18:28:32 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 EY1ONAKQgTpi for ; Wed, 29 Jul 2020 18:28:29 -0700 (PDT) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (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 605D13A0B5F for ; Wed, 29 Jul 2020 18:28:29 -0700 (PDT) Received: by mail-ej1-x62b.google.com with SMTP id d6so12432055ejr.5 for ; Wed, 29 Jul 2020 18:28:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E0p+/Gk7i/fUaA88vEGTbXJfQg2zTw+rI7hcWjOtywA=; b=bklpAqRBQnGfK/OXHJgSbueVmOC37nnAWWvItW1a81TRykYo2RPnpUKJ3qvG0s/CUY vxzYWOnysVqhGc74ax4YHfhqr+EwcdHUA5yxiQEfmma+syvUZvKlNYwJ9Lj+yC/+aQHh KNqmQ3JuwpUuieSwHQef1V5Qij88pD3gEkSFA7qWngDU2PQzXUXia9wkZUYH2WsOgwSU gR+dnUqtrjBQxzF9o/0nDOk1IPQPjXqb/EwS3SmmkHmRQSQtJAB6FzFCIHg1QQwuEsv+ z/X4LvJ6/g3b9k+gJ+Gmfs94G3IXYgNTeaIRpS2lrnfuQSdDwFkS9wpQCnnweibTeJEi 4kiQ== 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=E0p+/Gk7i/fUaA88vEGTbXJfQg2zTw+rI7hcWjOtywA=; b=WbcYHvOr/V9MYWr+AfFtjbCOVjBf4Qm+uLomFI7bIWrdGx3ESPvUX+3TDQ7Jk1d59s l+8dFxSt71sfoIyimndbSR+JFvAeF1lBcN/q9D4NbB6MRH+IV8zkceihStdRJygMaeHq aWl5CgJ9J5cvvmPdvj9yEms87b+7LV2fSmmj5j8mu+PyMLLvtWeew7vfmtn09v32rZhy 7Bhqo7PFQiWY1M3VvEGT140OD2Vju7g5WkIfBW0vKBFSZ1EiGr8vN6YhalAbp8FKtPi6 8Cizx6s1ctxQHvBeWuV+rFsemifrTYbEh/gzKYoUnarc1UCqEOY2KESetZHw7bJ/hdfc T8Fg== X-Gm-Message-State: AOAM530gzaLDbmozaoNQgisv6QncDW73eTe+lI3Esz67VPJkTb+BTaFK 9zOA2mwpEG9tijvqyfwwVI6IW13INicNfMxjTcPuqg== X-Google-Smtp-Source: ABdhPJxGXyMPv16A7zLMbuGX9ol6NtmuYaAh2tPvZ6K97xEwLPv6tFOKty1oe2zXDIdYztQ+mgKFt1/mxOV3irlqbgY= X-Received: by 2002:a17:906:b146:: with SMTP id bt6mr363662ejb.138.1596072507747; Wed, 29 Jul 2020 18:28:27 -0700 (PDT) MIME-Version: 1.0 References: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net> In-Reply-To: From: Tom Herbert Date: Wed, 29 Jul 2020 18:28:16 -0700 Message-ID: To: Yiannis Yiakoumis Cc: Ben Schwartz , Christian Huitema , network-tokens@ietf.org, "" Content-Type: multipart/alternative; boundary="000000000000dc41fc05ab9e969d" Archived-At: Subject: Re: [TLS] [Network-tokens] Network Tokens I-D and TLS / ESNI 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 Jul 2020 01:28:33 -0000 --000000000000dc41fc05ab9e969d Content-Type: text/plain; charset="UTF-8" On Wed, Jul 29, 2020 at 4:51 PM Yiannis Yiakoumis < yiannis@selfienetworks.com> wrote: > Hi Ben, > > Thanks for your comments. Please find some responses inline. > > On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz wrote: > >> This proposal is highly ossifying. Application protocols that are >> included in this scheme become very difficult to update. For example, in >> the case of zero-rating, this proposal would only be able to zero-rate >> application protocols that are understood by the network's token-parsing >> appliance. This seems likely to have serious negative consequences for >> protocol innovation, as these applications would no longer be able to >> implement novel protocols without losing whatever advantage the network >> token offers. For TLS, this proposal would ossify the extension format, >> which could no longer evolve in future TLS versions without risking loss of >> network services. >> > > In an ideal world, everything beyond IP would be encrypted and opaque to > the network, and network tokens would be embedded in IPv6 extension > headers. In practice, this has several (well-known) issues, here is my take > on the trade-offs: > > Tokens as IPv6 extension headers have the benefit that they are applicable > to all traffic/applications, and could potentially be enforced by the > network in a stateless, per-packet manner. The problems are that i) IPv6 > extension headers are often dropped by network operators, ii) there are no > good APIs to expose L3 socket APIs to the app developers who would > eventually acquire and insert tokens, and iii) it doesn't work with IPv4. > > Tokens as TLS extensions address the major shortcomings for IPv6, i.e., > they have integrity protection so they cannot be dropped by intermediary > nodes, they are closer to the app developer and can therefore expose APIs > for them to add/remove tokens, and iii) they work across both IPv4 and > IPv6. Obviously, they will support only the specific type of transport > which limits the scope. > > A major drawback of using TLS for this is that it requires the network to maintain per flow state. > Specifically on your comment about protocol innovation, and using ESNI as > an example: my understanding, is that dependency on existing network > services will be an issue for ESNI adoption, and I agree that this is > frustrating. I will counter argue though, that the problem is not that the > network appliance doesn't adopt to a new format or novel protocol, but > rather that there is no protocol and means in place for endpoints to > explicitly coordinate with the network. In that sense, having a thin > mechanism to do this coordination can accelerate innovation in all other > aspects. > > Does the group have any sense on the impact of existing DPI-based services > on adoption of new ideas on TLS? > > Also note that something like network tokens would be implemented in > programmable hardware and/or software, and in principle should be much > quicker to adopt to format changes comparing to fixed-silicon appliances. > > The proposal also violates the TLS Protocol Invariants, by attempting to >> process the ServerHello after forwarding an arbitrary ClientHello. >> > > Not sure I understand this. Can you explain what you mean by arbitrary > ClientHello, or point me to the related TLS section? > > It would also fail for QUIC, as previously noted, due to QUIC's mobility >> support, which is important for performance on mobile devices. >> > > Not very familiar with QUIC, will have to read on this. > > Additionally, storing this information in the TLS handshake causes an >> unnecessary privacy loss: it forces the token to be visible across the >> whole internet, even though it is only relevant on the near-client network >> segment. >> > > The token is not necessarily relevant only to the near-client network > segment. For example, in a zero-rating scenario where the token comes from > the server, there are intermediary networks that are not relevant for > charging. > > Even if the token is entirely opaque, a pervasive surveillance adversary >> could distinguish between connections with and without tokens, likely >> differentiating certain applications from others. >> > > You can already infer use of applications just by using IP addresses. > Also, the amount of information you can extract from the presence of tokens > decreases rapidly with the number of users that participate in them. > > I recommend that the authors focus on the draft's proposal to use an IPv6 >> extension header, and remove the other proposed encapsulations. Also, >> please remove the specific extension number from Section 7.1 unless and >> until IANA has allocated a number. For testing, you should use a value >> from the Private Use range, 65282-65535. >> > > OK - I'll pick one from them private range - thanks. > > Best, > Yiannis > > > > On Fri, Jun 26, 2020 at 1:43 PM Christian Huitema >> wrote: >> >>> >>> On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote: >>> >>> >>> >>> >>> On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema >>> wrote: >>> >>> On 6/25/2020 11:11 PM, Melinda Shore wrote: >>>> >>>> On 6/25/20 3:29 PM, Erik Nygren wrote: >>>> >>>> One quick comment is that binding tokens to IP addresses is strongly >>>> counter-recommended. >>>> It doesn't survive NATs or proxies, mobility, and it is especially >>>> problematic in IPv6+IPv4 dual-stack environments. >>>> >>>> There's been a bunch of past work done developing similar sorts of >>>> protocols, and for what it's worth I wrote up a mechanism for using address >>>> tags and address rewrites, but unfortunately Cisco decided to patent it. >>>> Anyway, there are ways of dealing with this problem that don't require >>>> binding the address to the token ("all technical problems can be solved by >>>> introducing a layer of indirection"). >>>> >>>> There is also an interesting privacy issue. The token is meant to let a >>>> provider identify some properties of the connection. I suppose there are >>>> ways to do that without having it become a unique identifier that can be >>>> tracked by, well, pretty much everybody. But you have better spell out >>>> these ways. >>>> >>> >>> You are right that for the duration of a token, one could use it to >>> identify an endpoint (either application or most likely a combination of >>> user/application). Tokens expire and intermediary nodes cannot correlate >>> tokens with each other as they are encrypted. So tracking cannot happen >>> across different tokens (of the same user), or between token-enabled and >>> non-token-enabled traffic. I guess similar type of tracking happens when >>> users are not behind a NAT and their IP address can be used to track them. >>> Would it make sense to have the user add a random value to a token, and >>> then encrypt it with the network's public key, so that each token becomes >>> unique and cannot be tracked. Would that address the privacy concerns >>> better? >>> >>> That would certainly be better. The basic rule is that any such >>> identifier should be used only once. Pretty much the same issue as the >>> session resume tickets. >>> >>> >>> Then, there are potential interactions with ESNI/ECH. The whole point of >>>> ECH is to keep private extensions private. The token extension would need >>>> to be placed in the outer envelope, which is public but does not expose >>>> seemingly important information like the SNI or the ALPN. >>>> >>> >>> Ah, I was not aware that ESNI can now include all CH extensions - thanks >>> for the pointer. Yes, the token would have to stay on the outer envelope so >>> the network can process it. The main idea is you can encrypt everything >>> that is client-server specific, and just keep a token to explicitly >>> exchange information with trusted networks. >>> >>> There are also implications for QUIC, in which the TLS data is part of >>>> an encrypted payload. The encryption key of the TLS carrying initial >>>> packets is not secret in V1, but it might well become so in a future >>>> version. >>>> >>> >>> Haven't looked into QUIC yet, but is on the list of things to do. If >>> anyone is interested to help us explore this, please let me know. >>> >>> You may want to have that discussion in the QUIC WG. If you are building >>> some kind of QoS service, you probably want it to work with QUIC too. >>> >>> -- Christian Huitema >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> > > > -- > Network-tokens mailing list > Network-tokens@ietf.org > https://www.ietf.org/mailman/listinfo/network-tokens > --000000000000dc41fc05ab9e969d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jul 29, 2020 at 4:51 PM Yiann= is Yiakoumis <yiannis@self= ienetworks.com> wrote:
3D""
Hi Ben,

Thanks= for your comments. Please find some responses inline.=C2=A0

On Wed, Jul 29, 2020 at 1:4= 8 PM, Ben Schwartz <bemasc@google.com> wrote:
This proposal is highly ossifying.=C2=A0 Application protocols that a= re included in this scheme become very difficult to update.=C2=A0 For examp= le, in the case of zero-rating, this proposal would only be able to zero-ra= te application protocols that are understood by the network's token-par= sing appliance.=C2=A0 This seems likely to have serious negative consequenc= es for protocol innovation, as these applications would no longer be able t= o implement novel protocols without losing whatever advantage the network t= oken offers.=C2=A0 For TLS, this proposal would ossify the extension format= , which could no longer evolve in future TLS versions without risking loss = of network services.=C2=A0

In an ideal world, everything beyond IP would = be encrypted and opaque to the network, and network tokens would be embedde= d in IPv6 extension headers. In practice, this has several (well-known) iss= ues, here is my take on the trade-offs:

= Tokens as IPv6 extension headers have the benefit that they are applicable = to all traffic/applications, and could potentially be enforced by the netwo= rk in a stateless, per-packet manner. The problems are that i) IPv6 extensi= on headers are often dropped by network operators, ii) there are no good AP= Is to expose L3 socket APIs to the app developers who would eventually acqu= ire and insert tokens, and iii) it doesn't work with IPv4.=C2=A0

Tokens as TLS extensions address the major shortcomi= ngs for IPv6, i.e., they have integrity protection so they cannot be droppe= d by intermediary nodes, they are closer to the app developer and can there= fore expose APIs for them to add/remove tokens, and iii) they work across b= oth IPv4 and IPv6. Obviously, they will support only the specific type of t= ransport which limits the scope.=C2=A0

=
A major drawback of using TLS for this is tha= t it requires the network to maintain per flow state.
=C2=A0
Specifically on your comment about protocol innovation, and usi= ng ESNI as an example: my understanding, is that dependency on existing net= work services will be an issue for ESNI adoption, and I agree that this is = frustrating. I will counter argue though, that the problem is not that the = network appliance doesn't adopt to a new format or novel protocol, but = rather that there is no protocol and means in place for endpoints to explic= itly coordinate with the network. In that sense, having a thin mechanism to= do this coordination can accelerate innovation in all other aspects.
<= /div>

Does the group have any sense on the impact of exi= sting DPI-based services on adoption of new ideas on TLS?
Also note that something like network tokens would be implement= ed in programmable hardware and/or software, and in principle should be muc= h quicker to adopt to format changes comparing to fixed-silicon appliances.= =C2=A0=C2=A0

<= blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,= 204,204);padding-left:1ex" class=3D"gmail_quote">
The proposal also violates the TLS Protocol Invariants, by a= ttempting to process the ServerHello after forwarding an arbitrary ClientHe= llo.=C2=A0
<= div>
Not sure I understand this. Can you explain what you mea= n by arbitrary ClientHello, or point me to the related TLS section?

It would also fail for QUIC, as previously noted, due to QUIC's mobil= ity support, which is important for performance on mobile devices.

= Not very familiar with QUIC, will have to read on this.=C2=A0

Addit= ionally, storing this information in the TLS handshake causes an unnecessar= y privacy loss: it forces the token to be visible across the whole internet= , even though it is only relevant on the near-client network segment.=C2=A0=

<= /div>
The token is not necessarily relevant only to the near-clie= nt network segment. For example, in a zero-rating scenario where the token = comes from the server, there are intermediary networks that are not relevan= t for charging.

Even if the token is entirely opaque, a perv= asive surveillance adversary could distinguish between connections with and= without tokens, likely differentiating certain applications from others.

You can already infer use of applications just by using IP add= resses. Also, the amount of information you can extract from the presence o= f tokens decreases rapidly with the number of users that participate in the= m.

= I recommend that the authors focus on the draft's proposal to use an IP= v6 extension header, and remove the other proposed encapsulations.=C2=A0 Al= so, please remove the specific extension number from Section 7.1 unless and= until IANA has allocated a number.=C2=A0 For testing, you should use a val= ue from the Private Use range,=C2=A065282-65535.

OK -= I'll pick one from them private range - thanks.=C2=A0
Best,
Yiannis



On Fri, Jun 26, 2020 at 1:43 PM = Christian Huitema <huitema@huitema.net> wrote:


On = 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:



=
On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema <hui= tema@huitema.net> wrote:

On 6/25/2020 11:11 PM, Melinda Shore wrote:

On 6/25/20 3:29 PM,= Erik Nygren wrote:

One quick comment is th= at binding tokens to IP addresses is strongly counter-recommended.
It doesn= 't survive NATs or proxies, mobility, and it is especially problematic in IPv6+IPv4 dual-stack environments.

There's been a bunch of past work done developing similar sorts of protocols, and for what it's worth I wrote up a mechanism for using address tags and address rewrites, but unfortunately Cisco decided to patent it. Anyway, there are ways of dealing with this problem that don't require binding the address to the token ("all technical problems can be solved by introducing a layer of indirection").

The= re is also an interesting privacy issue. The token is meant to let a provider identify some properties of the connection. I suppose there are ways to do that without having it become a unique identifier that can be tracked by, well, pretty much everybody. But you have better spell out these ways.


You are right that for the dur= ation of a token, one could use it to identify an endpoint (either application or most likely a combination of user/application). Tokens expire and intermediary nodes cannot correlate tokens with each other as they are encrypted. So tracking cannot happen across different tokens (of the same user), or between token-enabled and non-token-enabled traffic. I guess similar type of tracking happens when users are not behind a NAT and their IP address can be used to track them. Would it make sense to have the user add a random value to a token, and then encrypt it with the network's public key, so that each token becomes unique and cannot be tracked. Would that address the privacy concerns better?

That would certainly be better. The basic rule is that a= ny such identifier should be used only once. Pretty much the same issue as the session resume tickets.


Then, there are potential interactions with ESNI/ECH. The whole point of ECH is to keep private extensions private. The token extension would need to be placed in the outer envelope, which is public but does not expose seemingly important information like the SNI or the ALPN.


Ah, I was not aware that ES= NI can now include all CH extensions - thanks for the pointer. Yes, the token would have to stay on the outer envelope so the network can process it. The main idea is you can encrypt everything that is client-server specific, and just keep a token to explicitly exchange information with trusted networks.=C2=A0

<= div class=3D"gmail_extra">

There are also implication= s for QUIC, in which the TLS data is part of an encrypted payload. The encryption key of the TLS carrying initial packets is not secret in V1, but it might well become so in a future version.

<= /div>

Haven't looked into QUIC yet, but i= s on the list of things to do. If anyone is interested to help us explore this, please let me know.

You may want to have that discussion in the QUIC WG. If yo= u are building some kind of QoS service, you probably want it to work with QUIC too.

-- Christian Huitema

_____= __________________________________________
TLS mailing list<= br>
<= /div>



--
Network-tokens mailing list
Network-tokens= @ietf.org
https://www.ietf.org/mailman/listinfo/network-to= kens
--000000000000dc41fc05ab9e969d-- From nobody Wed Jul 29 19:09: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 E0EA33A0B85 for ; Wed, 29 Jul 2020 19:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LDxyPf2ndEeh for ; Wed, 29 Jul 2020 19:09:29 -0700 (PDT) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 EA8ED3A0B7D for ; Wed, 29 Jul 2020 19:09:28 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id q76so3544744wme.4 for ; Wed, 29 Jul 2020 19:09:28 -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 :cc; bh=Uic340/TPA6kW3D1kmfNB8e4Ko/fEB8GV5R5QO0t5YY=; b=epnxtnA6JIJBCwFmQcHQxt/dXvUUXXcTp0Ei5FJUe3XzWxboSrsC9viRlqxl3tRP2T 2FZZAkb+UjVAL3Jv3qsS4cTKGtXs9QlTg1QJpV5PhwO70WD2JmgCXgGyi79DJwfWFzz9 cPfW+Dua8wqR7i6vCUAFEPqIYSnp/I5yvQcgmc8aFy6Ubc5V9VKuFE162LnnuO8oZb5q hey8BBJ+AUvn8xXNSeVjqtWTsE8ETBA4/NLxwvSFbFjaqBfk/8zAGjgC7xTJclMazXxS 8ozQKyjDUhqI4MBoPVzSvO2+LbUPfqCPDMYw+J1lwRuOyH5fQmrEac+kf9SRnQGo3/oU yjvw== 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=Uic340/TPA6kW3D1kmfNB8e4Ko/fEB8GV5R5QO0t5YY=; b=Dowr5BFGxf5QovwK8ucxahiGvpgfCqF7tsLfR54nrO0KiCVLHc2C8eMsvtxUtfzAVQ U5e/ZeD3Rv1G19PMxBQQZzUb11pZprYr8tRSKsNm76TyEP7iwaxJzm4w7gcl2aFh5pfY PUI/klowb51RC7nCM82w4bQOHln7BlDQTEJF/G1oXJjsrZuLHjshXu0Ujn2lHN9PLkqV G7b0gND4vPIY+amSyUxfmtTZQq+pG+uGQWRQZiCTD1wiC2Ha7QIODvxZoXBdJTRgm8NB gnB13XljrPGnI7F1V24LVgBvwBbdFnGgEINVrTNvPdSPMalo2kJnKmI+GnMEzpYxQOin m2TQ== X-Gm-Message-State: AOAM533/e+80fGw3324DRbzwfKIsXqmJK/nStclvrMMMOoT5qwENQke7 9U7wbxu4+WBjSuIOuNyb2xbljdyP1OEcLIRsaXuUeQ== X-Google-Smtp-Source: ABdhPJztdrhoT4sJqUYF8VeTeR7lJZOGi8kWo5V7NSUa1PtTGhxBGkwdLWOp4Ugglc3x8cOCtbKXG96/K7Z6T9ZhK78= X-Received: by 2002:a1c:a757:: with SMTP id q84mr10748064wme.1.1596074967085; Wed, 29 Jul 2020 19:09:27 -0700 (PDT) MIME-Version: 1.0 References: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net> In-Reply-To: From: Ben Schwartz Date: Wed, 29 Jul 2020 22:09:14 -0400 Message-ID: To: Yiannis Yiakoumis Cc: network-tokens@ietf.org, "" , Christian Huitema Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000007a574005ab9f2967" Archived-At: Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI 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 Jul 2020 02:09:34 -0000 --0000000000007a574005ab9f2967 Content-Type: multipart/alternative; boundary="000000000000732d9305ab9f29a9" --000000000000732d9305ab9f29a9 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 29, 2020 at 7:51 PM Yiannis Yiakoumis < yiannis@selfienetworks.com> wrote: > Hi Ben, > > Thanks for your comments. Please find some responses inline. > > On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz wrote: > >> This proposal is highly ossifying. Application protocols that are >> included in this scheme become very difficult to update. For example, in >> the case of zero-rating, this proposal would only be able to zero-rate >> application protocols that are understood by the network's token-parsing >> appliance. This seems likely to have serious negative consequences for >> protocol innovation, as these applications would no longer be able to >> implement novel protocols without losing whatever advantage the network >> token offers. For TLS, this proposal would ossify the extension format, >> which could no longer evolve in future TLS versions without risking loss of >> network services. >> > > In an ideal world, everything beyond IP would be encrypted and opaque to > the network, and network tokens would be embedded in IPv6 extension > headers. In practice, this has several (well-known) issues, here is my take > on the trade-offs: > > Tokens as IPv6 extension headers have the benefit that they are applicable > to all traffic/applications, and could potentially be enforced by the > network in a stateless, per-packet manner. The problems are that i) IPv6 > extension headers are often dropped by network operators, > In all the listed use cases, the client-proximate network operator is the one who wants the tokens, so they can choose not to drop them. > ii) there are no good APIs to expose L3 socket APIs to the app developers > who would eventually acquire and insert tokens, > I appreciate that this is an obstacle, but I don't see a need to rush this capability. If there is demand for the feature, the APIs will be written. Also, v6 extension headers are not the only way to get the right routing properties. and iii) it doesn't work with IPv4. > Making this feature v6-only is not very limiting. Networks that want to support it just have to be dual-stack, which they should be anyway, and apps need to use IPv6, which they should support anyway. Even v6-only ISPs are already common, so by the time this specification is ready it won't be too much to require dual-stack for participating apps and networks. Tokens as TLS extensions address the major shortcomings for IPv6, i.e., > they have integrity protection so they cannot be dropped by intermediary > nodes, they are closer to the app developer and can therefore expose APIs > for them to add/remove tokens, and iii) they work across both IPv4 and > IPv6. Obviously, they will support only the specific type of transport > which limits the scope. > > Specifically on your comment about protocol innovation, and using ESNI as > an example: my understanding, is that dependency on existing network > services will be an issue for ESNI adoption, > I am not aware of an impediment to ESNI adoption. Moreover, since ESNI (now called "ECH") is entirely within the TLS Protocol Invariants, any entity that would create such a problem is already in violation. and I agree that this is frustrating. I will counter argue though, that the > problem is not that the network appliance doesn't adopt to a new format or > novel protocol, but rather that there is no protocol and means in place for > endpoints to explicitly coordinate with the network. > There is: the Internet Protocol! (Also ICMP, DHCP, PCP, and many others. PCP (RFC 6887) seems like it might be a particularly good fit for Network Tokens.) In that sense, having a thin mechanism to do this coordination can > accelerate innovation in all other aspects. Does the group have any sense > on the impact of existing DPI-based services on adoption of new ideas on > TLS? > > Also note that something like network tokens would be implemented in > programmable hardware and/or software, and in principle should be much > quicker to adopt to format changes comparing to fixed-silicon appliances. > I think most experienced members of the TLS group would tell you that deployed appliance firmware has empirically updated very slowly, if at all. For comparison, TLS 1.3 went through 29 revisions in four years, breaking compatibility frequently along the way. In the world you're describing, apps that use network tokens would potentially have been excluded from field-testing those versions. That field-testing was crucial in the development of the final standard, largely because of the presence of buggy systems that made assumptions specific to TLS 1.2. Protocol changes with Network Tokens are especially delicate because failure is largely expected to be silent. That means if some ISP's token inspector doesn't handle the app's protocol properly, the app never finds out. In the zero-rating case, the app would continue to work as normal, silently running up the user's bill, likely in violation of a written promise to the user. App developers would have to be exceptionally cautious when making protocol changes. That's ossification. The proposal also violates the TLS Protocol Invariants, by attempting to >> process the ServerHello after forwarding an arbitrary ClientHello. >> > > Not sure I understand this. Can you explain what you mean by arbitrary > ClientHello, or point me to the related TLS section? > RFC 8446 Section 9.3: - A middlebox which forwards ClientHello parameters it does not understand MUST NOT process any messages beyond that ClientHello. It MUST forward all subsequent traffic unmodified. Otherwise, it may fail to interoperate with newer clients and servers. Forwarded ClientHellos may contain advertisements for features not supported by the middlebox, so the response may include future TLS additions the middlebox does not recognize. These additions MAY change any message beyond the ClientHello arbitrarily. In particular, the values sent in the ServerHello might change, the ServerHello format might change, and the TLSCiphertext format might change. > It would also fail for QUIC, as previously noted, due to QUIC's mobility >> support, which is important for performance on mobile devices. >> > > Not very familiar with QUIC, will have to read on this. > See here: https://tools.ietf.org/html/draft-ietf-quic-transport-29#section-9 After the TLS handshake, QUIC connections can migrate across client IPs and interfaces without redoing the handshake. IPv6 extension headers would allow tagging the packets appropriately for the network they're on, but tagging the connection in the handshake is impossible. Additionally, storing this information in the TLS handshake causes an >> unnecessary privacy loss: it forces the token to be visible across the >> whole internet, even though it is only relevant on the near-client network >> segment. >> > > The token is not necessarily relevant only to the near-client network > segment. For example, in a zero-rating scenario where the token comes from > the server, there are intermediary networks that are not relevant for > charging. > Yes, the tagging has to be handled by the client in this scenario. That seems sufficient for all the listed use cases. If the network operator has to maintain flow state, that's no worse than the TLS-based proposal. Even if the token is entirely opaque, a pervasive surveillance adversary >> could distinguish between connections with and without tokens, likely >> differentiating certain applications from others. >> > > You can already infer use of applications just by using IP addresses. > For apps that use CDNs, that's generally not true. > Also, the amount of information you can extract from the presence of > tokens decreases rapidly with the number of users that participate in them. > I agree that this is a small amount of leakage; I'm merely pointing out that it's (a) not zero and (b) unnecessary. I recommend that the authors focus on the draft's proposal to use an IPv6 >> extension header, and remove the other proposed encapsulations. Also, >> please remove the specific extension number from Section 7.1 unless and >> until IANA has allocated a number. For testing, you should use a value >> from the Private Use range, 65282-65535. >> > > OK - I'll pick one from them private range - thanks. > > Best, > Yiannis > > > > On Fri, Jun 26, 2020 at 1:43 PM Christian Huitema >> wrote: >> >>> >>> On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote: >>> >>> >>> >>> >>> On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema >>> wrote: >>> >>> On 6/25/2020 11:11 PM, Melinda Shore wrote: >>>> >>>> On 6/25/20 3:29 PM, Erik Nygren wrote: >>>> >>>> One quick comment is that binding tokens to IP addresses is strongly >>>> counter-recommended. >>>> It doesn't survive NATs or proxies, mobility, and it is especially >>>> problematic in IPv6+IPv4 dual-stack environments. >>>> >>>> There's been a bunch of past work done developing similar sorts of >>>> protocols, and for what it's worth I wrote up a mechanism for using address >>>> tags and address rewrites, but unfortunately Cisco decided to patent it. >>>> Anyway, there are ways of dealing with this problem that don't require >>>> binding the address to the token ("all technical problems can be solved by >>>> introducing a layer of indirection"). >>>> >>>> There is also an interesting privacy issue. The token is meant to let a >>>> provider identify some properties of the connection. I suppose there are >>>> ways to do that without having it become a unique identifier that can be >>>> tracked by, well, pretty much everybody. But you have better spell out >>>> these ways. >>>> >>> >>> You are right that for the duration of a token, one could use it to >>> identify an endpoint (either application or most likely a combination of >>> user/application). Tokens expire and intermediary nodes cannot correlate >>> tokens with each other as they are encrypted. So tracking cannot happen >>> across different tokens (of the same user), or between token-enabled and >>> non-token-enabled traffic. I guess similar type of tracking happens when >>> users are not behind a NAT and their IP address can be used to track them. >>> Would it make sense to have the user add a random value to a token, and >>> then encrypt it with the network's public key, so that each token becomes >>> unique and cannot be tracked. Would that address the privacy concerns >>> better? >>> >>> That would certainly be better. The basic rule is that any such >>> identifier should be used only once. Pretty much the same issue as the >>> session resume tickets. >>> >>> >>> Then, there are potential interactions with ESNI/ECH. The whole point of >>>> ECH is to keep private extensions private. The token extension would need >>>> to be placed in the outer envelope, which is public but does not expose >>>> seemingly important information like the SNI or the ALPN. >>>> >>> >>> Ah, I was not aware that ESNI can now include all CH extensions - thanks >>> for the pointer. Yes, the token would have to stay on the outer envelope so >>> the network can process it. The main idea is you can encrypt everything >>> that is client-server specific, and just keep a token to explicitly >>> exchange information with trusted networks. >>> >>> There are also implications for QUIC, in which the TLS data is part of >>>> an encrypted payload. The encryption key of the TLS carrying initial >>>> packets is not secret in V1, but it might well become so in a future >>>> version. >>>> >>> >>> Haven't looked into QUIC yet, but is on the list of things to do. If >>> anyone is interested to help us explore this, please let me know. >>> >>> You may want to have that discussion in the QUIC WG. If you are building >>> some kind of QoS service, you probably want it to work with QUIC too. >>> >>> -- Christian Huitema >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> > > > --000000000000732d9305ab9f29a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 29, 2020 at 7:51 PM Yiannis Y= iakoumis <yiannis@selfiene= tworks.com> wrote:
3D""
Hi Ben,

Thanks for your comments. Please find some responses inline.=C2=A0

On Wed, Jul 29= , 2020 at 1:48 PM, Ben Schwartz <bemasc@google.com> wrote:
This proposal is highly ossifying.=C2=A0 Application pro= tocols that are included in this scheme become very difficult to update.=C2= =A0 For example, in the case of zero-rating, this proposal would only be ab= le to zero-rate application protocols that are understood by the network= 9;s token-parsing appliance.=C2=A0 This seems likely to have serious negati= ve consequences for protocol innovation, as these applications would no lon= ger be able to implement novel protocols without losing whatever advantage = the network token offers.=C2=A0 For TLS, this proposal would ossify the ext= ension format, which could no longer evolve in future TLS versions without = risking loss of network services.=C2=A0
<= /div>

In an ideal world, everything bey= ond IP would be encrypted and opaque to the network, and network tokens wou= ld be embedded in IPv6 extension headers. In practice, this has several (we= ll-known) issues, here is my take on the trade-offs:

Tokens as IPv6 extension headers have the benefit that they ar= e applicable to all traffic/applications, and could potentially be enforced= by the network in a stateless, per-packet manner. The problems are that i)= IPv6 extension headers are often dropped by network operators,
=

In all the listed use ca= ses, the client-proximate network operator is the one who wants the tokens,= so they can choose not to drop=C2=A0them.
=C2=A0
ii) there= are no good APIs to expose L3 socket APIs to the app developers who would = eventually acquire and insert tokens,

I appreciate that this is an obstacle, but I don&#= 39;t see a need to rush this capability.=C2=A0 If there is demand for the f= eature, the APIs will be written.=C2=A0 Also, v6 extension headers are not = the only way to get the right routing properties.

and = iii) it doesn't work with IPv4.=C2=A0
=

Making this feature v6-only is not very li= miting.=C2=A0 Networks that want to support it just have to be dual-stack, = which they should be anyway, and apps need to use IPv6, which they should s= upport anyway.=C2=A0 Even v6-only ISPs are already common, so by the time t= his specification is ready it won't be too much to require dual-stack f= or participating apps and networks.

Tokens as TLS ext= ensions address the major shortcomings for IPv6, i.e., they have integrity = protection so they cannot be dropped by intermediary nodes, they are closer= to the app developer and can therefore expose APIs for them to add/remove = tokens, and iii) they work across both IPv4 and IPv6. Obviously, they will = support only the specific type of transport which limits the scope.=C2=A0

Specifically on your comment about protocol inn= ovation, and using ESNI as an example: my understanding, is that dependency= on existing network services will be an issue for ESNI adoption,

I am not aware of an i= mpediment to ESNI adoption.=C2=A0 Moreover, since ESNI (now called "EC= H") is entirely within the TLS Protocol Invariants, any entity that wo= uld create such a problem is already in violation.

and= I agree that this is frustrating. I will counter argue though, that the pr= oblem is not that the network appliance doesn't adopt to a new format o= r novel protocol, but rather that there is no protocol and means in place f= or endpoints to explicitly coordinate with the network.

There is: the Internet Protocol!= =C2=A0 (Also ICMP, DHCP, PCP, and many others.=C2=A0 PCP (RFC 6887) seems l= ike it might be a particularly good fit for Network Tokens.)

=
In that sense, having a thin mechanism to do this coordination can a= ccelerate innovation in all other aspects. Does the group have any sense on= the impact of existing DPI-based services on adoption of new ideas on TLS?=

Also note that so= mething like network tokens would be implemented in programmable hardware a= nd/or software, and in principle should be much quicker to adopt to format = changes comparing to fixed-silicon appliances.=C2=A0=C2=A0
<= /div>

I think most experienced = members of the TLS group would tell you that deployed appliance firmware ha= s empirically updated very slowly, if at all.=C2=A0 For comparison, TLS 1.3= went through 29 revisions in four years, breaking compatibility frequently= along the way.=C2=A0 In the world you're describing, apps that use net= work tokens would potentially have been excluded from field-testing those v= ersions.=C2=A0 That field-testing was crucial in the development of the fin= al standard, largely because of the presence of buggy systems that made ass= umptions specific to TLS 1.2.

Protocol changes wit= h Network Tokens are especially delicate because failure is largely expecte= d to be silent.=C2=A0 That means if some ISP's token inspector doesn= 9;t handle the app's protocol properly, the app never finds out.=C2=A0 = In the zero-rating case, the app would continue to work as normal, silently= running up the user's bill, likely in violation of a written promise t= o the user.=C2=A0 App developers would have to be exceptionally cautious wh= en making protocol changes.=C2=A0 That's ossification.

<= div>
The proposal also viola= tes the TLS Protocol Invariants, by attempting to process the ServerHello a= fter forwarding an arbitrary ClientHello.=C2=A0
=

Not sure I understa= nd this. Can you explain what you mean by arbitrary ClientHello, or point m= e to the related TLS section?

RFC 8446 Section 9.3:
=C2=A0 =C2=A0- = =C2=A0A middlebox which forwards ClientHello parameters it does not
=C2= =A0 =C2=A0 =C2=A0 understand MUST NOT process any messages beyond that Clie= ntHello.
=C2=A0 =C2=A0 =C2=A0 It MUST forward all subsequent traffic unm= odified.=C2=A0 Otherwise, it
=C2=A0 =C2=A0 =C2=A0 may fail to interopera= te with newer clients and servers.

=C2=A0 =C2=A0 =C2=A0 Forwarded Cl= ientHellos may contain advertisements for features not
=C2=A0 =C2=A0 =C2= =A0 supported by the middlebox, so the response may include future TLS
= =C2=A0 =C2=A0 =C2=A0 additions the middlebox does not recognize.=C2=A0 Thes= e additions MAY
=C2=A0 =C2=A0 =C2=A0 change any message beyond the Clien= tHello arbitrarily.=C2=A0 In
=C2=A0 =C2=A0 =C2=A0 particular, the values= sent in the ServerHello might change, the
=C2=A0 =C2=A0 =C2=A0 ServerHe= llo format might change, and the TLSCiphertext format
=C2=A0 =C2=A0 =C2= =A0 might change.
=C2=A0
It would also fail for QUIC, as previously noted, due to = QUIC's mobility support, which is important for performance on mobile d= evices.

Not very familiar with QUIC, will have to read on this.=C2= =A0

See here:=C2=A0https://tools.ietf.org/html/draft-ietf-quic-transport-2= 9#section-9

After the TLS handshake, QUIC conn= ections can migrate across client IPs and interfaces without redoing the ha= ndshake.=C2=A0 IPv6 extension headers would allow tagging the packets appro= priately for the network they're on, but tagging the connection in the = handshake is impossible.

Additionally, storing this information in the TLS handsha= ke causes an unnecessary privacy loss: it forces the token to be visible ac= ross the whole internet, even though it is only relevant on the near-client= network segment.=C2=A0

The token is not necessarily relevan= t only to the near-client network segment. For example, in a zero-rating sc= enario where the token comes from the server, there are intermediary networ= ks that are not relevant for charging.

Yes, the tagging has to be handled by the cli= ent in this scenario.=C2=A0 That seems sufficient for all the listed use ca= ses.=C2=A0 If the network operator has to maintain flow state, that's n= o worse than the TLS-based proposal.

Even if the token is entirely opaque, a pe= rvasive surveillance adversary could distinguish between connections with a= nd without tokens, likely differentiating certain applications from others.=

<= div>
You can already infer use of applications just by using IP a= ddresses.

For apps that use CDNs, that's=C2=A0generally not true.
<= div>=C2=A0
Also, the amount of information you can extract = from the presence of tokens decreases rapidly with the number of users that= participate in them.

I agree that this is a small amount of leakage; I&= #39;m merely pointing out that it's (a) not zero and (b) unnecessary.

<= div>
I r= ecommend that the authors focus on the draft's proposal to use an IPv6 = extension header, and remove the other proposed encapsulations.=C2=A0 Also,= please remove the specific extension number from Section 7.1 unless and un= til IANA has allocated a number.=C2=A0 For testing, you should use a value = from the Private Use range,=C2=A065282-65535.

OK - I'll pick one from them private range - tha= nks.=C2=A0

Best,
Yiannis



On Fr= i, Jun 26, 2020 at 1:43 PM Christian Huitema <huitema@huitema.= net> wrote:


On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:



=
On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema <hui= tema@huitema.net> wrote:

On 6/25/2020 11:11 PM, Melinda Shore wrote:

On 6/25/20 3:29 PM,= Erik Nygren wrote:

One quick comment is th= at binding tokens to IP addresses is strongly counter-recommended.
It doesn= 't survive NATs or proxies, mobility, and it is especially problematic in IPv6+IPv4 dual-stack environments.

There's been a bunch of past work done developing similar sorts of protocols, and for what it's worth I wrote up a mechanism for using address tags and address rewrites, but unfortunately Cisco decided to patent it. Anyway, there are ways of dealing with this problem that don't require binding the address to the token ("all technical problems can be solved by introducing a layer of indirection").

The= re is also an interesting privacy issue. The token is meant to let a provider identify some properties of the connection. I suppose there are ways to do that without having it become a unique identifier that can be tracked by, well, pretty much everybody. But you have better spell out these ways.


You are right that for the dur= ation of a token, one could use it to identify an endpoint (either application or most likely a combination of user/application). Tokens expire and intermediary nodes cannot correlate tokens with each other as they are encrypted. So tracking cannot happen across different tokens (of the same user), or between token-enabled and non-token-enabled traffic. I guess similar type of tracking happens when users are not behind a NAT and their IP address can be used to track them. Would it make sense to have the user add a random value to a token, and then encrypt it with the network's public key, so that each token becomes unique and cannot be tracked. Would that address the privacy concerns better?

That would certainly be better. The basic rule is that a= ny such identifier should be used only once. Pretty much the same issue as the session resume tickets.


Then, there are potential interactions with ESNI/ECH. The whole point of ECH is to keep private extensions private. The token extension would need to be placed in the outer envelope, which is public but does not expose seemingly important information like the SNI or the ALPN.


Ah, I was not aware that ES= NI can now include all CH extensions - thanks for the pointer. Yes, the token would have to stay on the outer envelope so the network can process it. The main idea is you can encrypt everything that is client-server specific, and just keep a token to explicitly exchange information with trusted networks.=C2=A0

<= div class=3D"gmail_extra">

There are also implication= s for QUIC, in which the TLS data is part of an encrypted payload. The encryption key of the TLS carrying initial packets is not secret in V1, but it might well become so in a future version.

<= /div>

Haven't looked into QUIC yet, but i= s on the list of things to do. If anyone is interested to help us explore this, please let me know.

You may want to have that discussion in the QUIC WG. If yo= u are building some kind of QoS service, you probably want it to work with QUIC too.

-- Christian Huitema

_____= __________________________________________
TLS mailing list<= br>
<= /div>



--000000000000732d9305ab9f29a9-- --0000000000007a574005ab9f2967 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIPBgYJKoZIhvcNAQcCoIIO9zCCDvMCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ggxpMIIEkjCCA3qgAwIBAgINAewckktV4F6Q7sAtGDANBgkqhkiG9w0BAQsFADBMMSAwHgYDVQQL ExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEGA1UEAxMK R2xvYmFsU2lnbjAeFw0xODA2MjAwMDAwMDBaFw0yODA2MjAwMDAwMDBaMEsxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSEwHwYDVQQDExhHbG9iYWxTaWduIFNNSU1FIENB IDIwMTgwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUeobu8FdB5oJg6Fz6SFf8YsPI dNcq4rBSiSDAwqMNYbeTpRrINMBdWuPqVWaBX7WHYMsKQwCOvAF1b7rkD+ROo+CCTJo76EAY25Pp jt7TYP/PxoLesLQ+Ld088+BeyZg9pQaf0VK4tn23fOCWbFWoM8hdnF86Mqn6xB6nLsxJcz4CUGJG qAhC3iedFiCfZfsIp2RNyiUhzPAqalkrtD0bZQvCgi5aSNJseNyCysS1yA58OuxEyn2e9itZJE+O sUeD8VFgz+nAYI5r/dmFEXu5d9npLvTTrSJjrEmw2/ynKn6r6ONueZnCfo6uLmP1SSglhI/SN7dy L1rKUCU7R1MjAgMBAAGjggFyMIIBbjAOBgNVHQ8BAf8EBAMCAYYwJwYDVR0lBCAwHgYIKwYBBQUH AwIGCCsGAQUFBwMEBggrBgEFBQcDCTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBRMtwWJ 1lPNI0Ci6A94GuRtXEzs0jAfBgNVHSMEGDAWgBSP8Et/qC5FJK5NUPpjmove4t0bvDA+BggrBgEF BQcBAQQyMDAwLgYIKwYBBQUHMAGGImh0dHA6Ly9vY3NwMi5nbG9iYWxzaWduLmNvbS9yb290cjMw NgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9yb290LXIzLmNybDBn BgNVHSAEYDBeMAsGCSsGAQQBoDIBKDAMBgorBgEEAaAyASgKMEEGCSsGAQQBoDIBXzA0MDIGCCsG AQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG9w0B AQsFAAOCAQEAwREs1zjtnFIIWorsx5XejqZtqaq5pomEvpjM98ebexngUmd7hju2FpYvDvzcnoGu tjm0N3Sqj5vvwEgvDGB5CxDOBkDlmUT+ObRpKbP7eTafq0+BAhEd3z2tHFm3sKE15o9+KjY6O5bb M30BLgvKlLbLrDDyh8xigCPZDwVI7JVuWMeemVmNca/fidKqOVg7a16ptQUyT5hszqpj18MwD9U0 KHRcR1CfVa+3yjK0ELDS+UvTufoB9wp2BoozsqD0yc2VOcZ7SzcwOzomSFfqv7Vdj88EznDbdy4s fq6QvuNiUs8yW0Vb0foCVRNnSlb9T8//uJqQLHxrxy2j03cvtTCCA18wggJHoAMCAQICCwQAAAAA ASFYUwiiMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAtIFIz MRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTA5MDMxODEwMDAw MFoXDTI5MDMxODEwMDAwMFowTDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzAR BgNVBAoTCkdsb2JhbFNpZ24xEzARBgNVBAMTCkdsb2JhbFNpZ24wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDMJXaQeQZ4Ihb1wIO2hMoonv0FdhHFrYhy/EYCQ8eyip0EXyTLLkvhYIJG 4VKrDIFHcGzdZNHr9SyjD4I9DCuul9e2FIYQebs7E4B3jAjhSdJqYi8fXvqWaN+JJ5U4nwbXPsnL JlkNc96wyOkmDoMVxu9bi9IEYMpJpij2aTv2y8gokeWdimFXN6x0FNx04Druci8unPvQu7/1PQDh BjPogiuuU6Y6FnOM3UEOIDrAtKeh6bJPkC4yYOlXy7kEkmho5TgmYHWyn3f/kRTvriBJ/K1AFUjR AjFhGV64l++td7dkmnq/X8ET75ti+w1s4FRpFqkD2m7pg5NxdsZphYIXAgMBAAGjQjBAMA4GA1Ud DwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSP8Et/qC5FJK5NUPpjmove4t0b vDANBgkqhkiG9w0BAQsFAAOCAQEAS0DbwFCq/sgM7/eWVEVJu5YACUGssxOGhigHM8pr5nS5ugAt rqQK0/Xx8Q+Kv3NnSoPHRHt44K9ubG8DKY4zOUXDjuS5V2yq/BKW7FPGLeQkbLmUY/vcU2hnVj6D uM81IcPJaP7O2sJTqsyQiunwXUaMld16WCgaLx3ezQA3QY/tRG3XUyiXfvNnBB4V14qWtNPeTCek TBtzc3b0F5nCH3oO4y0IrQocLP88q1UOD5F+NuvDV0m+4S4tfGCLw0FREyOdzvcya5QBqJnnLDMf Ojsl0oZAzjsshnjJYS8Uuu7bVW/fhO4FCU29KNhyztNiUGUe65KXgzHZs7XKR1g/XzCCBGwwggNU oAMCAQICEAH8qNflD4Mi9yKttXfRdHcwDQYJKoZIhvcNAQELBQAwSzELMAkGA1UEBhMCQkUxGTAX BgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExITAfBgNVBAMTGEdsb2JhbFNpZ24gU01JTUUgQ0EgMjAx ODAeFw0yMDA2MDUwODIyMjhaFw0yMDEyMDIwODIyMjhaMCIxIDAeBgkqhkiG9w0BCQEWEWJlbWFz Y0Bnb29nbGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2kbyV9S0YLplF3kV 6t3GgD7IyHe8L29pJ7l+UR0Sj31uPgXOFdSSdTVwhPfQvxmB2OUDXWDgDtZdL2xu4DgHhrDyyOXT 8uDJqUCPw004ZSuUfUor1vz5u6+oYNfx2OTPTb81vtsQO2/khni3iAeQlKgO/rUI1c9+zvT6k3mR SZUypAlk/rCyG6NV7NMJMmOaU20/kPBXG297iP8+/F9w4xs+lyb3IkcSfoSUr3fVz7mYqESFato5 JnjRQGT2/f/ehxkc09jATqVGj9nyQMoD2GNPjiNnYyTVBwK5Ol/s9+E2VSL4TSLrgS2R07kY9zPi VOM3lhDDRnceboNSaqnfMwIDAQABo4IBczCCAW8wHAYDVR0RBBUwE4ERYmVtYXNjQGdvb2dsZS5j b20wDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUwJS1fB3cBxoLgZFatdIO9Vp5wOcwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEF BQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wUQYIKwYBBQUHAQEE RTBDMEEGCCsGAQUFBzAChjVodHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc3Nt aW1lY2EyMDE4LmNydDAfBgNVHSMEGDAWgBRMtwWJ1lPNI0Ci6A94GuRtXEzs0jA/BgNVHR8EODA2 MDSgMqAwhi5odHRwOi8vY3JsLmdsb2JhbHNpZ24uY29tL2NhL2dzc21pbWVjYTIwMTguY3JsMA0G CSqGSIb3DQEBCwUAA4IBAQCC91PBn9rMxo8kSo1zNY2mxkTQDTVc0oyYk8s3y72y21IEp/d/+h1H VTCD2FR30aFUv8hTJkebJ5Z1/zue2L7sx/lLEOIHm9uYxyTkTWbKup3+XrE1vhODTHVx+ktMuOTY z447/fwjy4praSaFrQsOjTPbAoU6xuC8S2j2K2Yg6XQsctcKHKeAJjN6evZYChDaTBLmtYq9LTSH KVv3Et795vNK3gWKjhEkJtaBu4FfKLoopb1PENJ/zK6p/3edCLFgCRMSlbQ0SGtdVESSJcgezSwW WK2VB1Zcj2kyVzcL1pmV8m1xQuz2aBgUMn7peoVxKxYKP12gMtzeMvkzltYBMYICYTCCAl0CAQEw XzBLMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEhMB8GA1UEAxMYR2xv YmFsU2lnbiBTTUlNRSBDQSAyMDE4AhAB/KjX5Q+DIvcirbV30XR3MA0GCWCGSAFlAwQCAQUAoIHU MC8GCSqGSIb3DQEJBDEiBCCZ9zm3T7ii+7WV8Fq3j6HIhGDLiLO9HsEPtX5hMVBBIDAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMDA3MzAwMjA5MjdaMGkGCSqGSIb3 DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEApQeB3ZIe2umY1lb9F607yBodKyNrm99Zc1FuaH9dzGe/LNCgKM/KYtPLz7H1RdPWDWPj09cG aqdsHaSc0zPi2WvY54pdiJxxGdy5+AF+Sex6UMpQLL+vreLSdE4gaWiuRQasvzXzwMsjyEBWvKc9 FxTuhtk4YcVa+JNF8cbg4ZF9/U5xaUKnKsXw+XM2rWKbAvGcoYqnxewdVBLnI2ZYYHYPQ22PdV9S N2EZVdttrqJBDqMPEJHOv8uj9IRLKodu3MLw/NjTmW8xg/ZZbvedg881IbgU6lyv3axB6KMJ/Bc7 7tBs6+EqPAkhDb25TFq6qBDda1EUqzuxtEm3RX/iMg== --0000000000007a574005ab9f2967-- From nobody Wed Jul 29 21:47: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 9BC013A0D0F; Wed, 29 Jul 2020 21:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hfoZNhb8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TgRtUZ5g 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 30SmKAzTipgg; Wed, 29 Jul 2020 21:47:33 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE1B3A0CEC; Wed, 29 Jul 2020 21:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6121; q=dns/txt; s=iport; t=1596084453; x=1597294053; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=k7DUGXikRz1CjmOmH3mUuGdqUb6Nyv5Y3og437aG+/s=; b=hfoZNhb8Vw8jhq2Z46TC9FucsNkP2rQlWIQS6QkWl41Q1mbq4LEdqEX/ rdV3q8oRV8DR56oTRoRgfp7pbUnqhYuEoXfcABzTEGaMVN8KO/qttIrjJ KlZAGJnBepG77pZ54oGpOj/1K/rMAJ8Q8QlVYR2pskYMBt2fmUJKOrXe2 s=; IronPort-PHdr: =?us-ascii?q?9a23=3Ay2dFtxfaxe4ZF50Mwv6EoST+lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaTAdfX7vtegKzXvrzuH2sa7sXJvHMDdclKUB?= =?us-ascii?q?kIwYUTkhc7CcGIQUv8MLbxbiM8EcgDMT0t/3yyPUVPXsqrYVrUry6+6DcIEV?= =?us-ascii?q?P+OBZ7YOPvFd2ag8G+zevn/ZrVbk1Bjya8ZrUnKhKwoE3Ru8AajJEkJLw2z0?= =?us-ascii?q?7Co2BDfKJdwmY7KA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAQC4TyJf/4UNJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGBeQQBAQsBgSIvIy4HgUcvLAqEK4NGA40qlBqEbIJTA1ULAQE?= =?us-ascii?q?BDAEBLQIEAQGETAIXgg0CJDcGDgIDAQELAQEFAQEBAgEGBG2FXAyFcgIEEgs?= =?us-ascii?q?GHQEBNwEPAgEIBDsDAgICMBQRAgQOBSKDBIF/TQMuAaROAoE5iGF2gTKDAQE?= =?us-ascii?q?BBYUUGIIOCYE4AYJug1+COoQFGoIAgTgMEIJNPoJcBIFcgxczgi2QDIIqPIZ?= =?us-ascii?q?dnDwKgl+ZfwMen3StaYNWAgQCBAUCDgEBBYFpJIFXcBVlAYI+PhIXAg2OH4N?= =?us-ascii?q?xilZ0AjUCBgEHAQEDCXyPHAGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,413,1589241600"; d="scan'208,217";a="519305566" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Jul 2020 04:47:32 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 06U4lWfn009010 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Jul 2020 04:47:32 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 29 Jul 2020 23:47:32 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Jul 2020 00:47:31 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 29 Jul 2020 23:47:30 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eHMdNBRwwjgMjLWdNOM0DjcqUPM4/IninzaxLOk5FJVEP2JtKSC0WvNjh8GtHclrSLqKP/EbWkxcW7f6SfRNV/lIEzQAZmvstRtSJk4U1iaobaI3GhO7CyUyy3jCRhIg0G0RtQPPTzaRwRRkmFVr+YPgL2G7MEYyiCxJicGZ99NNSfjvpfujp4TAzSfPABIz+JRPhVMaU8F7mRP0UxgKTtXnP6gAbD5QBd90eB007p+B+zJOfurJGhbaarSRHS48ZbLX63Pc1k2AZ9jvLONsbEXQg9KUVA6NCtlSdm6INrpfKvBrzQf4JnhVirHuVEjnXhwfGB6BomL1LWBYzy37Tg== 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=k7DUGXikRz1CjmOmH3mUuGdqUb6Nyv5Y3og437aG+/s=; b=WmqvsQyJXnaSnqwscDT/C8fOL4z+rjJxBvvcVFx/HMNUJSlR/XbkNDRYINKC2/v0xS2aUn5XunAfnOB2R8oJ/XkdS3w6/MpaJW19SO6qzTDseh288aAYYMZNoCLzJfx+yOdtif3QazlbEnLp2gDp3sT58uPOehxnJ7Vd+4Sdx7fGF3RzvnBwcImHGtOA8GelO9enScKgMKX+U640sgCUxAxg4ugpWALlLVXFGxY1vDP/HfQdT3it96kpAB7E9y15E8wfneNOBQqaiqglnQyhglaeDTpibso+/vV/GICcvdMAoRG05DUL6oQ48acGcX+wp15lrbI+jTt+UYAUbVOEkw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k7DUGXikRz1CjmOmH3mUuGdqUb6Nyv5Y3og437aG+/s=; b=TgRtUZ5g0BAoYwNRRsuIHlbJ0l2s31nXYyOGgCHfxz5fGOnEuSg8K91KqPSy9gJsT3FsUJU/2ynvxDy3RcImdh2CllYsjYuN5+TYnum8MyCsSjmWfphn0r3Jsc0ECKtY0v+rS1YpagT2BCGV028TURUrV/xbDQjqxIaCc0v78x8= Received: from BYAPR11MB2789.namprd11.prod.outlook.com (2603:10b6:a02:cc::11) by BY5PR11MB3992.namprd11.prod.outlook.com (2603:10b6:a03:188::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.24; Thu, 30 Jul 2020 04:47:29 +0000 Received: from BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870]) by BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870%6]) with mapi id 15.20.3216.033; Thu, 30 Jul 2020 04:47:29 +0000 From: "Eric Wang (ejwang)" To: "Salz, Rich" CC: Eric Rescorla , Stephen Farrell , Ron Bonica , OPSEC , Nick Harper , "tls@ietf.org" Thread-Topic: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AQHWZglyZL4k1mJowUK66EYfa/DABqkfVLGAgAA4SQA= Date: Thu, 30 Jul 2020 04:47:29 +0000 Message-ID: <16DCF5D7-CC18-4015-ADE1-D67A3EBAEDB5@cisco.com> References: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> <9e413fb1-da38-6a1f-8fca-a0dd5a6b6ebd@cs.tcd.ie> <32561228-08fc-79ea-1b2e-f5de87b9c8fe@cs.tcd.ie> <3AC7B7C6-E616-40DA-95A3-A8DE7927E17F@akamai.com> In-Reply-To: <3AC7B7C6-E616-40DA-95A3-A8DE7927E17F@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.15) authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [128.107.241.169] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb785de7-c649-4ae3-d625-08d83443a9ed x-ms-traffictypediagnostic: BY5PR11MB3992: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6790; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: z2yB5/5iKKixn6mpfUOrDIZv4NBcfjGIv9PXqkk554aRtjVMjjpZcXo6Y8lfalpolVyxjB+wyvt9houhXZhWdwRjRRUvSffw8IB5JTc0PwuTFRNp508tMhwPjxqAJpdLRv+kaZbMdzgb1qmogVwNWvRQcXi9xEvSwbR7tali4qgMZHyZus06K4JsVaSXXe9QupCLpU+sf3r/IeRg32CUWSOMaWDKHhGlmqJmdJjFe76NkFmXInUWIc14FOibwKhRzl6lkuF5y+6CzmP0eleA0oHDRRIn1MphVxMsTjg5vSIfxwSTJe2KRJSmJcGJdljZ3iIuaRCUPL5FXw31IznRhA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2789.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(39860400002)(136003)(376002)(346002)(5660300002)(2906002)(54906003)(316002)(71200400001)(83380400001)(86362001)(8936002)(6486002)(4326008)(8676002)(6512007)(66476007)(26005)(186003)(33656002)(36756003)(66946007)(66446008)(64756008)(76116006)(53546011)(6506007)(2616005)(478600001)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: LppOlT0xHcH+fw6h4LHEyEddTk34JzXCjVJGqSwEVqHZvO1TYTFaL/fR1X46yzX0B5ce2bHMzQaHbkTRMrhXV2hHzF0xShNGNbGaWrIvsYcDDlYBd/lqG2hRcdTrh9k1YuW8fCeHiYVZM51zJhPcBnDKCrRGEnqyAs21tQJCyjV5arMgkqVfpgzFNLnkwpg1FoaiXMFtKAayQLGK6ioJuJrMewI1vxghmIL9afnURDZQzgnrZb+oMVLF2QI9ahZkWxxCY3QLR5WUvDDpsq5lS+GpsD7BGvpeDUz8qZSia358Z5MpYYjf4l0urNqDPJrFyOZuEaE77W7ADHHreKN8Wfa3ataUsXkSuqSnwwfOo6ZTLV9sLWWImx8pycnvo8ChGxUb3VnzANzpbTZSrqn6hKvoZU6g50WxBNPmdYyPH1p5UtTdBPUliUsr+eYADd+9GPYju6u4kWYXcNzjMtrfiLRl2x1HiXu9Wzsrr2yO4CsMStP4R7tDc/EZ42Av5nT2 Content-Type: multipart/alternative; boundary="_000_16DCF5D7CC184015ADE1D67A3EBAEDB5ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2789.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eb785de7-c649-4ae3-d625-08d83443a9ed X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 04:47:29.0285 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZYkGqMCDW4KSD1PlT7n0xco4pgtFToSriAIAtbR4ZuVALHPqfZp/IcaK9SklYNJEmJty/2uxpSqVP2+k3feb0w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3992 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 04:47:39 -0000 --_000_16DCF5D7CC184015ADE1D67A3EBAEDB5ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gZWNobyB0aGUgaWNraW5lc3MgcGFydOKApiAgIFB1dHRpbmcgb24gbXkgZW5kIHVzZXIgaGF0 LCBpZiBJIGhhdmUgdG8gdGFrZSBpdCB3aXRoIGFuIGVudGVycHJpc2UgZGV2aWNlIG9uIHRoZSBl bnRlcnByaXNlIG5ldHdvcmssIEkgd291bGQgcmF0aGVyIGl0IGJlIGRvbmUgc2VjdXJlbHksIHJl c3BlY3RpbmcgbXkgcHJpdmFjeS4uLiAgSWYgSeKAmW0gb24gbXkgaG9tZSBuZXR3b3JrLCBJIHdh bnQgYW4gZWFzeSB3YXkgdG8gZGV0ZWN0IGFuZCByZWplY3QgaXQsIG5vIG1hdHRlciBpdCBpcyBm cm9tIGEgdmVuZG9yLCBwcm92aWRlciBvciBzdGF0ZS4gIEF0IHRoaXMgdGltZSwgdGhlcmUgc2Vl bXMgbm8gZWFzeSB3YXkgb24gZWl0aGVyIHNpZGUuDQoNCg0KT24gSnVsIDI5LCAyMDIwLCBhdCA2 OjI2IFBNLCBTYWx6LCBSaWNoIDxyc2Fsej00MGFrYW1haS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFp bHRvOnJzYWx6PTQwYWthbWFpLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQo+SSB3b3Vs ZCBzYXkgcmF0aGVyIHRoYXQgdGhvc2UgYW5hbHlzZXMgY29uc2lkZXIgdGhlbSBhcyBwcm90b2Nv bCBlbmRwb2ludHMgYW5kIGFkZHJlc3MgdGhlIHR3byBpbmRpdmlkdWFsIGNvbm5lY3Rpb25zIHRl cm1pbmF0ZWQgYnkgdGhlIHByb3h5IGFuZCBoYXZlIG5vdGhpbmcgdG8gc2F5IGFib3V0IHRoZSBj b21wb3NpdGlvbiBvZiB0aG9zZSB0d28gY29ubmVjdGlvbnMuDQoNCkkgdGhpbmsgdGhhdCBzb21l IG9mIHRob3NlIG9wcG9zZWQgYXJlIGNvbmZsYXRpbmcgdGhlIGdlbmVyYWwg4oCcZW5kIHRvIGVu ZOKAnSBhcmd1bWVudCB3aXRoIHdoYXQgdGhlIFRMUyBwcm90b2NvbCBSRkMgc2F5cywgYXMgZWty IGlzIHNheWluZy4NCg0KQ29uZm9ybWFuY2UgaXNu4oCZdCB0aGUgaXNzdWUsIHJlYWxseSwgaXTi gJlzIGlja2luZXNzLiAgSXTigJlzIG9uZSB0aGluZyBpZiBhbiBlbnRlcnByaXNlIGluc3RhbGwg aW50ZXJtZWRpYXJpZXMgdG8gbW9uaXRvciB0aGUgb3V0Ym91bmQgdHJhZmZpYyBvbiBpdHMgbWFj aGluZXMsIGl04oCZcyBhbm90aGVyIGlmIGEgbmF0aW9uYWwtc2NhbGUgYXR0YWNrZXIgZG9lcyBz dXJyZXB0aXRpb3VzbHksIGFuZCBpdOKAmXMgdmFyaW91cyBvdGhlciB0aGluZ3MgYWxvbmcgdGhv c2Ugc3BlY3RydW1zLiBXZeKAmWQgYWxsIGxpa2UgYSBjbGVhciBicmlnaHQgbGluZSB0byBzYXkg WUVTIGhlcmUsIE5PIHRoZXJlLCBhbmQgV0VMTCBNQVlCRSBJRiBZT1UgTVVTVCBvdmVyIHRoZXJl LCBidXQgdGhhdOKAmXMgbm90IHBvc3NpYmxlLg0KDQo= --_000_16DCF5D7CC184015ADE1D67A3EBAEDB5ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <0C3A51C82B91184AA66C2DF894454087@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NClRvIGVjaG8gdGhlIGlja2luZXNzIHBhcnTigKYg Jm5ic3A7IFB1dHRpbmcgb24gbXkgZW5kIHVzZXIgaGF0LCBpZiBJIGhhdmUgdG8gdGFrZSBpdCB3 aXRoIGFuIGVudGVycHJpc2UgZGV2aWNlIG9uIHRoZSBlbnRlcnByaXNlIG5ldHdvcmssIEkgd291 bGQgcmF0aGVyIGl0IGJlIGRvbmUgc2VjdXJlbHksIHJlc3BlY3RpbmcgbXkgcHJpdmFjeS4uLiAm bmJzcDtJZiBJ4oCZbSBvbiBteSBob21lIG5ldHdvcmssIEkgd2FudCBhbiBlYXN5IHdheSB0byBk ZXRlY3QgYW5kIHJlamVjdA0KIGl0LCBubyBtYXR0ZXIgaXQgaXMgZnJvbSBhIHZlbmRvciwgcHJv dmlkZXIgb3Igc3RhdGUuICZuYnNwO0F0IHRoaXMgdGltZSwgdGhlcmUgc2VlbXMgbm8gZWFzeSB3 YXkgb24gZWl0aGVyIHNpZGUuDQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEp1bCAyOSwgMjAyMCwgYXQgNjoyNiBQTSwg U2FseiwgUmljaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJzYWx6PTQwYWthbWFpLmNvbUBkbWFyYy5p ZXRmLm9yZyIgY2xhc3M9IiI+cnNhbHo9NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3JnPC9hPiZn dDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdv cmRTZWN0aW9uMTsgY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEx1Y2lk YVNhbnMtVHlwZXdyaXRlcjsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFj aW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRy YW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCiZndDtJIHdvdWxkIHNheSByYXRoZXIg dGhhdCB0aG9zZSBhbmFseXNlcyBjb25zaWRlciB0aGVtIGFzIHByb3RvY29sIGVuZHBvaW50cyBh bmQgYWRkcmVzcyB0aGUgdHdvIGluZGl2aWR1YWwgY29ubmVjdGlvbnMgdGVybWluYXRlZCBieSB0 aGUgcHJveHkgYW5kIGhhdmUgbm90aGluZyB0byBzYXkgYWJvdXQgdGhlIGNvbXBvc2l0aW9uIG9m IHRob3NlIHR3byBjb25uZWN0aW9ucy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBm b250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkkgdGhpbmsgdGhhdCBzb21lIG9mIHRo b3NlIG9wcG9zZWQgYXJlIGNvbmZsYXRpbmcgdGhlIGdlbmVyYWwg4oCcZW5kIHRvIGVuZOKAnSBh cmd1bWVudCB3aXRoIHdoYXQgdGhlIFRMUyBwcm90b2NvbCBSRkMgc2F5cywgYXMgZWtyIGlzIHNh eWluZy48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpDb25mb3JtYW5jZSBpc27i gJl0IHRoZSBpc3N1ZSwgcmVhbGx5LCBpdOKAmXMgaWNraW5lc3MuJm5ic3A7IEl04oCZcyBvbmUg dGhpbmcgaWYgYW4gZW50ZXJwcmlzZSBpbnN0YWxsIGludGVybWVkaWFyaWVzIHRvIG1vbml0b3Ig dGhlIG91dGJvdW5kIHRyYWZmaWMgb24gaXRzIG1hY2hpbmVzLCBpdOKAmXMgYW5vdGhlciBpZiBh IG5hdGlvbmFsLXNjYWxlIGF0dGFja2VyIGRvZXMgc3VycmVwdGl0aW91c2x5LCBhbmQgaXTigJlz IHZhcmlvdXMgb3RoZXIgdGhpbmdzIGFsb25nDQogdGhvc2Ugc3BlY3RydW1zLiBXZeKAmWQgYWxs IGxpa2UgYSBjbGVhciBicmlnaHQgbGluZSB0byBzYXkgWUVTIGhlcmUsIE5PIHRoZXJlLCBhbmQg V0VMTCBNQVlCRSBJRiBZT1UgTVVTVCBvdmVyIHRoZXJlLCBidXQgdGhhdOKAmXMgbm90IHBvc3Np YmxlLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_16DCF5D7CC184015ADE1D67A3EBAEDB5ciscocom_-- From nobody Wed Jul 29 22:24: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 42E9E3A0DE1; Wed, 29 Jul 2020 22:24: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 ubKXB5_tP68d; Wed, 29 Jul 2020 22:24:11 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 C70573A0DDE; Wed, 29 Jul 2020 22:24:10 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id t15so18083517iob.3; Wed, 29 Jul 2020 22:24:10 -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=2/ozDrFJZcICYETSaVKXqjH1pXy2y3ybqPuOB7h0csQ=; b=ooMgRO8MlYGCr7L0041XYULrTqKfleCDYgfjCRJqj71P1j/jcMioXSUMoIYdrZtbL6 7im5bTV0Q9Nuupd6g5O/0++1DATXJPztB6vX07JUKxDo+uBi3Vp/whprA7erjw1l1ErR 2AE7fcEhtdEqjhDkp85t4x7q1s6I49UkIl5/ZjZJlt7/u8IMA0zqcee+kWe4ssQpgxoU zPH22XfQsMejrk2JMrzzFJ0oK6q4+JUlh36yMnkr8Y08oCAmJW+8FFkmrBeMT52gZOF9 XhpKR/P2RENujAXPEALiY092MuFEUB29FVQqt2b3azYEUluCg1LmK5F/VU5okJKoUII1 4o7A== 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=2/ozDrFJZcICYETSaVKXqjH1pXy2y3ybqPuOB7h0csQ=; b=rfAVAq0VwpioiDL5RbUh3uf/LAViOVUm2UZ9Vw6HfP818OhgAUlJ1fYL4/S36iMmkL +Jx9xhbq6aQtnnyhjDKkw3ymU9E2LmiXzjyo9ujh68whgne+8Twzt7IL1x7N6FiDer8W j9B3Rap021JB0YIqTSvQEzH/ANrR2gUhxc92QymAw9JDl+ylxtuaVYak7x//myd+l5Dj pbqhWzo1M1fkp/95omWRL+us87hV8Svvm/7ZBBrc1nDfiURGhlyvKVAObh4P7UuNLd82 jofBT4JgvGDFy25ZdnA1/ib89nLctu8UQgsU6ekmUq6A1pUbKzBOD2yfVsj3iEiO5afH rhQQ== X-Gm-Message-State: AOAM530OT4BOmpX9P0tTOwlzgiAu1QwDpxYiidiOPinL+HlXAxnpJzTz /TPPJgG+tw9lUGKtJXILwp8xkBQP4FtN8kY6CpM= X-Google-Smtp-Source: ABdhPJx+CVUrIBkrhbw7QRrCTWc2AuL2e8PO82TTWbUDma3Y4MW/gxInHxtcrbPEGMF6ayqmWknXqdoos2s6tk4AbAg= X-Received: by 2002:a5d:9755:: with SMTP id c21mr28077037ioo.69.1596086649863; Wed, 29 Jul 2020 22:24:09 -0700 (PDT) MIME-Version: 1.0 References: <34226646-93F3-4592-A972-A55B160D5B78@cisco.com> <9e413fb1-da38-6a1f-8fca-a0dd5a6b6ebd@cs.tcd.ie> <32561228-08fc-79ea-1b2e-f5de87b9c8fe@cs.tcd.ie> <3AC7B7C6-E616-40DA-95A3-A8DE7927E17F@akamai.com> <16DCF5D7-CC18-4015-ADE1-D67A3EBAEDB5@cisco.com> In-Reply-To: <16DCF5D7-CC18-4015-ADE1-D67A3EBAEDB5@cisco.com> From: Rob Sayre Date: Wed, 29 Jul 2020 22:23:56 -0700 Message-ID: To: "Eric Wang (ejwang)" Cc: "Salz, Rich" , Ron Bonica , OPSEC , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cbc1e405aba1e175" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 05:24:12 -0000 --000000000000cbc1e405aba1e175 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 29, 2020 at 9:48 PM Eric Wang (ejwang) wrote: > To echo the ickiness part=E2=80=A6 Putting on my end user hat, if I hav= e to take > it with an enterprise device on the enterprise network, I would rather it > be done securely, respecting my privacy... If I=E2=80=99m on my home net= work, I > want an easy way to detect and reject it, no matter it is from a vendor, > provider or state. At this time, there seems no easy way on either side. > I don't think this makes sense. thanks, Rob --000000000000cbc1e405aba1e175 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 29, 2020 at 9:48 PM Eric Wang= (ejwang) <ejwang=3D40cisco.com@dmarc.ietf.org> wrote:
To echo the ickiness part=E2=80=A6 =C2=A0 Putting on my end user hat, if I = have to take it with an enterprise device on the enterprise network, I woul= d rather it be done securely, respecting my privacy...=C2=A0 If I=E2=80=99m= on my home network, I want an easy way to detect and reject it, no matter it is from a vendor, provider or state.=C2=A0 At this time, = there seems no easy way on either side.

I don't think this makes sense.

thanks,
Rob
=C2=A0
--000000000000cbc1e405aba1e175-- From nobody Thu Jul 30 03:57: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 E45763A110C; Thu, 30 Jul 2020 03:57:13 -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 7bNrle9780LN; Thu, 30 Jul 2020 03:57:11 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 6A0B33A10DB; Thu, 30 Jul 2020 03:57:09 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id 140so14703317lfi.5; Thu, 30 Jul 2020 03:57:09 -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=XqehbibD87tab9M90sAvlqecIEYENXR9fGIt55B6cMM=; b=CXC3TNt1Uo/AlgyKV3514mept1fg6XXcoa05UeKBanYPs/UhdZFvInzVbUX4bpuEL5 gMm92KJUcYOlhkq1x6FjuFj0VANwJAtRW59kViv0HXukJk0xrAvyg5NSw/uteLjvvoGC dia4kYES08nsfFylEyx/itLug3lCQejgw4Uh8WveZsOJMn9z7HlQ6p1X45c3W/ABTErB Ie6hsxaReMws60zTR92QXAaiRAjdpj2ZuIb11uCdIlGkyExvXslocswn8xOhCz+n/1/6 pn6DQPbshIJg1Udx/VQWbSoaBMy74j6zpA2aNANaj4tmmNAcctKV6HZq+6KEY+Wxmzur sBvQ== 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=XqehbibD87tab9M90sAvlqecIEYENXR9fGIt55B6cMM=; b=rjTTxV5e7T9ZxQ8qFq//71573bLeFPZInysqGA4aEf/PzB4K3d1H1PbyDLw2c3ftQZ ss0qQpvZbyk3VOl4SjqxBJ/u/Gqi0M//nz5l1wUSmnZnLqeeIQaITH8+qSDImERXVRl7 aiEZVE1CQMPcPMaBJgN/PIjv+FX+e5ot2zSZslE5LOZLthaoSONbkoDoaWJU7oOfjJ+3 OsHMlWcCSDvPdt8iEJbT/fvbh7upGM28Gsa9OVyv2dh3WL3JO6UN4ukRUTaDJamx9xUf LqbSJ2BOQ5SUkT735dCwBa+B/eL/urCoEeqgxfSRdVBgzL3zOx1FF+0boA5TbG0pekL3 DJOQ== X-Gm-Message-State: AOAM532dRH6mT4WNMoDy6ddIhpQMSPQdwzVBhKwYgec+RDHfeTOgB7Cc pmQQmJ08wbRJ2SlZ8HdiwFtL9WmKLXA/vvrJE28= X-Google-Smtp-Source: ABdhPJz4n9lvpJ9Fm+YRh5t6qyHxwY2WTaNqJ5yp3FKgR1++7r7nC2nyZFm6uTjFIz7g/Qmc9ejBMB7R9ZTsdbwsY3I= X-Received: by 2002:a19:8c9:: with SMTP id 192mr1394753lfi.204.1596106627274; Thu, 30 Jul 2020 03:57:07 -0700 (PDT) MIME-Version: 1.0 References: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net> In-Reply-To: From: Watson Ladd Date: Thu, 30 Jul 2020 06:56:52 -0400 Message-ID: To: Yiannis Yiakoumis Cc: Ben Schwartz , network-tokens@ietf.org, "" Content-Type: multipart/alternative; boundary="0000000000008ada9505aba68864" Archived-At: Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI 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 Jul 2020 10:57:18 -0000 --0000000000008ada9505aba68864 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 29, 2020, 7:51 PM Yiannis Yiakoumis wrote: > Hi Ben, > > Thanks for your comments. Please find some responses inline. > > On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz wrote: > >> This proposal is highly ossifying. Application protocols that are >> included in this scheme become very difficult to update. For example, in >> the case of zero-rating, this proposal would only be able to zero-rate >> application protocols that are understood by the network's token-parsing >> appliance. This seems likely to have serious negative consequences for >> protocol innovation, as these applications would no longer be able to >> implement novel protocols without losing whatever advantage the network >> token offers. For TLS, this proposal would ossify the extension format, >> which could no longer evolve in future TLS versions without risking loss of >> network services. >> > > In an ideal world, everything beyond IP would be encrypted and opaque to > the network, and network tokens would be embedded in IPv6 extension > headers. In practice, this has several (well-known) issues, here is my take > on the trade-offs: > > Tokens as IPv6 extension headers have the benefit that they are applicable > to all traffic/applications, and could potentially be enforced by the > network in a stateless, per-packet manner. The problems are that i) IPv6 > extension headers are often dropped by network operators, ii) there are no > good APIs to expose L3 socket APIs to the app developers who would > eventually acquire and insert tokens, and iii) it doesn't work with IPv4. > Aren't network operators the ones interpreting these tokens? Aren't application developers integrating these? Don't they use sockets? BSD sockets is the API for BSD sockets. IPv4 shouldn't be a consideration for a greenfield enhancement imho. > Tokens as TLS extensions address the major shortcomings for IPv6, i.e., > they have integrity protection so they cannot be dropped by intermediary > nodes, they are closer to the app developer and can therefore expose APIs > for them to add/remove tokens, and iii) they work across both IPv4 and > IPv6. Obviously, they will support only the specific type of transport > which limits the scope. > > Specifically on your comment about protocol innovation, and using ESNI as > an example: my understanding, is that dependency on existing network > services will be an issue for ESNI adoption, and I agree that this is > frustrating. I will counter argue though, that the problem is not that the > network appliance doesn't adopt to a new format or novel protocol, but > rather that there is no protocol and means in place for endpoints to > explicitly coordinate with the network. In that sense, having a thin > mechanism to do this coordination can accelerate innovation in all other > aspects. > Internet is end to end and layered for a reason. The economics of middleboxes make upgrades far slower than client and server. Even with visibility and negotiation the problems of middleboxes remain. > Does the group have any sense on the impact of existing DPI-based services > on adoption of new ideas on TLS? > TLS 1.3 is filled with kluges to make it look like TLS 1.2 to middleboxes. > > Also note that something like network tokens would be implemented in > programmable hardware and/or software, and in principle should be much > quicker to adopt to format changes comparing to fixed-silicon appliances. > If you want per-flow instead of per-packet processing of priorities you can look at the header on the first packet of a flow and copy on the rest. Flow based does have challenges scaling, but if your hardware can't look into extension headers this could work. > The proposal also violates the TLS Protocol Invariants, by attempting to >> process the ServerHello after forwarding an arbitrary ClientHello. >> > > Not sure I understand this. Can you explain what you mean by arbitrary > ClientHello, or point me to the related TLS section? > > It would also fail for QUIC, as previously noted, due to QUIC's mobility >> support, which is important for performance on mobile devices. >> > > Not very familiar with QUIC, will have to read on this. > > Additionally, storing this information in the TLS handshake causes an >> unnecessary privacy loss: it forces the token to be visible across the >> whole internet, even though it is only relevant on the near-client network >> segment. >> > > The token is not necessarily relevant only to the near-client network > segment. For example, in a zero-rating scenario where the token comes from > the server, there are intermediary networks that are not relevant for > charging. > > Even if the token is entirely opaque, a pervasive surveillance adversary >> could distinguish between connections with and without tokens, likely >> differentiating certain applications from others. >> > > You can already infer use of applications just by using IP addresses. > Also, the amount of information you can extract from the presence of tokens > decreases rapidly with the number of users that participate in them. > If tokens are per application vs. used as a tracking vector. The set of applications people use is identifying. I don't think pointing at a bigger leak elsewhere is a good justification for making another hole in the boat. > > I recommend that the authors focus on the draft's proposal to use an IPv6 >> extension header, and remove the other proposed encapsulations. Also, >> please remove the specific extension number from Section 7.1 unless and >> until IANA has allocated a number. For testing, you should use a value >> from the Private Use range, 65282-65535. >> > > OK - I'll pick one from them private range - thanks. > > Best, > Yiannis > > > > On Fri, Jun 26, 2020 at 1:43 PM Christian Huitema >> wrote: >> >>> >>> On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote: >>> >>> >>> >>> >>> On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema >>> wrote: >>> >>> On 6/25/2020 11:11 PM, Melinda Shore wrote: >>>> >>>> On 6/25/20 3:29 PM, Erik Nygren wrote: >>>> >>>> One quick comment is that binding tokens to IP addresses is strongly >>>> counter-recommended. >>>> It doesn't survive NATs or proxies, mobility, and it is especially >>>> problematic in IPv6+IPv4 dual-stack environments. >>>> >>>> There's been a bunch of past work done developing similar sorts of >>>> protocols, and for what it's worth I wrote up a mechanism for using address >>>> tags and address rewrites, but unfortunately Cisco decided to patent it. >>>> Anyway, there are ways of dealing with this problem that don't require >>>> binding the address to the token ("all technical problems can be solved by >>>> introducing a layer of indirection"). >>>> >>>> There is also an interesting privacy issue. The token is meant to let a >>>> provider identify some properties of the connection. I suppose there are >>>> ways to do that without having it become a unique identifier that can be >>>> tracked by, well, pretty much everybody. But you have better spell out >>>> these ways. >>>> >>> >>> You are right that for the duration of a token, one could use it to >>> identify an endpoint (either application or most likely a combination of >>> user/application). Tokens expire and intermediary nodes cannot correlate >>> tokens with each other as they are encrypted. So tracking cannot happen >>> across different tokens (of the same user), or between token-enabled and >>> non-token-enabled traffic. I guess similar type of tracking happens when >>> users are not behind a NAT and their IP address can be used to track them. >>> Would it make sense to have the user add a random value to a token, and >>> then encrypt it with the network's public key, so that each token becomes >>> unique and cannot be tracked. Would that address the privacy concerns >>> better? >>> >>> That would certainly be better. The basic rule is that any such >>> identifier should be used only once. Pretty much the same issue as the >>> session resume tickets. >>> >>> >>> Then, there are potential interactions with ESNI/ECH. The whole point of >>>> ECH is to keep private extensions private. The token extension would need >>>> to be placed in the outer envelope, which is public but does not expose >>>> seemingly important information like the SNI or the ALPN. >>>> >>> >>> Ah, I was not aware that ESNI can now include all CH extensions - thanks >>> for the pointer. Yes, the token would have to stay on the outer envelope so >>> the network can process it. The main idea is you can encrypt everything >>> that is client-server specific, and just keep a token to explicitly >>> exchange information with trusted networks. >>> >>> There are also implications for QUIC, in which the TLS data is part of >>>> an encrypted payload. The encryption key of the TLS carrying initial >>>> packets is not secret in V1, but it might well become so in a future >>>> version. >>>> >>> >>> Haven't looked into QUIC yet, but is on the list of things to do. If >>> anyone is interested to help us explore this, please let me know. >>> >>> You may want to have that discussion in the QUIC WG. If you are building >>> some kind of QoS service, you probably want it to work with QUIC too. >>> >>> -- Christian Huitema >>> _______________________________________________ >>> 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 > --0000000000008ada9505aba68864 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 29, 2020, 7:51 PM Yiannis Yiakoumis <yiannis@selfienetworks.com&= gt; wrote:
3D"
Hi Ben,

=
Thanks for your comments. Please find some responses inline.=C2=A0
=

On Wed, Jul 29, = 2020 at 1:48 PM, Ben Schwartz <bemasc@google.com>= ; wrote:
This proposal is highly ossifying.=C2=A0 Application protocols tha= t are included in this scheme become very difficult to update.=C2=A0 For ex= ample, in the case of zero-rating, this proposal would only be able to zero= -rate application protocols that are understood by the network's token-= parsing appliance.=C2=A0 This seems likely to have serious negative consequ= ences for protocol innovation, as these applications would no longer be abl= e to implement novel protocols without losing whatever advantage the networ= k token offers.=C2=A0 For TLS, this proposal would ossify the extension for= mat, which could no longer evolve in future TLS versions without risking lo= ss of network services.=C2=A0

In an ideal world, everything beyond IP wou= ld be encrypted and opaque to the network, and network tokens would be embe= dded in IPv6 extension headers. In practice, this has several (well-known) = issues, here is my take on the trade-offs:

Tokens as IPv6 extension headers have the benefit that they are applicab= le to all traffic/applications, and could potentially be enforced by the ne= twork in a stateless, per-packet manner. The problems are that i) IPv6 exte= nsion headers are often dropped by network operators, ii) there are no good= APIs to expose L3 socket APIs to the app developers who would eventually a= cquire and insert tokens, and iii) it doesn't work with IPv4.=C2=A0
=
Aren't network operators the ones interpretin= g these tokens? Aren't application developers integrating these? Don= 9;t they use sockets? BSD sockets is the API for BSD sockets.

IPv4 shouldn't be a consideration= for a greenfield enhancement imho.

=

Tokens as TLS extensions addr= ess the major shortcomings for IPv6, i.e., they have integrity protection s= o they cannot be dropped by intermediary nodes, they are closer to the app = developer and can therefore expose APIs for them to add/remove tokens, and = iii) they work across both IPv4 and IPv6. Obviously, they will support only= the specific type of transport which limits the scope.=C2=A0

Specifically on your comment about protocol innovation, and= using ESNI as an example: my understanding, is that dependency on existing= network services will be an issue for ESNI adoption, and I agree that this= is frustrating. I will counter argue though, that the problem is not that = the network appliance doesn't adopt to a new format or novel protocol, = but rather that there is no protocol and means in place for endpoints to ex= plicitly coordinate with the network. In that sense, having a thin mechanis= m to do this coordination can accelerate innovation in all other aspects. <= br>

Internet is end to end and layered for a reaso= n. The economics of middleboxes make upgrades far slower than client and se= rver. Even with visibility and negotiation the problems of middleboxes rema= in.

<= br>
Does the group have any sense on the impact of existing DPI-b= ased services on adoption of new ideas on TLS?

TLS= 1.3 is filled with kluges to make it look like TLS 1.2 to middleboxes.

Also note that someth= ing like network tokens would be implemented in programmable hardware and/o= r software, and in principle should be much quicker to adopt to format chan= ges comparing to fixed-silicon appliances.=C2=A0=C2=A0

If you want per-flow instead of per-packet processing of prioriti= es you can look at the header on the first packet of a flow and copy on the= rest. Flow based does have challenges scaling, but if your hardware can= 9;t look into extension headers this could work.

=
The proposal also violates the TLS Protocol Invariants, by attempting= to process the ServerHello after forwarding an arbitrary ClientHello.=C2= =A0
Not sure I understand this. Can you explain what you mean by ar= bitrary ClientHello, or point me to the related TLS section?
=
It would also fail for QUIC, as = previously noted, due to QUIC's mobility support, which is important fo= r performance on mobile devices.

Not very familiar with QUIC, will = have to read on this.=C2=A0

Additionally, storing this information in the TLS handshake causes= an unnecessary privacy loss: it forces the token to be visible across the = whole internet, even though it is only relevant on the near-client network = segment.=C2=A0
<= div>

The token is not necessarily relevant only to= the near-client network segment. For example, in a zero-rating scenario wh= ere the token comes from the server, there are intermediary networks that a= re not relevant for charging.

=
Even if the token is entirely opaque, a pervasive surveilla= nce adversary could distinguish between connections with and without tokens= , likely differentiating certain applications from others.
<= /div>

Yo= u can already infer use of applications just by using IP addresses. Also, t= he amount of information you can extract from the presence of tokens decrea= ses rapidly with the number of users that participate in them.

If tokens are per application vs. used as a tr= acking vector. The set of applications people use is identifying.

I don't think pointing at a b= igger leak elsewhere is a good justification for making another hole in the= boat.

I recommend that the authors focus on the draft's propo= sal to use an IPv6 extension header, and remove the other proposed encapsul= ations.=C2=A0 Also, please remove the specific extension number from Sectio= n 7.1 unless and until IANA has allocated a number.=C2=A0 For testing, you = should use a value from the Private Use range,=C2=A065282-= 65535.
<= /div>

OK - I'll pick one from them = private range - thanks.=C2=A0

Best,
<= div>Yiannis



On Fri, Jun 2= 6, 2020 at 1:43 PM Christian Huitema <huitema@huite= ma.net> wrote:


On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:



=
On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema <huitema@huitema.net> wrote:

=

On 6/25/2020 11:11 PM, Melinda Shore wrote:

On 6/25/20 3:29 PM,= Erik Nygren wrote:

One quick comment is th= at binding tokens to IP addresses is strongly counter-recommended.
It doesn= 't survive NATs or proxies, mobility, and it is especially problematic in IPv6+IPv4 dual-stack environments.

There's been a bunch of past work done developing similar sorts of protocols, and for what it's worth I wrote up a mechanism for using address tags and address rewrites, but unfortunately Cisco decided to patent it. Anyway, there are ways of dealing with this problem that don't require binding the address to the token ("all technical problems can be solved by introducing a layer of indirection").

The= re is also an interesting privacy issue. The token is meant to let a provider identify some properties of the connection. I suppose there are ways to do that without having it become a unique identifier that can be tracked by, well, pretty much everybody. But you have better spell out these ways.


You are right that for the dur= ation of a token, one could use it to identify an endpoint (either application or most likely a combination of user/application). Tokens expire and intermediary nodes cannot correlate tokens with each other as they are encrypted. So tracking cannot happen across different tokens (of the same user), or between token-enabled and non-token-enabled traffic. I guess similar type of tracking happens when users are not behind a NAT and their IP address can be used to track them. Would it make sense to have the user add a random value to a token, and then encrypt it with the network's public key, so that each token becomes unique and cannot be tracked. Would that address the privacy concerns better?

That would certainly be better. The basic rule is that a= ny such identifier should be used only once. Pretty much the same issue as the session resume tickets.


Then, there are potential interactions with ESNI/ECH. The whole point of ECH is to keep private extensions private. The token extension would need to be placed in the outer envelope, which is public but does not expose seemingly important information like the SNI or the ALPN.


Ah, I was not aware that ES= NI can now include all CH extensions - thanks for the pointer. Yes, the token would have to stay on the outer envelope so the network can process it. The main idea is you can encrypt everything that is client-server specific, and just keep a token to explicitly exchange information with trusted networks.=C2=A0

<= div class=3D"gmail_extra">

There are also implications for QU= IC, in which the TLS data is part of an encrypted payload. The encryption key of the TLS carrying initial packets is not secret in V1, but it might well become so in a future version.

<= /div>

Haven't looked into QUIC yet, but i= s on the list of things to do. If anyone is interested to help us explore this, please let me know.

You may want to have that discussion in the QUIC WG. If yo= u are building some kind of QoS service, you probably want it to work with QUIC too.

-- Christian Huitema

_____= __________________________________________
TLS mailing list<= br>



_________________= ______________________________
TLS mailing list
TLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/tls --0000000000008ada9505aba68864-- From nobody Thu Jul 30 04:28: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 2C6FA3A109B; Thu, 30 Jul 2020 04:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 Jku7XAqDIKZV; Thu, 30 Jul 2020 04:28:48 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-oln040092073104.outbound.protection.outlook.com [40.92.73.104]) (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 2E1BA3A1094; Thu, 30 Jul 2020 04:28:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JJYLz+uFZBOL+leiXpDy4j3FOoWrdXwl/s3lvWwcWRKstCVXmMAODW6WdHHbQEgkcr3oB+OK7bd9SyWhOqfQrCUmKT3AUqavGJmiwRerVGGznwKUHzv5Q6fjnyhXfUqql4ogzXu+dZFI1kqNhkDQ2M72zEujWDFeKOn2diLX8kEOTGvBDjumq0Yz5Rpfe4EQcYJNMYX7tf8us5vS9W0Cm1+Xw3fUonpNqEwclw+ZaMd76daSsDVIH2bwtOUPUS7+9fFbRI16P9gorIGYC2aAvKuLgpxJ7o/3PSsyTQ1x/lIQwG4APCpvg2stshLir1p9PuKweBJinxirs2Z+YPW6Ew== 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=Ew7vPa0m+68qCqWFbnIqVDIC7x/pAHXkYFR5sb4SZHw=; b=LIbD5D/HdhRmtiok63QOy2YoAQGyY7YGGm9E5C0taHu+km+uKlR1q1CkJdL6UlVO5MG/XFEhduN7Q3KWAvz0G/A5wQ/Ge5VPuatfqL130LxK7Y1X4MIbMSDnkyyJm3A3vcRTIKiM7eaJA6DVQCEWRaAqEEBSaDI8jQltc/q+hcU+iqWSprPvl5BjHrVLUy0A0swikfxqM2YbSM9pawIrETV15zrOQx0qDIxAQdPR14aPKZZiSwd+OurtAvO5qdrEk62GtCcbiX27MerhBZL6YVRMuMOxrQ8EdRPyS4anR5JivLfrBGpfwDUIFuZWeeDosjw7RGj2DV1CGyVRv86pJg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Ew7vPa0m+68qCqWFbnIqVDIC7x/pAHXkYFR5sb4SZHw=; b=mPmh9mgs0/eU5Uy08BPY+yTcervgHO5VRhezhlcDvSsXxMqjNTp4Rqef7GOuAcXSzB3+ipqIx0AYjHKzhzsLefDNvOzjuU8HJpNjwpG3wHFsB/PBfFv3oEAM7pyFTgat1LU8apAkuuGfX81Xg0EZWd4/u0YLrYA2UF9qLvLGC9B40ZYPTkrfiwOCWJaZ4EoNlsg6crTAaNnUvE26VJF+Hqt+bbdtJ85sAHWE4wLOn/u/PFMHv7oOn71CYGP31idXRNKpghCmEg8r+BuQNmtQNXaZfEu5VeHluJ1sBJ+Be9r7N0LVZd6R33zVRmeDvkeqDXMRrVUfze8lU2FUhpZJEA== Received: from HE1EUR04FT049.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0d::47) by HE1EUR04HT200.eop-eur04.prod.protection.outlook.com (2a01:111:e400:7e0d::398) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17; Thu, 30 Jul 2020 11:28:45 +0000 Received: from CWLP265MB0643.GBRP265.PROD.OUTLOOK.COM (2a01:111:e400:7e0d::4d) by HE1EUR04FT049.mail.protection.outlook.com (2a01:111:e400:7e0d::171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17 via Frontend Transport; Thu, 30 Jul 2020 11:28:45 +0000 Received: from CWLP265MB0643.GBRP265.PROD.OUTLOOK.COM ([fe80::154c:d761:f115:e0eb]) by CWLP265MB0643.GBRP265.PROD.OUTLOOK.COM ([fe80::154c:d761:f115:e0eb%3]) with mapi id 15.20.3239.019; Thu, 30 Jul 2020 11:28:45 +0000 From: Paul Brears To: Arnaud.Taddei.IETF , Jen Linkova CC: OPSEC , OpSec Chairs , "tls@ietf.org" Thread-Topic: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AdZd8qs4MVhjKcpfSaSC3eC5PK0rEQCniF8AAQpSLQAAamJhqg== Date: Thu, 30 Jul 2020 11:28:45 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:C2A4EF67E387E02F55557F3DCBE41943B0C02DF80EAE594D7EE9A4C4D259E0CC; UpperCasedChecksum:0B5B8E92DEC6F7C0E56CB4613F09359669EC2D8A63462E3352D00388C66552C6; SizeAsReceived:7325; Count:45 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [0rpwE4XknPleqAtQQj0FKp70lWYRM4Jy] x-ms-publictraffictype: Email x-incomingheadercount: 45 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: d5685188-dc26-434d-1289-08d8347bb8c9 x-ms-traffictypediagnostic: HE1EUR04HT200: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yH/GYu0SGgaCFrt9IJMn1v248z2uHCJ3gi9DAQ3kIimp0jv3aU5qBXGSxbvUZOAx0kGKCyemxUnzsumwFy6jAV5c0XnbVEyw8pPKicBnG5kuAEXIFKzjYesqNwMzikYOw7B5QEuH14UqmMXxrKy6ErgDbCwyBr9Yh50CDqQafaaz5EBhEmnuDw9DIyO420ngLrDSKKTT1cn8NAja75p4I2xUemCn1ov7Wj3SHyfBzDWTf2qMGii8WfbiDjJPNwpK x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:CWLP265MB0643.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; x-ms-exchange-antispam-messagedata: G24s5DHw/26DnUkmbMWMXwvm4nmOtte/Y58LoFd7GTucZLziSOb8sIloEcmL2ZPNjJIOK6Mxbi0eOJcTBTjOHDq1m2sF6pmx+O/LcfSGJzPZqXvUIsKuXqNlRNmNd+LrXb5tsiAIc0n0JtEGrHcbeQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CWLP265MB0643AFFDE43DF92784A14775D2710CWLP265MB0643GBRP_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: HE1EUR04FT049.eop-eur04.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: d5685188-dc26-434d-1289-08d8347bb8c9 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2020 11:28:45.7712 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1EUR04HT200 Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 11:28:50 -0000 --_000_CWLP265MB0643AFFDE43DF92784A14775D2710CWLP265MB0643GBRP_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable I support this draft and agree with the points made below. Paul From: Arnaud.Taddei.IETF Sent: 28 July 2020 09:36 To: Jen Linkova Cc: OPSEC; OpSec Chairs; tls@ietf.org Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp I strongly support this work as it represents capabilities that are being d= eveloped, deployed and used in practice. It has good intentions and provide= s a good approach in the context of defense in depth approaches. No securit= y cannot be just on both ends of the communication. One can dream about it = but that is not how reality is. Removing this possibility is a limit to the= overall defense. I do not understand the reasons behind ignoring reality and the IETF would = have, in my naive mind, a strong interest in getting this work under good c= ommunity adoption so that it is kept in good control with validated best pr= actices. Everyone would win. I support this draft Sent with ProtonMail Secure Email. =1B$B!>!>!>!>!>!>!>=1B(B Original Message =1B$B!>!>!>!>!>!>!>=1B(B On Thursday 23 July 2020 03:30, Jen Linkova wrote: > One thing to add here: the chairs would like to hear active and > explicit support of the adoption. So please speak up if you believe > the draft is useful and the WG shall work on getting it published. > > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica > rbonica=3D40juniper.net@dmarc.ietf.org wrote: > > > Folks, > > This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp. > > Please send comments to opsec@ietf.org by August 3, 2020. > > > > Ron > > > > > > Juniper Business Use Only > > > > OPSEC mailing list > > OPSEC@ietf.org > > https://www.ietf.org/mailman/listinfo/opsec > > -- > > SY, Jen Linkova aka Furry > > 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 --_000_CWLP265MB0643AFFDE43DF92784A14775D2710CWLP265MB0643GBRP_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

I support this draft and agree with the points made = below.

 

Paul

 

From: Arnaud.T= addei.IETF
Sent: 28 July 2020 09:36
To: Jen Linkova
Cc: OPSEC; OpSec Chairs; tls@ietf.org
Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-p= roxy-bp

 

I strongly support this work as it represents capabi= lities that are being developed, deployed and used in practice. It has good= intentions and provides a good approach in the context of defense in depth= approaches. No security cannot be just on both ends of the communication. One can dream about it but that is= not how reality is. Removing this possibility is a limit to the overall de= fense.

I do not understand the reasons behind ignoring reality and the IETF would = have, in my naive mind, a strong interest in getting this work under good c= ommunity adoption so that it is kept in good control with validated best pr= actices. Everyone would win.

I support this draft


Sent with ProtonMail Secure Email.

=1B$B!>!>!>!>!>!>!>=1B(B Original Message =1B$B!>!>!>!>!>!>!>=1B(B
On Thursday 23 July 2020 03:30, Jen Linkova <furry13@gmail.com> wrote= :

> One thing to add here: the chairs would like to hear active and
> explicit support of the adoption. So please speak up if you believe > the draft is useful and the WG shall work on getting it published.
>
> On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
> rbonica=3D40juniper.net@dmarc.ietf.org wrote:
>
> > Folks,
> > This email begins a Call For Adoption on draft-wang-opsec-tls-pro= xy-bp.
> > Please send comments to opsec@ietf.org by August 3, 2020.
> >
> >           =             &nb= sp;            =             &nb= sp;            =     Ron
> >
> >
> > Juniper Business Use Only
> >
> > OPSEC mailing list
> > OPSEC@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/opsec
>
> --
>
> SY, Jen Linkova aka Furry
>
> 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

 

--_000_CWLP265MB0643AFFDE43DF92784A14775D2710CWLP265MB0643GBRP_-- From nobody Thu Jul 30 05:03: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 908A53A10C4; Thu, 30 Jul 2020 05:03:55 -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 vO06cVBKgEUA; Thu, 30 Jul 2020 05:03:54 -0700 (PDT) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (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 4FB4D3A07D7; Thu, 30 Jul 2020 05:03:54 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id y17so14284186ybm.12; Thu, 30 Jul 2020 05:03:54 -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=T/v+rz6kg9tH1VeHNm0DZaXzOJP63ZInGslUhyP1NjY=; b=VaSQzBbkx9NSoTCGD2cb+cOhoeTyTlruuSXHOQd3ypVczp2rQw2QK9piWdBX1Jbs1z 3t6qUuvM569oRCAxVHYQ28E+tcO5ascoboZ79iQqujEETjvmAWt8XplUQGpjCmNDYpmH ev2xirrM5mi1iOjdpYT7HP2VF2MCsBuiQEHV5tYugAqM9d+MJaIjzXXF5V+IAAjrnG1j mLvjRw3UQT5hsEAlJeiwOzfAzfay9nsR1uDNKRyjBHNGQLgrt7nhOU4Wcj7xutjE0SUx kcwCwww0E9QSCX5ROBbVBjSE5LIXWL+JgFpUAQFmMAbu1HLqBBGmEVAnjpxxJC3LmwsZ jgsA== 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=T/v+rz6kg9tH1VeHNm0DZaXzOJP63ZInGslUhyP1NjY=; b=JPH5V2SS/rJPpX22LJQt0Xr8A5Q6LkFHuPrPQy2203i5OMrl58j4V981DUikSEjHe5 ngQbugUWBaVSKRnba0Mczdz9MViZgyyC3R1WXooyDmzxXjmdUtB3blfX6zJ/Lw9TAZQE Uk9RkdA/G26cj3BYWicTAj4L1u2EDHT9sJGssTHcofx/ivstqNWCYv/rcgVq3mkBjMxO GEuVUMQVtvCW15aYVUOKqrE6/5hm1IBPubosLnbjaBNArEdntegCYxCB3XNYlCqplWZW REhCjJSX6PnYaQKw/j/bQrQRJK556d4MffJJnNAyf9kqPQBEXJjXH1yLByLV/nG6pDRR Bllw== X-Gm-Message-State: AOAM533YC+uaTMVPSWq1EBXg/kCtj0hDX7gL+qb/ykoeIdTUZEe3dYBt +MBAcs+G4/iuSR80iQh+JMqDq7FgWHH8hKsaRdU= X-Google-Smtp-Source: ABdhPJyGOyrPoZliAw+GatM1hBZg0aE7uYRturxpD3jUVysivnMyNGL8Kewtnn8QTB35Q/TcHRAMepbg51LKdvXDW8E= X-Received: by 2002:a25:d4b:: with SMTP id 72mr3876791ybn.22.1596110633437; Thu, 30 Jul 2020 05:03:53 -0700 (PDT) MIME-Version: 1.0 References: <9F2FDA20-12AA-4523-905D-7C9380B7A390@ll.mit.edu> <43A56381-0BA8-4123-A2D5-950FD1EDFC86@cisco.com> <845E6D98-DD1C-4FD7-AEF6-A262C10B35A8@ll.mit.edu> In-Reply-To: <845E6D98-DD1C-4FD7-AEF6-A262C10B35A8@ll.mit.edu> From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Thu, 30 Jul 2020 15:03:40 +0300 Message-ID: To: "Blumenthal, Uri - 0553 - MITLL" Cc: "Nancy Cam-Winget (ncamwing)" , Stephen Farrell , Jen Linkova , OPSEC , "tls@ietf.org" , OpSec Chairs Content-Type: multipart/alternative; boundary="000000000000540d3905aba777bc" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 12:03:56 -0000 --000000000000540d3905aba777bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Peace, On Mon, Jul 27, 2020, 4:18 PM Blumenthal, Uri - 0553 - MITLL wrote: > in this particular case, instead of "if you want to do this, then do it > that way, and I'll help you inter-operate" I prefer "if you want to do th= is > - you're on your own, don't seek a blessing or advice from me". > I don't think this is how it works. I would personally prefer an explicit "this is not recommended or in any way endorsed". I've already heard that "IETF considers this a grey area to be defined in future, and some interoperability is outlined in 8446" in middlebox sales pitches. > -- T=C3=B6ma > --000000000000540d3905aba777bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Peace,

On Mon, Jul 27, 2020, 4:18 PM Blumenthal, Uri - = 0553 - MITLL <uri@ll.mit.edu> wrote:
in this particular case, instead of "if you want to do this, then = do it that way, and I'll help you inter-operate" I prefer "if= you want to do this - you're on your own, don't seek a blessing or= advice from me".

I don't think this is how it works.

I would personally prefer an explicit= "this is not recommended or in any way endorsed".

I've already heard that "IET= F considers this a grey area to be defined in future, and some interoperabi= lity is outlined in 8446" in middlebox sales pitches.

--
T=C3=B6ma
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
--000000000000540d3905aba777bc-- From nobody Thu Jul 30 05:12: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 63BD03A10DD; Thu, 30 Jul 2020 05:12:03 -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 7wtLneH14kah; Thu, 30 Jul 2020 05:12:01 -0700 (PDT) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 B8B773A1163; Thu, 30 Jul 2020 05:11:29 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id n141so12120374ybf.3; Thu, 30 Jul 2020 05:11:29 -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=tbeFglOl4uWLlnsJncSHo+0ycHtMcdAJcba4Hit/QpQ=; b=AslA3ea0EEiSj6y8uWY3ZwClk58+0SSNJehVNyHs3f/1A1x3VTZjpp4vsY+M0jSoSo 1QCqMLMQC9P6ZzZg1GpXy4hgdKm0rY8DQ4oTgWb1GkGuP3Y1mwiDiPL0H150CpQ5oiw0 xLZzDmwzV4+tfyJj/8lquLADVXaldLIxuNAUYCA+5ZwK9TDtjYAF9nOyZ/nYAtla1uOB tuRXbqEwuxpErfm/xLVYLlw0FV6pxviTQcuydg7Sk0ZNWfuEw1rPi14JAUWZDY3yC4zE 84kj3Y+/y18VcU/pdufBQzYpukcw70OxtBMSm2ItgsO1NQWK/soxQ7PfCv3xqUyvOR8/ 9f6Q== 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=tbeFglOl4uWLlnsJncSHo+0ycHtMcdAJcba4Hit/QpQ=; b=HHIOW7sOhUdPRjPUfthjVfDyE5n5OY+PUZ7hSNMLhbZfAJbJ3hMFQuWeWHCHAfzRhQ vmV5k/ocA/JQi+o2vGGpHGah8bngclH5LHJnkH3/NXReg78Vr//FHfvSHb9rOUtJle03 TxxUqtTkKF5NUX47HYrP/hBptunOeE3Ky43uYGH1TJf8b2lvdkFYMUayjqMqRXj8IGvO L21GYRccb13zuvCUQfVlYpFrwQ8Flyv3StUj91flRhgIJQylsPTeQcFOEX/gpP/eVa8D LPTgcdOEJ9Gz9f/NrHYH5C7Xjale0xXraHAsbAEDLZ/qndqY1mJydEHWKQxywWtZG9rE PAlA== X-Gm-Message-State: AOAM532V+4T3VzaiJ9jE6YuaIi+ErPoS+1iG0lLUu064mpLstqY9Aclk cNBPSNXcDlVW1cniO3E3uof5ex7DDGNHtl4xFzg= X-Google-Smtp-Source: ABdhPJwoiVGXO/BHQ16G/u6004CapLdUZC8cPN2BCYszR4p7q7lWiJkaw4wIVCYzYRhbjrtWC4abzMUeSSIaQVfhMBk= X-Received: by 2002:a25:c60b:: with SMTP id k11mr3839262ybf.482.1596111088886; Thu, 30 Jul 2020 05:11:28 -0700 (PDT) MIME-Version: 1.0 References: <4937FCE4-23EF-4585-8675-C07F3B347AC6@cisco.com> In-Reply-To: From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Thu, 30 Jul 2020 15:11:16 +0300 Message-ID: To: "Salz, Rich" Cc: Watson Ladd , "Eric Wang (ejwang)" , Jen Linkova , OPSEC , OpSec Chairs , "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000079a80705aba79293" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 12:12:04 -0000 --00000000000079a80705aba79293 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Peace, On Wed, Jul 29, 2020, 2:20 PM Salz, Rich wrote: > Also, a CDN is not a proxy. It **IS** an entity that the origin has > contracted with to perform certain functions. > It is (in all but a couple of implementations I think) a *proxy* that the origin has contracted with. Could you please elaborate on your point? -- T=C3=B6ma > --00000000000079a80705aba79293 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Peace,

On Wed, Jul 29, 2020, 2:20 PM Salz, Rich= <rsalz=3D40akamai.com@dm= arc.ietf.org> wrote:

Also, a CDN is not a proxy.=C2=A0 It *IS* an = entity that the origin has contracted with to perform certain functions.


It is (in all but a couple of implementations I think) a *proxy* that th= e origin has contracted with.=C2=A0 Could you please elaborate on your poin= t?

--
T=C3=B6ma
--00000000000079a80705aba79293-- From nobody Thu Jul 30 05:33: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 F0F773A10E2; Thu, 30 Jul 2020 05:33: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, 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 (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 dfMBfJFeMVz4; Thu, 30 Jul 2020 05:33:28 -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 B3B553A10DF; Thu, 30 Jul 2020 05:33:28 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06UCNl6d001802; Thu, 30 Jul 2020 13:33:26 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=wotw9HUyHF9K1FK2sHGtlWe93q2VZTxHaO4N2acwO9A=; b=oSlKg7sfLOlA+AFXL3xGs4uwMzEkvd4j5anIqv7L8T6Jv+PdKmWmioxA+R/YjAtsF+c7 ifC4Zh+dfZdasgvCMvwRluvtd/W0Yzt96+25LQHtd298nyQ0AjsMQqlfBuCl551nnbV/ gD7fgXl4JzCruYekktXXrgyL9vxZIPoo6utwlQdmmHYG4ZnK697S6XwHGhlpFsrSQNrG dsKvdXzSNt/wNLugCP8YM2WFna16DjN2/o3shbKA47y5XQUlZe9B+I1Z7RmPDTuP5/zb wUAnGhQ6HlT59luY7m2ohEHf7sbdwvrabExtSvlUx+EGJBoSy28TouZ0rJDBrDw5po+P oQ== Received: from prod-mail-ppoint8 (a72-247-45-34.deploy.static.akamaitechnologies.com [72.247.45.34] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 32gcsrwekf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jul 2020 13:33:26 +0100 Received: from pps.filterd (prod-mail-ppoint8.akamai.com [127.0.0.1]) by prod-mail-ppoint8.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06UCKAwn027325; Thu, 30 Jul 2020 08:33:25 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.115]) by prod-mail-ppoint8.akamai.com with ESMTP id 32kfr636bq-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 30 Jul 2020 08:33:25 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Jul 2020 07:33:24 -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; Thu, 30 Jul 2020 07:33:24 -0500 From: "Salz, Rich" To: =?utf-8?B?VMO2bWEgR2F2cmljaGVua292?= CC: Watson Ladd , "Eric Wang (ejwang)" , Jen Linkova , OPSEC , OpSec Chairs , "tls@ietf.org" Thread-Topic: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AdZd8qs4MVhjKcpfSaSC3eC5PK0rEQCv6iMAAH8Fd4AAUf7RAABaakYAAA6JtwAAPo6TAP//wx4A Date: Thu, 30 Jul 2020 12:33:23 +0000 Message-ID: References: <4937FCE4-23EF-4585-8675-C07F3B347AC6@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.61] Content-Type: multipart/alternative; boundary="_000_D4AEF5C17AAE44EEB52BED0FC6A47642akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-30_10:2020-07-30, 2020-07-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 mlxlogscore=999 malwarescore=0 bulkscore=0 spamscore=0 suspectscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007300092 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-30_10:2020-07-30, 2020-07-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 mlxscore=0 adultscore=0 mlxlogscore=999 lowpriorityscore=0 clxscore=1011 spamscore=0 bulkscore=0 suspectscore=0 priorityscore=1501 phishscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007300092 Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 12:33:30 -0000 --_000_D4AEF5C17AAE44EEB52BED0FC6A47642akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSXQgaXMgKGluIGFsbCBidXQgYSBjb3VwbGUgb2YgaW1wbGVtZW50YXRpb25zIEkgdGhp bmspIGEgKnByb3h5KiB0aGF0IHRoZSBvcmlnaW4gaGFzIGNvbnRyYWN0ZWQgd2l0aC4gIENvdWxk IHlvdSBwbGVhc2UgZWxhYm9yYXRlIG9uIHlvdXIgcG9pbnQ/DQoNCkl0IGhhcyBhIFRMUyBjZXJ0 IHRoYXQgaWRlbnRpZmllcyBpdHNlbGYgYXMgdGhlIG9yaWdpbi4gIEl0IGRvZXNu4oCZdCBqdXN0 IHRlcm1pbmF0ZSBUTFMsIGJ1dCBpdCBkb2VzIHdvcmsgYXQgdGhlIEhUVFAgbGF5ZXIuDQoNCkhv dyBpcyBpdCBkaWZmZXJlbnQgZnJvbSBhbiBvcmlnaW4gdGhhdCB1c2VzIGxvYWQtYmFsYW5jaW5n IHRvIHNlbmQgeW91IHNvbWV3aGVyZT8gIElzIHd3dy5mYWNlYm9vay5jb208aHR0cDovL3d3dy5m YWNlYm9vay5jb20+IGEgQ0ROIG9yIGludGVybWVkaWFyeSwgb3IgaXMgaXQgdGhlIG9yaWdpbj8N Cg== --_000_D4AEF5C17AAE44EEB52BED0FC6A47642akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <4331DEEC575872439039DF81EC2A0490@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6 MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxl ZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE4NTAxNzYzNTc7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjU1NDM2ODUxMCAtMTk1OTc3 Njk0OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0 LWF0Ojk7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWFu c2ktZm9udC13ZWlnaHQ6Ym9sZDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXY+DQo8ZGl2Pg0K PHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPkl0IGlzIChpbiBhbGwgYnV0IGEgY291cGxlIG9mIGltcGxlbWVudGF0aW9ucyBJIHRoaW5r KSBhICpwcm94eSogdGhhdCB0aGUgb3JpZ2luIGhhcyBjb250cmFjdGVkIHdpdGguJm5ic3A7IENv dWxkIHlvdSBwbGVhc2UgZWxhYm9yYXRlIG9uIHlvdXIgcG9pbnQ/PG86cD48L286cD48L2xpPjwv dWw+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGhhcyBhIFRMUyBjZXJ0IHRoYXQgaWRlbnRp ZmllcyBpdHNlbGYgYXMgdGhlIG9yaWdpbi4mbmJzcDsgSXQgZG9lc27igJl0IGp1c3QgdGVybWlu YXRlIFRMUywgYnV0IGl0IGRvZXMgd29yayBhdCB0aGUgSFRUUCBsYXllci48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SG93IGlzIGl0IGRpZmZlcmVudCBmcm9tIGFuIG9yaWdpbiB0aGF0IHVzZXMg bG9hZC1iYWxhbmNpbmcgdG8gc2VuZCB5b3Ugc29tZXdoZXJlPyZuYnNwOyBJcw0KPGEgaHJlZj0i aHR0cDovL3d3dy5mYWNlYm9vay5jb20iPnd3dy5mYWNlYm9vay5jb208L2E+IGEgQ0ROIG9yIGlu dGVybWVkaWFyeSwgb3IgaXMgaXQgdGhlIG9yaWdpbj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D4AEF5C17AAE44EEB52BED0FC6A47642akamaicom_-- From nobody Thu Jul 30 05:48: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 250403A10DC for ; Thu, 30 Jul 2020 05:48:02 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-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 FKADuBayUcy7 for ; Thu, 30 Jul 2020 05:47:58 -0700 (PDT) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (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 686F43A10E3 for ; Thu, 30 Jul 2020 05:47:57 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id o23so367577ejr.1 for ; Thu, 30 Jul 2020 05:47:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p/5uNZPDNrfmuOEcjA/FaWVukh+FuVLxUgidm01JW3I=; b=WIqgO+0TOC0QKS6AuUV9XUcRhf7+qiyvS/VLuKWc/EgsQRkpdsDF+rRXqUqPX5FNe9 oov/Fwsw+a2s/GuvomJa0SUPEA9wMmm3vmJoNbjzmjazT0DRHy06m358dON6dxs0wMOT gD1tNmN9rYGRffO7TdkgjDaTLbOhYH/b3lBYGn7yVlDEKnJFOlOp+WCglSvwKxDu68Yi RkS2zeUhkmCsWoHOHYv/w7ynZeju4oaTHg2aWHnrM+kqNfsZAiCeQ6RSMOwppsybwk6M k04X59zwnS8fOWsl2wiziHnyOp+qjmF9pR5pf6PpoTJ+NIGbSg4kzBoDzAlfXPLX+a2M VenQ== 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/5uNZPDNrfmuOEcjA/FaWVukh+FuVLxUgidm01JW3I=; b=VKiqjdqySKAGFN3GxxAdiMXoCOQazzYsZ0ayYabV6eioW2HDQBd0CGHwgmQPfxUvqA qC3voBOG9lrHfk4vCPr43IkhOFa2mnHG2/2ROK2foAQV5CQAOd/XGOmJKf/FeQE/oT0g JA6spIL87WrExj/spPxl1JsahAvVZNz/XHHLfoETaZ2MfvG0O5pLNM00lDmLeuwrEZoA Xdv7gVO++Q1DAbgMX9qbeqHchdC1ABg6uzEyqbQxI8Miv9n4kZmiCzGJacb3twUPgWqy abkXd0+ukoXeLe2pyxlY+zfTgXfJIEC+JteHFcxdNshsXxEnam0mIdL7uxNHTAIk2i0k is/w== X-Gm-Message-State: AOAM531aDyq2Klu0CaFkPchG0hK46S152M6y7HzAQTLJxVnmKSFgvLjx lO/F570cTfSxRV2ZW3J5/3k1eIJtlybR0V8d151+pg== X-Google-Smtp-Source: ABdhPJwXk/bCelZERROB9naTNFtXeRGxeI8nspCFuFrysIjjHUPBAt4QLtTih9tyGH1P78fN3jRTlSypfZuRdYoygrs= X-Received: by 2002:a17:906:a242:: with SMTP id bi2mr2345157ejb.243.1596113275198; Thu, 30 Jul 2020 05:47:55 -0700 (PDT) MIME-Version: 1.0 References: <87e6e635-d1ec-9f36-41c3-339774f510ca@nomountain.net> <38d4885d-71f0-e69c-e78c-608482036956@huitema.net> <8a6e6520-9f7b-586b-42b4-3b1cab387ccb@huitema.net> In-Reply-To: From: Tom Herbert Date: Thu, 30 Jul 2020 05:47:44 -0700 Message-ID: To: Watson Ladd Cc: Yiannis Yiakoumis , Ben Schwartz , network-tokens@ietf.org, "" Content-Type: multipart/alternative; boundary="000000000000ca348b05aba81470" Archived-At: Subject: Re: [TLS] [Network-tokens] Network Tokens I-D and TLS / ESNI 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 Jul 2020 12:48:02 -0000 --000000000000ca348b05aba81470 Content-Type: text/plain; charset="UTF-8" On Thu, Jul 30, 2020 at 3:57 AM Watson Ladd wrote: > > > On Wed, Jul 29, 2020, 7:51 PM Yiannis Yiakoumis < > yiannis@selfienetworks.com> wrote: > >> Hi Ben, >> >> Thanks for your comments. Please find some responses inline. >> >> On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz wrote: >> >>> This proposal is highly ossifying. Application protocols that are >>> included in this scheme become very difficult to update. For example, in >>> the case of zero-rating, this proposal would only be able to zero-rate >>> application protocols that are understood by the network's token-parsing >>> appliance. This seems likely to have serious negative consequences for >>> protocol innovation, as these applications would no longer be able to >>> implement novel protocols without losing whatever advantage the network >>> token offers. For TLS, this proposal would ossify the extension format, >>> which could no longer evolve in future TLS versions without risking loss of >>> network services. >>> >> >> In an ideal world, everything beyond IP would be encrypted and opaque to >> the network, and network tokens would be embedded in IPv6 extension >> headers. In practice, this has several (well-known) issues, here is my take >> on the trade-offs: >> >> Tokens as IPv6 extension headers have the benefit that they are >> applicable to all traffic/applications, and could potentially be enforced >> by the network in a stateless, per-packet manner. The problems are that i) >> IPv6 extension headers are often dropped by network operators, ii) there >> are no good APIs to expose L3 socket APIs to the app developers who would >> eventually acquire and insert tokens, and iii) it doesn't work with IPv4. >> > > Aren't network operators the ones interpreting these tokens? Aren't > application developers integrating these? Don't they use sockets? BSD > sockets is the API for BSD sockets. > > Yes, we can set HBH options via socket options. One caveat, in Linux at least, is that currently only applications with admin privileges can set options. Either this can be fixed by allowing unprivileged applications to set them or we can have a new socket option just to set this. Either way, I don't believe it's a major blocker to fix and relative to the time to standardize a new protocol or deploy support in the network I don't believe it's the bottleneck. Tom IPv4 shouldn't be a consideration for a greenfield enhancement imho. > > >> Tokens as TLS extensions address the major shortcomings for IPv6, i.e., >> they have integrity protection so they cannot be dropped by intermediary >> nodes, they are closer to the app developer and can therefore expose APIs >> for them to add/remove tokens, and iii) they work across both IPv4 and >> IPv6. Obviously, they will support only the specific type of transport >> which limits the scope. >> >> Specifically on your comment about protocol innovation, and using ESNI as >> an example: my understanding, is that dependency on existing network >> services will be an issue for ESNI adoption, and I agree that this is >> frustrating. I will counter argue though, that the problem is not that the >> network appliance doesn't adopt to a new format or novel protocol, but >> rather that there is no protocol and means in place for endpoints to >> explicitly coordinate with the network. In that sense, having a thin >> mechanism to do this coordination can accelerate innovation in all other >> aspects. >> > > Internet is end to end and layered for a reason. The economics of > middleboxes make upgrades far slower than client and server. Even with > visibility and negotiation the problems of middleboxes remain. > > >> Does the group have any sense on the impact of existing DPI-based >> services on adoption of new ideas on TLS? >> > > TLS 1.3 is filled with kluges to make it look like TLS 1.2 to middleboxes. > >> >> Also note that something like network tokens would be implemented in >> programmable hardware and/or software, and in principle should be much >> quicker to adopt to format changes comparing to fixed-silicon appliances. >> > > If you want per-flow instead of per-packet processing of priorities you > can look at the header on the first packet of a flow and copy on the rest. > Flow based does have challenges scaling, but if your hardware can't look > into extension headers this could work. > > >> The proposal also violates the TLS Protocol Invariants, by attempting to >>> process the ServerHello after forwarding an arbitrary ClientHello. >>> >> >> Not sure I understand this. Can you explain what you mean by arbitrary >> ClientHello, or point me to the related TLS section? >> >> It would also fail for QUIC, as previously noted, due to QUIC's mobility >>> support, which is important for performance on mobile devices. >>> >> >> Not very familiar with QUIC, will have to read on this. >> >> Additionally, storing this information in the TLS handshake causes an >>> unnecessary privacy loss: it forces the token to be visible across the >>> whole internet, even though it is only relevant on the near-client network >>> segment. >>> >> >> The token is not necessarily relevant only to the near-client network >> segment. For example, in a zero-rating scenario where the token comes from >> the server, there are intermediary networks that are not relevant for >> charging. >> >> Even if the token is entirely opaque, a pervasive surveillance adversary >>> could distinguish between connections with and without tokens, likely >>> differentiating certain applications from others. >>> >> >> You can already infer use of applications just by using IP addresses. >> Also, the amount of information you can extract from the presence of tokens >> decreases rapidly with the number of users that participate in them. >> > > If tokens are per application vs. used as a tracking vector. The set of > applications people use is identifying. > > I don't think pointing at a bigger leak elsewhere is a good justification > for making another hole in the boat. > >> >> I recommend that the authors focus on the draft's proposal to use an IPv6 >>> extension header, and remove the other proposed encapsulations. Also, >>> please remove the specific extension number from Section 7.1 unless and >>> until IANA has allocated a number. For testing, you should use a value >>> from the Private Use range, 65282-65535. >>> >> >> OK - I'll pick one from them private range - thanks. >> >> Best, >> Yiannis >> >> >> >> On Fri, Jun 26, 2020 at 1:43 PM Christian Huitema >>> wrote: >>> >>>> >>>> On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote: >>>> >>>> >>>> >>>> >>>> On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema >>> > wrote: >>>> >>>> On 6/25/2020 11:11 PM, Melinda Shore wrote: >>>>> >>>>> On 6/25/20 3:29 PM, Erik Nygren wrote: >>>>> >>>>> One quick comment is that binding tokens to IP addresses is strongly >>>>> counter-recommended. >>>>> It doesn't survive NATs or proxies, mobility, and it is especially >>>>> problematic in IPv6+IPv4 dual-stack environments. >>>>> >>>>> There's been a bunch of past work done developing similar sorts of >>>>> protocols, and for what it's worth I wrote up a mechanism for using address >>>>> tags and address rewrites, but unfortunately Cisco decided to patent it. >>>>> Anyway, there are ways of dealing with this problem that don't require >>>>> binding the address to the token ("all technical problems can be solved by >>>>> introducing a layer of indirection"). >>>>> >>>>> There is also an interesting privacy issue. The token is meant to let >>>>> a provider identify some properties of the connection. I suppose there are >>>>> ways to do that without having it become a unique identifier that can be >>>>> tracked by, well, pretty much everybody. But you have better spell out >>>>> these ways. >>>>> >>>> >>>> You are right that for the duration of a token, one could use it to >>>> identify an endpoint (either application or most likely a combination of >>>> user/application). Tokens expire and intermediary nodes cannot correlate >>>> tokens with each other as they are encrypted. So tracking cannot happen >>>> across different tokens (of the same user), or between token-enabled and >>>> non-token-enabled traffic. I guess similar type of tracking happens when >>>> users are not behind a NAT and their IP address can be used to track them. >>>> Would it make sense to have the user add a random value to a token, and >>>> then encrypt it with the network's public key, so that each token becomes >>>> unique and cannot be tracked. Would that address the privacy concerns >>>> better? >>>> >>>> That would certainly be better. The basic rule is that any such >>>> identifier should be used only once. Pretty much the same issue as the >>>> session resume tickets. >>>> >>>> >>>> Then, there are potential interactions with ESNI/ECH. The whole point >>>>> of ECH is to keep private extensions private. The token extension would >>>>> need to be placed in the outer envelope, which is public but does not >>>>> expose seemingly important information like the SNI or the ALPN. >>>>> >>>> >>>> Ah, I was not aware that ESNI can now include all CH extensions - >>>> thanks for the pointer. Yes, the token would have to stay on the outer >>>> envelope so the network can process it. The main idea is you can encrypt >>>> everything that is client-server specific, and just keep a token to >>>> explicitly exchange information with trusted networks. >>>> >>>> There are also implications for QUIC, in which the TLS data is part of >>>>> an encrypted payload. The encryption key of the TLS carrying initial >>>>> packets is not secret in V1, but it might well become so in a future >>>>> version. >>>>> >>>> >>>> Haven't looked into QUIC yet, but is on the list of things to do. If >>>> anyone is interested to help us explore this, please let me know. >>>> >>>> You may want to have that discussion in the QUIC WG. If you are >>>> building some kind of QoS service, you probably want it to work with QUIC >>>> too. >>>> >>>> -- Christian Huitema >>>> _______________________________________________ >>>> 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 >> > -- > Network-tokens mailing list > Network-tokens@ietf.org > https://www.ietf.org/mailman/listinfo/network-tokens > --000000000000ca348b05aba81470 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jul 30, 2020 at 3:57 AM Watso= n Ladd <watsonbladd@gmail.com> wrote:


3D""
Hi Ben,

Thanks for your comments. = Please find some responses inline.=C2=A0

On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz <= span dir=3D"ltr"><bemasc@google.com> wrote:
This proposal is highly ossifying.=C2=A0 Applicati= on protocols that are included in this scheme become very difficult to upda= te.=C2=A0 For example, in the case of zero-rating, this proposal would only= be able to zero-rate application protocols that are understood by the netw= ork's token-parsing appliance.=C2=A0 This seems likely to have serious = negative consequences for protocol innovation, as these applications would = no longer be able to implement novel protocols without losing whatever adva= ntage the network token offers.=C2=A0 For TLS, this proposal would ossify t= he extension format, which could no longer evolve in future TLS versions wi= thout risking loss of network services.=C2=A0

In an ideal world, everythi= ng beyond IP would be encrypted and opaque to the network, and network toke= ns would be embedded in IPv6 extension headers. In practice, this has sever= al (well-known) issues, here is my take on the trade-offs:
Tokens as IPv6 extension headers have the benefit that t= hey are applicable to all traffic/applications, and could potentially be en= forced by the network in a stateless, per-packet manner. The problems are t= hat i) IPv6 extension headers are often dropped by network operators, ii) t= here are no good APIs to expose L3 socket APIs to the app developers who wo= uld eventually acquire and insert tokens, and iii) it doesn't work with= IPv4.=C2=A0

Aren't network operators the = ones interpreting these tokens? Aren't application developers integrati= ng these? Don't they use sockets? BSD sockets is the API for BSD socket= s.

Yes, we can set= HBH options via socket options. One caveat, in Linux at least, is that cur= rently only applications with admin privileges can set options. Either this= can be fixed by allowing unprivileged=C2=A0applications to set them or we = can have a new socket option just to set this. Either way, I don't beli= eve it's a major blocker to fix and relative to the time to standardize= a new protocol or deploy support in the network I don't believe it'= ;s the bottleneck.

Tom

IPv4 shouldn't be a consideration for a gre= enfield enhancement imho.


Tokens as TLS extens= ions address the major shortcomings for IPv6, i.e., they have integrity pro= tection so they cannot be dropped by intermediary nodes, they are closer to= the app developer and can therefore expose APIs for them to add/remove tok= ens, and iii) they work across both IPv4 and IPv6. Obviously, they will sup= port only the specific type of transport which limits the scope.=C2=A0
<= /div>

Specifically on your comment about protocol innova= tion, and using ESNI as an example: my understanding, is that dependency on= existing network services will be an issue for ESNI adoption, and I agree = that this is frustrating. I will counter argue though, that the problem is = not that the network appliance doesn't adopt to a new format or novel p= rotocol, but rather that there is no protocol and means in place for endpoi= nts to explicitly coordinate with the network. In that sense, having a thin= mechanism to do this coordination can accelerate innovation in all other a= spects.

Internet is end to end and layered fo= r a reason. The economics of middleboxes make upgrades far slower than clie= nt and server. Even with visibility and negotiation the problems of middleb= oxes remain.


Does the group have any sense on= the impact of existing DPI-based services on adoption of new ideas on TLS?=
TLS 1.3 is filled with kluges to make it look lik= e TLS 1.2 to middleboxes.

Also note that something like network tokens wou= ld be implemented in programmable hardware and/or software, and in principl= e should be much quicker to adopt to format changes comparing to fixed-sili= con appliances.=C2=A0=C2=A0
<= /div>

If you want per-fl= ow instead of per-packet processing of priorities you can look at the heade= r on the first packet of a flow and copy on the rest. Flow based does have = challenges scaling, but if your hardware can't look into extension head= ers this could work.

<= div>

The proposal also violates the T= LS Protocol Invariants, by attempting to process the ServerHello after forw= arding an arbitrary ClientHello.=C2=A0

Not sure I understand this. = Can you explain what you mean by arbitrary ClientHello, or point me to the = related TLS section?

It would also fail for = QUIC, as previously noted, due to QUIC's mobility support, which is imp= ortant for performance on mobile devices.

Not very familiar with QU= IC, will have to read on this.=C2=A0

Additional= ly, storing this information in the TLS handshake causes an unnecessary pri= vacy loss: it forces the token to be visible across the whole internet, eve= n though it is only relevant on the near-client network segment.=C2=A0
=

=
The token is not necessarily relevant only to the near-client ne= twork segment. For example, in a zero-rating scenario where the token comes= from the server, there are intermediary networks that are not relevant for= charging.

Even if the token is entirely o= paque, a pervasive surveillance adversary could distinguish between connect= ions with and without tokens, likely differentiating certain applications f= rom others.
=
You can already infer use of applications just by= using IP addresses. Also, the amount of information you can extract from t= he presence of tokens decreases rapidly with the number of users that parti= cipate in them.
<= /div>

If tokens are per = application vs. used as a tracking vector. The set of applications people u= se is identifying.

I don= 't think pointing at a bigger leak elsewhere is a good justification fo= r making another hole in the boat.
=

I recommend that the authors focus on the= draft's proposal to use an IPv6 extension header, and remove the other= proposed encapsulations.=C2=A0 Also, please remove the specific extension = number from Section 7.1 unless and until IANA has allocated a number.=C2=A0= For testing, you should use a value from the Private Use range,=C2=A065282-65535.

OK - I'll p= ick one from them private range - thanks.=C2=A0

Best,
Yiannis



<= /div>
On Fri, Jun 26, 2020 at= 1:43 PM Christian Huitema <huitema@huitema.net= > wrote:


On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:



=
On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema <huitema@huitema.net> wrote:

=

On 6/25/2020 11:1= 1 PM, Melinda Shore wrote:

On 6/25/20 3:29 PM,= Erik Nygren wrote:

One quick comment is th= at binding tokens to IP addresses is strongly counter-recommended.
It doesn= 't survive NATs or proxies, mobility, and it is especially problematic in IPv6+IPv4 dual-stack environments.

There's been a bunch of past work done developing similar sorts of protocols, and for what it's worth I wrote up a mechanism for using address tags and address rewrites, but unfortunately Cisco decided to patent it. Anyway, there are ways of dealing with this problem that don't require binding the address to the token ("all technical problems can be solved by introducing a layer of indirection").

The= re is also an interesting privacy issue. The token is meant to let a provider identify some properties of the connection. I suppose there are ways to do that without having it become a unique identifier that can be tracked by, well, pretty much everybody. But you have better spell out these ways.


You are right that for the dur= ation of a token, one could use it to identify an endpoint (either application or most likely a combination of user/application). Tokens expire and intermediary nodes cannot correlate tokens with each other as they are encrypted. So tracking cannot happen across different tokens (of the same user), or between token-enabled and non-token-enabled traffic. I guess similar type of tracking happens when users are not behind a NAT and their IP address can be used to track them. Would it make sense to have the user add a random value to a token, and then encrypt it with the network's public key, so that each token becomes unique and cannot be tracked. Would that address the privacy concerns better?

That would certainly be better. The basic rule is that a= ny such identifier should be used only once. Pretty much the same issue as the session resume tickets.


Then, there are potential interacti= ons with ESNI/ECH. The whole point of ECH is to keep private extensions private. The token extension would need to be placed in the outer envelope, which is public but does not expose seemingly important information like the SNI or the ALPN.


Ah, I was not aware that ES= NI can now include all CH extensions - thanks for the pointer. Yes, the token would have to stay on the outer envelope so the network can process it. The main idea is you can encrypt everything that is client-server specific, and just keep a token to explicitly exchange information with trusted networks.=C2=A0

<= div class=3D"gmail_extra">

There = are also implications for QUIC, in which the TLS data is part of an encrypted payload. The encryption key of the TLS carrying initial packets is not secret in V1, but it might well become so in a future version.

<= /div>

Haven't looked into QUIC yet, but i= s on the list of things to do. If anyone is interested to help us explore this, please let me know.

You may want to have that discussion in the QUIC WG. If yo= u are building some kind of QoS service, you probably want it to work with QUIC too.

-- Christian Huitema

_____= __________________________________________
TLS mailing list<= br>



_________________= ______________________________
TLS mailing list
TLS@ie= tf.org
https://www.ietf.org/mailman/listinfo/tls --
Network-tokens mailing list
Network-tokens= @ietf.org
https://www.ietf.org/mailman/listinfo/network-to= kens
--000000000000ca348b05aba81470-- From nobody Thu Jul 30 06:15: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 519153A1110; Thu, 30 Jul 2020 06:14:49 -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 n0XqV5uWAPL2; Thu, 30 Jul 2020 06:14:47 -0700 (PDT) Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) (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 3CC723A0AD3; Thu, 30 Jul 2020 06:14:23 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id e14so547141ybf.4; Thu, 30 Jul 2020 06:14:22 -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=28jY7w84lj7SN26GrM75tOBbV0QwHRjxyiBxNfnAu98=; b=bAOObChKKt1px5WvUa/PzpThnamUyL+K5p9qd/mMa69MB3173COQw6oQHsIO+sYuUG 1IF9f/IKvJWKr8nKja+1ZppQWWIEifypscIjhKkpv3kY0tCwB5A2vHoN41CfOIrqT3HH UMCScN3PVV8HiYuUlUkhQb4L0tHH1Wa669y8+ihqSUUV5zM7mtXC6zQVi+rTQ+d86AXC YrX2/uVSMRV0O3AK2c3H3DlYzfFEBVm4j8gLzvfM4YQw7g+KTCTsf8BDfaF9KLAKfLz/ A5uaO1n0UcObVj1MYSL1W0EI71CO9pD9RGKveVn1capA0ZE4V3UbFAka3Og2XEN/f+pt 7Olg== 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=28jY7w84lj7SN26GrM75tOBbV0QwHRjxyiBxNfnAu98=; b=gIixfMPRvZX9xTfjCVShDoqQC2wkaVHF9my3h/GP16PtZq2Z7LBwCXRysEh7woVuqc kCymuKyUNm0bdhkLeGCgp2RP3BVlHSk0JHaV89TpqADtxsmiTR+DL2o7Vl790eTjoPhM voemdAhX/qe1GJy2X+dkpmmrx6DItt75lyI/XZdGss46eSJdnVrt1y+BjmBcpICCBtmM LgZ4PRqB5a5A+ssrW2y6/LCvnbYURN0dfhLFafD4fmFOGXHhZ5a1U1EVmlouoI1RqpaV T62Vhle9jM3sYkmK77vX4IBBn2iBVpA1iwUsvupPuKtivS0XFciTkbs4EmYjG0HNB6zd lJ0g== X-Gm-Message-State: AOAM530q1l0AXk0x26CfWnck84/Jevx/jnzTgw6fFrrCUhAoH30+Qi+X L5+AhER1Vwa8MG/2GF3yHA80txBOjVabDW7diFA= X-Google-Smtp-Source: ABdhPJwwf7qmfeUXJR/zqGG373EVykhsz/kEokfGgRIoaRbzHWGaMhg03+ZoH4HMy4x8F72fdu0ZvmDq/zjqsspc5oc= X-Received: by 2002:a25:5557:: with SMTP id j84mr32942423ybb.461.1596114861854; Thu, 30 Jul 2020 06:14:21 -0700 (PDT) MIME-Version: 1.0 References: <4937FCE4-23EF-4585-8675-C07F3B347AC6@cisco.com> In-Reply-To: From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Thu, 30 Jul 2020 16:13:09 +0300 Message-ID: To: "Salz, Rich" Cc: Watson Ladd , "Eric Wang (ejwang)" , Jen Linkova , OPSEC , OpSec Chairs , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 13:14:49 -0000 Peace, On Thu, Jul 30, 2020 at 3:33 PM Salz, Rich wrote: >> It is (in all but a couple of implementations I think) > a *proxy* that the origin has contracted with. Could > you please elaborate on your point? > > It has a TLS cert that identifies itself as the origin. It depends! In the majority of cases (i.e. delivering preseeded static content), no. It identifies as some-1337-garbage.static.example.com, which it basically *is*. The manner in which the content (hopefully uploaded by the origin via an end-to-end encrypted connection) propagates to edge nodes is then up to the implementation, and it is contained within the area of responsibility of the CDN operator. However, there's a minority of cases where a CDN is also used to deliver *dynamically generated* content which could not be cached, e.g. because it is only available to authenticated users. In this case, the CDN in fact impersonates the origin, processes all the authentication data, and the only way to implement that is proxying across different areas of responsibility. How's that different from what middleboxes are doing is not clear to me. Proxy is a proxy. There are various kind of proxies probably also doing something which is deemed useful to their owners and users, which doesn't relax the statement that such proxying is not endorsed by the IETF. The intent and purpose behind proxying are IMO in scope of model-t and are, accordingly, out of scope here. > How is it different from an origin that uses load-balancing to send you s= omewhere? Is www.facebook.com a CDN or intermediary, or is it the origin? Is www.facebook.com a Facebook-owned middlebox, or is it the endpoint server? (And this is *one* of the reasons I won't trust Facebook for anything sensitive!) Again, I think this is more of a topic for model-t. The main difference though is that the data crosses the boundary between the areas of responsibility in a way which is not transparent to me. It is a common approach to allow insecure connections over the Internet from the edge nodes to the origin, and I have no way of knowing if this is the case for the resource I'm currently using. There are also more subtle differences but I think I've long crossed the boundary of the off-topic area here myself! -- T=C3=B6ma From nobody Thu Jul 30 06:39: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 058A83A1157; Thu, 30 Jul 2020 06:39:20 -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, DKIMWL_WL_HIGH=-0.001, 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 ZVCOCfcvK-p8; Thu, 30 Jul 2020 06:39:16 -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 ACDAF3A1158; Thu, 30 Jul 2020 06:39:16 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id 06UDVl7A028441; Thu, 30 Jul 2020 14:39:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=uTzo5wYQVG5Z8f/bQlBpfdxZsCaq5KE/8ywlT6D41F0=; b=HzEZbOYJ7SSmSXSmeY6tAZb9aJLi7FF75TniTWatR2BVKf00pduCSD8ZGWvqhuriu57h XC4yhYjkxfKK0McCCDC1DLY8xYnZhDYVuVYLcJ570oAIivT7XjpeIaO0tnTscHlCMDX5 eHP4cd1mW8CKb49MIUBdyzpa/E4xaI0+u/hISCCwNqM/EigHNf1cF1dyDJXw4fE14adP m8qrvptrCNs0H/vT6cEyaeEa4lrwMzHFenDu+UMLaR9vZU62jQdYj/4u5UDocfWEjO3a 6dVez6JtGv4LOBfNGgUbcx7uEVD+tTloK42IbiAm2jGcsVL1Z7kfH7MNUhQh1WnZNbzH 4w== Received: from prod-mail-ppoint7 (a72-247-45-33.deploy.static.akamaitechnologies.com [72.247.45.33] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 32gc9db2p3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jul 2020 14:39:13 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.42/8.16.0.42) with SMTP id 06UDJbID020783; Thu, 30 Jul 2020 09:39:12 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint7.akamai.com with ESMTP id 32j464pj0y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 30 Jul 2020 09:39:12 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb4.msg.corp.akamai.com (172.27.165.122) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Jul 2020 08:39:12 -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; Thu, 30 Jul 2020 08:39:12 -0500 From: "Salz, Rich" To: =?utf-8?B?VMO2bWEgR2F2cmljaGVua292?= CC: Watson Ladd , "Eric Wang (ejwang)" , Jen Linkova , OPSEC , OpSec Chairs , "tls@ietf.org" Thread-Topic: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AdZd8qs4MVhjKcpfSaSC3eC5PK0rEQCv6iMAAH8Fd4AAUf7RAABaakYAAA6JtwAAPo6TAP//wx4AgABOLID//8Q2AA== Date: Thu, 30 Jul 2020 13:39:11 +0000 Message-ID: <2D916A08-8C24-4BED-8F8A-4DD04B9B1B0F@akamai.com> References: <4937FCE4-23EF-4585-8675-C07F3B347AC6@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.61] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-30_10:2020-07-30, 2020-07-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 spamscore=0 mlxscore=0 adultscore=0 suspectscore=0 phishscore=0 malwarescore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007300097 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-30_10:2020-07-30, 2020-07-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 bulkscore=0 impostorscore=0 mlxscore=0 adultscore=0 spamscore=0 priorityscore=1501 lowpriorityscore=0 phishscore=0 malwarescore=0 suspectscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007300099 Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 13:39:20 -0000 PiAgICBJbiB0aGUgbWFqb3JpdHkgb2YgY2FzZXMgKGkuZS4gZGVsaXZlcmluZyBwcmVzZWVkZWQg c3RhdGljIGNvbnRlbnQpLA0KICAgIG5vLiBJdCBpZGVudGlmaWVzIGFzIHNvbWUtMTMzNy1nYXJi YWdlLnN0YXRpYy5leGFtcGxlLmNvbSwgd2hpY2ggaXQNCiAgICBiYXNpY2FsbHkgKmlzKi4NCg0K Tm8uICBUaGF0IG1pZ2h0IGJlIHRoZSBETlMgbmFtZSwgYnV0IGl0IGlzIG5vdCB0aGUgVExTIGNl cnRpZmljYXRlIHRoYXQgdGhlIHNlcnZlciBwcmVzZW50cy4gVGhhdCBjZXJ0aWZpY2F0ZSBNVVNU IGhhdmUgYSBuYW1lIHRoYXQgbWF0Y2hlcyB0aGUgb3JpZ2luYWwgbmFtZSB0aGF0IHRoZSBjbGll bnQgKGJyb3dzZXIsIG9mdGVuKSBwcmVzZW50LiBUaGF0J3MgZnVuZGFtZW50YWwuDQoNCj4gICAg SG93ZXZlciwgdGhlcmUncyBhIG1pbm9yaXR5IG9mIGNhc2VzIHdoZXJlIGEgQ0ROIGlzIGFsc28g dXNlZCB0bw0KICAgIGRlbGl2ZXIgKmR5bmFtaWNhbGx5IGdlbmVyYXRlZCogY29udGVudCB3aGlj aCBjb3VsZCBub3QgYmUgY2FjaGVkLA0KICAgIGUuZy4gYmVjYXVzZSBpdCBpcyBvbmx5IGF2YWls YWJsZSB0byBhdXRoZW50aWNhdGVkIHVzZXJzLiAgSW4gdGhpcw0KICAgIGNhc2UsIHRoZSBDRE4g aW4gZmFjdCBpbXBlcnNvbmF0ZXMgdGhlIG9yaWdpbiwgcHJvY2Vzc2VzIGFsbCB0aGUNCiAgICBh dXRoZW50aWNhdGlvbiBkYXRhLCBhbmQgdGhlIG9ubHkgd2F5IHRvIGltcGxlbWVudCB0aGF0IGlz IHByb3h5aW5nDQogICAgYWNyb3NzIGRpZmZlcmVudCBhcmVhcyBvZiByZXNwb25zaWJpbGl0eS4g IEhvdydzIHRoYXQgZGlmZmVyZW50IGZyb20NCiAgICB3aGF0IG1pZGRsZWJveGVzIGFyZSBkb2lu ZyBpcyBub3QgY2xlYXIgdG8gbWUuDQoNCkNETidzIGFsc28gZG8gdGhpbmdzIGxpa2UgQVBJIGdh dGV3YXlzLCBCT1QgZGV0ZWN0aW9uLCBldGMuICBJbiBzb21lIGNhc2VzLCB0aGUgZHluYW1pYyB0 cmFmZmljIG1hbmlwdWxhdGlvbiBpcyBtb3JlIGluIGVpdGhlciBieXRlcyBvciBjb25uZWN0aW9u cy4NCkNvbnNpZGVyIHRoaXMgY29uZmlndXJhdGlvbiBpbiBhIGZha2UgbGFuZ3VhZ2UNCgk8bWF0 Y2ggY29uZD0idXNpbmctd2Vhay1jaXBoZXIoKSI+DQoJCTxyZWRpcmVjdD4vZ2V0L2JldHRlci9i cm93c2VyLmh0bWw8L3JlZGlyZWN0Pg0KCTwvbWF0Y2g+DQoNCldoZXJlIGRvZXMgdGhpcyBmYWxs Pw0KDQpJIGFncmVlIHRoYXQgaWYgZXhhbXBsZS5jb20gaGlyZXMgYSBDRE4gb3IgZGVwbG95cyBh IG1pZGRsZWJveCB0byBkbyB0aG9zZSB0aGluZ3MsIHRoZXJlIGlzIG5vIGRpZmZlcmVuY2UuDQoN Cj4gICAgUHJveHkgaXMgYSBwcm94eS4NCg0KVGhhdCdzIHRvbyBzaW1wbGlzdGljLiBXZSBoYXZl IGEgcHJvZHVjdCwgc2l0ZSBzaGllbGQsIHRoYXQgY3VzdG9tZXJzIGNhbiB1c2UgdG8gbGltaXQg dGhlIElQIGFkZHJlc3NlcyBvZiB3aG8gY2FuIHJlYWNoIHRoZWlyIG9yaWdpbiBzZXJ2ZXIuICBF dmVyeW9uZSBlbHNlIGlzIGJsb2NrZWQuIFNvbWUgdXNlIHRoYXQgdG8gbWFrZSBzdXJlIHRoYXQg Km9ubHkqIEFrYW1haSBzZXJ2ZXJzIHdpbGwgdGFsayB0byB0aGVtLCBhbmQgdGhhdCBldmVyeXRo aW5nIGVsc2UgZ29lcyB0aHJvdWdoIHVzLiAgSXMgdGhhdCBhIHByb3h5PyBIb3cgaXMgaXQgZGlm ZmVyZW50IGZyb20gdGVybWluYXRpbmcgVExTIGluIHRoZSBETVogYW5kIHNlbmRpbmcgaXQgaW5z aWRlPyBIb3cgZG9lcyB0aGUgY2xpZW50IGtub3c/DQoNCj5pcyAuLi4gIGEgRmFjZWJvb2stb3du ZWQgbWlkZGxlYm94LCBvciBpcyBpdCB0aGUgZW5kcG9pbnQNCiAgICBzZXJ2ZXI/DQoNCldoYXQg aXMgdGhlIGVuZHBvaW50IHNlcnZlciwgaWYgZmFjZWJvb2sgc2VuZHMgeW91IHRoZXJlPw0KDQo+ ICAgIFRoZSBtYWluIGRpZmZlcmVuY2UgdGhvdWdoIGlzIHRoYXQgdGhlIGRhdGEgY3Jvc3NlcyB0 aGUgYm91bmRhcnkNCiAgICBiZXR3ZWVuIHRoZSBhcmVhcyBvZiByZXNwb25zaWJpbGl0eSBpbiBh IHdheSB3aGljaCBpcyBub3QgdHJhbnNwYXJlbnQNCiAgICB0byBtZS4gDQoNCkFuZCBteSBwb2lu dCBpcyB0aGF0IHRoZXJlIGlzIG5vIHN1Y2ggYm91bmRhcnkuIE9yIHBlcmhhcHMgbW9yZSBhY2N1 cmF0ZWx5LCBpdCBpcyBhIGJhcnJpZXIgdGhhdCB0aGV5IGRvbid0IHdhbnQgIHlvdSB0byBzZWUu IEp1c3QgbGlrZSB0aGV5IG1pZ2h0IG5vdCB3YW50IHlvdSB0byBrbm93IGFib3V0IHRoZSBETVog YW5kIGludGVyaW9yIG5ldHdvcmssIHdoaWNoIGFyZSBvZnRlbiBydW4gYnkgZGlmZmVyZW50IG9y Z2FuaXphdGlvbnMgaW5zaWRlIHRoZSBjb3Jwb3JhdGlvbi4NCg0KDQoNCg== From nobody Thu Jul 30 07:57: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 AE2103A0528; Thu, 30 Jul 2020 07:57:35 -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 BOEZf8XjIqII; Thu, 30 Jul 2020 07:57:33 -0700 (PDT) Received: from mail-yb1-xb41.google.com (mail-yb1-xb41.google.com [IPv6:2607:f8b0:4864:20::b41]) (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 ECFDF3A0796; Thu, 30 Jul 2020 07:56:57 -0700 (PDT) Received: by mail-yb1-xb41.google.com with SMTP id c18so7163843ybr.1; Thu, 30 Jul 2020 07:56:57 -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=N/gheHoS4imCYLehim/GTLr//GfMVTVlh86eFfYgzlc=; b=etjGwKP7aWyZLP0N4s1YeMpmMigpStIGXFZmo5IHDHvvpwdkqAxcAOwPmV2wB33WmD zckl2hg83s3jpjQSVIpg1IxEBmjrlG9APJapE/34nA4BEeZaP+c9wZ1fJ0dbrGnZLIib MtLnDSUeoOVVBJ1S4aJ0jgHRfTps97zI0cMEe/WJcK1M7lTqmuLihOeofyyJPtnvH9L7 sUpByccg++PPEZ/rIACnfyZ10JLtpQo2n6ikO75kiPzqRLeQzY+l4RzPvamN4ySP0fCz F5x3bhkOof00IDaLgHuovGity9UVjaXTIyfCHKU8ZLbPDdv30sx3IefAesDu8lX1O+06 V3gA== 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=N/gheHoS4imCYLehim/GTLr//GfMVTVlh86eFfYgzlc=; b=lfNdwPimne4MxNECMyYJDuixKDGKK8jMOZvjUMrtY0PiIA6+Xpxteje9HFYi/K7Q5d 7WcWrHLqFFs99BdJP7DkQuxSTqubeKa0iWUR1ycmQRTfydhvVfeLIjl6k9ZAAKVFfKV6 WmnqtACB8a1UASRUYGhjbDAcArcx9N7cOoQEc5Zzx5K/OhXvpmxfZsbsUIn6r+2/AD1H S+onTgAYZwwUc1KLWvrPn076sKMOtdMI2qDHTI1ZAS1T4PRXtIn7xWln9Pj3P9/Dfyc7 Jv40FaIzkmlk9lXrXQkStST9PMKyBcM2vRHvhsB74xthgLveO8nj+atlfMCj66CRZssX 9vRg== X-Gm-Message-State: AOAM532gBTXYgkYPx1YdKUe4SO2UeVAf1ChnrXCK3d00puZIKZ6Ur6cy SrlIlQrCI4Bk2vSNvKw28W94SRF82F5e9xdXGGc= X-Google-Smtp-Source: ABdhPJzXyAe+P4D6aN5Vzza4yRv0+GT4y9XcK1GfKjcpjTJXcAZhI44ReKR0srl+uM0voivfv3yBbwqnl8JiRGfP6PY= X-Received: by 2002:a25:be45:: with SMTP id d5mr5212018ybm.444.1596121016910; Thu, 30 Jul 2020 07:56:56 -0700 (PDT) MIME-Version: 1.0 References: <4937FCE4-23EF-4585-8675-C07F3B347AC6@cisco.com> <2D916A08-8C24-4BED-8F8A-4DD04B9B1B0F@akamai.com> In-Reply-To: <2D916A08-8C24-4BED-8F8A-4DD04B9B1B0F@akamai.com> From: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Date: Thu, 30 Jul 2020 17:56:44 +0300 Message-ID: To: "Salz, Rich" Cc: Watson Ladd , "Eric Wang (ejwang)" , Jen Linkova , OPSEC , OpSec Chairs , "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003b466405aba9e2cc" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 14:57:36 -0000 --0000000000003b466405aba9e2cc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Peace, On Thu, Jul 30, 2020, 4:39 PM Salz, Rich wrote: > We have a product, site shield, that customers can use to limit the IP > addresses of who can reach their origin server. Everyone else is blocked= . > Some use that to make sure that *only* Akamai servers will talk to them, > and that everything else goes through us. Is that a proxy? How is it > different from terminating TLS in the DMZ and sending it inside? How does > the client know? > I don't know, and this *is* the problem. I may be connecting to the service from a network I don't trust with my information, and I have (almost) no tool to tell me whether it is served from a different network via a secure connection *or* it is served from an edge node deployed *in the same network I don't trust*, that node being connected to the service through an unauthenticated channel. Like in [1], where this unauthenticated channel is being marketed as "end-to-end encryption". This approach basically defies all the end-to-end encryption efforts. When it comes to static content, with all the JS security implemented, this is mostly fine. Dynamic content is a very different story. [1] https://support.cloudflare.com/hc/en-us/articles/200170416-End-to-end-HTTPS= -with-Cloudflare-Part-3-SSL-options -- T=C3=B6ma > --0000000000003b466405aba9e2cc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Peace,

On Thu, Jul 30, 2020, 4:39 PM Salz, Rich <rsalz@akamai.com> wrote:
We have a product, site shield, that customers ca= n use to limit the IP addresses of who can reach their origin server.=C2=A0= Everyone else is blocked. Some use that to make sure that *only* Akamai se= rvers will talk to them, and that everything else goes through us.=C2=A0 Is= that a proxy? How is it different from terminating TLS in the DMZ and send= ing it inside? How does the client know?

I don't know, and this *is* the= problem.

I may be conne= cting to the service from a network I don't trust with my information, = and I have (almost) no tool to tell me whether it is served from a differen= t network via a secure connection *or* it is served from an edge node deplo= yed *in the same network I don't trust*, that node being connected to t= he service through an unauthenticated channel.

<= /div>
Like in [1], where this unauthenticated channel is b= eing marketed as "end-to-end encryption".=C2=A0 This approach bas= ically defies all the end-to-end encryption efforts.

When it comes to static content, with all the = JS security implemented, this is mostly fine.=C2=A0 Dynamic content is a ve= ry different story.


--
T=C3=B6ma
--0000000000003b466405aba9e2cc-- From nobody Thu Jul 30 08:18: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 63CEF3A094F for ; Thu, 30 Jul 2020 08:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=unavailable 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 JlCf_k_IxZEe for ; Thu, 30 Jul 2020 08:18:14 -0700 (PDT) Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 F17863A093B for ; Thu, 30 Jul 2020 08:18:13 -0700 (PDT) Received: by mail-ot1-x335.google.com with SMTP id p25so10983841oto.6 for ; Thu, 30 Jul 2020 08:18:13 -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 :cc; bh=qyi38KYkImN6F9WBfGDg5gZxkyWBlaoGFLeUXgHt9PI=; b=EBApBnu1y2G5B1U813auJMlaFXWPKfOOET6L/iDnHZUSF18piHjhHHBu11gxOvoM7m 6zdJxF5dI+6ecT2VRLgoA+h6JzSeDYnB6rQ+f8J86kuBrOdp7IQCUTUk5sE+/1HVuJMG 0jBOAZpK0o5tIMXXrcHCA11DQCnqj/dm4HzzOghu/D67COrmuDCvlBegh7hgWCLtHg2L ZvscYv52QX++FOGfbsi8ppUCfrlt9qU3CV996V+Td7j3EgAj7o8rtYC0TEsjRSZyurYq NMxJOCDr3HtyHW8m14UkBKsrKvHwhlOEkxOCksL9iDuJL4uwrB8Br11UsFmhNO9Iwy6c JYdA== 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=qyi38KYkImN6F9WBfGDg5gZxkyWBlaoGFLeUXgHt9PI=; b=Autgd8jGX39QP/A54oRINVIM/LNgGJWH8aBh6U8vx3M4OcUDDKar7PbGaV3/Gg+n8H +z9BNG4k5CYYawZWNovWacgg4KMsZKNkvQ9ZAn2hX9QEea4iw7N22UUWrar5hDp0gsw1 3ih7HcBa3rNJUoLHyMYXeMFdbGVqI2fJq6SmntPfb/7E2iVfRTvorazvQrom2UBbVubX +29iam1SeAXraoSaL16OIu+GT8FwKTQW3t/mLGEV7ITgtUO52oNSinW/6USXqtWQSVWJ cxzj1c3U9Rza/X4WokuMVkIac8KUcgRQHrw1lb39aH7qOtwiv2emXLxIwJKAvizphShf YiGA== X-Gm-Message-State: AOAM532KiVZK1a8RVqYqH8xNbyXgcU7XlQ0Uk54WsBL0AB3zmYV8IwFr lrgwgP8PFoqAp/kZiayMrlPocxgxGjS5ZNcNptMegw== X-Google-Smtp-Source: ABdhPJx/LQqtFF1X5Py7CwKadg6LFqsQcheCY4kk03iyFDsbkwzd2QKXgkOknWtiSWmvU6k6ubJHc1K51V+gq9YY4pE= X-Received: by 2002:a05:6830:1d6c:: with SMTP id l12mr2622454oti.275.1596122292876; Thu, 30 Jul 2020 08:18:12 -0700 (PDT) MIME-Version: 1.0 References: <4937FCE4-23EF-4585-8675-C07F3B347AC6@cisco.com> <2D916A08-8C24-4BED-8F8A-4DD04B9B1B0F@akamai.com> In-Reply-To: From: Nick Harper Date: Thu, 30 Jul 2020 08:18:01 -0700 Message-ID: To: =?UTF-8?Q?T=C3=B6ma_Gavrichenkov?= Cc: "Salz, Rich" , Jen Linkova , OPSEC , "tls@ietf.org" , OpSec Chairs Content-Type: multipart/alternative; boundary="00000000000049530f05abaa2e19" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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 Jul 2020 15:18:17 -0000 --00000000000049530f05abaa2e19 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 30, 2020 at 7:58 AM T=C3=B6ma Gavrichenkov = wrote: > Peace, > > On Thu, Jul 30, 2020, 4:39 PM Salz, Rich wrote: > >> We have a product, site shield, that customers can use to limit the IP >> addresses of who can reach their origin server. Everyone else is blocke= d. >> Some use that to make sure that *only* Akamai servers will talk to them, >> and that everything else goes through us. Is that a proxy? How is it >> different from terminating TLS in the DMZ and sending it inside? How doe= s >> the client know? >> > > I don't know, and this *is* the problem. > The point is, whatever server/device has a publicly trusted certificate for a domain name is authoritative for that domain. That server can get the content it serves (whether dynamic or static) from any source. TLS only provides guarantees about the connection between the client and server. It says nothing about whether the content served was obtained or generated in some secure manner. That content could be sourced locally, it could be aggregated or generated from other servers via connections over other secure protocols that aren't TLS, it could even come from some insecure source like transmitting an audio stream collected from an antenna connected to the server. I may be connecting to the service from a network I don't trust with my > information, and I have (almost) no tool to tell me whether it is served > from a different network via a secure connection *or* it is served from a= n > edge node deployed *in the same network I don't trust*, that node being > connected to the service through an unauthenticated channel. > If you're connecting to a service, at some point you have to trust that the service operator is running it in a reasonable way. TLS only tells you that your connection to the server is secure - it tells you nothing about the provenance of the content served, and even if such a mechanism exists (I am not advocating that such a thing should exist), the server can always claim that it generated it instead of that it got it from somewhere else. > > Like in [1], where this unauthenticated channel is being marketed as > "end-to-end encryption". This approach basically defies all the end-to-e= nd > encryption efforts. > > When it comes to static content, with all the JS security implemented, > this is mostly fine. Dynamic content is a very different story. > > [1] > https://support.cloudflare.com/hc/en-us/articles/200170416-End-to-end-HTT= PS-with-Cloudflare-Part-3-SSL-options > > -- > T=C3=B6ma > >> _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000049530f05abaa2e19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jul 30, 2020 at 7:58 AM T=C3= =B6ma Gavrichenkov <ximaera@gmail.c= om> wrote:
Peace,

On Thu, Jul 30, 2020, 4:39 PM Salz, Rich <= rsalz@akamai.com&= gt; wrote:
We have a= product, site shield, that customers can use to limit the IP addresses of = who can reach their origin server.=C2=A0 Everyone else is blocked. Some use= that to make sure that *only* Akamai servers will talk to them, and that e= verything else goes through us.=C2=A0 Is that a proxy? How is it different = from terminating TLS in the DMZ and sending it inside? How does the client = know?

I don't know, and this *is* the problem.
<= div>
The point is, whatever server/device has a publicly trus= ted certificate for a domain name is authoritative for that domain. That se= rver can get the content it serves (whether dynamic or static) from any sou= rce. TLS only provides guarantees about the connection between the client a= nd server. It says nothing about whether the content served was obtained or= generated in some secure manner. That content could be sourced locally, it= could be aggregated or generated from other servers via connections over o= ther secure protocols that aren't TLS, it could even come from some ins= ecure source like transmitting an audio stream collected from an antenna co= nnected to the server.

I may be connecting to the service from a network I don't trust with= my information, and I have (almost) no tool to tell me whether it is serve= d from a different network via a secure connection *or* it is served from a= n edge node deployed *in the same network I don't trust*, that node bei= ng connected to the service through an unauthenticated channel.
=

If you're connecting to a service, at = some point you have to trust that the service operator is running it in a r= easonable way. TLS only tells you that your connection to the server is sec= ure - it tells you nothing about the provenance of the content served, and = even if such a mechanism exists (I am not advocating that such a thing shou= ld exist), the server can always claim that it generated it instead of that= it got it from somewhere else.

Like in [1], where this unauthenticated channel is being marketed as "= ;end-to-end encryption".=C2=A0 This approach basically defies all the = end-to-end encryption efforts.

When it comes to static content, with all the JS security implemente= d, this is mostly fine.=C2=A0 Dynamic content is a very different story.


--
T=C3=B6ma
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000049530f05abaa2e19-- From onoketa@iyouport.org Thu Jul 30 08:46: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 AFB0B3A0A9E for ; Thu, 30 Jul 2020 08:46:01 -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, HTML_MESSAGE=0.001, 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=iyouport.org 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 nvr5_5XeQ1o7 for ; Thu, 30 Jul 2020 08:45:59 -0700 (PDT) Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) (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 965713A0AB0 for ; Thu, 30 Jul 2020 08:45:59 -0700 (PDT) Date: Thu, 30 Jul 2020 15:45:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iyouport.org; s=protonmail; t=1596123957; bh=fxdL1smBW4pT2rcPfPxhk4esCe1B9za6eZox3ubfVNA=; h=Date:To:From:Reply-To:Subject:From; b=N4JPdmHnQNmbCJj4Hj5d8768g5tvR00UjDYx/bo+wW5NtioDfZB9aVljkCdVyOrH5 biUDoggXksiuOm7T1nVDGz2ETQT9YgQQYacz1ThpiqgOPVw9IN38WuGRXsYt22AVgo Pc2f7w2fHqNWjaK+8Sf37YL87hEXVwZ8tvW9PAEA= To: "tls@ietf.org" From: onoketa Reply-To: onoketa Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha256; boundary="---------------------40de9e46b8694b32d32718bc06e6aadf"; charset=utf-8 Archived-At: Subject: [TLS] Possible blocking of Encrypted SNI extension in China 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 Jul 2020 16:26:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------40de9e46b8694b32d32718bc06e6aadf Content-Type: multipart/mixed;boundary=---------------------3094fe9dff71aac214b628a56d35498c -----------------------3094fe9dff71aac214b628a56d35498c Content-Type: multipart/alternative;boundary=---------------------98d1a3c72d14b037a803b2827faa0d12 -----------------------98d1a3c72d14b037a803b2827faa0d12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain;charset=utf-8 Hi, The Great Firewall of China may have identified and blocked Cloudflare's E= SNI implementation. I have found that when using a TLS client hello with ESNI extension to con= nect to servers behind Cloudflare's CDN, the connection will be cut off af= ter the whole TLS handshake is done. And then that IP address will be bloc= ked at the TCP level for several minutes. onoketa -----------------------98d1a3c72d14b037a803b2827faa0d12 Content-Type: multipart/related;boundary=---------------------3b0eee659445934ba0b5a43c92f28532 -----------------------3b0eee659445934ba0b5a43c92f28532 Content-Type: text/html;charset=utf-8 Content-Transfer-Encoding: base64 PGRpdj5IaSw8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgR3JlYXQgRmlyZXdhbGwg b2YgQ2hpbmEgbWF5IGhhdmUgaWRlbnRpZmllZCBhbmQgYmxvY2tlZCBDbG91ZGZsYXJlJ3MgRVNO SSBpbXBsZW1lbnRhdGlvbi48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIGhhdmUgZm91 bmQgdGhhdCB3aGVuIHVzaW5nIGEgVExTIGNsaWVudCBoZWxsbyB3aXRoIEVTTkkgZXh0ZW5zaW9u IHRvIGNvbm5lY3QgdG8gc2VydmVycyBiZWhpbmQgQ2xvdWRmbGFyZSdzIENETiwgdGhlIGNvbm5l Y3Rpb24gd2lsbCBiZSBjdXQgb2ZmIGFmdGVyIHRoZSB3aG9sZSBUTFMgaGFuZHNoYWtlIGlzIGRv bmUuIEFuZCB0aGVuIHRoYXQgSVAgYWRkcmVzcyB3aWxsIGJlIGJsb2NrZWQgYXQgdGhlIFRDUCBs ZXZlbCBmb3Igc2V2ZXJhbCBtaW51dGVzLjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pm9u b2tldGE8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+ -----------------------3b0eee659445934ba0b5a43c92f28532-- -----------------------98d1a3c72d14b037a803b2827faa0d12-- -----------------------3094fe9dff71aac214b628a56d35498c Content-Type: application/pgp-keys; filename="publickey - onoketa@iyouport.org - 0xC34EA268.asc"; name="publickey - onoketa@iyouport.org - 0xC34EA268.asc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="publickey - onoketa@iyouport.org - 0xC34EA268.asc"; name="publickey - onoketa@iyouport.org - 0xC34EA268.asc" LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQpWZXJzaW9uOiBPcGVuUEdQLmpz IHY0LjEwLjcNCkNvbW1lbnQ6IGh0dHBzOi8vb3BlbnBncGpzLm9yZw0KDQp4c0JOQkYzcHREa0JD QURlcit3K3lRYkQ3MWFIRzFKZHpNOFVRNDNGOWxVK21KbTUzdSticlJHb1E4a0kNCkFBSm1uaE5m VVNoQkUrZnBHTUtmQnZydFB5eFVZaytubzh5VEdpMDc4Tk1XdTNlZ3J1VGxad3JGdUtRYw0KM0Z5 TW9rQjFLWVcxSFZaM3FSci9oZVBLUEVrK3RDcmRzcFNKQjJabGtGTkRiYkJlT2JsUjJJMW0wY20x DQpzOEdBNHNoM3JEdHNhb1BnS0Robk44VDJnN08rQjBOZk9sMFZBbTdUOVVnclhkRDVZY2gxQkJh Y1NTcS8NCmhNZnIzTzZPYzFKakQxcDZkcjlyZE5IM0xydmw4UDEvMzFFOW1tNHR1Zmo0Tk9vSmll anJsOHNNWjFxcQ0KL0pJNXpycndhNGp6Yld3UVJScExUbFh3Vk5KRGNNK0NVZFdLUDR2dnRqMms1 OWlwL2FMM3N5bERBQkVCDQpBQUhOSzI5dWIydGxkR0ZBYVhsdmRYQnZjblF1YjNKbklEeHZibTly WlhSaFFHbDViM1Z3YjNKMExtOXkNClp6N0N3SFVFRUFFSUFCOEZBbDNwdERrR0N3a0hDQU1DQkJV SUNnSURGZ0lCQWhrQkFoc0RBaDRCQUFvSg0KRVBreVNjR3YwVkdXZ1hvSC9qSDZUcFFKTzQrLyt3 UTk0amh5N3g1ZGxnUFRCWmNnalFORUZoN0FydEJFDQplclkrYTYxaEZKNzdTY2tlUURJMTFTc1Bi NUVLdFE0bnpkczdwMHo0WDJreEtvVlFLaUVSdzY2aVdONTgNClJCUVhsNWZWU2ZwdG16R2dlbVRz WnNMS0ZJTDU0MitKcEtEcVJPWTlLUE9JS2xCRk4rWmtyUlNxeE1WNg0KZEorSXA1dUZ6c1JsTWgr R1BzR0NLaU5JMHlEblRIREpxTjBQUW1hZ3NVUGk3MVo2UWs4dkF2Tys0TFBiDQp0c3FaUDhQSTdM b1dYVTJ0aGFLaW5ub21LUnlNdjdkN1k1dmN1Zm1KSXBtWCtPTlEzVGxmWFFnVzcvbW0NCmNUSDJ6 WFZTeW9UU2xGVmZKSmVKbCtmZ1I3RGtnSnNaTEtodGt2YnZCZjE3NW9MRnRia0dnK1VCZW8vTw0K d0UwRVhlbTBPUUVJQUxBY0V1dTJLSGdTVTMxSHpYSWM4ZGtBWUpZbW1QQWNMMzJCQlltSFgyS2Fx UGdMDQpKcjZzOTJSOEtybU9oc2JhcVZXKzhFSUFWYkZBNDN0czk1aHNOUXp5SE10TGZBUjErQXFX WUExbzVwRHANCi83ZE5MRThObTAyRmQ5VUdHa2lUVEZCWWxFczlmc012SW9PdmhpVXUwVEhndE05 L2NJc1V3VnpEalBNVQ0KeHVDUzM4RHJaNXBxdTZldHRIdTJCbVQ2eGlaK1QxVi90UVU1bUpGdHRJ ZmpvUDlveEZZbnFFbExpdG91DQpDVHBFQXZNRFFDNHN4RDdjdDNUdng0T2lVRnNqYmppa1BjR2NB eFdzYTdqd1BkU0Z1UndKSGIwY1IvbXENCkczV2xnUG1na3VHMUZWTlpNRHFXT0wyOGNIL2VTWVl4 TjYzN2dYZjB4UkdXVDlYL01sZXdGNXNBRVFFQQ0KQWNMQVh3UVlBUWdBQ1FVQ1hlbTBPUUliREFB S0NSRDVNa25CcjlGUmxzNjhDQUNhdTlIZ05FbUs4Z1BhDQpzNTRIVWlnOUI4VlhhVWozR3dBNUdP TEJ6MU41cm5sdUNhRTMzQ014VGt5eEtZVFJsUC9JWEhScE5Sa3UNCnZsa0FaS3A3Q1VVd0FRMnZZ MTdFQmltVVBHWXFreDBGenUrS01xZXdvRk9LczlEemJQUmpOWjVpRDlNZg0Kb0o5UTM1UnZsSkFm WDFOam94NVgvTTJ6NjBhS1FtSStkQW9IVW1uYVVPeXFNSmVkZDNCeC9mSVRuTVZ3DQpLMU91Tk12 cDFmWG54QytXOGNLa2tSRG92N3RHYmM4U2hvRER6QWxhdDBOaFRqMTNLSGVwNklWTGR5M3oNCjNM QmpPTFNSdEx1dW5PYTNuZHRWcVMwTm16NWR6c2RTWEZtbGJMNmlUSzJlRjhYRGs2T3dWdmJKQ2RS TQ0KYW9rVTJDKy9VMmNadlgvMW14TE93RVIrNFNuVg0KPTVISnINCi0tLS0tRU5EIFBHUCBQVUJM SUMgS0VZIEJMT0NLLS0tLS0NCg== -----------------------3094fe9dff71aac214b628a56d35498c-- -----------------------40de9e46b8694b32d32718bc06e6aadf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: ProtonMail wsBzBAEBCAAGBQJfIusoACEJEPkyScGv0VGWFiEEw06iaHEUCwrPiFl8+TJJ wa/RUZYIsgf+Om4+Ra+AcPEmUBepz6arsDoqKf062t7e07CPFPYOy8RzFjGn mnZf/CsBvooa5CI+czSGs35URZWy0bHEXO7oNfIocfYhlDoQr9q14DJZxh5k fHZyqYpnOgY3kGBkIyEEEhYznJqXjBAKnFtmJq6c64zHxr38erxuIeFvw76K ojy8DPglh0QlKdWw+K2r2Iut+FIEECDqGLpQF7XOAFap1cHG4PPRmzTgnasb KXSShzXJG8OvS4h7ITA33YkJNNlGbmFQ5b6rNL6M0DCymm+SaVaCYzImzWZF mpARLOH3Sclt4xl2Pq6B67/Op3r6imuTzFBn/j8894bXo75vjZtQBg== =3cIU -----END PGP SIGNATURE----- -----------------------40de9e46b8694b32d32718bc06e6aadf-- From nobody Thu Jul 30 11:17: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 00FA53A10D4 for ; Thu, 30 Jul 2020 11:17:13 -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, NICE_REPLY_A=-0.001, 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 6np0EgQE1vFz for ; Thu, 30 Jul 2020 11:17:11 -0700 (PDT) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 574F23A10D2 for ; Thu, 30 Jul 2020 11:17:11 -0700 (PDT) Received: from xse403.mail2web.com ([66.113.197.149] helo=xse.mail2web.com) by mx13.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1k1D72-0008PP-RN for tls@ietf.org; Thu, 30 Jul 2020 20:17:07 +0200 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4BHdsp3MHpzDGJ for ; Thu, 30 Jul 2020 11:17:02 -0700 (PDT) Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1k1D70-0002JJ-Bd for tls@ietf.org; Thu, 30 Jul 2020 11:17:02 -0700 Received: (qmail 28955 invoked from network); 30 Jul 2020 18:17:02 -0000 Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.14]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 30 Jul 2020 18:17:01 -0000 To: onoketa , "tls@ietf.org" References: From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH Message-ID: <71e4d18d-9ad8-fd72-729c-db5a0cf7593b@huitema.net> Date: Thu, 30 Jul 2020 11:16:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dXheD7iFMrHJeTpO5LePFGvXd5rgnpejM" X-Originating-IP: 66.113.197.149 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Z5BfDU3z1JRwSLH8/hgjJupSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDoOWO0i/H75teRGzF9TgV+efH zJ6mVE7ewsipSVIfs4bkPGNfjOeg7Wmc4+9EpxPHgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+drtT1wK6ppwERo35un0Ie1mdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdLn4jABaJqtNDIuGYj2WGeveXgFMyx0sD4hRS2uyMFprER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnFWB11dhDcan IFpyAO2lFVu7nh8N8M+WXoHXpIPrYDFDo8MMkTk98hF/ohyfoGYmVj58/Y/30hCyp3SuDPRAaFzv 5pWb82qAoDl3ILGSF0vmDvI0DEihOd7XzCAIcFZdY11677oPXF7r5zsW33ZNliqQWXiK63IBlEyx 50xFFL1+8y9Ga5iCmdJFIvDEJb+pKRqf27VeHOkXe82afzWlDIu/I2lY1QUnic/WPwVbyyG9HHAS JNUmoOHSoqgqxfHmWRWcrRhLeB34s3hUb32GO+2OAWL7bjyAZ/2SwZYMexRW08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [TLS] Possible blocking of Encrypted SNI extension in China 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 Jul 2020 18:17:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dXheD7iFMrHJeTpO5LePFGvXd5rgnpejM Content-Type: multipart/mixed; boundary="OIrYvc837M3ABV5bBrCQepTgi7k7jQCUh"; protected-headers="v1" From: Christian Huitema To: onoketa , "tls@ietf.org" Message-ID: <71e4d18d-9ad8-fd72-729c-db5a0cf7593b@huitema.net> Subject: Re: [TLS] Possible blocking of Encrypted SNI extension in China References: In-Reply-To: --OIrYvc837M3ABV5bBrCQepTgi7k7jQCUh Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 7/30/2020 8:45 AM, onoketa wrote: > Hi, > > The Great Firewall of China may have identified and blocked > Cloudflare's ESNI implementation. > > I have found that when using a TLS client hello with ESNI extension to > connect to servers behind Cloudflare's CDN, the connection will be cut > off after the whole TLS handshake is done. And then that IP address > will be blocked at the TCP level for several minutes. Thanks for the report. I think this relates to our ambivalence about the requirement for ESNI to not "stick out". That requirement is hard to meet, and designs have drifted towards an acceptation that it is OK to stick out as long as a sufficiently large share of the traffic does it. If that share is large, goes the reasoning, it would be too costly for censors to just "drop everything that looks like ESNI". Well, given actors like the Great Firewall, one wonders. -- Christian Huitema --OIrYvc837M3ABV5bBrCQepTgi7k7jQCUh-- --dXheD7iFMrHJeTpO5LePFGvXd5rgnpejM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQTDcbg3CLhASkABdRQQsCaooFi0lAUCXyMOkgAKCRAQsCaooFi0 lKpdAP41Oky3kWEcEFf5YEUEkw7OaKwJ8zwhg1QPW8vSNdC/yAEA89+252ISwsWc rPXn8BnRbpOyZ6QBHZNWQRLR6deymg0= =E5lv -----END PGP SIGNATURE----- --dXheD7iFMrHJeTpO5LePFGvXd5rgnpejM-- From nobody Fri Jul 31 07:21: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 2F1983A0E01 for ; Fri, 31 Jul 2020 07:21:26 -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=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 5jpXUl6amqNO for ; Fri, 31 Jul 2020 07:21:22 -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 A9D013A0BCD for ; Fri, 31 Jul 2020 07:21:21 -0700 (PDT) Received: from smtpauth2.mailarray.34sp.com (lvs5.34sp.com [46.183.13.73]) by 5.smtp.34sp.com (Postfix) with ESMTPS id 966A62C1CCD for ; Fri, 31 Jul 2020 15:21:13 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bensmyth.com; s=dkim; t=1596205273; bh=O7V4tLoobvoTz7RV7W/XORUTuhr6iAhkMr7I6T2O2F4=; h=References:In-Reply-To:Reply-To:From:Date:Subject:To:Cc; b=RPi3TVPUsFlTuyVynGAcBgu6YtiOvpNA2i0lxRnJNKgYpcRnTdLrGvxq+MpNPx9/0 JX5Q/WuQHu0lXJ0vo7ArW+m3RjrNDzfFLdcHKUmEaL8UDV2klhh2D/nTf7DvVTHvev thZG5AoJhtWSHJfczQ2o/a//P6i/314+NC+DbFhg= Received: from mail-ej1-f53.google.com ([209.85.218.53]:33433) by smtpauth2.mailarray.34sp.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1k1VuL-0003d3-8a; Fri, 31 Jul 2020 15:21:13 +0100 Received: by mail-ej1-f53.google.com with SMTP id kq25so18641911ejb.3; Fri, 31 Jul 2020 07:21:13 -0700 (PDT) X-Gm-Message-State: AOAM531k6CK8S6gcZCyz9qiex+eyNALrTgsovYesY884Bfi6Pfqn0sw3 uMdMagDUXWNyPB0uoC3kczp5zlprEdjmFcAv340= X-Google-Smtp-Source: ABdhPJwL/tHvPNTJSpahwM5eCAhwDrkhgFObGZn38h4C4PzQYaid1ZhJYIfpdQlRu/G60wD3vi3saT4wL8SKZVcePn0= X-Received: by 2002:a17:906:b046:: with SMTP id bj6mr4474979ejb.349.1596205272875; Fri, 31 Jul 2020 07:21:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Reply-To: research@bensmyth.com From: Ben Smyth Date: Fri, 31 Jul 2020 16:20:46 +0200 X-Gmail-Original-Message-ID: Message-ID: To: "Arnaud.Taddei.IETF" Cc: Jen Linkova , OPSEC , OpSec Chairs , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Authenticated-As: research@bensmyth.com X-OriginalSMTPIP: 209.85.218.53 X-34spcom-MailScanner-Information: Please contact the ISP for more information X-34spcom-MailScanner-ID: 966A62C1CCD.A4BC5 X-34spcom-MailScanner: Found to be clean X-34spcom-MailScanner-SpamCheck: not spam, SpamAssassin (score=-11.101, required 6.5, autolearn=disabled, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, SPF_PASS -0.00, X34SP_ALLOW_GMAIL_EVEN_IF_BLACKLISTED -10.00, X34SP_OVERRIDE -1.00) X-34spcom-MailScanner-From: research@bensmyth.com Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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, 31 Jul 2020 14:21:26 -0000 On Tue, 28 Jul 2020 at 10:35, Arnaud.Taddei.IETF wrote: > I strongly support this work as it represents capabilities that are being= developed, deployed and used in practice. It has good intentions and provi= des a good approach in the context of defense in depth approaches. No secur= ity cannot be just on both ends of the communication. One can dream about i= t but that is not how reality is. I appreciate that capabilities are being developed, deployed, and used. However, shouldn't a secure solution be sought? Surely secure solutions are just waiting to be discovered? From nobody Fri Jul 31 11:41:30 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 9DEE93A0CAB; Fri, 31 Jul 2020 11:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=LOo4N9Rb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WBb5Zsc/ 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 4_WPOJ8F_1-P; Fri, 31 Jul 2020 11:41:14 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA7A3A0CA8; Fri, 31 Jul 2020 11:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6271; q=dns/txt; s=iport; t=1596220874; x=1597430474; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eiS6tQr3kAs7zDW9wuJaLiyg70wBf6Jm+EUIBRFCBt0=; b=LOo4N9RbCcDyVlRYl1tU8cP+oijZWoJ2m6V3JWWai0UIuZ9R9zbZWur6 VEpT73WjOzuxDq2sG3kgyUno66JQFCNpKUTnULUFbGud/9MX7Zn5qJin6 Mof2m328i8/f82hZpQ+3oQIZM2QnjyWSPi1RaUt5aOFckZXT7WAKitmz4 g=; IronPort-PHdr: =?us-ascii?q?9a23=3AKyr4XxWZf83KIsEfw3LmYhGYDKTV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyHuf1BguvS9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7dp3Sz6XgZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHCgCuZCRf/4UNJK1gHQEBAQEJARI?= =?us-ascii?q?BBQUBggqBUlEHb1gvLAqEK4NGA40piiiJc4RsgUKBEQNVCwEBAQwBARgBCgo?= =?us-ascii?q?CBAEBhEwCF4IcAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgIEAQEQCwYdAQE?= =?us-ascii?q?sCwEPAgEIBAoxAwICAh8GCxQRAQEEAQ0FIoMEAYF+TQMuAQ6mUAKBOYhhdoE?= =?us-ascii?q?ygwEBAQWCSoJYDQuCDgMGgTiCcINfgQGBOYQFGoIAgTgMEIJNPoIaQgEBAoE?= =?us-ascii?q?oARIBIIMXM4ItknOGXZtwTgqCYJULhHkDHoJ7iUyTMJIjjRSOOYNWAgQCBAU?= =?us-ascii?q?CDgEBBYFqI2dwcBU7KgGCPj4SFwINjh+DcYUUhUJ0AjUCBgEHAQEDCXyPEgG?= =?us-ascii?q?BEAEB?= X-IronPort-AV: E=Sophos;i="5.75,419,1589241600"; d="scan'208,217";a="805966194" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Jul 2020 18:41:13 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 06VIfDkT011818 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 31 Jul 2020 18:41:13 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 31 Jul 2020 13:41:12 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 31 Jul 2020 13:41:12 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 31 Jul 2020 13:41:12 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RoZff3FX5vB4gL45zq9OgVz26V1tkr1aKUCbyOWklf34o97V74uuVBTyPqqgP1Un2LIcxK4/plgus120EFcSJ9NecePqXijzgja5bO77HrlPVJGnMenvx8r1HGa1AF/YObyJMP8LAjy6or67JOtTQTSFXsdx27JbBDlOt7HRGFpg4W2Ws2TE8aHgHuJ+aBne1Xup/dI8enpiVXxlbPGrdxH4d2r8wizITwelgknFTE0jTv69qeCS0pDJjfaJpzdiYK+B8BG1jZmz5zWEnpnxVX0q0lcjCYO1dB58/61owRrkD0S0KepvtRL/NI1BsOHYHi2V1tOxFhybakHWYDtC8g== 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=eiS6tQr3kAs7zDW9wuJaLiyg70wBf6Jm+EUIBRFCBt0=; b=WhfbG1qp5JgVdw8JUrHr+o9bQST1NNE/PNqvFbJKuNDMX15Q7en4k4KgXkkowk1DfRtDmK4kAlKVBv9u1PSk+sX1DfANcWtuOss3lLcUJju1c4+/OadXey77xTdLNRBOzVI34BdTu8Snv2ETwDNU+xe7/K40W2ACXnOo4huZIQvibx8l194DCGqVHAIq45Ilrt4tPiYuFMz1Gj6VeQdnDCsII6tOmnlUbsrWneLerg6SK0mPhVQSd/AMKyXIhZyBGQqQngt6sEkiy89bmHfBUiHdymwETFpf34FYkXYisgWrsBxx8QJcYuEK0J13NlFBSG9Il4jggvrc1zdXmYof9g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eiS6tQr3kAs7zDW9wuJaLiyg70wBf6Jm+EUIBRFCBt0=; b=WBb5Zsc/DftRUJap7np0VOr8TJamSCAgNLblnZ71ek1vZXs59GKo4mz4JtHHzIYUTKNTRmKcGPPGjuNWUpfkV2EOgWmzexibKpdr7hG3Xu5a5od1YT3Uco1e/ezURD69UllyrJN0N5AavuWlfoL/EqyRnUvZC/4EmwjLnQIreKo= Received: from BYAPR11MB2789.namprd11.prod.outlook.com (2603:10b6:a02:cc::11) by BYAPR11MB2789.namprd11.prod.outlook.com (2603:10b6:a02:cc::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.26; Fri, 31 Jul 2020 18:41:11 +0000 Received: from BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870]) by BYAPR11MB2789.namprd11.prod.outlook.com ([fe80::9913:ef92:7ce3:8870%6]) with mapi id 15.20.3216.033; Fri, 31 Jul 2020 18:41:11 +0000 From: "Eric Wang (ejwang)" To: Jen Linkova , OPSEC , "tls@ietf.org" CC: OpSec Chairs Thread-Topic: [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp Thread-Index: AdZd8qs4MVhjKcpfSaSC3eC5PK0rEQCniF8AAbZWrwA= Date: Fri, 31 Jul 2020 18:41:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.15) authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [128.107.241.168] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e9bd908a-6bf9-4594-2429-08d835814c02 x-ms-traffictypediagnostic: BYAPR11MB2789: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 90YhlUZxQY18Ea/p1GwleKOnNfvAgPc+bSSaATRMs7/wO8NazzNsZ5L7klSymqZol6IVqVOgy1TvWqYhPEDuCccEM8bAmT27aHESLPtzur9PKiINr5nCjTm5x4AyN/jj84Y059KOaDfYKpHq4X8aas8Ky0H+epe1K68c/ns7N/Kd4eHiDCA897DOqnkS94ND+1A1xyIVHenePVVlEn/2PjYBNQ2uMjiuDfxxDpKDwsbXBdj5laenqfLpW7i/RJJIVq2FvjrSlUkQwIWOKjTQ6bqgeZpYt2GAsXmHO8QiIaSewbfhhfUreCcjVclVkKvS5pC/VDOvaT5gGqqi3dXba1WfYgPBuHMQIoWayfbrA2DqgLR3d6L/rstg0ONrY7oKkTKEj+AT4gf+Rx+XdRax9Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2789.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(366004)(396003)(346002)(376002)(86362001)(2906002)(8936002)(8676002)(316002)(4326008)(33656002)(36756003)(71200400001)(110136005)(53546011)(91956017)(64756008)(6486002)(66946007)(66446008)(966005)(66556008)(5660300002)(26005)(186003)(6512007)(6506007)(2616005)(478600001)(76116006)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: CEWK1N0MtNFgBxgTBMN3ALq3Z7tIAW2Em4hxu55suXOkn+plsRD4kE/SlSNEtCpDSdQIYDSOuljc4IduWNeiBgnW55vftNrnkmaAEisJmVrDzVjaiwnpH8kdi3Acey/077/XmLKiGRCPkTNzpyWTqUKILvYMniPjka91D7ZXghs9Ae/dI6mlssGmpEzT5mVe1kWivcNJjBt2RVPlEcCagHRYSuuhpofoApgTVbCNfD0zek20xrsCafEBhTKthYSg4dMP93ktbA/rXGKE4CCb6gcAt7k/FPMpKXM0+dMOF5ndg6MiPa1/ooK4+E60H3oArbLDR/iSb0ZcHZ9BgM6oGl6q9akKW3zjEJ44+a3L7Y1QfXKNUfLQt1XcM+/DGwKNmXmAcZHxkvgCU2ya7b16QGkuFy1t8Tai9BSd9LqyMX7PUZ5LHChq2hR6RAOsAKAloY58mkWu8StrZq2ux8KUDgnrseSZWEJ139yOnesg2NtMZALJ/XkklTPItysplCSM Content-Type: multipart/alternative; boundary="_000_F1A69FD691364830811103C4C791C349ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2789.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e9bd908a-6bf9-4594-2429-08d835814c02 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2020 18:41:11.2798 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: H8uXINiMGYL/2Pf5YgaYPfSePrMOg8ZuTCK7Wn7zft8skhgk8SuHsjaKp6SsdPYQPseB7IylO2ksk3czUKZTLw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2789 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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, 31 Jul 2020 18:41:17 -0000 --_000_F1A69FD691364830811103C4C791C349ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgYXV0aG9ycyB3ZSBhcHByZWNpYXRlIGFsbCB0aGUgY29uc3RydWN0aXZlIGNvbW1lbnRzIG9u IHRoZSBkcmFmdC4gIEJhc2VkIG9uIHRoZSBmZWVkYmFjaywgd2Ugd2lsbCByZXZpc2UgdGhlIHNj b3BlIG9mIHRoZSBkb2N1bWVudCB0byBjb3ZlciDigJxwbGFpbuKAnSBUTFMgcHJveHkgb25seSAo cmVtb3Zpbmcg4oCcc2VsZWN0aXZlIHByb3h5aW5n4oCdKS4gIFdlIHdpbGwgY2lyY3VsYXRlIGEg bmV3IHJldmlzaW9uIHdoZW4gaXQgaXMgcmVhZHkuDQoNCkJlc3QsDQotRXJpYyAob24gYmVoYWxm IG9mIHRoZSBhdXRob3JzKQ0KDQoNCk9uIEp1bCAyMiwgMjAyMCwgYXQgNjozMCBQTSwgSmVuIExp bmtvdmEgPGZ1cnJ5MTNAZ21haWwuY29tPG1haWx0bzpmdXJyeTEzQGdtYWlsLmNvbT4+IHdyb3Rl Og0KDQpPbmUgdGhpbmcgdG8gYWRkIGhlcmU6IHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBoZWFy IGFjdGl2ZSBhbmQNCmV4cGxpY2l0IHN1cHBvcnQgb2YgdGhlIGFkb3B0aW9uLiBTbyBwbGVhc2Ug c3BlYWsgdXAgaWYgeW91IGJlbGlldmUNCnRoZSBkcmFmdCBpcyB1c2VmdWwgYW5kIHRoZSBXRyBz aGFsbCB3b3JrIG9uIGdldHRpbmcgaXQgcHVibGlzaGVkLg0KDQpPbiBNb24sIEp1bCAyMCwgMjAy MCBhdCAzOjM1IEFNIFJvbiBCb25pY2ENCjxyYm9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0 Zi5vcmc8bWFpbHRvOnJib25pY2E9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4+IHdyb3Rl Og0KDQpGb2xrcywNCg0KDQoNClRoaXMgZW1haWwgYmVnaW5zIGEgQ2FsbCBGb3IgQWRvcHRpb24g b24gZHJhZnQtd2FuZy1vcHNlYy10bHMtcHJveHktYnAuDQoNCg0KDQpQbGVhc2Ugc2VuZCBjb21t ZW50cyB0byBvcHNlY0BpZXRmLm9yZzxtYWlsdG86b3BzZWNAaWV0Zi5vcmc+IGJ5IEF1Z3VzdCAz LCAyMDIwLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0KDQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9u bHkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk9Q U0VDIG1haWxpbmcgbGlzdA0KT1BTRUNAaWV0Zi5vcmc8bWFpbHRvOk9QU0VDQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9vcHNlYw0KDQoNCg0KLS0NClNZ LCBKZW4gTGlua292YSBha2EgRnVycnkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCk9QU0VDIG1haWxpbmcgbGlzdA0KT1BTRUNAaWV0Zi5vcmc8bWFp bHRvOk9QU0VDQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9vcHNlYw0KDQo= --_000_F1A69FD691364830811103C4C791C349ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2D6367143A393149A06CF603357F1F54@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkFzIGF1dGhvcnMgd2UgYXBwcmVjaWF0ZSBhbGwg dGhlIGNvbnN0cnVjdGl2ZSBjb21tZW50cyBvbiB0aGUgZHJhZnQuICZuYnNwO0Jhc2VkIG9uIHRo ZSBmZWVkYmFjaywgd2Ugd2lsbCByZXZpc2UgdGhlIHNjb3BlIG9mIHRoZSBkb2N1bWVudCB0byBj b3ZlciDigJxwbGFpbuKAnSBUTFMgcHJveHkgb25seSAocmVtb3Zpbmcg4oCcc2VsZWN0aXZlIHBy b3h5aW5n4oCdKS4gJm5ic3A7V2Ugd2lsbCBjaXJjdWxhdGUgYSBuZXcgcmV2aXNpb24gd2hlbiBp dCBpcyByZWFkeS4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkJlc3QsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi1FcmljIChvbiBiZWhhbGYgb2YgdGhl IGF1dGhvcnMpPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pk9uIEp1bCAyMiwgMjAyMCwgYXQgNjozMCBQTSwgSmVuIExpbmtvdmEgJmx0OzxhIGhyZWY9Im1h aWx0bzpmdXJyeTEzQGdtYWlsLmNvbSIgY2xhc3M9IiI+ZnVycnkxM0BnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbmUgdGhpbmcgdG8gYWRkIGhlcmU6IHRoZSBj aGFpcnMgd291bGQgbGlrZSB0byBoZWFyIGFjdGl2ZSBhbmQ8YnIgY2xhc3M9IiI+DQpleHBsaWNp dCBzdXBwb3J0IG9mIHRoZSBhZG9wdGlvbi4gU28gcGxlYXNlIHNwZWFrIHVwIGlmIHlvdSBiZWxp ZXZlPGJyIGNsYXNzPSIiPg0KdGhlIGRyYWZ0IGlzIHVzZWZ1bCBhbmQgdGhlIFdHIHNoYWxsIHdv cmsgb24gZ2V0dGluZyBpdCBwdWJsaXNoZWQuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K T24gTW9uLCBKdWwgMjAsIDIwMjAgYXQgMzozNSBBTSBSb24gQm9uaWNhPGJyIGNsYXNzPSIiPg0K Jmx0OzxhIGhyZWY9Im1haWx0bzpyYm9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmci IGNsYXNzPSIiPnJib25pY2E9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdy b3RlOjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPjxiciBj bGFzcz0iIj4NCkZvbGtzLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NClRoaXMgZW1haWwgYmVnaW5zIGEgQ2FsbCBGb3IgQWRvcHRpb24g b24gZHJhZnQtd2FuZy1vcHNlYy10bHMtcHJveHktYnAuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUGxlYXNlIHNlbmQgY29tbWVudHMg dG8gPGEgaHJlZj0ibWFpbHRvOm9wc2VjQGlldGYub3JnIiBjbGFzcz0iIj5vcHNlY0BpZXRmLm9y ZzwvYT4gYnkgQXVndXN0IDMsIDIwMjAuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Um9uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seTxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyIGNsYXNzPSIiPg0KT1BTRUMgbWFpbGluZyBsaXN0PGJyIGNsYXNz PSIiPg0KPGEgaHJlZj0ibWFpbHRvOk9QU0VDQGlldGYub3JnIiBjbGFzcz0iIj5PUFNFQ0BpZXRm Lm9yZzwvYT48YnIgY2xhc3M9IiI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29wc2VjPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KLS08YnIgY2xhc3M9IiI+DQpTWSwgSmVuIExpbmtv dmEgYWthIEZ1cnJ5PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpPUFNFQyBtYWls aW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86T1BTRUNAaWV0Zi5vcmciIGNs YXNzPSIiPk9QU0VDQGlldGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vb3BzZWM8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_F1A69FD691364830811103C4C791C349ciscocom_-- From nobody Fri Jul 31 15:34: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 2DBB13A0D16; Fri, 31 Jul 2020 15:33:39 -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=unavailable 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 3_glIAKb5_0E; Fri, 31 Jul 2020 15:33:37 -0700 (PDT) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0: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 E61593A0D13; Fri, 31 Jul 2020 15:33:36 -0700 (PDT) Received: by mail-il1-x132.google.com with SMTP id s21so26604154ilk.5; Fri, 31 Jul 2020 15:33:36 -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=47WwRy0zeLRNZ1BaVjYBNGfI4tltszIIpLisbbXS9z8=; b=GZpmQoHckEM0vFV+1VrwmkgKgg7LCQhX//GwvIuYTIXdZwIncrBz68l3JmAiaDyLtn gFYu0QHBixI1nEZ82/LQCKMIZSBTY2BwW1BHS8iX50Ho/qPoT7j2j933jHDR9rjBy+Q8 d3vdB2yvjTPriUm52KJgnihGtGBmrHmNPflxofVpZ9o1ttSDQ3eD6/Umgvqn5RR9AhxS QlMbLC8dfWlpwAutOHGYH2YEbkPDU2nnFOVi0tKovVId3CCuSrEBy2Xtj5M7rJah0fR5 TpRjvyWBubyr4mwhBH6A1kLj3KHADPxtEkAI73rpPss6Z3fl7aXPQDeQv9ptapisRx1Q giDQ== 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=47WwRy0zeLRNZ1BaVjYBNGfI4tltszIIpLisbbXS9z8=; b=epkObeGCGeneNIr6VJcuhXo5l3+zlGMsOBwyGTNwVFA6VfHXGtD09XBJk4yt+eEAmz 7Uqtb7ldC5hL5p0Zbgg8kbUMRX03JUO2AooWTQQ7Sl/R8Nq1I2fF2VXSzEOEHqP7UtgE y94jZPWGQRPtt69xkEfCJhibLupZeB85QtQHRBv26COP0SBD6BHfqbhuKPjo9SeUDKci ij3Zr68LPrEJxuG5/lCoQEQyWbLoMm0KztObyL1D66DbqjWflD+z5EdeFJUtCaojho1B 4ee3K1p3bVz8ir3ONfHp3W5w6bJPXdMstWZDSNk1hXI8WvWI7G5nIuLrfdiGoIGkFldu ljWQ== X-Gm-Message-State: AOAM530EwV4XYFb7IvNU0yjNH9yIferdmKPxsKeYXlBqOuxrWnCzJ23G kNsbRavesoKamre+KhgvnA+l4vkRzlcZGpA2eYo= X-Google-Smtp-Source: ABdhPJwzCYyKEbA+mCroA/Yw2kPPkTNELP1IhyxEEAF47Db3fkXkt5AOcaaxL9jg94CT3J2myGQdTxtqahM8wAc5CWE= X-Received: by 2002:a92:858d:: with SMTP id f135mr5885751ilh.257.1596234816060; Fri, 31 Jul 2020 15:33:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Fri, 31 Jul 2020 15:33:23 -0700 Message-ID: To: "Eric Wang (ejwang)" Cc: Jen Linkova , OPSEC , "tls@ietf.org" , OpSec Chairs Content-Type: multipart/alternative; boundary="0000000000003080ef05abc46130" Archived-At: Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp 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, 31 Jul 2020 22:33:40 -0000 --0000000000003080ef05abc46130 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I think this WG is a bit zombie-like. Its most recent milestones are from 2013 [1]. I favor rejecting all active drafts (although I can see value in publishing them via the ISE), and closing this WG. thanks, Rob [1] https://datatracker.ietf.org/wg/opsec/about/ On Fri, Jul 31, 2020 at 11:41 AM Eric Wang (ejwang) wrote: > As authors we appreciate all the constructive comments on the draft. > Based on the feedback, we will revise the scope of the document to cover > =E2=80=9Cplain=E2=80=9D TLS proxy only (removing =E2=80=9Cselective proxy= ing=E2=80=9D). We will circulate > a new revision when it is ready. > > Best, > -Eric (on behalf of the authors) > > > On Jul 22, 2020, at 6:30 PM, Jen Linkova wrote: > > One thing to add here: the chairs would like to hear active and > explicit support of the adoption. So please speak up if you believe > the draft is useful and the WG shall work on getting it published. > > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica > wrote: > > > Folks, > > > > This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp. > > > > Please send comments to opsec@ietf.org by August 3, 2020. > > > > Ron > > > > > Juniper Business Use Only > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > > > > -- > SY, Jen Linkova aka Furry > > _______________________________________________ > OPSEC mailing list > OPSEC@ietf.org > https://www.ietf.org/mailman/listinfo/opsec > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000003080ef05abc46130 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I think this WG is a bit zombie-lik= e. Its most recent milestones are from 2013 [1].

I= favor rejecting all active drafts (although I can see value in publishing = them via the ISE), and closing this WG.


On Fri, Jul 31, 2020 at 11:41 AM Eric Wang (ejwang) <ejwang=3D40cisco.com@dmarc.ietf.org&g= t; wrote:
As authors we appreciate all the constructive comments on the draft.=C2=A0 = Based on the feedback, we will revise the scope of the document to cover = =E2=80=9Cplain=E2=80=9D TLS proxy only (removing =E2=80=9Cselective proxyin= g=E2=80=9D).=C2=A0 We will circulate a new revision when it is ready.

Best,
-Eric (on behalf of the authors)


On Jul 22, 2020, at 6:30 PM, Jen Linkova <furry13@gmail.com> wrote:

One thing to add here: the chairs would like to hear active and
explicit support of the adoption. So please speak up if you believe
the draft is useful and the WG shall work on getting it published.

On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
<rbonica=3D40juniper.net@dmarc.ietf.org> wrote:

Folks,



This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp.



Please send comments to opsec@ietf.org by August 3, 2020.



=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=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= =A0Ron




Juniper Business Use Only

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/opsec



--
SY, Jen Linkova aka Furry

_______________________________________________
OPSEC mailing list
OPSEC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/opsec

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000003080ef05abc46130-- From nobody Fri Jul 31 17:55: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 7B6E03A0E0B for ; Fri, 31 Jul 2020 17:55:12 -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 iyr8o_OamOno for ; Fri, 31 Jul 2020 17:55:09 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 6CDAF3A0D54 for ; Fri, 31 Jul 2020 17:55:09 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id l64so23741085qkb.8 for ; Fri, 31 Jul 2020 17:55:09 -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=Rvek5u+38GPX7OY5GwDWUD8r35UeXF7cHlBqbxkg/CM=; b=J0nmfBi6a6cYknp0iZ6ztZhVqX5K4CVUe0U/mQkqR8tMAE72t2ZJy82Z9Ig1xWm2sg VYfBh/NTisHl7Lks2UUbGYVoutNRLYbpNEiAcrCFgUqzrRTsQSZ3Wc1oGVz3PCfTl5qJ 9bbJQELdUKcIVgrjOKjDzY5tPo6EpU+EW2hxM= 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=Rvek5u+38GPX7OY5GwDWUD8r35UeXF7cHlBqbxkg/CM=; b=YnccSNiN9HxPSIu1wpvgI+0Ly1iFNTKwn/KChIBVrS+caurftEbw2uarjvzBOVHUr0 7xs6UNF5E2q4xgwh73Yg+9NxU2wpI084EZminrlU3F24P0nzxvUN6mzJfs8n9V+E5n+G /zf3ciZCzvZIPwMQeCvz9ZehBKgsBRKMveLuFaGkY2goOPJirJgN6NNq3r+MY61OG+K3 5c5Q11N6EKAucoInQpqUqQWnn55LSrvL8r8B8Brsx/qGg7rxZ0dCCfsPj0tMx5ONpZyu vA3yRE1Rc3xTwhA4w4xVnLhnAmhQlGWssMEf8cjwxuV+LApmrzZAUPsN6UoeUnv6O6Yn d5Fw== X-Gm-Message-State: AOAM5338suPE0dfZd4zSZai0ysDC6+aImSNoIeQNDKMF3us5G+GzfDOk IL0ANga9BoLNVZy7W+5SHVdyZb9sXIo= X-Google-Smtp-Source: ABdhPJygX1mSruonq26mjHz5DxnTPpM6YRNjNrQRc6ON5IHLZ2NxSFU1OnEGN3WtqDRHZ0eeHEqKCQ== X-Received: by 2002:a37:68c1:: with SMTP id d184mr6627912qkc.62.1596243307729; Fri, 31 Jul 2020 17:55:07 -0700 (PDT) Received: from [192.168.1.152] (pool-108-31-39-252.washdc.fios.verizon.net. [108.31.39.252]) by smtp.gmail.com with ESMTPSA id 205sm10648071qkn.104.2020.07.31.17.55.06 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 31 Jul 2020 17:55:06 -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.120.23.2.1\)) Date: Fri, 31 Jul 2020 20:55:05 -0400 References: <0A9203D5-C4F3-4AA8-B59E-7D63E4650B3B@sn3rd.com> To: TLS List In-Reply-To: <0A9203D5-C4F3-4AA8-B59E-7D63E4650B3B@sn3rd.com> Message-Id: <18D1075E-8BD1-4080-A41E-B5B1805A7A30@sn3rd.com> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc 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, 01 Aug 2020 00:55:13 -0000 Just a reminder that this WG adoption call is still ongoing. spt > On Jul 22, 2020, at 14:55, Sean Turner wrote: >=20 > Hi! >=20 > The authors of "Return Routability Check for DTLS 1.2 and DTLS 1.3" = have asked for adoption of their draft as a WG item. Please state = whether you support adoption of this draft as a WG item by posting a = message to the TLS list by 2359 UTC 06 August 2020. Please include any = additional information that is helpful in understanding your position. >=20 > NOTE: > We discussed this draft at IETF 105 in connection with = draft-ietf-tls-dtls-connection-id [0]. The plan at the time was to = progress draft-tschofenig-tls-dtls-rrc after we progressed = draft-ietf-tls-dtls-connection-id. That time is now. >=20 > Thanks, > Chris, Joe, and Sean >=20 > [0] = https://datatracker.ietf.org/meeting/105/materials/slides-105-tls-sessb-ci= d-00